* [linux-lvm] moving a logical volume between servers
@ 2007-12-04 9:03 Brad Sickler
2007-12-04 16:46 ` Stuart D. Gathman
0 siblings, 1 reply; 4+ messages in thread
From: Brad Sickler @ 2007-12-04 9:03 UTC (permalink / raw)
To: linux-lvm
I'm surprised I couldn't find a good answer to the question before but I
want to move logical volumes from one computer to another.
A little more detail... I created a bunch of xen images on logical
volumes. I brought another computer up to split the load of all the
virtual machines and I want to move some volumes to the new computer.
When I created them I figured I could just dd them like a partition but
upon attempting this and booting the transported xen machine/logical
volume fsck showed some bad errors on the boot partition of the virtual
machine. The later partitions seemed fine.
I did some testing and found that I got the same error no matter the
block size. That if I created a new logical volume on the same machine
as the source and dd'd between them ala
lvcreate -n machine2 -L 20G lvmxen
dd if=/dev/lvmxen/machine of=/dev/lvmxen/machine2
machine2 worked just like machine.
But when I dd'd to a file, moved that file to another computer then dd'd
back into a new logical volume. I had the errors again.
I have some ideas on how to fix the error inside of the virtual machine
but they would be painful considering that I have 10 virtual boxes
running in this configuration.
So, I have a few questions for the lvm guru's.
A. Is it possible to move logical volumes from one computer to another?
And no, these aren't simple ext3 file systems so I can't just mount it
and export the files, they contain entire machines. I was hoping for
something in the nature of lvexport / lvimport but that obviously
doesn't exist.
B. Why does this occur?... I searched for a while but didn't find
anything concrete as to why this occurs. I've always thought that a
block device = a block device. Evidently I was wrong.
Thanks for any help.
Brad Sickler
Bioinformatician, Genome Center
University of California, Davis
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] moving a logical volume between servers
2007-12-04 9:03 [linux-lvm] moving a logical volume between servers Brad Sickler
@ 2007-12-04 16:46 ` Stuart D. Gathman
2007-12-05 3:11 ` f-lvm
0 siblings, 1 reply; 4+ messages in thread
From: Stuart D. Gathman @ 2007-12-04 16:46 UTC (permalink / raw)
To: LVM general discussion and development
On Tue, 4 Dec 2007, Brad Sickler wrote:
> I'm surprised I couldn't find a good answer to the question before but I
> want to move logical volumes from one computer to another.
>
> A little more detail... I created a bunch of xen images on logical
> volumes. I brought another computer up to split the load of all the
> virtual machines and I want to move some volumes to the new computer.
> When I created them I figured I could just dd them like a partition but
> upon attempting this and booting the transported xen machine/logical
> volume fsck showed some bad errors on the boot partition of the virtual
> machine. The later partitions seemed fine.
I do this all the time. You want to take a snapshot of the LV and copy
the snapshot. Make sure the target is the same size or bigger.
This works with journaled filesystems like ext3, xfs, reiserfs, jfs. If you do
it with ext2 or other non-journalled fs, you'll need to run fsck on the copy.
Oh, and once I reversed the src and dst :-( Now I have a co-worker check
before I press enter.
PS. It would be possible for LVM to flag PEs newly added to an LV as
"uninitialized". Attempts to read uninitialized data could result in
a read error. This would catch a lot of fat finger mistakes - if it
didn't break too much stuff in the process. Maybe just flag the entire LV
"write only" until the first write, and subsequent first reads would
return zeroes for security reasons. There should be a flag to disable
all this in case the LV is created for data recovery purposes.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
^ permalink raw reply [flat|nested] 4+ messages in thread* [linux-lvm] moving a logical volume between servers
2007-12-04 16:46 ` Stuart D. Gathman
@ 2007-12-05 3:11 ` f-lvm
2007-12-05 14:48 ` Stuart D. Gathman
0 siblings, 1 reply; 4+ messages in thread
From: f-lvm @ 2007-12-05 3:11 UTC (permalink / raw)
To: linux-lvm
> Date: Tue, 4 Dec 2007 11:46:56 -0500 (EST)
> From: "Stuart D. Gathman" <stuart@bmsi.com>
> Oh, and once I reversed the src and dst :-( Now I have a co-worker check
> before I press enter.
See my PS.
> PS. It would be possible for LVM to flag PEs newly added to an LV as
> "uninitialized". Attempts to read uninitialized data could result in
> a read error. This would catch a lot of fat finger mistakes - if it
> didn't break too much stuff in the process. Maybe just flag the entire LV
> "write only" until the first write, and subsequent first reads would
> return zeroes for security reasons. There should be a flag to disable
> all this in case the LV is created for data recovery purposes.
Would it be possible to use "blockdev --setro" on the source volume,
so nothing (well, except things that bypass the kernel or whatever)
can write to it? I haven't tried this; is there a gotcha?
Of course, this assumes that something else isn't legitimately writing
to the source LV while you're copying it, but presumably that would
lead to a corrupted copy anyway and it'd be good to catch that early...
P.S. This is why I bitterly resent the disappearance of write-protect
switches when hard disks transitioned from being removable media (like
those washing-machine-sized 300MB drives with their 12-platter disks)
to integrated units. How hard could it -be- to put a write-protect
jumper on the disk, or have some IDE/SATA/etc command that will
-definitely- write-lock the disk and for which userspace tools
exist to manipulate this? [Yeah, yeah, I know that none of this
applies in an LVM context. But I've done my share of dd'ing whole
drives in the past.]
Lacking these, write-lock requires active (and relatively sophisticated)
electronics that can play man-in-the-middle on the cable. That's
expensive and prone to obsolescence, although it apparently is a
good moneymaker for companies selling such things to people who have
to do forensics on drives and be able to state in court that their
analysis system couldn't have written to it...
Not being able to write-lock disks means I've had to be very, very
careful in a number of situations when I wished I didn't have to worry
so much about shooting myself in the foot.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [linux-lvm] moving a logical volume between servers
2007-12-05 3:11 ` f-lvm
@ 2007-12-05 14:48 ` Stuart D. Gathman
0 siblings, 0 replies; 4+ messages in thread
From: Stuart D. Gathman @ 2007-12-05 14:48 UTC (permalink / raw)
To: LVM general discussion and development
On Tue, 4 Dec 2007 f-lvm@media.mit.edu wrote:
> Not being able to write-lock disks means I've had to be very, very
> careful in a number of situations when I wished I didn't have to worry
> so much about shooting myself in the foot.
For IDE drives, hdparm -r will set the readonly flag for the entire
drive. I'm not sure if SATA has a similar feature. But as you say,
in a number of situations, a hardware jumper is better.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-12-05 14:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-04 9:03 [linux-lvm] moving a logical volume between servers Brad Sickler
2007-12-04 16:46 ` Stuart D. Gathman
2007-12-05 3:11 ` f-lvm
2007-12-05 14:48 ` Stuart D. Gathman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.