Re: still a problem with gpt(8) reading from LVM volumes? (was: problems with GPT (and maybe dkctl wedges) on LVM volumes)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 18 Mar 2021 18:44:14 -0700
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1lN4BS-0036x90@more.local>


  | I'm still not quite sure why gpt(8) can't show me the full partition
  | table when reading from a raw LVM volume (dm) device as above in exactly
  | the same way it does when reading from the raw (xbd emulated) disk in
  | the domU.

I don't know much about LVM, but I suspect that the dm has some extra
structure that is needed to manage its lvm sub-devices, which isn't present
in a physical drive, or an emulated physical drive like an xbd.

We have two kinds of things that present a somewhat disk like interface
(random access to a large number of fixed sized blocks) - those are
actual disk drives (virtual or physical) and logical partitions (filesystem
devices).

The latter are simply an array of blocks, with no structure other than
whatever the filesystem used imposes on them.   The former have labels
which can divide the device into a number of the latter, which are then
what gets used.

xdb (and sd wd vnd cgd ccd raid) are all devices.   dk ld and lvm (and maybe
some more) and sdNa (partitions from a disklabel) are all partitions.

gpt (and disklabel, fdisk) only work on devices, not partitions (technically,
I guess they could be used on a partition, or could be coerced to work that
way, but nothing would use the label they install).

A partition can be turned into a device by running a "filesystem" in it
which presents a device interface (raid, ccd, cgd, also passing it to
a DomU where it becomes an xbd is the same).   Then you can add a label (any
appropriate one of the 3 supported).   Similarly, you can make a file in
a filesystem, and then make that a "device" with vnd.

Unfortunately, the terminology is very murky, from the way things developed
historically, and all these things tend to be called "disk" in some
situations or other (ie: originally filesystems went on disks, then disks
grew partitions, which hold filesystems, but filesystems went on disks,
so the partitions must be disks, right?)

What I do for my systems is not use sysinst on DomU's, instead I make
however many partitions I need in the Dom0, extract (or more commonly
build with their structure mounted as RELEASEDIR) then unmount from the
Dom0 and pass the partitions used as separate "drives" to the DomU.
When the DomU is running, it has access to the partitions as any number
of drives (from 1 (root) for simple tests, to quite a few if I am doing
some kind of pkgsrc building).  When it isn't running the partitions become
available to be mounted on the Dom0 (or a different DomU ... these days I
use one DomU to build into a RELEASEDIR which is a separate xbd and which
becomes the root of the new DomU) and whatever I need to do there (including
analysis of crashes, config setups, etc) can be done.   I do no division
(no internal partitions) of the xbd drives inside the DomU - there it just
sees the fake label that the kernel invents when it sees an unlabelled drive.
There is no real advantage of having a single xbd that is partitioned,
over several different xbds.   That is, unless I was doing sysinst testing,
then of course things would be done differently.

kre