Oops, I pasted in the wrong notes of what I was sketching out... very sorry about that confusion. Totally botched up.
My question about your method was that a pvmove could be done to a snapshot, which I am going to answer myself by trying it right now. I thought that snapshot were inexorably connected to the source. If there is a problem I am sure I will see the errors. heh. Christopher G. Stach II wrote: > ----- "Ben M." <[email protected]> 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. > _______________________________________________ CentOS-virt mailing list [email protected] http://lists.centos.org/mailman/listinfo/centos-virt
