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

[Daniel Pocock]

>> No, I was just hoping to get clarification of the issue, because I've
>> seen it described in different ways.  Also, I imagine that more
>> experienced people have comprehensive solutions for this (e.g. how they
>> expand their LVs when partition tables are present), but those type of
>> important details are not covered in any of the basic documents that
>> most users are likely to come across online.  I was hoping to tease out
>> some of those details
> 
> Hmm, I'm not sure, I expect they do it just like they do on a physical
> system -- e.g. by adding a new disk, putting a new PV on that, adding it
> to the VG,  resizing the LV and finally resize the filesystem, at least
> that's what I would do...

Yes, that works - but you could end up with a lot of LVs on the dom0,
not such a pretty solution.  You also have extra work for yourself if
you want to move them from one dom0 to another or some other storage
migration project in future.

> Can you resize a PV with LVM? That would allow you to skip some of those
> steps by just resizing the backend device.

1) You can resize the LV in the dom0 with lvresize
2) You then have the problem of adjusting the partition table (e.g.
delete and re-add the last partition entry to use all available space).
3) The pvresize command automates the next step (expanding the PV on the
bigger partition).  Just `pvresize /dev/xvda4'

In this example, step (2) is the messy one, I imagine some people would
feel a little bit nervous temporarily deleting their partitions in
production.  parted or other tools offer a resize function for step (2)

>> One thing I would like to do is get a wiki page up and running about
>> this issue, because it is fundamental for anyway running VMs, and the
>> waters are about to be muddied a lot more with the coming of btrfs
>> (where md and subvolume behaviour is implemented by the FS, for
>> example), so documenting the status quo will help to provide firm ground
>> for discussing the next generation of solutions.
>>
>> Do you think this stuff belongs in the Debian Xen wiki:
>> http://wiki.debian.org/Xen
>>
>> or maybe somewhere else?
>> http://wiki.debian.org/Linux%20volume%20management
>> http://wiki.debian.org/LVM
>>
>> or even outside the debian.org space (given it is not just a problem for
>> Debian or Xen or LVM)?
> 
> wiki.xen.org could be another option? Depends on which angle you end up
> approaching it from. 

It may be useful on the Debian wiki because that may lead to developing
a model that is typical across Debian systems, people designing tools
and D-I features will have it in mind

>> Another thing that comes to mind, almost like a third solution: can LVM2
>> (or maybe another volume manager, maybe EVMS would have done this) allow
>> each domU to see the entire dom0 VG, but only access individual LVs that
>> are permitted by some administrative controls?  This would be an
>> alternative to declaring the LV mappings in the Xen cfgs.
> 
> I'm not aware of any way of doing that. LVM isn't generally safe against
> multiple parties accessing it so you would need to be very careful not
> to corrupt the metadata etc.

Yes, it is definitely not something to do with LVM as it stands

Once people start mixing in fibre channel and iSCSI, many more
permutations start to arise as well.  For example, if someone wants
their server to start off as virtual, but `graduate' to running on a
dedicated machine later, they might be keeping it on a dedicated (and
partitioned) LUN that is outside the scope of their dom0's VG.