Manage Learn to apply best practices and optimize your operations.

Online Backup to Windows Share using vmsnap_all and (W2K3)

Using vmsnap_all and Windows share you can backup all your running VM’s. This does require some modifications to the default file which ships as part of VMware’s ESX Server.

Using vmsnap_all and Windows share you can backup all your running VM’s. This does require some modifications to the default file which ships as part of VMware’s ESX Server. Basically, you make /vmimages point to a Windows Share – and instruct not to use SCP as it was originally designed to do. 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 – you need to set-up SSH Key Authentication on the ESX host
  • Even though SCP is not used during the transfer process requires it…

Setting up SSH Key Authentication on the ESX Server (Could be Optional)
1. Logon to the Service Console as ROOT
2. Type:

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:

cd /root/.ssh
ls -la

This should list all the files id_dsa and – 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/ /root/.ssh/authorized_keys

You can check if this copy was successful with:

diff 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:

ssh yourservername

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
3. Type:

nano -w /etc/fstab

4. At the end of the file type:

//instructor/vmimages /vmimages  smbfs ip=,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

mount /vmimages

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

SMB 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 to Export to SMB Location

  • When vmsnap_all runs it in fact calls checks the destination export location for free disk space
  • 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 to smb we need to disable this check

1. Logon to the Service Console as ROOT
2. Type:

nano -w /usr/sbin/

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:

First Edit to

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 - as this no-longer required

2nd Edit of

If you want to automate this you can write a bash shell script like this:

echo Backing up all running virtual machines
mount /vmimages
umount /vmimages

A script like this can be linked to cron to make the backup run at a specified time.

Dig Deeper on VMware ESX and ESXi administrative tips

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.