moving a logical volume between servers
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
Quoted 10 lines · Brad Sickler
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.
Signature · 4 lines
Stuart D. Gathman <[email protected]> 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.
Quoted 5 lines
Date: Tue, 4 Dec 2007 11:46:56 -0500 (EST)
From: "Stuart D. Gathman" <[email protected]>Oh, and once I reversed the src and dst :-( Now I have a co-worker check before I press enter.
See my PS.
Quoted 7 lines
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.
Quoted 3 lines · On Tue, 4 Dec 2007 [email protected] 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.
Signature · 4 lines
Stuart D. Gathman <[email protected]> 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.