Archive for the ‘vmware’ Category

VMWare ESX Thin Provisioned Disks And Credit Cards…….

Friday, March 11th, 2011

In my youth, I was offered credit cards. I thought they were great, allowing me lots of instant retail gratification, I was on cloud 9 on the high street…….then I had to repay them. My cloud evaporated and I came back down to earth with a bump right on my wallet !

The principal behind thinly provisioned disks on VMWare ESX storage LUNs would appear to be along the same lines as that of credit cards. Utilising more than you actually have at your disposal.

With credit cards the impact is that later down the line you have to repay the money you spent that you don’t actually have (ouch !). With thinly provisioned disks the pain is that of not being able to reclaim free disk space without a lot of work.

With normal *fat* disk allocation when you create a volume all the space is allocated at creation time. So if you have a 100GB storage LUN and you create a 50GB volume on it, that 50GB is immediately deducted from the 100GB, leaving you with only 50GB free space on the storage LUN.

But with thin provisioned disks, if you allocate a 50GB *thin* volume, the space is only deducted from the storage LUN as it gets used. So if you only write 20GB of files to the 50GB thin volume, the storage LUN will report 80GB of free space out of the total 100GB.

But here’s the kicker, if you then delete 10GB of those files, the free space remains at only 80GB, the space does not get returned back to the storage LUN. This is because Windows/Linux does not actually delete files, it simply marks those blocks as being avilable for use in the file table. As the blocks do not actually get cleared, VMWare does not pick up on this and remains ignorant to the free’d up filespace.

In order to shrink the disk and reclaim the space, you have to actually clear the physical blocks so that they are actually empty. You can do this using the free tool Sdelete from Sysinternals. You use the -c switch (which tells it to zero out the blocks). This is a rather I/O demanding task best done out of peak useage hours.

Once sdelete has completed you will need to migrate the VM files to another datastore for VMWare to re-read the free blocks and give back the cleared up space. You may then have to re-migrate the VM files back to where you actually want them to run from if your fussy about the location of your VM’s on your datastores.

I’m not saying thin disk provisioning has no place, it’s great for R&D, labs and proof of concept type setups where you will be setting up and ripping down and don’t really care too much about long term storage levels. But for production systems, the administration overhead is just too great for my liking.

disk squish

VMWare ESXi 4.1 CLI VM Does Not Start…….

Thursday, January 6th, 2011

So for some odd reason, my VCentre VM had stopped/died/crashed or, possibly been shutdown by someone. For whatever reason, I could not logon to my VCentre instance using my vSphere client.

For some reason it did not occur to me to just attached my vSphere client directly to one of my ESX hosts. Instead I had this minor learning curve.

The command line to start a VM is

vim-cmd vmsvc/power.on <Vmid>

where is a integer that identifies a VM in/on your infrastructure. To obtain your Vmid’s, you need to list your VM’s on your ESX host with

vim-cmd vmsvc/getallvms

While several VM’s were listed, the VM for my vCentre instance was not among those shown. So I had to find the .vmx config file to add to my host config. My VMWare setup uses iSCSI paths that map to /vmfs/volumes and in here I eventually found my way to

ls /vmfs/volumes/4ce64694-5ae4e508-917e-001b216c49dd/VCenter4.1/

In this directory was the .vmx config file along with all the other files that make up a virtual machine instance. I needed to add this VM to my host config (this is a lttle like when you add a VM to the inventory in the vSphere client !). The command to do this was

vim-cmd solo/registervm <full path to the .vmx file>

Now that my Vm had been added to my ESX host VM list, repeating

vim-cmd vmsvc/getallvms

now showed

Now I had the Vmid number with with to use the command line to powr on the VM.

vim-cmd vmsvc/power.on <Vmid>

This should have been enough to get my vCenter VM up and running. But, 10 mins later, when I tried to ping the IP address of the VM, I still could not contact it ? I decided to have a look at any queued command to the VM with

vim-cmd /vmsvc/get.tasklist <Vmid>

but this simply listed the command to power on. I tried sending a reset VM command with

vim-cmd /vmsvc/power.reset <Vmid>

but this command just got stacked under the existing command to power on the VM ? At this point it dawned on me that I could start the vSphere client up and attache directly to the ESX host IP address instead of the vCenter Ip address. When I did this, I saw the all to familiar little exclamtion mark on the vCenter VM icon.

pesky gui question

When I right-clicked the icon and selected ‘Open Console’, this popped up the ‘Did you move/copy this VM’ dialog box shown above !

Grrrrrrrr. Reading up I cannot see any way to :-

a) Determine if one of these has been fired
b) Respond to it if this is the case

from the VMWare command line. Most annoying, but it did give me a crash course in ESXi command line :o)

Correct ESX NTP Time Periodically

Friday, May 14th, 2010

Just had an odd one. Everytime I rebooted any one of my Windows VM’s, when it came back up the clock would be out by a varying amount.

VM’s on the same physical host would be out by identical amounts, but Vm’s on different physical hosts would be out by different amounts.

The physical VM host servers are all running NTPd, and are configured to sync to the pool.ntp.org server lists, so I thought this was all sorted, seems I was wrong.

Each physical box, even though it was syncing with NTP peers in the outside world, was experiencing varying degrees of skew on the clock. The amount was up to 20mins across all the physical nodes.

To correct this, I have created a cron job on each server with the following entry

0 9 * * * /usr/sbin/ntpdate -s -b -p 4 -u 0.pool.ntp.org

Now the server will correct the clock skew once each day at 9am, and hopefully now I can forget all about this :-?