Ack. It wants to be in same Volume Group. I want to keep my VGs segregated to PVs segregrated to distinct harddrives (or devmapped raid1s). But it "almost" worked. :) Ben M. wrote: > 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." <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. >> > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt >