- casino online slots

vmWare personality footprint too big

by Administrator on June 17, 2007

In DC, then again in Kansas City, attendees of the seminars where I was speaking about data protection voiced their views of vmWare, that gotta-have-it server virtualization technology currently hawked by EMC.  All in all, reviews were very positive.  Everybody likes the idea of loading and unloading a server personality on the fly.  However, several attendees wanted answers to a hard question.

They complained that the personality file created by vmWare was simply too fat to move efficiently over a WAN link for disaster recovery-oriented replication.  They wanted to know whether plans were afoot to skinny down the image file so it could be used more effectively in a remote disaster recovery scenario in which the backup site was distant from the primary site (aka, more than 50 miles).

I should think that one of the many de-duplicators or block change CDP guys would have a fix for this.  Anyone?  Anyone?

{ 1 comment… read it below or add one }

Pq65 June 17, 2007 at 7:55 pm

Indeed. Outside of backup/archiving, VMware is THE place for dedup given the block redundancy that exists among the many VMs, typically Windows, on an ESX server.

Played with it a little by turning on dedup on a netapp box with 4x 20GB VMs. When it was all said and done, I ended up with ~4.2GB of used space. Mind you this is an extreme example because my VMs were identical and didn’t have any app data, however deduping the OS alone is pretty substantial.

By default, vmdk space is pre-allocated even if it’s not used. If I create a 20GB vmdk and write 4GB, I will be backing up/copying 20GB. Another solution would to create “thin” as in thin provisioned vmdks and allocate during writes. This can be done in a safe way where you do not thin provisioning the VMFS (just the VMDK).

Previous post:

Next post: