Four Things VMware Engineering Can Give Me For Christmas

I hope everybody out there in the virtualization world is having a great holiday season this year! My religion celebrates Christmas, and these are four things I’d love to see under my Christmas tree this year.

1. IPv6 support at all levels of the VMware stack.

For a cloud vendor that fancies themselves as forward-looking, not to mention trying to be the “VMware of Networking,” the lack of IPv6 is pretty embarrassing. I know, I know, the tired argument is that nobody is really looking at IPv6. Well, it’s hard to look at when your vendor doesn’t support it much. 🙂 Chicken, meet egg. This would also help ameliorate the fact that VMware products need an awful lot of IPs just for themselves.

It’d also be pretty sweet if the vCloud Networking edge gateways could do what their hardware counterparts can do and front-end an IPv4-only service with an IPv6 address. Instant IPv6 client compatibility.

2. Better security automation.

VMware should practice what it preaches about automation, especially when it comes to making security things brain-dead simple to implement. For example, lately I’ve followed the instructions outlined in KB 2036744 for replacing the vCenter Appliance 5.1 SSL certificates. There are 81 steps.

Eighty one steps.

Seriously. And most of them are the same step over and over. William Lam is taking some stabs at this particular problem (and honestly I scripted a lot of it, too) but this should be a native feature of the product. Why in the heck can’t I press a button on a web interface or run a script, have it barf out a Zip file with CSRs & keys and stuff, I go get them signed, and then put the certificates in the right spot and run another script to have them installed in the proper places for me? Why can’t vCenter change the SSL keys for me on all my ESXi hosts, in the same manner? Right click on a cluster, export SSL CSRs, get ’em signed, import them again.

Beyond that, why is there a vSphere Hardening Guide? Why are these not the defaults and we rename the guide the “vSphere Softening Guide?”

Eighty one steps. Holy crap.

3. Expose hardware random number generators to guest OSes.

I don’t know all that much about how Windows handles entropy pools, but Linux hosts gather data for their /dev/random and /dev/urandom devices from timing of keyboard, mouse, and some other interrupts. This presents a problem for VMs, since they don’t have that hardware, and as such the pools of entropy that help guarantee that cryptographic functions work well aren’t very big. Services that depend on /dev/random will block when it’s out of randomness, causing poor performance (in contrast, /dev/urandom doesn’t block but also isn’t as secure).

Want to see how much randomness you have on your Linux VM now? Try:

cat /proc/sys/kernel/random/entropy_avail

Then try it on a physical piece of hardware. A Dell PowerEdge R710 running Oracle Linux 6.3 natively had 3968 bits of entropy. Same OS just in VM form had 136. Uncool.

Modern server hardware has real hardware-based random number generators built in, often as part of the TPM functionality. It’d be really great for security and performance if VMware could expose those to the guest OSes via the VMware Tools or something.

4. vApp (or multi-VM) snapshot groups.

Wouldn’t it be cool if you could snapshot an application and its database on two different VMs simultaneously? Yeah, it would. 2013 is the year we get this feature, VMware. It’s in the hardware-defined data center (look up “consistency groups”) and needs to be in the software-defined data center, too.

Thanks, VMware, I look forward to unwrapping some of these on Christmas day! And to save you time I won’t need a gift receipt for any of them. 🙂