From the title, you might think I would be griping about Hyper V, Microsoft’s server virtulization technology. The truth is, I am only frustrated by the prerequisites of Hyper V, one of which is particularly troublesome. Mainly, that you need to have a Virtualization Technology (VT) enabled processor from either Intel or AMD to run Hyper V.
This effectively makes it impossible to have a virtualized Hyper V test/development environment by ensuring that all of your Hyper V hosts are indeed physical. With vSphere, it is very possible to run an entire cluster on a machine that has enough enough memory through using a product like VMware workstation. In that scenario, you are limited to 32 bit guest operating systems on that cluster because vSphere requires the VT bit for 64 bit virtual machines. In the end, that is A-OK because what you are truly learning about is how to setup and configure the hosts along with vCenter. Hyper V is a fairly complicated beast, so it would be nice to be able to completely go through its configuration (not too mention testing configuration changes) in a virtual environment.
It’s been a frustrating day at work because of this requirement. Supposedly, Sun’s Virtualbox could pass along this VT bit capability to the VMs you were running, theoretically enabling the the running of a Hyper V host in a VM. I am here to tell you that doesn’t work, at least in the latest 3.1 release of Virtualbox. Other than that, I have no beef with Virtualbox, its actually pretty speedy and simple.
A large part of my new job has been helping with architect a large VMware Lab Manager 4 implementation. This has proven to be fairly annoying when deploying Lab Manager in a big way. It is important to keep in mind that the main design challenge and constraint of nearly all virtualization solutions is the back end disk, configured in VMware as “Datastores.” Some of the main frustrations we are currently facing:
- Lab Manager blatantly disregards VMwares own best practices when it comes to disk allocation – we are talking about 2TB LUNS as a minimum and facing the issue of using VMFS extents. Horrible! You are almost forced to use NFS, which brings more support complications to the table as you can no longer rely on calling VMware as the primary support vendor. How this can be when VMware sells and and supports it? You would think VMFS would be the recommended file system for any VMware solution until they provide the ability to create and maintain NFS Datastores from within vCenter.
- You can’t use thin provisioning in Lab Manager. Arguably, this would be more useful than Linked Clones, which just create more management headaches than they are worth in a bigger deployment. I am not alone here in thinking this. We are deploying unique VM’s with ~200-500GB of auxiliary disk. Having this all thick provisioned upfront is harmful, especially as users have the ability to make clones of these – or even worse, check them into the library where they would take up that space again and be *required* to be on the same Datastore.
- Even though Lab Manager devs are well aware of how they are bound by datastore limitations and know full well the way that vSphere overcomes many of those challenges, they don’t provide a way to seamlessly use storage vMotion either within Lab Manager or external to it.
- Lab Manager could provide for automatic load balancing for Datastores and Networks, but it doesn’t. Instead we have to trust users to do this for themselves. That’s just silly, the users don’t care about these things and therefore no amount of training will get them to do this on a consistent basis. I’ve already mentioned that we can’t fix overloaded Datastores without user impact, and Lab Manager doesn’t even help us preempt it.
- It would be great if we could take actions on flags, for example once a datastore reaches 70% full we disable to the ability to create VM’s on it. That would help keep us away from the situation where a LUN drops offline because it is packed to the gills.
- Disable Linked Clones all together. They make it more complicated than its worth with 100′ s of self provisioning users and tens of Datastores. It also incredibly inhibits VM mobility.
- A way to have a centralized template store that admins can put VM’s on but no one else can.
The items above are really inhibiting our ability to make good use of Lab Manager. It is clear that this piece of software was not built with large scale deployment in mind. It also features too many design compromises that hamper the overall value of running vSphere as a whole. This is epitomized in a conversation I just had with my boss. When talking about Lab Manager, we are constantly talking about the problems it is causing us. With vSphere, we are talking about how the technology allows us to over come challenges.
We need a solution not a constraint, dammit.