The Last Octet

I've never liked the disconnect between power management (DPM) and some of the other features built into vSphere 4. One of the more aggravating situations occurs when a host hosting templates and powered down VM's goes into standby. When this occurs you lose the ability to deploy servers from your templatized VM's. The same situation occurs with VM's that are powered off. They become a hostage on the suspended host.

I've come up with a simple workaround. Since templates and powered down VM's aren't consuming any host resources you can usually be assured that they are going to stay were you put them. In other words, they aren't going to drift around as DRS does its job. With this in mind, I've excluded one host from participating in DPM while keeping the remainder active. You can do this by:

Right clicking on your cluster -> Edit Settings... -> VMware DRS -> Power Management -> Host Options

Select the host that you want to keep running (that will house your powered off VM's and templates) and click the "Power Management" column for that host. Select Disable and click OK. If you have DPM configured for automatic, the remaining hosts should still reflect the "Default (Automatic)" setting under the "Power Management column". The last step is to migrate your powered down VM's and templates to the DPM disabled host.

With this done, you should now be able to reliably deploy VM's from templates and continue to allow DPM manage the power status of the remaining hosts.

In an update of a previous post (vSphere Client on Linux) I was having trouble getting tsclient to except custom resolutions so I rewrote the launcher to execute the following:

rdesktop -u bfitzhugh -p -n virtualcenter.hostname.local -g 1680x995 -s 'c:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe' -D

Launching the vSphere client using the rdesktop statement above allows me tweak the resolution to just the right dimensions and be able to maintain my top and bottom panels.

In my last post I ran a little test where I copied a few ISO's over to the test server to see how the deduplication process worked on ZFS. I've continued that testing, and copied a few virtual machines up to the same lab server. To make things a bit more interesting I've enabled ZFS compression as well.

Let's take a look at the data we're working with:

VMware VMDK's

• Virtual Machine 1 has a single disk that is about 12GB
• Virtual Machine 2 has a single disk that is about 10GB

Virtual Box Hard Disks

• 10GB of Virtual Box hard disk's

So the plan is to create folders 1-4. Folders 1 and 2 will hold duplicate copies of the VMware VMDK files, and folders 3 and 4 will hold duplicate copies of the Virtual Box hard disk files. The the raw uncompressed undedup'ed data total should be about 64GB. Let's look at the before and after upload results:

Before Upload

• zpool list rpool
  NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
  rpool   696G  7.78G   688G     1%  1.02x  ONLINE  -

• zfs get compressratio rpool/data
  NAME        PROPERTY       VALUE  SOURCE
  rpool/data  compressratio  1.0x  -

After Upload

• zpool list rpool
  NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
  rpool   696G  13.6G   682G     1%  2.07x  ONLINE  -

• zfs get compressratio rpool/data
  NAME        PROPERTY       VALUE  SOURCE
  rpool/data  compressratio  1.71x  -

If we take a look further we can see that df reports about 17GB of disk space used:

df -h
Filesystem            Size  Used Avail Use% Mounted on
rpool/data            686G   17G  670G   3% /rpool/data

If we contrast the zpool list results it appears that our 64GB of data has consumed about 6GB of actual disk space. Not bad.

Although this setup warrants further testing (and inclusion in a supported OpenSolaris release), these results should give us a bit of insight into how ZFS dedup and compression will handle our data when we use it as a backup target for our virtualized data.

Here's a quick look at the dedup results on the test box I built a week back. While this isn't a detailed test, you can see ZFS dedup in action.

1. Base File System

   NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
   rpool   696G  5.59G   690G     0%  1.00x  ONLINE  -

2. Result After Copying Up the OpenSolaris 2009.06 ISO

   NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
   rpool   696G  6.23G   690G     0%  1.00x  ONLINE  -

3. Result After Copying Up a 2nd OpenSolaris 2009.06 ISO

   NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
   rpool   696G  6.23G   690G     0%  1.92x  ONLINE  -

4. Result After Copying Up the OpenSolaris Build131 ISO

   NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
   rpool   696G  6.84G   689G     0%  1.50x  ONLINE  -

5. Result After Copying Up the a 2nd OpenSolaris Build131 ISO

   NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
   rpool   696G  6.89G   689G     0%  2.00x  ONLINE  -

So in summary, I wrote about 2.6 GB of data to the pool and only consumed about 1GB of free space. Not bad, though it should be a bit more interesting when we start loading the box up with VMDK files.

Need to do a one time or scripted zip of a specific set of files? Here's how i did it with my dated folder structure.

Folder structure example:

20091213
20091214
20091215


What I did to compress these folders:

find . -name "200912*" -print| zip -r 2009-12 -@

The find section can be adjusted to print out a specific path. My example grabs the December files in my current folder. The zip section just takes the STDOUT of the find section and recursively compresses the folders and contents into 2009-12.zip.