VMware Cloud Community
rickardnobel
Champion
Champion

How is guest alignment possible?

I think I understand the reasons for that partitions should be aligned - that when the logical filesystem formats the partition it shall not create the clusters/allocation units/blocks (different names for a logical collection of sectors) crossing cylinders unnecessary. Or perhaps over stripes on a disk array? Is that correct?

But for a guest operating system - how is this possible? There seems to be too many layers: first the physical disks that probably are bundled together in a RAID array, then the Vmware partition with VMFS blocks, then somewhere on this partition is a flat-vmdk file (which could be moved around sometimes by sVmotion) and inside this file, which the Guest VM sees as a harddisk, we shall create the internal partitions.

My question is how should it be possible to "aim" any alignments from inside the guest which are operating at such high level?

My VMware blog: www.rickardnobel.se
Tags (1)
0 Kudos
7 Replies
AWo
Immortal
Immortal

But for a guest operating system - how is this possible?

Either by storage vendor tools (mbralign from NetApp, for example) or by using an guest OS which is self-aligning or by following the guest OS vendor tutorials.

There seems to be too many layers: first the physical disks that probably are bundled together in a RAID array, then the Vmware partition

with VMFS blocks, then somewhere on this partition is a flat-vmdk file (which could be moved around sometimes by sVmotion)

and inside this file, which the Guest VM sees as a harddisk, we shall create the internal partitions.

Don't care about the physics, it is about logical block boundaries. The disk itself presents its storage units as logical blocks (LBA).

If you read such a logical block (optimization of how it is read/ organized from/on the platters is up to the disk) you generate an I/O. So if you know the start address and size of that block you can optimze the I/O's needed to get or write data. That is what alignment does. But on the layer which is not aligned you may generate more I/O's than necessary because reading data which is stored across more than one block (but which might have fit into one block if it were aligned) generates unecessary I/O's.

Read that VI3 document (yes, I know, that is not the lates one. IT IS ONLY FOR EXPLAINING ALIGNMENT): http://www.vmware.com/pdf/esx3_partition_align.pdf

It has some nice pictures and hints on how to achive alignment on guest OS systems.


AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
rickardnobel
Champion
Champion

Either by storage vendor tools (mbralign from NetApp, for example) or by using an guest OS which is self-aligning or by following the guest OS vendor tutorials.

Thanks for your reply. I was possible unclear in my question. It was not how to actually do the alignment inside the guest (diskpart and others), but how this is both practical and necessary from inside the guest, where there are so many invisible layers underneath which hides the actual hardware configuration that guest partition alignment tries to optimize?

My VMware blog: www.rickardnobel.se
0 Kudos
AWo
Immortal
Immortal

I edited my post, check it again!


AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
0 Kudos
rickardnobel
Champion
Champion

I edited my post, check it again!

Thanks! However, I think I am far from getting this unfortunaly.

I have tried to create a picture to understand what I do not get.

The image

In this example we have some kind of disksystem which is made up of physical disk sectors (yellow). The size of sectors is 512 byte.

These sectors is combined into some stripe size by the storage administrator (grey). The size of this should be invisible to the outside, is that correct? The stripe size could be perhaps 128kB.

The storage admin then creates a disk out of these, that could be called a LUN, that is visible to the ESX host. (white)

The ESX admin creates a VMFS partition on this disk. If using the vSphere Client the partition should be aligned to the disk. (purple)

When formating the partition with VMFS a block size is selected. Perhaps 1 MB blocks (green).

Somewhere on the VMFS partition we create a virtual disk for a VM. The flat-vmdk file will be located somewhere on the volume, and most reasonable be starting at the beginning of a VMFS block. So the VMDK file (blue) is now created.

After giving the new virtual disk (yellow) to a Virtual Machine the VM admin wants to create a new partition inside the VM. This should be a data partition called D:. Now we should align it.

So with using some suitable tool, perhaps diskpart, we push the start of the partiton (grey) a little bit into the disk, perhaps 64 sectors.

Here is the big mystery.. what am I "aiming" at with this start location? The VMFS blocks? Or the stripes/chunks?

And the final step now. The partition is formated logically inside the VM with some file system, say NTFS and the Windows admin selects a cluster size/allocation unit which by default is 4kB.

So the VM has a second disk with a 😧 partition which is made up of a large number of clusters. So now it will be reading some clusters, perhaps clusters 5-8. What will the gain be? In all of these layers with so many different sizes of accessing the disk, how can this final step be possible to optimize?

I thinks this is really very interesting and would like to know. Does anyone has any ideas, suggestions or answers I would be very grateful! And I hope this makes any sense at all.. Smiley Happy

Please also let me know which parts of all above that I am misunderstanding.

My VMware blog: www.rickardnobel.se
0 Kudos
joshuatownsend
Enthusiast
Enthusiast

Is this of any help: http://vmtoday.com/2010/06/storage-basics-part-vii-storage-alignment/






If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

Please visit http://vmtoday.com for News, Views and Virtualization How-To's

Follow me on Twitter - @joshuatownsend

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful". Please visit http://vmtoday.com for News, Views and Virtualization How-To's Follow me on Twitter - @joshuatownsend
0 Kudos
rickardnobel
Champion
Champion

Is this of any help: http://vmtoday.com/2010/06/storage-basics-part-vii-storage-alignment/

Thanks, your article was very good and your image of the problem much better looking than mine. Smiley Happy

However, I still do not understand what the guest OS alignment is "aiming at". (Sorry for not really be able to express what I mean, but hard to non-native english speaker). I know that in some way by moving the start of the partition somewhat into the disk it will match more closely to... something!? The goal should be to not have the storage array to access more blocks than necessary per IO from the guest, but do I need to know the storage stripe size to do this correctly?

Or is it just by making the partition start at some even number (instead of sector 63) it will most likely match the storage chunk size of the average SAN vendor? It is just so many layers between that confuses me where the gain really is.

My VMware blog: www.rickardnobel.se
0 Kudos
AWo
Immortal
Immortal

As I wrote in the beginning, it is all about logical block addressing. If at one layer the layer above thinks it needs to get two blocks it issues two I/O's. Regardless on how the data ends up on the disks.


AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
0 Kudos