Guy's Random Support

A common experience I have had and seen others need help with is the situation where you created one or more of your initial VMDK files too small. I always struggled with trying to create the smallest practical files for our expected needs. We don’t want to waste any of that precious SAN resource now, do we? There are so many reasons that can lead to needing more space. It is great when you find that you do have options other than recreating the whole install. There are variations on this information available elsewhere on the internet, however I spent what I felt was an excessive amount of time trying to find it and figure it out myself. Hopefully this will save someone else significant time and effort. I wanted the simplest procedure possible and I didn’t want to buy any software to get it done. Here is the procedure…

As with any operation of this type I would highly recommend doing a backup in case anything goes wrong. You will be making modifications to the raw VMDK files associated with your VM so take care!

Use this procedure to resize an existing Windows VMDK file when you need more space. It looks long because of all the screenshots, but only takes about 5 minutes. What you need:

• A valid login to the VM Host Server
• PuTTy (to Telnet to the VM Host Server)
• The Root Password to the VM Host Server
• The location and name of the VMDK file
• Enough disk space on the Physical drive to fit the extended VMDK file.
• Access from the VM to an ISO image of the GPartEd partition manager

Log into the VM HOST Server and extend the VMDK file

This may be daunting if you are not experienced in Linux, but is still very easy if you follow these instructions.

• Shut down the Virtual Machine that has the disk needing to be extended.
• Log into one of the VMWare host servers that host the VM using PuTTy.
• Change to root using the SU command.
• Change to the directory where the VMDK is held. For example:

cd /vmfs/volumes/VM-SCSI_OS_1/SVMesaApp01/

• List the directory. Note the size of the *–flat.vmdk file. There are 2 vmdk files. Note that you are looking at the –flat.vmdk file for size purposes ONLY the file that you run the command against will be the file without the flat in the file name:

[root@smesavm1 SVMesaApp01]# ls -lah
total 8.1G
drwxr-xr-x 1 root root 2.1K Apr 25 06:05 .
drwxrwxrwt 1 root root 1.2K Apr 25 02:13 ..
-rw——- 1 root root 10.0G Apr 25 06:05 SVMesaApp01-flat.vmdk
-rw——- 1 root root 8.5K Apr 25 06:05 SVMesaApp01.nvram
-rw——- 1 root root 343 Apr 25 05:04 SVMesaApp01.vmdk
-rw——- 1 root root 0 Apr 25 02:15 SVMesaApp01.vmsd
-rwxr-xr-x 1 root root 1.3K Apr 25 06:07 SVMesaApp01.vmx
-rw——- 1 root root 255 Apr 25 06:07 SVMesaApp01.vmxf
-rw-r–r– 1 root root 21K Apr 25 02:13 vmware-4.log
-rw-r–r– 1 root root 27K Apr 25 02:13 vmware-5.log
-rw-r–r– 1 root root 27K Apr 25 02:13 vmware-6.log
-rw-r–r– 1 root root 22K Apr 25 02:13 vmware-7.log
-rw-r–r– 1 root root 30K Apr 25 02:13 vmware-8.log
-rw-r–r– 1 root root 27K Apr 25 02:13 vmware-9.log
-rw-r–r– 1 root root 52K Apr 25 06:05 vmware.log

• Execute the vmkfstools command specifying the NEW size of the file. Make sure it is > the old size! I haven’t tested it, but it is likely that specifying a smaller size will truncate your existing partition data. IMPORTANT: The file that you specify is the vmdk file that doesn’t have the “–flat” in the file name!

YES - [root@smesavm1 SVMesaApp01]# /usr/sbin/vmkfstools -X 12G SVMesaApp01.vmdk
NO! - [root@smesavm1 SVMesaApp01]# /usr/sbin/vmkfstools -X 12G SVMesaApp01-flat.vmdk

• List the directory again. The *-flat.vmdk file should now be the new size.

