Running out of space on your VMWare Server? Try this to convert some of your larger preallocated disks to growable. This way they only consume the space on the disk that they currently need, and will not consume disk space on the host drive for disk space on the guest systems whic is in fact empty and unused.
Stop the VM, then:
vmware-vdiskmanager -r GuestVM.vmdk -t 0 NewGuestVM.vmdk
This will create a new, growable, copy of the original drive. Then you will need to point the VM at the new drive (or delete the original and rename the new one back to the same name as the old).
I assume there is a performance penalty for doing this. But if you are running out of space, this can at least buy you some time.
While you are messing around on the command line, you could use the following to defrag the VMDK file for better perfomance.
vmware-vdiskmanager -d Guest.vmdk
This is a known bug inherited from RedHat.
http://rhn.redhat.com/errata/RHSA-2009-0225.html
Workaround is to add
scsi0.virtualDev = "lsilogic"
to the .vmx file before installation.
dd if=/dev/cdrom of=your_image.iso
Ensure the mount point /mnt/cdrom exists.
To perform the mount:
mount -t auto /dev/cdrom /mnt/cdrom
If the symbolic link /dev/cdrom is not there, then try:
mount -t auto /dev/hdb /mnt/cdrom
replacing hdb with whatever your device is called.
With CentOS 5.2 (as ever), use the following to enable a listening tcp port (in this case 8000) to be accessed through the firewall.
sudo /sbin/iptables -A INPUT -p tcp -d 8000 -j ACCEPT
sudo /sbin/service iptables save
sudo /sbin/iptables -F
The instructions for retrofitting Terminal server to Windows Vista Home are here. This enables Remote Desktop to that machine.
The instructions for retrofitting Terminal server to Windows XP Home are here. This enables Remote Desktop to that machine.
I have never really found a good way to diagnose HDD performance problems under any version of Windows, especially not Vista. I did, however, recently find this cool util which is a useful tool to keep at hand. Simple install, intuitive GUI and it just works (as admin under Vista). HD Tune
The best way to make sure servers have the correct time set on their system clock, is to use NTP to synchronize the clock to an external time source. I always use pool.ntp.org as the external source, as this represents a pool of servers who are willing to provide the service. All sorts of things can go wrong if you do not keep clocks set accurately - especially security stuff where ticket and certificate validity periods get checked automatically. I set this up on my CentOS box as follows (as root).
To check the client was installed: yum list ntp
It was: ntp.i386 4.2.2p1-8.el5.centos.1 installed
If it had not been, I would have used: yum install ntp
To get the client started on system start: chkconfig ntpd on
To force a sync of the clock to NTP now: ntpdate pool.ntp.org
To start the service as if the system had been powered on: /etc/init.d/ntpd start
I wanted to find out if my CPU was 64 bit capable. It was a few years old, so probably not, but I figured I should be able to get linux to tell me without having to lookup the hardware spec of the box and then check the Intel website.
First I checked the cpuinfo data that linux provides (in this case, my trusty CentOS 5.2 installation):
[andy@vm rpm]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 9
cpu MHz : 2386.429
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts cpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4775.09
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
stepping : 9
cpu MHz : 2386.429
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts cpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4772.09
Interesting, but no smoking 64 bit gun.
I then found a utility called CPUID which seemed to report much more interesting data.
First fetch the rpm: wget http://www.etallen.com/cpuid/cpuid-20060917-1.i386.rpm
Then install it: sudo yum --nogpgcheck localinstall cpuid-20060917-1.i386.rpm
At this point, yum whimpered with
Existing lock /var/run/yum.pid: another copy is running as pid xxxx
Another app is currently holding the yum lock; waiting for it to exit...
Another app is currently holding the yum lock; waiting for it to exit...
I checked around to see who was holding the lock, but i seems it was just a left over from some prior operation. So as root, I deleted the file /var/run/yum.pid and tried the install again.
This time it worked fine and I was then able to run CPUID:
CPU:
vendor_id = "GenuineIntel"
version information (1/eax):
processor type = primary processor (0)
family = Intel Pentium 4/Pentium D/Pentium Extreme Edition/Celeron/Xeon/Xeon MP/Itanium2, AMD Athlon 64/Athlon XP-M/Opteron/Sempron/Turion (15)
model = 0x2 (2)
stepping id = 0x9 (9)
extended family = 0x0 (0)
extended model = 0x0 (0)
(simple synth) = Intel Pentium 4 (Northwood D1) / Xeon (Prestonia D1) / Mobile Pentium 4 (Northwood D1) / Mobile Pentium 4 Processor-M (Northwood D1) / Celeron 478-pin, .13um
miscellaneous (1/ebx):
process local APIC physical ID = 0x1 (1)
cpu count = 0x2 (2)
CLFLUSH line size = 0x8 (8)
brand index = 0xb (11)
brand id = 0x0b (11): Intel Xeon, .13um
feature information (1/edx):
x87 FPU on chip = true
virtual-8086 mode enhancement = true
debugging extensions = true
page size extensions = true
time stamp counter = true
RDMSR and WRMSR support = true
physical address extensions = true
machine check exception = true
CMPXCHG8B inst. = true
APIC on chip = true
SYSENTER and SYSEXIT = true
memory type range registers = true
PTE global bit = true
machine check architecture = true
conditional move/compare instruction = true
page attribute table = true
page size extension = true
processor serial number = false
CLFLUSH instruction = true
debug store = true
thermal monitor and clock ctrl = true
MMX Technology = true
FXSAVE/FXRSTOR = true
SSE extensions = true
SSE2 extensions = true
self snoop = true
hyper-threading / multi-core supported = true
therm. monitor = true
IA64 = false
pending break event = true
feature information (1/ecx):
PNI/SSE3: Prescott New Instructions = false
MONITOR/MWAIT = false
CPL-qualified debug store = false
VMX: virtual machine extensions = false
Enhanced Intel SpeedStep Technology = false
thermal monitor 2 = false
context ID: adaptive or shared L1 data = true
cmpxchg16b available = false
xTPR disable = true
cache and TLB information (2):
0x50: instruction TLB: 4K & 2M/4M pages, 64 entries
0x5b: data TLB: 4K & 4M pages, 64 entries
0x66: L1 data cache: 8K, 4-way, 64 byte lines
0x40: No L3 cache
0x70: Trace cache: 12K-uop, 8-way
0x7b: L2 cache: 512K, 8-way, sectored, 64 byte lines
extended feature flags (0x80000001/edx):
SYSCALL and SYSRET instructions = false
execution disable = false
64-bit extensions technology available = false
Intel feature flags (0x80000001/ecx):
LAHF/SAHF supported in 64-bit mode = false
brand = " Intel(R) Xeon(TM) CPU 2.40GHz"
(multi-processing synth): hyper-threaded (t=2)
(synth) = Intel Xeon (Prestonia D1), .13um
And so I had my answer: 64-bit extensions technology available = false
