Re: problems with GPT (and maybe dkctl wedges) on LVM volumes

[mlelstv%serpens.de@localhost (Michael van Elst)]

woods%planix.ca@localhost ("Greg A. Woods") writes:

>Also it seems dkctl doesn't work as I had expected it would on LVM
>partitions, even though it can apparently find a viable partition:

># dkctl /dev/mapper/rvg0-nbtest.0 getwedgeinfo
>vg0-nbtest.0 at vg0-nbtest.0: vg0-nbtest.0
>vg0-nbtest.0: 41943040 blocks at 0, type: ffs

The LVM volume acts like a partition (or wedge), not a partitionable
disk.

># dkctl /dev/mapper/rvg0-nbtest.0 makewedges
>dkctl: /dev/mapper/rvg0-nbtest.0: makewedges: Inappropriate ioctl for device

The LVM volume is not a disk.

># dkctl /dev/mapper/rvg0-nbtest.0 addwedge nbtest-root 64 41942943 ffs
>dkctl: /dev/mapper/rvg0-nbtest.0: addwedge: Inappropriate ioctl for device

It is still not a disk.


>So it looks like I'm back to using plain MBR for domUs again, at least
>for my next round of Xen server rebuilds.

Partitioning doesn't work recursively. You start with a disk that
can be partitioned (e.g. disklabel partitions or wedges). The
partitions cannot be partitioned further.

LVM volumes (dm devices) act like partitions not like disks.


You have two workarounds:

- use device mapper directly (not LVM) to subdivide dm devices into
smaller dm devices to access the guest partitions.

- create a ccd(4) disk on top of a partition or LVM volume (with a
recent kernel). The ccd device is a disk again and partitioning
works on it. Some people use raid(4) instead, but ccd(4) is easier.


There are still two caveats.

The DomU xvbd driver always pretends that the disk has 512 byte
sectors which is bogus. But Dom0 sees the real disk and presents
disk and partitions as having the real (logical or emulated) sector
size. If this isn't the same, you cannot access the guest filesystem
from DomU.

Even when you can access the filesystem, you must not mount it
concurrently on Dom0 and DomU (both mounting read-only is ok).

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."