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." <cen...@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@centos.org > http://lists.centos.org/mailman/listinfo/centos-virt > _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