[root@smesavm1 SVMesaApp01]# ls -lah
total 11G
drwxr-xr-x 1 root root 2.1K Apr 25 06:27 .
drwxrwxrwt 1 root root 1.2K Apr 25 02:13 ..
-rw——- 1 root root 12G Apr 25 06:05 SVMesaApp01-flat.vmdk
-rw——- 1 root root 8.5K Apr 25 06:05 SVMesaApp01.nvram
-rw——- 1 root root 343 Apr 25 06:27 SVMesaApp01.vmdk
-rw——- 1 root root 0 Apr 25 02:15 SVMesaApp01.vmsd
-rwxr-xr-x 1 root root 1.3K Apr 25 06:07 SVMesaApp01.vmx
-rw——- 1 root root 255 Apr 25 06:07 SVMesaApp01.vmxf
-rw-r–r– 1 root root 21K Apr 25 02:13 vmware-4.log
-rw-r–r– 1 root root 27K Apr 25 02:13 vmware-5.log
-rw-r–r– 1 root root 27K Apr 25 02:13 vmware-6.log
-rw-r–r– 1 root root 22K Apr 25 02:13 vmware-7.log
-rw-r–r– 1 root root 30K Apr 25 02:13 vmware-8.log
-rw-r–r– 1 root root 27K Apr 25 02:13 vmware-9.log
-rw-r–r– 1 root root 52K Apr 25 06:05 vmware.log

• You may now log out of the Virtual host server.

Extending the existing partition to use the new space

The scary part is done. The rest is easy…

• If you log into the Windows server (you don’t have to, I’m just mentioning it here for purposes of illustration) and run the Windows disk management tool (Start ->Run -> diskmgmt.msc) you should see the disk that you extended with new unallocated space at the end.
• At this point you can use whatever partition manager you want to merge the newly allocated space into your existing partition. Partition Magic would work, but that costs money. Who wants to spend money? Instead we will use GPartEd which is free and well maintained.
• Now, reboot the VM with the GPartEd CD mounted. To do this you have attach the GPartEd ISO to the VM’s CD device in Virtual Center and reboot the VM. To boot from the CD you will have to press the ESC key during the BIOS Post routine.

NOTE: It is VERY easy to miss pressing ESC at the correct time during the VMWare VM BIOS POST routine. If you do miss pressing ESC then you need to let Windows reboot before trying again. Do not cycle power or otherwise disrupt the boot process because if you do, the next step will fail because the disk will be considered ‘dirty’. If you do it correctly you will be given the option to reboot from the CD-ROM Device.

• After selecting to boot from the "CD-ROM Drive" you should see the GPartEd splash screen.
• Press Enter to continue
• When the menu comes up select “Manual Video Card” to trigger additional config later in the process.

I’m not sure why this is, but I with the version of GPartEd I was using for this I couldn’t get it to work properly if I didn’t do this step!

• Select “Done”
• When it prompts for your language select "US English" or whatever makes you happy.
• Next select your keyboard, I select querty/us.map
• Next is the Video selection. Select "VESA" and then "24" for the color depth, and then "1024x768" for the resolution.
• The GUI for the partition manager will then come up and should show a list of your disks and partitions.
• Right-click the partition that you want to extend and select “Resize/Move”
  
• A graphical view of the partition will be displayed. You can click and drag the right hand side of the size slider until the bar fills the entire space, or you can change the "Free Space Following" value to 0.
  
• Click on the "Resize/Move" button
• Back at the main screen click on the "Apply" button.
• An "Applying Pending Operations" Dialog will appear while the process is completed.
  

Done!

NOTE: If this process fails on the last stop you can expand the “Details” item repeatedly until you drill down the explanation of the error. The only problem that I have ever found here is the error caused when you try to reboot from the CD and miss the short window of time to press the “ESC” key (used to select the boot device on the BIOS post screen). If this happens and you reboot again without letting the Windows boot complete then the file system is considered ‘dirty’ and the resize may fail. If this happens then just reboot windows and try again.