Les Mikesell <lesmikesell AT gmail DOT com> wrote on 09/10/2009 12:02:15 PM:

> > And I have another idea 'coz of rsync copying the whole .vdmk file 
over-
> > this could be related to access time. Obviously the times changes as 
the
> > file is under continously access from the ESX host. I'll see if I can
> > skip the time identification and force rsyn just to check the content.
> 
> You'll almost certainly end up with an unusable copy if you let the VM 
> run while copying - unless you can isolate changes with a snapshot.

Even then, this is an unsupported state, and will fail on restore (the 
worst possible time!) in most cases.  The only way to do this properly is 
to:

        Shut down the guest, quiesce the filesystem (which may happen 
automatically:  e.g. ext3), take an LVM snapshot, and restart the guest, 
or 

        WUse VMware's snapshot functionality and just copy the files 
normally without any kind of LVM snapshot--and plan on reverting the 
snapshot if you restore the VM!

We combine these two for maximum reliability:  shut down the guest, VMware 
snapshot the guest, restart the guest and copy the files from the 
filesystem.  Once the copy has finished, we simply delete the snapshot 
(which freezes the guest for a few *minutes*, so be prepared for this). In 
the event of a restore, we revert the snapshot (returning the VM to the 
shut down state before the snapshot) and restart the VM just as if we were 
simply powering it up cleanly.

Minimal fuss and greatest reliability in the event of disaster.  Not only 
does this give you the cleanest state, it allows you to restore a guest VM 
to a machine with different underlying hardware (there are CPUID and NX 
issues if you try to do this with a powered-on guest).  The biggest 
hassles are having to shut down the guest for a minute or two to create a 
clean snapshot, and the freezing of the guest for some small period of 
time while the snapshot is committed.

It is *not* completely transparent, but that's what you get when you're 
using the free tools.  If you want truly transparent, VMware will happily 
sell you their vMotion and backup tools.  They're even relatively 
reasonably priced.

> > For the 2GB chunks idea it'll take quiet a while to migrate the 540GB
> > vmdk to 2GB chunks. Oh, and I think ESX does not support this type...
> 
> I think vmware server can do it, but I'm having trouble finding a spot 
> with enough space since I took the full amount on the physical drives 
> for what I want to mirror.

VMware Sever 2.0 supports disks in single files, or split in 
arbitrary-sized pieces (usually 2GB), both fully allocated or 
grow-on-demand.  ESX/ESXi only supports single-file images, and it is 
designed to use VMFS.  I don't know for sure if you can use split images 
across an NFS share (the only non-block NAS-style share supported by 
ESX/ESXi), but my guess is no--the tools won't let you, and part of the 
process of converting a guest from Server to ESX/ESXi is to create the 
appropriate image file format.

Tim Massey


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/