Copying a raw disk image to LVM2
I have been hunting for some time over the past couple of days, and find several documentss that talk about converting from an LVM2 volume to a raw disk image for Xen, but nothing about the reverse.
I have a VHD disk file that I would like to put on to an LVM2 volume, like my other DomU guests.
I can see using dd, but am concerned about overwriting the LVM2 header.
Does anybody have any suggestions?
Thanks,
Brian
If you write from disk image to virtual LVM device, you will never overwrite LVM metadata. The most convenient way to copy VM image is using qemu-img, since it may not copy unallocated places of VM image, leaving it uninitialized in LVM, which is significantly faster.
2016-07-08 20:52 GMT+05:00 Brian McCullough <[email protected]>:
Quoted 24 lines
I have been hunting for some time over the past couple of days, and find several documentss that talk about converting from an LVM2 volume to a raw disk image for Xen, but nothing about the reverse.
I have a VHD disk file that I would like to put on to an LVM2 volume, like my other DomU guests.
I can see using dd, but am concerned about overwriting the LVM2 header.
Does anybody have any suggestions?
Thanks,
Brian_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Signature · 1 line
Segmentation fault
Quoted 5 lines · Brian McCullough
I have been hunting for some time over the past couple of days, and find several documentss that talk about converting from an LVM2 volume to a raw disk image for Xen, but nothing about the reverse.
Quoted 7 lines
I have a VHD disk file that I would like to put on to an LVM2 volume, like my other DomU guests.
I can see using dd, but am concerned about overwriting the LVM2 header.
Does anybody have any suggestions?
I've done this with KVM before just fine. The LV metadata won't be overwritten when you write to the actual LV. So this would work fine;
dd if=/path/to/image.raw of=/dev/vg0/lv_foo bs=4M; sync
Then just change your server's definition to point at the LV instead of the raw file and voila.
Signature · 4 lines
Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
One note: sync does not syncs written data, since it affects only data, written through filesystem. You should use dd .... conv=fdatasync instead.
2016-07-09 22:00 GMT+05:00 Digimer <[email protected]>:
Quoted 33 lines · Brian McCullough
Quoted 5 lines
I have been hunting for some time over the past couple of days, and find several documentss that talk about converting from an LVM2 volume to a raw disk image for Xen, but nothing about the reverse.
Quoted 7 lines
I have a VHD disk file that I would like to put on to an LVM2 volume, like my other DomU guests.
I can see using dd, but am concerned about overwriting the LVM2 header.
Does anybody have any suggestions?
I've done this with KVM before just fine. The LV metadata won't be overwritten when you write to the actual LV. So this would work fine;
dd if=/path/to/image.raw of=/dev/vg0/lv_foo bs=4M; sync
Then just change your server's definition to point at the LV instead of the raw file and voila.
--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without access to education?_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Signature · 1 line
Segmentation fault
Quoted 3 lines · ???????? ??????????????????
One note:
syncdoes not syncs written data, since it affects only data, written through filesystem. You should usedd .... conv=fdatasyncinstead.
Thank you both.
This is essentially the answer that I got from the Xen group, as well, so I went ahead and tried it. No problems.
Brian
the lvm metadata is stored in the begining of the physical volume, the logical volume is simple block device, so using dd you don't overwrite any lvm header.
2016-07-09 19:33 GMT+02:00 Марк Коренберг <[email protected]>:
Quoted 49 lines
One note:
syncdoes not syncs written data, since it affects only data, written through filesystem. You should usedd .... conv=fdatasyncinstead.2016-07-09 22:00 GMT+05:00 Digimer <[email protected]>:
Quoted 28 lines · Brian McCullough
Quoted 5 lines
I have been hunting for some time over the past couple of days, and find several documentss that talk about converting from an LVM2 volume to a raw disk image for Xen, but nothing about the reverse.
Quoted 7 lines
I have a VHD disk file that I would like to put on to an LVM2 volume, like my other DomU guests.
I can see using dd, but am concerned about overwriting the LVM2 header.
Does anybody have any suggestions?
I've done this with KVM before just fine. The LV metadata won't be overwritten when you write to the actual LV. So this would work fine;
dd if=/path/to/image.raw of=/dev/vg0/lv_foo bs=4M; sync
Then just change your server's definition to point at the LV instead of the raw file and voila.
--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without access to education?Quoted 5 lines
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/--
Segmentation fault_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Signature · 5 lines
.~. /V\ // \\ /( )\ ^`~'^
emmanuel segura schreef op 11-07-2016 0:02:
Quoted 3 lines
the lvm metadata is stored in the begining of the physical volume, the logical volume is simple block device, so using dd you don't overwrite any lvm header.
I must say I did experience something weird when copying a LUKS partition (encrypted).
Apparently LUKS stores information about the device it is on (or was one) because I coudln't get it to re-adjust to a larger volume.
cryptsetup resize is supposed to resize to the size of the underlying block device.
I had to recreate my LUKS container before it would recognise the new size.
E.g. I copied from 2GB volume to 3GB volume using dd.
LUKS kept thinking it was still on a 2GB volume.
So resize didn't work and I could manually resize it to 3GB but automatic resize would resize it back to 2GB.