Hyper-V VM Partition Alignment
Hello everybody. This is Cristian Edwards Sabathe from Microsoft Spain. Today I am really happy to write my first post on our new World Wide Virtualization PFE blog. Our team has lots of talented PFEs and I am a lucky man to be part of it. I am pretty sure this blog is going to be a good reference for the community and I hope I can contribute with useful content.
Now let’s talk about a subject that some of you might have heard before.
One of the configurations we analyze during the Hyper-V Health Checks is the disk partition misalignments within the VMs (Virtual Machines) because this can impact the Hyper-V storage performance.
We also validate this configuration at host level but this will not be an issue in most cases because partitions created with Windows Server 2008 R2 are aligned by default using the 1,048,576 bytes starting at offset (1024KB). So when installing the Host OS you use the wizard to create the partition you can be sure that is already aligned. Of course, if you create a partition on a new disk from Disk Management console on Windows Server 2008 R2 it will be aligned too.
Note: The intention of this post is not to explain what the partition misalignment (as it’s already been well explained on the following articles) but I am just adding information to cover this topic when Hyper-V is part of the equation.
Disk Partition Alignment Best Practices for SQL Server
https://msdn.microsoft.com/en-us/library/dd758814(v=sql.100).aspx
Disk Partition Alignment (Sector Alignment) for SQL Server: Part 1: Slide Deck
Disk Partition Alignment (Sector Alignment) for SQL Server: Part 4: Essentials (Cheat Sheet)
Disk Partition Alignment (Sector Alignment): Make the Case: Save Hundreds of Thousands of Dollars
Assuming that the partition where you place your VHDs is aligned we need to go one step deeper and validate that the NTFS partition inside the VHD that will be used by the Guest operating system is also aligned.
If the guest operating system is Windows Vista, Windows 7, Windows Server 2008 or Windows Server 2008 R2 and the partitions were created using one of these operating systems you don’t have to worry because they will be aligned.
Unfortunately, partitions created with Windows Server 2003 and Windows XP will have the default starting offset 32,256 bytes, (31.5 KB) and will be misaligned.
The picture below has 5 rows and assumes that your starting offset is set at 32,768 bytes. I decided to use the same pattern that is in the above MSDN articles to be consistent with the SQL team example.
The first black row represents a stripped volume from the SAN that is using 64k block allocation unit size. This means that data will be read and write on pieces of 64K.
The second grey row represents the number of physical sectors contained on each SAN block allocation unit size.
In this case the SAN block size is 64K (65536 bytes). Note that this value has to be provided by your SAN vendor. If you divide 65536 by the physical sector size (512 bytes) you are going to have 128 sectors on each SAN block.
Starting at the third blue row you can see a NTFS partition with the default cluster size (4K). Now we have 2 different block sizes. The stripped SAN block size and the NTFS block size. We can say that NFTS partition is aligned with the stripped volume because 64K is divisible by 4K and that fits perfect without crossing any block boundary. One SAN block will contain 32 NTFS 4K blocks with the exception of the first block that is shared with the MBR information.
The fourth orange layer represents a VHD file placed on the NTFS partition and has no block information at all. Fixed VHD file structures are transparent at block size level to improve performance.
The fifth blue row with 63KB marked in red is a NTFS partition inside the VHD file that has a misaligned starting offset 32,256 bytes, (31.5 KB). This means that data will be written starting at sector 128, which is the last sector of the SAN block.
So, two SAN blocks will be accessed if the OS inside the VM needs to read or write data on the firsts 8K. This will degrade the performance because it requires two accesses to the SAN disks instead of just using one disk IO within the same SAN block.
The most common cases for this problem are Windows Server 2003 or Windows XP VMs where the partitions were created using the default method instead of using Diskpart.exe to define an aligned starting offset.
If you perform a P2V (Physical to Virtual) of a Window Server 2003 machine and it has a misaligned partition you also going to bring the same issue to your VM.
The last blue row with 64KB marked in green is a NTFS partition inside the VHD file that has an aligned partition. Any IO inside VMs will use only the necessary IOs at SAN level because the block boundaries are aligned.
How can you detect it?
You can use the following command to list your partitions starting offset inside your VMs and make an easy operation. Divide the StartingOffset value by the block size value. If the returned value is an integer without decimals your partition is aligned at NTFS level. In the example below this operation (1048576 / 512 = 2048) for the first partition on disk 0 results on 2048, which is an aligned partition.
Once you are sure that your partition is aligned at NTFS level inside the VM, you should check the same but at Host level. To do that you need to run the same command in your Hyper-V host and divide the StartingOffset by the Stripped allocation unit size provided by your SAN vendor. In the picture above we use an example of 64KB SAN block size, which means we need to divide the starting offset by 65536 bytes. If we assume that partition where the VHDs are placed was created using WS2008 R2, the operation will be (1048576 / 65536 = 16). The resulting value is 16 and this means that the partition where the VHD is placed is also aligned.
You can find more examples and information in the following link.
Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000
https://support.microsoft.com/kb/929491
Command: wmic partition get BlockSize, StartingOffset, Name, Index
How can you fix the issue?
Unfortunately there isn’t any easy solution for this problem. If your VMs have misaligned partitions you will have to reformat the partitions using the procedure documented in the following KB;
Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000
https://support.microsoft.com/kb/929491
Hope that helps and see you in next posts.