Les Mikesell <lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
