Re: [libvirt] Would it make sense to have a <disk device='logicalvolume'>?
2012/1/10 Daniel P. Berrange <berrange(a)redhat.com>:
The problem is that a logical volume is a software concept in the
host OS, and a software concept in the guest OS. Block devices
passed to guests are all types of disk hardware, whether IDE,
SCSI, USB, Virtio Block (a sort of paravirt SCSI).
In fact what I am missing from current hypervisors is the possibility
to expose a a block device that is not seen as a disk hardware. This
could be more semantically correct where exposed block devices are
used to directly create fs inside them and not a full partitioning
structure.
To do what you describe, you'd need to write a virtio-lvm
paravirt
driver for Linux & QEMU. And even then, I'm not sure the guest
OS LVM tools will like seeing a logical volume, without any
corresponding volume group, or physical volumes visible. Indeed
if the guest doesn't have any VG or PVs visible, then you loose
the most important benefit of having a logical volume - the ability
to resize it. So it all seems rather pointless to me.
The point would be not to resize the "fake" LV from the guest, but
from the host. So it's not really needed to recreate an emulated LVM
layer in the guest: the guest would need just to be notified about the
resize being performed.
So in the previous scenario, where the host block device is a real LV
(host side), you could issue:
# lvresize -L +100GB /dev/mapper/domain0_home
from the host. And issue:
# resize2fs /dev/mapper/home
in the guest.
IMO, having this feature would really ease administering of storage.
As a plus, you can already get a performance/space usage efficiency
bonus not having LVM management inside the guest. I already setup VMs
in this way, but for resizing I have to shut them and perform the fs
resize from the host.
Anyway, thanks for confirming me that this is not possible without
patches to linux/QEMU.
Greetings,
Francesco