Shrinking a Linux VM in VMware Workstation

I do a fair bit of messing around with Linux in VMware Workstation on Windows.  This tends to make the underlying VMDK increase rapidly in size, and the ‘Compact’ feature doesn’t work in the current version of Workstation.

Here’s how to fix this.  You will need enough free space to hold the fully inflated VMDK twice.

In the VM, fill up the disk with a big file full of zeroes (I assume here you have slightly more than 10GB of disk space free);

dd if=/dev/zero of=/fillit bs=1M count=10240

Don’t completely fill the disk!  You just want to fill it enough that you’ll get some benefit from the compact.  Get rid of the file afterwards.

Next, go and download the VDDK from VMware.  Get a recent one, from the same (or newer) release of vSphere that corresponds to your Workstation install.  Extract it somewhere.

Now, find your VMDK.  You should find a single .vmdk followed by a whole bunch of -sNNN.vmdk files.  You want the head VMDK, it’ll be a small file.

Power off the VM, and discard any snapshots you may have of it!

First up, defragment the VMDK;

C:\vddk\bin\vmware-vdiskmanager -d VMNAME.vmdk

Then, shrink it.

C:\vddk\bin\vmware-vdiskmanager -s VMNAME.vmdk

Done.  Your VMs should now consume a lot less space on disk!

NOTE:  This won’t work if you’re encrypting the VMDK with dmcrypt or something, because the underlying sectors will just get random gibberish in them and you can’t shrink that.  Regretfully, TRIM support doesn’t work for Linux VMs in VMware because the SCSI emulation isn’t the right version.

Ubuntu VM AutoResize with 15.10

Installed Ubuntu in a VMware Workstation 12 VM, and can’t get desktop autosize working with open-vm-tools?  Here’s how to fix it.

Make sure you have the open-vm-tools-desktop package installed;

sudo apt-get install open-vm-tools-desktop

Edit /etc/xdg/autostart/vmware-user.desktop and add the following line at the bottom;

X-Gnome-autostart-enabled=1

Restart, and then make sure that under the View tab you have Autofit Guest enabled.  Should do the trick.

VCP-510 (now VCP5-DCV) passed!

Been spending the past week cramming as much information into my head as possible in order to get my VCP5 certification.  I already hold a VCP in VI3 (pretty outdated now), and I did the vSphere 4: What’s New course, which would have qualified me for the VCP4, but I never sat the exam!

As such, when vSphere 5 came out, I didn’t qualify to be able to do the VCP5 through only doing the What’s New course and had to do the full course to qualify.  I did that, and then put off doing the exam for a while.  Anyway, the free exam voucher I had was expiring soon, so I went and sat the exam, and passed – by a comfortable margin.

I can recommend the VCP5 Study Guide by Brian Atkinson for this.  On the whole, this guide was pretty good, but it does cover some stuff you don’t need for the exam.  Notably, since the release of 5.1, VMware will only test you for things that are common between 5.0 and 5.1, so you will not be asked any questions where the answer will have changed between the two versions.  This cuts out many of the configuration maximum and licensing type questions straight away.

The most important bit of advice I can really give is to read each question very carefully, and read the possible answers even more carefully.  Go through and select the answers you think are right, then go through in the review and cross off the answers you know are wrong.  VMware seems to love trying to trip you up on grammar, little technicalities and other minor things.  Things like remembering the maximum size of a VMDK in VMFS-5 is 512 bytes short of 2TB, not 2TB exactly.  Be careful with that sort of technicality, they love it.

Next up, study for XenServer, XenDesktop and XenApp.  Phew.

Fixing W32Time in a Guest OS

NOTE: For informative purposes only. I take no responsibility at all for any harm that may result to your environment as a consequence of this information. Use at your own risk, and research appropriately!

Sometimes you must run W32Time on a guest OS, but it’s not a good idea to run it at the same time as using VMWare Tools time synchronization. A good example of this is a domain controller – it must have W32Time running, must have accurate time, and must supply time to member servers.

