Tuesday, 26 January 2010
Moving and renaming VMware images - WiP
This is the first of (potentially) many drafts, as I try and get a handle on the process of moving/renaming VMware images.
A virtual disk is made up of one or more .vmdk files. If you have specified that the virtual disk should be split into 2GB chunks, the number of .vmdk files depends on the size of the virtual disk. As data is added to a virtual disk, the .vmdk files grow in size, to a maximum of 2GB each. (If you specify that all space should be allocated when you create the disk, these files start at the maximum size and do not grow.) Almost all of a .vmdk file's content is the virtual machine's data, with a small portion allotted to virtual machine overhead.
If the virtual machine is connected directly to a physical disk, rather than to a virtual disk, the .vmdk file stores information about the partitions the virtual machine is allowed to access.
Earlier VMware products used the extension .dsk for virtual disk files.
This is partly due to the fact that VMware Fusion ( Mac ) and VMware Workstation (Lin/Win) automatically create image names based upon the OS. As an example, a Red Hat Linux v4 image is created as a series of files named Red Hat Linux.* e.g. Red Hat Linux.vmx, Red Hat Linux.vmxf etc.
Now I don't claim to be totally conversant with the VMware file naming structure, but I'm sure that there are masses of documents on t'internet describing it more clearly.
Using this document as a source: -
the files that I've been manipulating are: -
.VMX
This is the primary configuration file, which stores settings chosen in the New Virtual Machine Wizard or virtual machine settings editor. If you created the virtual machine under an earlier version of VMware Workstation on a Linux host, this file may have a .cfg extension
.VMXF
This is a supplemental configuration file for virtual machines that are in a team. Note that the .vmxf file remains if a virtual machine is removed from the team.
.VMDK
This is a virtual disk file, which stores the contents of the virtual machine's hard disk drive.
A virtual disk is made up of one or more .vmdk files. If you have specified that the virtual disk should be split into 2GB chunks, the number of .vmdk files depends on the size of the virtual disk. As data is added to a virtual disk, the .vmdk files grow in size, to a maximum of 2GB each. (If you specify that all space should be allocated when you create the disk, these files start at the maximum size and do not grow.) Almost all of a .vmdk file's content is the virtual machine's data, with a small portion allotted to virtual machine overhead.
If the virtual machine is connected directly to a physical disk, rather than to a virtual disk, the .vmdk file stores information about the partitions the virtual machine is allowed to access.
Earlier VMware products used the extension .dsk for virtual disk files.
So, without further ado, here's my process ... oh, hang on, forgot to add the CAVEAT.
This process is DESTRUCTIVE DESTRUCTIVE DESTRUCTIVE - if it goes wrong, you will LOSE your precious virtual machine. If in doubt, do NOT do it WITHOUT a good proven backup. Otherwise, do NOT DO IT <PERIOD>
In this example, we have a subdirectory called WPX615 within which we have a bunch of files, all named WPX615...
WPX615-s001.vmdk
WPX615-s002.vmdk
WPX615-s003.vmdk
WPX615-s004.vmdk
WPX615-s005.vmdk
WPX615-s006.vmdk
WPX615-s007.vmdk
WPX615-s008.vmdk
WPX615-s009.vmdk
WPX615-s010.vmdk
WPX615-s011.vmdk
WPX615.nvram
WPX615.vmdk
WPX615.vmem
WPX615.vmsd
WPX615.vmss
WPX615.vmx
WPX615.vmxf
WPX615-s002.vmdk
WPX615-s003.vmdk
WPX615-s004.vmdk
WPX615-s005.vmdk
WPX615-s006.vmdk
WPX615-s007.vmdk
WPX615-s008.vmdk
WPX615-s009.vmdk
WPX615-s010.vmdk
WPX615-s011.vmdk
WPX615.nvram
WPX615.vmdk
WPX615.vmem
WPX615.vmsd
WPX615.vmss
WPX615.vmx
WPX615.vmxf
At the end of the process, the subdirectory will be renamed Portal61 and each file will be Portal61...
- It's probably a stupid thing to say, but make sure that the VM is not running; ideally, shut down Fusion / Workstation before proceeding
- Rename the subdirectory
- Remove the log files - they play no part in the actual operation of the VM, but may be worth moving/backing up for future reference
- Remove the appListCache directory - this MAY be a VMware Fusion feature which I don't use, so don't mind losing
- Rename all of the files
- Replace references to WPX615 in the .VMX, .VMXF and .VMDK files
So here's the script: -
#!/bin/bash
# Test for sufficient parameters
if [ $# -eq 0 ]
then
echo "Usage: renameVM.sh OldVM NewVM"
exit 65
fi
# Parameter 1 is the old directory/file name
echo "Moving from " $1
# Parameter 2 is the new directory/file name
echo "Moving to " $2
# Move the directory
mv $1 $2
# Change to the new directory
cd $2
# Remove the appListCache directory ( VMware Fusion only ? )
rm -Rf appListCache
# Remove the log files
rm -Rf *.log
# Move the VMware files from the old name to the new name
ls *.* | awk '{print("mv "$1" "$1)}' | sed 's/'$1'/'$2'/2' | /bin/sh
# Replace references to the old filenames
sed -i '' 's/'$1'/'$2'/g' $2.vmx
sed -i '' 's/'$1'/'$2'/g' $2.vmxf
sed -i '' 's/'$1'/'$2'/g' $2.vmdk
# Finished
echo "All done, please try your new VM"
So far, so good.
This has worked for me today with a single VM, switching back and forth from one name to another.
Will update as I progress ...
PS I learnt a lot about awk, sed and bash in this process, and also found that the command fgrep -I <pattern> filename was of great use in testing the search/replace on the VMX files etc.
# posted by Dave Hay : 20:11
Subscribe to Posts [Atom]
