I really don’t get this whole “storage is cheap” stuff. Storage to stick in the back of your PC is cheap but server storage is far from cheap. The cost of a 146GB disk may be a fraction of what it was 5 years ago but we need to use a heck of a lot more to do the same stuff now as we did back then, e.g. look at the size of a Windows boot drive now. Someone has to pay for this, e.g. an ever decreasing IT budget (IT is a non-profit generating cost centre which isn’t so popular these days) or a customer (either internal or external) has to pay for it and we all know that customers don’t want to pay for something they don’t directly use, e.g. a VMM library. Then ask yourself, why would you fill that library LUN with files that are 75% empty?
If you’ve been using VMware ESX then you know how efficient it is when it comes to storing template machines. Unfortunately, VMM 2008 isn’t that intelligent. I tried to have this conversation with one of the folks at TechEd but because of MS’s tendency to rename every industry accepted term he hadn’t a clue at what I was trying to say.
So here it is in VMware (sort of) lingo and then I’ll translate. In Virtual Center, you can sysprep a machine (either via the GUI which I do not recommend because sysprep is both OS and service pack specific which VC cannot handle) or manually (which I do recommend). When I covert that VM into a template it’s removed from the production VMFS LUN and placed into the library. Part of this (if I remember correctly – it’s been a while) was that the disk is stored as a dynamically expanding disk instead of a fixed size one. Why store 40GB of mostly empty virtual disk when you can store 8GB? Imagine having lots of templates that you need to manage. You could have a library that’s TB upon TB of wasted space. When you deploy the template, the virtual disk is converted back to fixed size on the VMFS LUN.
So I asked about taking a template machine in VMM and doing the same. Straight away said person got confused because MS decided template would refer to the simple file that describes the VM configuration and nothing else. The conversation beyond that point could go nowhere. So here’s what would be great. Take a VM and sysprep it down. The library storage process would take the VHD on the Hyper-V host and if it’s fixed it would convert (without an unnecessary copy taking up space) over the wire to a dynamically expanding VHD in the library. A deployment of that VHD would ask if you want a fixed or dynamic disk. If it’s fixed then the VHD would be converted, again over the wire without a wasteful copy, and a new fixed size VHD would appear in the destination LUN on the Hyper-V host.
Here’s What I Do
That’s not there now so I’m doing something slightly more manual. I build a template (yeah I said “template” cos that’s what it is; Ask any OS deployment person) using a dynamically expanding VHD on my development host. I then copy it into my library which is a compressed folder. Sure it’s a slight bit slower but it’s worth the saved space. For a VM deployment I deploy a VMM template (ICK – the machine configuration kind) to the Hyper-V host’s LUN for that VM. I log into the host and then fire up the Hyper-V console. Using the disk editor I browse to the VMM library and convert that disk to a fixed type whose location is the VM’s LUN.
That manual process does everything that I’d like MS be able to do with VMM. It might take me about 1 minute more to deploy a VM than it would otherwise but I’m saving a tonne of space on expensive disk.
This is the only thing that really bugs me with VMM. But it really annoys me. I’m guessing the mix between the restrictive Hyper-V security model and the inability to access GUID drives over the network have caused this. The new cluster file system in Hyper-V R2 will give them an opportunity to sort this out. Hopefully MS will sort it out.