First, a note. Don’t just go and point your PDC at some dummy NTP source that doesn’t exist. If you do that, after some period W32Time will just shut down and stop serving time. Instead, we need to find a way to get W32Time and VMWare Tools to co-exist peacefully.

The solution is to set W32Time so it only tries to slew the clock very occasionally, so the adjustments made by VMWare Tools dominate the clock and keep it in sync. Since W32Time is still in contact with a valid time source, it doesn’t commit seppuku.

You can do this by changing this registry key to “Weekly”. Data type is REG_SZ, if you need to create it;

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Period

Restart the W32Time service when you do that, and then all should be well. Oh yeah, and after giving it a little while to settle down, don’t forget to check your event viewer, and do a;

w32tm /stripchart /computer:ANOTHER_DC

to check that your machine is still in sync with the rest of your domain.

VMWare & the System Clock

The system clock behaves … strangely … under VMWare in a guest OS. It tends to run slow, and the amount by which it runs slow varies wildly from day to day. Without a fixed time synchronization source, guests will quickly fall out of synchronization and time-critical mechanisms such as Kerberos will break.

This happens because the guest OS assumes that there is a constant period of time between instructions – ie, it has all of the processor’s attention. The system clock is a high-precision clock maintained by this fact. When you put a guest OS into a virtual environment this goes out the window – the guest no longer has a consistent period of time between instructions, in general this time is longer than expected. Therefore means that individual ticks of the system clock take longer than the fixed (outside) time periods they should, and the system clock runs slow.

So, how do we stop this? Well, one solution is to use a guest-internal NTP client such as W32Time. This is a very bad idea. NTP clients adjust the system clock by slewing (speeding up or slowing down) the clock progressively so they can converge the system clock with NTP time. Since the system clock is running at an unpredictable rate, slewing the clock is a recipe for disaster – it causes the clock to swing to and fro and never stabilize. An unstable clock can cause very strange things to happen.

We could also just keep setting the time as we need to. This is also a very bad idea. Modern OSes rely on the continuity of time. If you just keep resetting the clock, the system ‘loses time’, and tasks that were supposed to run in the lost time just don’t happen.

The solution is to let VMWare Tools handle the problem, and check the box that lets it synchronize with the host. When you do this, VMWare Tools slews the clock appropriately so it doesn’t break anything, and your time converges as you’d expect. When you do this, you must turn off any other kind of time sync software such as W32Time, otherwise they will fight over the clock and much havoc will ensue.

There are certain times when you must run an NTP time server such as W32Time (such as on a domain controller). How you go about preventing W32Time and VMWare Tools fighting is an issue for another post.

NTP Time Synchronization in VI3

Time synchronization is of critical importance in a VMWare infrastructure. If it goes wrong, all hell breaks loose, especially in a Windows 200x environment using Kerberos.

Due to how system clocks work in VMWare, this means that you need to use VMWare Tools’ sync capability to keep your VMs right on time. This means that all your hosts need to be properly synchronized.

So, how do you do this? If you’re using any fancy deployment solution like Altiris, disable time synchronization in it. Why? Because if you don’t, you’ll forget six months down the track, virtualize your deployment solution, and then wonder why all your clocks go crazy.

Read this article and implement it. That’ll get your NTP daemon sorted out, but that’s not quite enough. You need to get your machine’s system clock and hardware clock in sync before NTP can slew the clock and keep it synchronized.

In order to do that, get into a console on your VI3 server, and do the following (I assume that firewall.contoso.com is one of your NTP sources, change to suit);

service ntpd stop
ntpdate firewall.contoso.com
hwclock –systohc
service ntpd start
watch “ntpq -p”

That will configure your system and hardware clocks to be close to the NTP source you named, and then start a watch process showing you the state of your NTP peers.

After a while, you should see an asterisk appear next to one of the peers (not LOCAL, that’s your host’s internal clock). When that happens, you’re all good.