Discussion:
[linux-lvm] convert LV to physical device _in_place_?
Matthias Leopold
2017-07-13 13:25:10 UTC
Permalink
hi,

i'm fiddling around with LVM backed KVM raw disks, that i want to use
_directly_ in oVirt virtualization (as "Direct LUN"). i would like to
avoid "importing", dd, etc. if possible. in the KVM origin system exists
a mapping of one iSCSI whole device (no partitions) to one PV to one VG
to one LV per KVM disk. i can now present these iSCSI devices to the
oVirt hosts, where i can only use them as "Direct LUN" without the LVM
layer (i guess). so all i would need is to remove the LVM metadata from
the iSCSI device preserving the "content" of the LV. pvremove seems to
be too "intrusive" for this... i know this sounds rather naive and i
didn't find any recipes for it. everybody talks about dd to a new
device, which of course works (i tried it), but is exactly what i want
to avoid when migrating very large disks (TB). i hope someone
understands my concern and maybe has a solution

thx a lot
matthias
Zdenek Kabelac
2017-07-13 15:25:10 UTC
Permalink
Post by Matthias Leopold
hi,
i'm fiddling around with LVM backed KVM raw disks, that i want to use
_directly_ in oVirt virtualization (as "Direct LUN"). i would like to avoid
"importing", dd, etc. if possible. in the KVM origin system exists a mapping
of one iSCSI whole device (no partitions) to one PV to one VG to one LV per
KVM disk. i can now present these iSCSI devices to the oVirt hosts, where i
can only use them as "Direct LUN" without the LVM layer (i guess). so all i
would need is to remove the LVM metadata from the iSCSI device preserving the
"content" of the LV. pvremove seems to be too "intrusive" for this... i know
this sounds rather naive and i didn't find any recipes for it. everybody talks
about dd to a new device, which of course works (i tried it), but is exactly
what i want to avoid when migrating very large disks (TB). i hope someone
understands my concern and maybe has a solution
Hi

Yep, it really sounds a bit naive :)

PV has 'header' so the real 'data' are shifted by PV header+lvm2 metadata.
and also LV does not need to be sequential.

However if you have been having a single 'segment' LV and and you calculate
proper skipping offset (typically 1MB) you can try to use such device directly
without lvm2 with a loop device mapping - see losetup --offset option - but
you would need to use this everytime you want to access such storage - so
there is not a single magic 'flip' which would make an LV to appear like
regular device.

Regards

Zdenek
Stuart D. Gathman
2017-07-13 16:06:09 UTC
Permalink
Post by Zdenek Kabelac
PV has 'header' so the real 'data' are shifted by PV header+lvm2 metadata.
and also LV does not need to be sequential.
However if you have been having a single 'segment' LV and and you calculate
proper skipping offset (typically 1MB) you can try to use such device
directly without lvm2 with a loop device mapping - see losetup --offset
The AIX system used a single segment boot volume LV so that bootstrap
code needed only an offset and did not need to understand the LVM.
But the boot volume was a normal LV in all other respects. I think
there was a flag on the LV to ensure it remained a single segment.
--
Stuart D. Gathman <***@gathman.org>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
Matthias Leopold
2017-07-13 19:54:11 UTC
Permalink
Post by Zdenek Kabelac
Post by Matthias Leopold
hi,
i'm fiddling around with LVM backed KVM raw disks, that i want to use
_directly_ in oVirt virtualization (as "Direct LUN"). i would like to
avoid "importing", dd, etc. if possible. in the KVM origin system
exists a mapping of one iSCSI whole device (no partitions) to one PV
to one VG to one LV per KVM disk. i can now present these iSCSI
devices to the oVirt hosts, where i can only use them as "Direct LUN"
without the LVM layer (i guess). so all i would need is to remove the
LVM metadata from the iSCSI device preserving the "content" of the LV.
pvremove seems to be too "intrusive" for this... i know this sounds
rather naive and i didn't find any recipes for it. everybody talks
about dd to a new device, which of course works (i tried it), but is
exactly what i want to avoid when migrating very large disks (TB). i
hope someone understands my concern and maybe has a solution
Hi
Yep, it really sounds a bit naive :)
PV has 'header' so the real 'data' are shifted by PV header+lvm2 metadata.
and also LV does not need to be sequential.
However if you have been having a single 'segment' LV and and you calculate
proper skipping offset (typically 1MB) you can try to use such device
directly without lvm2 with a loop device mapping - see losetup
--offset option - but you would need to use this everytime you want to
access such storage - so there is not a single magic 'flip' which
would make an LV to appear like
regular device.
Regards
Zdenek
Hi Zdenek,

thanks for explaining. I practically knew it was impossible when i wrote
it, but sometimes i get carried away by fixed ideas and need someone
"authoritative" to tell me the obvious (with maybe a little technical
background)... you did the job ;-)

Regards

matthias
Marek Podmaka
2017-07-13 20:05:14 UTC
Permalink
Hello Zdenek,
Post by Zdenek Kabelac
However if you have been having a single 'segment' LV and and you calculate
proper skipping offset (typically 1MB) you can try to use such device directly
without lvm2 with a loop device mapping - see losetup --offset option - but
you would need to use this everytime you want to access such storage - so
there is not a single magic 'flip' which would make an LV to appear like
regular device.
Wouldn't creating a partition with correct start sector work as a permanent
solution? (Although I didn't understand if using a partition is an
option for the original poster.)
--
bYE, Marki
Stuart Gathman
2017-07-14 03:41:12 UTC
Permalink
Post by Matthias Leopold
i'm fiddling around with LVM backed KVM raw disks, that i want to use
_directly_ in oVirt virtualization (as "Direct LUN"). i would like to
avoid "importing", dd, etc. if possible. in the KVM origin system
exists a mapping of one iSCSI whole device (no partitions) to one PV
to one VG to one LV per KVM disk. i can now present these iSCSI
devices to the oVirt hosts, where i can only use them as "Direct LUN"
without the LVM layer (i guess). so all i would need is to remove the
LVM metadata from the iSCSI device preserving the "content" of the LV.
pvremove seems to be too "intrusive" for this... i know this sounds
rather naive and i didn't find any recipes for it. everybody talks
about dd to a new device, which of course works (i tried it), but is
exactly what i want to avoid when migrating very large disks (TB). i
hope someone understands my concern and maybe has a solution
I use iSCSI at home, and I just export the LV as an iSCSI target. Now
you have direct LUN for use with VM hosts on the network (I just have a
gigabit LAN at home). The iSCSI server still uses LVM, and you can
snapshot the volume for backup on the server.

Maybe that's too obvious, and I misunderstood your problem?

There is no LVM metatdata on the exported iSCSI devices - that is on the
underlying disk. As the export LUN looks like a disk, you can even add
an optional partition table, PVs, VGs, etc for use by the virtual machine.
Loading...