CentOS virt - Oct 2009 - Move Windows within an LV to another pv safely

----- "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

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.
>

----- "Ben M." <centos at rivint.com> wrote:
> What a mess that turned out to be. Hey, maybe it was your "awesome 
> numbering" <ducking and running>. jk, probably because I forgot
to
> take 
> some meds today or something.
Measure twice. Cut once. :)
> Oh, the dd quit on me before complete. Is it okay making the target lv
> bigger than the source when I try it again or does it have to be
> exact? 
> I need some extra disk space in that xen vm too.
You can make it larger if you want. The partition table copied from the source
will only have the original size allocated. Did you allocate the new LV with the
same number of extents on a VG with the same extent size? It should work
perfectly, if so.

-- 
Christopher G. Stach II