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@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.