I have read VMware's document on Recommendations for Aligning VMFS Partitions and have a question:
1. If you use the VC to add VMFS storage to an ESX host, do you still need to perform guest file system alignment within the VM itself? The guest being Windows 2003 in my case.
I am trying to ascertain whether you need to do this regardless if you have used VC or fdisk to add the storage to an ESX host.
Seems a tedious process to follow every time you want a new VM built. I know you could add the second disk as part of a template but maybe you don't know the disk size requirements.
I'm with ajnrock, btw.
If you can gracefully, eg. via a PE, get the thing aligned at 64k/128k, go for it. No harm, and it is "the right thing to do".
I don't think I'm ever going to see any effect whatsoever in my environment, either on the front or back end, aligned or not. Key is no data disks on VM's. (The Oracle/DB2/SQL servers unrelated to my ESX environment that share the same EMC's are hitting them harder by several orders of magnitude - my ESX load is in the noise on my SAN)
I think were I to have \_very_ significant disk I/O on
my VM's I'd probably worry about it. But, around
here, and I would venture a guess, for a lot of
folks, it is a worthless endeavor to worry about it.
I agree. I always set my paritions to use 4K cluster myself. But on the whole, this is like people arguing over which is better AMD or Intel, you are splitting hairs. The 99.99% population, is \*NOT* going to notice the difference.
I don't think I'm ever going to see any effect
whatsoever in my environment, either on the front or
back end, aligned or not.
I think it can help when you're doing VMs backup.
That's a night thing running when users are out, but that's always nice if you can reduce your backup window.
I have trawled through EMC's KB and found this for procedure for Windows 2003 SP1. This seems to dispense with having to create the 1MB dummy partition (for Basic disks at least) that was in the VMware procedure:
Date Created: 03/16/2005
Last Modified: 12/28/2006
Environment: OS: Microsoft Windows 2003
Environment: Product: Symmetrix
Environment: Product: CLARiiON
SP1 contains a new parameter for the "diskpart.exe" command-line utility called the "align" parameter.
Note: After aligning a disk using diskpart align, you may need to first assign a drive letter to the partition before you format it as NTFS.
To use the align parameter on a basic disk, perform the following command to create the partition:
This will make the partition start at sector 128.
Note: The align command will not work on dynamic disks. You must use diskpar.exe from the Microsoft ResourceKit. Refer to the EMC White Paper entitled "Microsoft Windows File System Alignment.pdf" for additional information about how to use Diskpar to align Dynamic Disks.
Fix: Dynamic disks are aligned after following the steps above. You can verify this by reading sector 128 and seeing that it has a valid NTFS boot sector, but if you read the MBR and view the partition table the "dynamic" partition will have a relative sector of 63. This value of 63 is read from the dynamic disk header in a setting called public offset. If a customer discovers this and wants to know why, explain that it is read from the dynamic disk header and is not an issue.
If a customer wants to correct this issue, have them contact TS2 Windows support to use a Microsoft tool called DMPSS.exe to correct the value in the dynamic disk header called "public offset," which is set to 63. The "public offset" value can be changed to 128, and after a reboot will be reflected in the MBR for the dynamic partition.
Notes: GPT disks are also misaligned by default, and that issue is also corrected using the Diskpart align=64 method above. Refer to EMC White Paper 300-004-075 "Aligning GPT Basic and Dynamic disks" for additional information.
We have many Windows VM's and when large I/O operations occur to all of them (such as deploying Norton updates, or applying patches), we see SAN access spike to the point that it is noticable. We are in the process of aligning VMFS filesystems, but have not decided how to tackle the partitions within the guest VM's.
Do we have any viable options on this? Is there any way to align partitions to 64K offset on existing VM's short of reinstalling? I'm even open to options that require downtime at this point (though it would be LOVELY to be able to do this with VMWare Converter...seems you cannot even with v3 though).
I found a solution to this! This works for ANY partition, be it a boot partition or any other kind of partition in your Windows VM.
You'll need to download a copy of DFSee from here:
Really, you should buy the license. It is an excellent piece of software, and the only thing I've found that can do this.
Then, you'll need to do the following steps. This will require downtime that will vary depending on the size of your partition, and you'll need spare disk space equal to the size of the partition(s) you are moving:
1) BACK UP YOUR VM!!!
2) Shut down the VM
3) Grow the disk you are realigning by 1MB or so (we're really only shifting it by 32.5K...if you want, you can probably grow it by 33K and it will be enough)
4) Create a 2nd drive for the VM that is 33K (or more) larger than the disk you are shifting. Add it to your VM as a 2nd hard drive. This is only for temporary use anyway.
5) Set the VM to use the DFSee ISO as a CDROM
6) Boot to the CDROM
7) Issue the following commands in DFSee:
part 1 - (selects the first partition)
move -f:3 - (moves this partition to the 2nd drive)
part 1 - (reselects the first partition, now on the 2nd drive)
move -f:2 -e0x41,s -c - (copies the partition back to the first drive, but offset by 65 sectors from the beginning of the free space (41 hex))
part 1 - (select the first partition again, now it is back on the first drive)
fixpbr -! - (fix the boot sector to skip the 65 sectors we just added)
This works because a default windows install starts the partition 63 sectors from the beginning (31.5K), and since Windows rounds this up, we see 32K in DISKPART. What we are really doing is moving an addtitional 65 sectors past these 63 sectors already there. 65 + 63 = 128, and at 512 bytes per sector, we end up with our 64K offset.
I URGE you to read the documentation and know what you are doing before you do this...you can destroy all your data if you're not careful, and some of the partition or freespace numbers may very well be different on your system! If you have multiple partitions on your drive, you will probably have to move them ALL, and the procedure will be somewhat different...I'm leaving that as an exercise to the reader. And of course, I bear no responsibility if you do something that completely hoses your system.
😎 Power off the VM, remove the 2nd drive, clear out the CD-ROM, and shut it down to save disk state. Then power it all back up, and it should come up fine with a 64K offset shown in diskpart.
Hopefully this helps someone.
You'll need to download a copy of DFSee from here:
Really, you should buy the license. It is an
excellent piece of software, and the only thing I've
found that can do this.
We do the same with Paragon Partition Manager. Added bonus: it can convert partitions from Dynamic Disks to Basis Disks.
I didn't think the Paragon Product would align to such a small offset? I tried it out and the only thing I could find was how to align it with an offset in MB. Did I miss something?
I know this is an older post but I am in the same situation. I knew about the offset from an Exchange cluster that we setup that was not using VMWare. For what it's worth, I have found this in the "VMware ESX Server and EMC Symmetrix" document on page 3-51
If you have a powerlink account, here is the whitepaper:
This makes things easier.... I will have EMC and VMware engineers here next week. I will see what their opinions are. I'm sure there different.
Do you need to do this with each partition on a disk, or just the first partition? For example I have one vmdk file but I split it into two different partitions do I offset the first partition and it will offset every partition after that, or each partition on the disk?
A note on aligning boot partitions: Please read the white paper. VMware neither recommends nor requires an aligned boot partition. Customers have encountered MSFT VSS problems on more than one storage platform when they've aligned their boot partitions, so please avoid this.
Aligning data disks on the host level is desireable, and the steps to accomplish this using diskpart.exe are documented in the paper.
I tried this DFSEE boot disk.
I ran the commands as list here but the VM came back up with the same offset, 32,256k, which is still unaligned.
looking at the console while it's doing the copy I see:
old start position: 0x0000003f = CHS: 01 01 00 = Cyl: 0 H: 1 S: 1
old end position : 0x013eead4 - CHS: fe 7f 14 = Cyl: 1300 H:254 S:63
new start position: 0x0000003f = CHS: 01 01 00 = Cyl: 0 H: 1 S: 1
new end position : 0x013eead4 - CHS: fe 7f 14 = Cyl: 1300 H:254 S:63
so it's the same. I add the extra MB to the disks etc. I went through it twice,
also fixpbr -! says "no fix needed"
All I am trying to do is align the C drive of a VM I got from VMWware standalone converter, converting a physical server to Infrastructure Client. The drive is a 20GB partition.
Well not sure how to do this inside a VM, we have tools that do this outside and adjusts the VMDK, and creates a copy of the VM during the process.
So you may wan to talk to your SAN vendor about a script that does this. If this is local, then I wouldn't worry about alignment. We ran many test, and there are threads a dozen on here that exhaustively discusses pro and con, and from what I have in my own test, and seen, the alignment really depends on many factors. For the most part, and really negligible difference, the alignment has ZERO impact. I aligned our templates 'in case' there may be future needs, but in all truthfulness I don't see where it's worth your time. I did about 10 VM's, which is about 10 hours time to make the copy and align, and the results proved uninteresting. I didn't see any significant change, either better or worse.
The real impact is to lessen the blow on the SAN because every IO wasted is IO that another high performance process may need. So the reality is, it's largely unncessary. Feel free to search for alignment in other threads, and you can see where there is no clear argument one way or the other.
A friendly question: If the white paper says it's neither required nor recommended, if other people confirm that the gain for an aligned boot partition is marginal at best, if it's know to cause problems in certain circumstances, and it's so difficult to do, then why do it? As the author of the paper, I'm curious.
Sorry for revamping the argument, but a few questions:
- inside the wp referred in the thread, it seems that there is the assumption 1disk = 1partition. This is true for Windows but generraly not for Linux. So how to manage a disk with multiple partitions? I saw a reply saying that it should eb done for all partitions.... Does this mean that for example the 2nd partition would start at a sector that is multiple of 128? Or that it would be better doing only 1 partition (apart from boot disk, where actually alignment is not reccomended at all...)
- what about a partition that actually is a PV of an LVM? Actually it is a container for tipically more than one logical volume / file system.... so where would go alignement? Even if I align the PV, who knows about its LVs? And please don't tell that I had better not using LVM. It's too much useful
- is this matter related to alignment true for all SAN based storage arrays or only specific to EMC ones? What about for example IBM DS6k, HP Eva, HP XP, etc?