Thanks again Christopher, you continue to be a welcome source of help. Though I have some knowledge gaps on the veracity of snapshots on a "non-ext3" lv I am going to try this and am starting the snapshot. Does this appear to be a sound procedure? I have one inline question. 1. Shutdown domU source (source lvname = win2k8-source) which is never file mounted in Xen dom0, just "lvm'd". 2. snapshot source win2k8-source to win2k8-snapshot [How long do I wait before bringing DomU source back up? Is there in indication when it is done? It is approx. 50gig] 3. Bring up domU (Is this necessary if seeking accurate data state, would rather keep offline on a weekend dayrather than lose data entries.) 4. Create identical lv extent space (win3k8-target) on target pv/vg 5. dd if=/dev/vgsnapshotsource/win2k8-snapshot of=/dev/vgtarget/win2k8-target 6. Shutdown DomU, change xen win2k8-source domU conf file phy: reference to win2k8-target 6a. Drop snapshot, rename source lv to win2k8-old 7. Start "new" domU. 8. test extensively, if works, run for few a day or two. Keep *-old as fallback for a week or so. Then move to an archive using dd. Christopher G. Stach II wrote: > ----- "Ben M." <centos at rivint.com> wrote: > >> BUT, according to 'man pvmove' it doesn't have a switch to leave a >> copy >> behind, or the old extents in place for a fallback. That makes me a >> little apprehensive about having something ready to roll back to in >> its >> most current "data" state. > > Right, it doesn't. To keep downtime minimal, you can shut down the windows guest, create an LVM snapshot of the guest's LV, boot the guest back up, dd from the snapshot to a new LV for your backup, remove the snapshot, and then pvmove. Be patient with pvmove, as it can take a while. >