Partition Alignment in ESX 3

I came across this article today while doing some research on using dd in a vmfs environment on partition alignment in ESX server. If you aren't familiar with the issues that can be caused by partition misalignment, it is most definitely a worthwhile read. If your head starts spinning in the first couple of sections and you feel like it's not worth the trouble, skip ahead to the benchmarking section at the end and I'm sure you'll reconsider.

Why Your Virtual Infrastructure Network Should Be Segmented

When architecting a Virtual Infrastructure, networking is one of your most important concerns. Dropping 50 servers into 5 buckets creates new IO and security concerns. Here is how we have implemented this and had good results:

1) Service Console vLAN - Having a separate vLAN for your service consoles not only brings up the level of security around them, but ensures that your ESX to ESX pings for high availability cannot be bogged down by other network traffic.

2) vMotion Physically Segmented - The obvious reason for this is to improve performance. Running a vMotion or an svMotion sends an enormous amount of data over the network. So as to not impact the performance of other applications on your network and to get the best throughput possible in your migrations, having this physically separate is key.

The less obvious reason for this is security. When a vMotion is happening, the raw contents of a VM's memory are sent across the network. Should a malicious party be listening on this vLAN, they would be able to read the entire memory contents of your server. If you have any type of sensitive data being processed on that server, this creates an additional point of exposure.

3) Virtual Machine Network - In our case, we use the same vLAN for our VMs that we use for our physical servers.

4) Storage Network - If you will be using iSCSI or NFS on the back end, it makes sense to segment this out at least virtually if not physically to be able to ensure proper performance of your storage devices.

A GUI for sVmotion

A couple of days ago, I downloaded and installed a VI Client plugin for Storage vMotion which makes utilizing Storage vMotion as easy as a standard vMotion migration. David Davis over at VirtualizationAdmin.com has written up a nice little guide on installing and using this plugin. It was written by Andrew Kutz and is provided free of charge on his Google Code page. The only gripe I have is that I was unable to use it to locate my vmdks and vmx files on separate SAN LUNs. I find this especially useful in the case of something like a database where I may want a vmdk on RAID 5 for my data files and a separate VMDK on RAID 10 for my transaction logs. If anyone knows of a slick GUI that supports this functionality, I'd appreciate the tip.