A little bit of knowledge is a dangerous thing. I just wrote to the wrong lv with a dd and lost 5 days of work on a project. Dumb, dumb, dumb.
Ben M. wrote: > Ah, vgsplit. That is likely the answer. I was completely unfamiliar with > that command. > > Going to try that now. > > Good stuff again, thanks for the simple straightforward procedures. > > 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 > _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
