[libvirt] Would it make sense to have a <disk device='logicalvolume'>?
The questions is this: 1) would it make sense to expose a block device in the host to be mapped like a "logical volume" in the guest (I mean: not actually exposing it as a physical disk)? 2) Is there any existing hypervisor that could be made to work like this? Example scenario: Just suppose I have a real logical volume in the *host* called "/dev/mapper/domain0_home" (it could be any block device, but this would be a real useful configuration). Consider the following hypothetical libvirt configuration: <disk type='block' device='lv'> <source dev='/dev/mapper/domain0_home'/> <target dev='home' bus='virtio'/> </disk> 'lv' stands for "logicavolume". The block device should be automatically mapped in the *guest* as "/dev/mapper/home", and not advertised as a physical disk.
On Tue, Jan 10, 2012 at 12:00:27PM +0100, Francesco Pretto wrote:
The questions is this: 1) would it make sense to expose a block device in the host to be mapped like a "logical volume" in the guest (I mean: not actually exposing it as a physical disk)? 2) Is there any existing hypervisor that could be made to work like this?
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). 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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
2012/1/10 Daniel P. Berrange <berrange@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
On Tue, Jan 10, 2012 at 02:04:09PM +0100, Francesco Pretto wrote:
2012/1/10 Daniel P. Berrange <berrange@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.
FYI, you can already resize Virtio Block and SCSI devices from the host and tell QEMU to update the guest size. You justneed to issue an lvresize in the host, and then issue the 'virsh blockresize' command to inform the guest of the new size. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
2012/1/10 Daniel P. Berrange <berrange@redhat.com>:
FYI, you can already resize Virtio Block and SCSI devices from the host and tell QEMU to update the guest size. You justneed to issue an lvresize in the host, and then issue the 'virsh blockresize' command to inform the guest of the new size.
! This does mean that 90% of features is actually already in place (other things are more cosmetics: it's not a big deal if mkfs warns that it is creating a fs in a disk instead of a partition). Although 'virsh blockresize' seems pretty new, sorry if this discussion turned to be more user related. Thanks, Francesco
On Tue, Jan 10, 2012 at 02:36:47PM +0100, Francesco Pretto wrote:
2012/1/10 Daniel P. Berrange <berrange@redhat.com>:
FYI, you can already resize Virtio Block and SCSI devices from the host and tell QEMU to update the guest size. You justneed to issue an lvresize in the host, and then issue the 'virsh blockresize' command to inform the guest of the new size.
! This does mean that 90% of features is actually already in place (other things are more cosmetics: it's not a big deal if mkfs warns that it is creating a fs in a disk instead of a partition). Although 'virsh blockresize' seems pretty new, sorry if this discussion turned to be more user related.
Yep, it is definitely in 1.0 QEMU, and has been in libvirt for one or two releases Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Daniel P. Berrange -
Francesco Pretto