* [linux-lvm] convert LV to physical device _in_place_?
@ 2017-07-13 13:25 Matthias Leopold
2017-07-13 15:25 ` Zdenek Kabelac
2017-07-14 3:41 ` Stuart Gathman
0 siblings, 2 replies; 6+ messages in thread
From: Matthias Leopold @ 2017-07-13 13:25 UTC (permalink / raw)
To: linux-lvm
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] convert LV to physical device _in_place_?
2017-07-13 13:25 [linux-lvm] convert LV to physical device _in_place_? Matthias Leopold
@ 2017-07-13 15:25 ` Zdenek Kabelac
2017-07-13 16:06 ` Stuart D. Gathman
` (2 more replies)
2017-07-14 3:41 ` Stuart Gathman
1 sibling, 3 replies; 6+ messages in thread
From: Zdenek Kabelac @ 2017-07-13 15:25 UTC (permalink / raw)
To: LVM general discussion and development, Matthias Leopold
Dne 13.7.2017 v 15:25 Matthias Leopold napsal(a):
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] convert LV to physical device _in_place_?
2017-07-13 15:25 ` Zdenek Kabelac
@ 2017-07-13 16:06 ` Stuart D. Gathman
2017-07-13 19:54 ` Matthias Leopold
2017-07-13 20:05 ` Marek Podmaka
2 siblings, 0 replies; 6+ messages in thread
From: Stuart D. Gathman @ 2017-07-13 16:06 UTC (permalink / raw)
To: LVM general discussion and development
On Thu, 13 Jul 2017, Zdenek Kabelac wrote:
> 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 <stuart@gathman.org>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] convert LV to physical device _in_place_?
2017-07-13 15:25 ` Zdenek Kabelac
2017-07-13 16:06 ` Stuart D. Gathman
@ 2017-07-13 19:54 ` Matthias Leopold
2017-07-13 20:05 ` Marek Podmaka
2 siblings, 0 replies; 6+ messages in thread
From: Matthias Leopold @ 2017-07-13 19:54 UTC (permalink / raw)
To: LVM general discussion and development; +Cc: zkabelac
Am 2017-07-13 17:25, schrieb Zdenek Kabelac:
> Dne 13.7.2017 v 15:25 Matthias Leopold napsal(a):
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] convert LV to physical device _in_place_?
2017-07-13 15:25 ` Zdenek Kabelac
2017-07-13 16:06 ` Stuart D. Gathman
2017-07-13 19:54 ` Matthias Leopold
@ 2017-07-13 20:05 ` Marek Podmaka
2 siblings, 0 replies; 6+ messages in thread
From: Marek Podmaka @ 2017-07-13 20:05 UTC (permalink / raw)
To: Zdenek Kabelac, LVM general discussion and development,
Matthias Leopold
Hello Zdenek,
Thursday, July 13, 2017, 17:25:10, you wrote:
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] convert LV to physical device _in_place_?
2017-07-13 13:25 [linux-lvm] convert LV to physical device _in_place_? Matthias Leopold
2017-07-13 15:25 ` Zdenek Kabelac
@ 2017-07-14 3:41 ` Stuart Gathman
1 sibling, 0 replies; 6+ messages in thread
From: Stuart Gathman @ 2017-07-14 3:41 UTC (permalink / raw)
To: linux-lvm
On 07/13/2017 09:25 AM, Matthias Leopold wrote:
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-07-14 3:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-13 13:25 [linux-lvm] convert LV to physical device _in_place_? Matthias Leopold
2017-07-13 15:25 ` Zdenek Kabelac
2017-07-13 16:06 ` Stuart D. Gathman
2017-07-13 19:54 ` Matthias Leopold
2017-07-13 20:05 ` Marek Podmaka
2017-07-14 3:41 ` Stuart Gathman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).