[Pkg-xen-devel] (re-titled) partitions and LVs

[Ian Campbell]

On Tue, 2011-12-27 at 14:11 +0100, Daniel Pocock wrote:
> 
> On 20/12/08 19:05, Ian Campbell wrote:
> > On Sat, 2008-12-20 at 16:29 +0000, Daniel Pocock wrote:
> >> My only other concern with the domU is that it has partitioned an LVM 
> >> volume, and grub installed to the MBR.  That makes it more awkward to 
> >> mount the LVM volume from dom0 (although not impossible).  Should I have 
> >> used
> >>
> >> disk = ['phy:vg00/th2_root,xvda1,w']
> >>
> >> instead of
> >>
> >> disk = ['phy:vg00/th2_root,xvda,w']  ?
> >>
> >> Would the grub install work with the latter approach?
> > 
> > I don't like that way myself but I think it would work, the installer
> > might be confused during the partitioning phase I guess.
> > 
> > I use kpartx in dom0 which makes is reasonably simple to mount the
> > individual partitions of an LVM device.
> > 
> 
> Can anyone comment on whether both approaches are still generally
> considered to be valid, and/or, in which situations?

Both continue to be valid and supported. It's largely a case of personal
preference and what fits best with a particular deployment.

> My current understanding of the issue:

That looks about right.

I would just add that the "whole disk" approach is what is tested and
works well with Debian Installer. The "individual partitions" approach
is more suitable / a better fit for the debbootstrap style of deployment
(at least IMHO) but is not tested with D-I.

(I've forgotten all of the context of this mail, was it that something
was a bit kooky using the partitions approach with D-I?)

> Benefits of having a partition table on the LV used by the domU:
> - some software seems to expect this
> - better for situations where each domU has a distinct sys admin (e.g. a
> virtual hosting provider where each domU is owned by a different customer)
> - better for SANs and iSCSI with many volumes and servers, as the
> partition table serves as a kind of label to help identify the filesystem
> - domU /etc/fstab can have meaningful device (LV) names if a nested VG
> is used

I'm not sure about this last one. Is it just that with the per-partition
scheme dom0 will also see the PV (LVM sense of the term) and hence the
VG and so you need a naming scheme to keep everything straight in the
admin's head and/or prevent naming conflicts?

> Benefits of giving the domU a different dom0 LV for each of it's
> filesystems:
> - easier to mount/administer from the dom0 (no need for kpartx and
> vgimport, lvchange, etc)
> - easier to move individual LVs between different domUs (whereas
> resizing a partition requires a domU reboot)
> - easier to resize (expand or shrink) individual LV allocations on the
> dom0s VG (consequently more space efficient)

Note that you can also combine the two schemes, e.g. present xvda as a
full disk with a partition table containing the root filesystem and
present xvdb1 as a partition, e.g. containing a data partition which you
might want to move between VMs.

Ian.
-- 
Ian Campbell
Current Noise: Textures - Minor Earth, Major Skies

The road to Hades is easy to travel.
		-- Bion