If you’re interested by methods of aligning disk partitions used by guest operating systems in VMware environments then you’re probably already aware of the potential issues that arise when block boundaries don’t align (even in non-VMware environments). If you’re not aware of the issues or want to refresh your memory, read
Some time ago I was presented with reports of sub-optimal usage levels on storage array controllers and looked into the role played by virtual machines with misaligned partitions. Discriminating the impact of disk I/O not aligned to the block boundaries used by the array was difficult at the time (mixed workloads, earlier firmware / software), but early trials indicated improvement.
The problem we faced was, in part, due to a previous successful physical-to-virtual migration effort. The P2V tool used at the time did not re-align partitions, and there were many hundreds of misaligned partitions! I started to consider the problem, the tools available and other ways to approach realignment.
After a little prototyping I was pleased to find that – with a little VMDK preparation – it is possible to leverage vSphere storage vMotion to do the bulk of the re-alignment work… with the virtual machine powered on!
The new method
This is a basic description. I hope to provide more detailed descriptions, examples and source code in follow-up posts.
The method described here in general terms works because storage vMotion (and some other vSphere virtual disk operations) can handle a source virtual disk with multiple extents and create a single, concatenated extent at the destination.
Considering a non-boot VMDK with a Master Boot Record, the general steps are:
- Calculate partition offset required (to align with block boundary)
- Copy the existing partition table to a new file
- Pad the end of the new file by the amount of offset required
- Add the offset to the partition starting logical block address(es) in the copied partition table
- Power-off the virtual machine
- Add the new file to the VMDK descriptor (before the existing backing file)
- Power-on the virtual machine
The effect is that the logical block address associated with the start of the partition is shifted by the size of the first extent (i.e. the size of the new “padding” backing file), and the new start address is read by the operating system from the modified partition table.
Checking partition alignment at this stage from the guest operating system would suggest that the partition is now aligned with the desired block boundary. This is an illusion (albeit a convenient one), and virtual disk I/O will still be occurring across block boundaries when it reaches the backing storage device.
The final step is to migrate the VMDK to another datastore.
Like most of the other tools that re-align partitions contained in VMDKs, there are a number of things to consider.
Here are some of the important ones that I’ll address in more detail in another post:
- Boot considerations
- Master Boot Records and GUID Partition Tables
- Addressable size
- CHS addressing, geometry
- Logical Block Addressing
- Volume identification and mounting
- Boot loaders (e.g. GRUB, Windows)
- Data protection
- What changes
- Reversing changes, point of no return
- Backup and recovery
- Interaction with snapshots
Wrapping it up as a tool
I’ve previously written code to automate this new method, but don’t hold the rights to make it available here.
Although it involves a rewrite, I have started coding another implementation of this method and would like to make it available under an open source software license. Perhaps more importantly, I would like to make implementations available in a number of different programming languages. I will post further updates as usable code becomes available.
Recommendations for Aligning VMFS Partitions contains some good background information on issues with misalignment. Although this information was published in relation to VI3, it is generally relevant to vSphere 4 and 5 also.
There are a number of descriptions available on the internet of what misalignment is and how to address it, and I would note two excellent blog posts by VMware bloggers Duncan Epping and Cormac Hogan:
The comments to Duncan’s post contain further valuable information and Cormac’s post includes links to technical articles from a number of storage vendors and from Microsoft.
Duncan’s post also contains a list of existing tools that can be used to address existing misaligned partitions.
Options for dealing with misaligned I/O have improved since the information above was first published, and I would suggest checking with your storage system vendor for the latest information.