I'm using VMWare ESX 3.5.

I've just created a couple of different-flavour VMs (a Windows 2008 one and a Windows 2003 one), installed windows updates, and am generally happy with their pristine nature.

I will want to run them now, but reuse them from their current state later. So, I want to archive off a snapshot now, to come back to when I want to spin up more.

What are my options?

  • Manually zip up the directory that contains the VM and physically store that someplace else?
  • Something specific to VMWare ESX?

I have allocated xGb for the virtual disk; is unused-but-allocated space still taken up on the "real" disk?

Note: Backups are not my question - I'll handle that separately.


  • I'm not using vSphere or vCenter; that's AFAIK not available to me as an option here (separate license? Am unfamiliar).

Use VMWare Converter to connect to the ESX server - you can then "convert" your VM into a Virtual Appliance file (ovf), and store this on a network share, external hard drive etc. The appliance format will also compact your virtual hard drives, so you aren't archiving empty space.

You can also leave it as a VM, but the single ovf file is easier to manage IMHO.

Back in November 2009 VMware converter seemed to be the only VMware supported method for getting a VMs files out of the Datastore. Quick and easy too. Backup is another option, but VMWare converter is a lot easier to use for occaisonal archiving, or moving VMs around between different networks.

VMware Converter 4 will create ovf and VMs for ESX 3.5 and vSphere - make sure you use the appropriate one for your environment.

  • +1. in my experience moving VMs without a converter lead to unexpected results :) – monomyth Jan 13 '10 at 2:07
  • All I can find is the vCenter Converter Tool and it's used to convert a physical instance to vmware. I found the OVF - Tool and it looks like this is the tool for the job now vmware.com/support/developer/ovf ...any experience for this tool? – Goot Dec 14 '15 at 14:54

I have had this work before, but I'm sure there are others who wouldn't recommend it.

We're running ESXi and don't have servers that are necessarily 24/7 critical. I shut down the VM, then using the disk storage browser, copy the directory to a storage NAS and then 7zip the directory into one large 7z file (and verify there aren't any errors). This takes a LOT of time to copy over, but for us it works. If something goes wrong I can copy the VM back over to the ESXi server and point a new VM configuration there to fire it back up. Be aware that you may have to be careful about things like MAC addresses and such being "duplicated" if you're restoring; we do this primarily in case there's a failure of the VM server. Use MD5 sums to verify your large backup file when transferring it to make sure it's not corrupted in storage or transfer.

Another option is to treat your VM as a regular server and make full backups to your backup server. If there's a failure, spin up a new VM and do a "bare metal" restore on the virtual computer. This saves you having to have special storage set aside just for the virtual machines, which can easily grow to several gig each and the larger the file, the greater the chance that it'll get corrupted. This is probably a better solution in many cases because it eliminates variables with version of VMWare (your backup is one version, you upgrade VMWare or change something and forget, suddenly your backups are screwy...)

Your last option would probably be to get VMWare-specific backup solutions that are ESX-aware. Expensive as all get-out, but they're aware of the issues involved in file locking and access for the virtual disks, and you won't need to shut down the VM's to do the backup. Attempting any copying or modifications while it's running results in Bad Things(tm).

I've read that there are issues with using a VM that has snapshots and just copying files over as a "Backup" (my first suggestion), so I don't use snapshots in VMWare. I can't confirm the issues though.

  • 1
    Anopther thing you can do is to shut down the VM and export it as an appliance (in OVF format). You can then import the VM as an appliance to the same host if needed or to another host. – joeqwerty Jan 12 '10 at 14:43
  • I've done this and it works but if your xfring a lot or want to do it in a more automated fashion I'd recommend enabling SFTP on the ESX host and using either WinSCP or SFTP to pull the images down. I've found it faster and more reliable. – Antitribu Jan 12 '10 at 16:51

If you are using ESX in concert with vSphere Virtual Center, you should be able to create a "template" from your VM. The template, which is essentially a specially type of "clone," is stored on a VMFS volume just as a VM would. If the source VM uses "thin" disks, I believe the template would as well.

  • +1 for Templates in vSphere. vSphere can also customise the installation for each deployment to change the server name/license key as well. – Mark Henderson Jan 12 '10 at 22:28

I personally don't like leaving suspended VMs or seldom-used templates lying around, whether I have the space or not. I'd be tempted to just back them, either by using VCB or just copying the VM directory from the datastore - then removing the VM altogether if you need the space.

With v4 you could have SVM'ed the VM to thin disks first of course.

  • 1
    I don't know what "SVM'd the VM to thin disks first" means, sorry. I'm a developer, really, not a sysadmin ;-) – Peter Mounce Jan 12 '10 at 12:07
  • If you were using vsphere/version4 there's an option to convert your disks to 'thin' (smaller, slower) disks - thus saving you disk space - it uses a function called 'Storage vMotion' or SVM - sorry for the confusion. – Chopper3 Jan 12 '10 at 12:22
  • Thanks; but sadly I'm not using vSphere. – Peter Mounce Jan 18 '10 at 13:29

You just need to backup the vmdk and vmx files. The compressionratio's are good. If I had vCenter Server, I would use templates. Otherwise backups, as I described, are a better option.


As ktower mentions templates are the simplest method but only if you have Virtual Center\vCenter as the templating feature isn't available on standalone ESX\ESXi hosts. If you select to clone the VM to a compressed template you get a reasonably compact copy, it just removes unused space in the VMDK's it's not a true compression but it will create a much smaller set of files. It's important to mention that templates are also a set of files, just like a VM not a single file like an OVF.

I tend to put templates of systems that I want to save in this manner onto a NAS that is presented to the ESX host and make backups\copies directly from there when I want to move them around, in my experience this is faster (if more cumbersome) than exporting OVF's but a lot depends on the setup you are working with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.