----- "Ben M." <centos at rivint.com> wrote: > Does this appear to be a sound procedure? I have one inline question. I read your version of the procedure and it looks like you want to skip the pvmove. That's fine, but it means more downtime (an unreliable estimate is one minuted per GB). In that case, you don't even need the snapshot. You won't need a point in time copy if you are copying from a stable source. > 1. Shutdown domU source (source lvname = win2k8-source) which is never > file mounted in Xen dom0, just "lvm'd". Yeah, just turning off the guest and making sure it doesn't have the ``o'' flag set in the ``lvs'' output is enough. I hope that nothing else had it open (for writing) while your guest was running. :) > 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] A few milliseconds. It will return almost immediately. > 3. Bring up domU (Is this necessary if seeking accurate data state, > would rather keep offline on a weekend dayrather than lose data > entries.) The snapshot won't change. It's not necessary if you don't need your guest to be up. In fact, you can skip the whole snapshot bit if you don't care about downtime for your guest. Just dd from win2k8-source. You can't perform this step if you aren't going to use pvmove. Your source will change and your snapshot will be out of date. You would lose all of your changes between the snapshot and when you reboot the guest the second time. > 4. Create identical lv extent space (win3k8-target) on target pv/vg Yes, but win2k8-target. :) Since you are copying to a new VG, you can just keep the LV name the same. > 5. dd if=/dev/vgsnapshotsource/win2k8-snapshot > of=/dev/vgtarget/win2k8-target Yes, but you can specify a larger block size and it will take less time. I personally just default to using bs=1048576 for most things, even if it's not ideal. > 6. Shutdown DomU, change xen win2k8-source domU conf file phy: > reference to win2k8-target Nope. Keep it the same. You don't want to run from the snapshot or the backup copy, unless you're skipping the pvmove. If you are, you want to change the VG and/or LV name to the non-backup copy. > 6a. Drop snapshot, rename source lv to win2k8-old If you were going with pvmove, you would perform that after this step. > 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. So, we have two possible procedures intermingled here. The major differences are Procedure A (lots of downtime) and Procedure B (minimal downtime). Procedure A ~~~~~~~~~~~ 1. Create target LV with geometry identical to source LV geometry 2. Stop guest. 3. dd 4. Modify guest configuration to point to target LV 5. Start guest This is the procedure to use if simplicity is desired. As a perk, your source LV becomes your backup. Procedure B ~~~~~~~~~~~ 1. Create backup LV with geometry identical to source LV geometry 2. Stop guest. 3. Create snapshot of source LV 4. Start guest 5. dd from snapshot of source LV to backup LV 6. Drop snapshot of source LV 7. vgextend source VG with additional PV 7. pvmove source LV to additional PV (opt) 8. vgsplit [source VG into additional VG with additional PV] (opt) 9. Modify guest configuration [to point to source LV on additional VG] Procedure B can be different for Linux guests in that, depending upon your guest filesystem choices (ext3 journal, in particular) and site specific caching issues, step 2 could be "Pause guest" and step 4 would then be "Resume guest". Depending upon how you handle your PVs and VGs in the optional 8 and 9 steps, you may need to shut down your guest(s). Your desire to have one VG per PV will probably necessitate that being done eventually. -- Christopher G. Stach II