Using vmsnap_all and Windows share you can backup all your running VM’s. This does require some modifications to the default vmsnap.pl file which ships as part of VMware’s ESX Server. Basically, you make /vmimages point to a Windows Share – and instruct vmsnap.pl not to use SCP as it was originally designed to do. VMsnap.pl also checks the free available disk space – this has to be disabled – because the SMB Client in ESX cannot check the available free-space on a Windows Share.
Once you are setup you merely have to type:
to backup every running virtual machine to a Windows Shared location
- It’s up to you how you do the name resolution to the Windows Server
- You could have name resolution via DNSâ€¦ if so then you need to check /etc/resolv.conf
- You could have name resolution via the hosts file on with the Service Consoleâ€¦ if so then you need check /etc/hosts
- If this is the first time you have ever used vmsnap.pl – you need to set-up SSH Key Authentication on the ESX host
- Even though SCP is not used during the transfer process vmsnap.pl requires itâ€¦
Setting up SSH Key Authentication on the ESX Server (Could be
1. Logon to the Service Console as ROOT
ssh-keygen -t dsa
ssh-keygen allows you to create public and private key pairs. -t allows you to specify the type of key you wish to generate, in this case a dsa key.
Accept the default location for the files, which is a hidden directory in ROOT’s home directory, and do not specify a pass-phrase. If you do you will have to type this in every time you run.
3. Check the files that have been created by using:
This should list all the files id_dsa and id_dsa.pub – the -la switch list all files, even ones that are hidden
4. Copy your .pub file into a authorized_keys file with:
cp /root/.ssh/id_dsa.pub /root/.ssh/authorized_keys
You can check if this copy was successful with:
diff id_dsa.pub authorized_keys
If there is no difference between the files – then nothing is displayed on screen. If there is – it prints the contents of each file for comparison.
5. To Test “local” authentication, type:
This can take a short while the first time you try it so be a bit patient. It’s virtue remember â€¦
6. Choose Yes, to accept the key
When you choose Yes – to these kind of prompts you’re accepting the identity of the server for the first time. These prompts get “cached” to a file called known_hosts. This file is located also in /root/.ssh – it is a text file. Entries should be removed as when servers are removed or renamed
7. Run, ssh yourservername again, to check you are NOT prompted for your user credentials again.
This is very, very important. If you are prompted for a password you have made a mistake. Go back and try again. The backup perl script will not work properly if you are challenged for a password!
My most common error when doing this is spelling authorized _key (UK Spelling) instead of authorized _keys (US spelling!)
Setting up your Windows Shares
Many people set-up their vmimages locally – in this case I am making /vmimages point to a network location.
1. Share a folder on Windows Machine
2. Logon to the Service Console as ROOT
nano -w /etc/fstab
4. At the end of the file type:
//instructor/vmimages /vmimages smbfs ip=192.168.2.200,username=administrator,password=Password1,noauto 0 0
//instructor/vmimages is the name of my server and the sources is the folder I shared. /sources will be the name of our mounting point. Smbfs tells the system to use the SMB protocol. IP is my ip address on my network. I used the administrator account to gain access. Noauto means X, and 0 0 means do not do a file system check or memory dump/cache
5. Save the File and Exit nano
6. Then mount the /vmimages location with
Test you can create a file in this location – if not review your permissions
7. To see the files use cd /vmimages and ls -l to list them
The definition in the mount point in fstab will survive reboots – but you will have to use mount /vmimages at the Service Console to view the files themselves. It’s a performance hit on the Service Console to have network mount points open all the time. So they should be mounted and unmounted when required
If you are using Windows 2003 – you might find you get this error
This is caused by the introduction of “security signing” of SMB packets as a default (this was optional in Windows 2000). The Service Console implementation of SAMBA does not support this. The only solution is to lower the security of the file server to which you are trying to connect to. Using the Windows Policy system (make sure you use the right one! There are many!)
Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options
Locate the policy called “Microsoft network server: Digitally sign communications (always)”
Choose © Disabled
This issue is outlined in the MS KB Article 823659
Re-engineering the vmsnap_all.pl to Export to SMB Location
- When vmsnap_all runs it in fact calls vmsnap.pl. Vmsnap.pl checks the destination export location for free disk space
- Vmsnap.pl was designed to export to a local EXT3 partition not a SMB share.
- I believe that the smbclient is unable to retrieve this information – and without modification
the script fails with “There is not enough space to export the path to vmdk file”. This happens
even if there is TB worth of free space
“ To use vmsnap.pl to smb we need to disable this check
1. Logon to the Service Console as ROOT
nano -w /usr/sbin/vmsnap.pl
3. In nano type control+w to find the string: df and locate this section of script – and use # to remark out the if-statement which checks for free disk space. Like so:
You can now use vmsnap_all to backup all your running virtual machines to the windows server
4. I also disable the SCP copy part of vmsnap.pl - as this no-longer required
If you want to automate this you can write a bash shell script like this:
echo Backing up all running virtual machines
A script like this can be linked to cron to make the backup run at a specified time.
This was first published in January 2006