----- "Ben M." centos@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.
- 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. :)
- 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.
- 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.
- 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.
- 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.
- 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.
- Start "new" domU.
- 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.
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@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.
- 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. :)
- 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.
- 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.
- 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.
- 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.
- 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.
- Start "new" domU.
- 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
- Create backup LV with geometry identical to source LV geometry
- Stop guest.
- Create snapshot of source LV
- Start guest
- dd from snapshot of source LV to backup LV
- Drop snapshot of source LV
- vgextend source VG with additional PV
- 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.
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@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.
- 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. :)
- 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.
- 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.
- 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.
- 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.
- 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.
- Start "new" domU.
- 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
- Create backup LV with geometry identical to source LV geometry
- Stop guest.
- Create snapshot of source LV
- Start guest
- dd from snapshot of source LV to backup LV
- Drop snapshot of source LV
- vgextend source VG with additional PV
- 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
----- "Ben M." centos@rivint.com wrote:
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).
Mm hmm. pvmove only works within a VG. You would need to do the vgextend for it to at least be temporarily joined and then vgsplit later. I've found that it's usually worth the extra steps to be able to pvmove.
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.
I run into an occasional issue with dropping temp pv's assigned to vg's to move things around. I've learned to do pvck, vgck, lvscan, etc. to make sure everything in order whenever I do anything related to lvm. Occasionally I get "vg corruption" wherein the IUD is still being sought and I have to "vgreduce --removemissing <vgname>" to make sure all is clean. If I reboot with that in the root containing vg, I hang on boot and lose remote access (no serial hookup yet, planned for next machine).
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.
Christopher G. Stach II wrote:
----- "Ben M." centos@rivint.com wrote:
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).
Mm hmm. pvmove only works within a VG. You would need to do the vgextend for it to at least be temporarily joined and then vgsplit later. I've found that it's usually worth the extra steps to be able to pvmove.
----- "Ben M." centos@rivint.com wrote:
Oops, I pasted in the wrong notes of what I was sketching out... very sorry about that confusion. Totally botched up.
Yeah, like my awesome numbering skills in B. :)
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.
You drop the snapshot before you pvmove (step 6).
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." centos@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.
- 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. :)
- 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.
- 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.
- 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.
- 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.
- 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.
- Start "new" domU.
- 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
- Create backup LV with geometry identical to source LV geometry
- Stop guest.
- Create snapshot of source LV
- Start guest
- dd from snapshot of source LV to backup LV
- Drop snapshot of source LV
- vgextend source VG with additional PV
- 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
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." centos@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.
- 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. :)
- 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.
- 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.
- 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.
- 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.
- 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.
- Start "new" domU.
- 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
- Create backup LV with geometry identical to source LV geometry
- Stop guest.
- Create snapshot of source LV
- Start guest
- dd from snapshot of source LV to backup LV
- Drop snapshot of source LV
- vgextend source VG with additional PV
- 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
-
Ben M. -
Christopher G. Stach II