On Wed, Jul 03, 2013 at 11:54:15AM +0100, Richard W.M. Jones wrote: > On Tue, Jul 02, 2013 at 12:03:10PM +0200, Marko Weber | ZBF wrote: > > is this a restriction by virt-manager? is it best choose to use > > "raw" on lvm? in many qemu-kvm books i read best way will be to use > > qcow2. > > Despite what you may have read, I don't think using qcow2 on top of > LVM is a good idea unless you really know what you're doing. qcow2 > files generally grow as they are being used up to a maximum size which > is not well-defined. LVs of course are fixed size, and can be grown > only using an explicit command (lvresize). > > On oVirt/RHEV the LVs are resized on demand. This is done by having > qemu pause when it detects that it has run out of space during a qcow2 > write. This fact is signalled up to the oVirt management layer which > invokes lvresize and restarts the guest. libvirt handles the signals > but the resizing happens in the management layer above libvirt. There > is no such "layer above libvirt" when using virt-manager (except > perhaps virt-manager itself). Yeah, for qcow2-inside-lvm to be practical you need to have a continously active management application, to deal with ENOSPC alerts. virt-manager doesn't satisfy that requirement. > The only alternative would be to over-provision the LV so it can cope > with the largest possible qcow2 file. But then you might as well > using raw which will faster and easier to reason about. Agreed. IIUC, the main reason why oVirt did the qcow2-inside-LVM think in the first place was because they weren't happy with performance/functionality of LVM snapshots. I know alot of work has been done to address this in LVM since that time, so I'd just avoid qcow2-inside-lvm entirely. 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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
