On Tue, Jul 23, 2013 at 03:52:56PM +0200, Paolo Bonzini wrote: > Il 23/07/2013 15:36, Daniel P. Berrange ha scritto: > > On Tue, Jul 23, 2013 at 03:29:40PM +0200, Paolo Bonzini wrote: > >> Il 23/07/2013 15:26, Daniel P. Berrange ha scritto: > >>>>> > >>>>> Ok, this answers my question. :) > >>>>> > >>>>> I think the default mode should be direct, because otherwise things such > >>>>> as persistent reservations do not work. > >>> No, the default has to be host mode, because that is the only mode that > >>> is guaranteed to be usable with any QEMU. The direct mode requires a > >>> QEMU that is new enough, and a distro to have enabled it. We can't > >>> rely on that as a default choice. > >> > >> Volume sources are also new enough that you can assume a good QEMU. > > > > No we can't assume that. New libvirt is frequently used with old QEMU > > and we want to have good default behaviour there. > > New libvirt, yes. But can't new libvirt features also assume a new QEMU > if the old one causes more trouble than anything? I've no problem with new features requiring new QEMU but that's not the issue here. This is a question about what the default configuration should be. For default configuration we aim for maximum compatibility not the latest possible features. > >> Host mode for iSCSI is broken. It also doesn't reconnect well if you > >> have a network problem, because after a LUN rescan the inode may change. > > > > That's a much smaller level of brokeness, than if QEMU doesn't support > > the iscsi block protocol & thus the default configuration won't even > > boot. > > Failure to reconnect is not part of the brokenness. :) > > If you use host mode and the guest issues reservation commands, you may > get data corruption. That is the brokenness. So be it, that's been the case for every version of libvirt and QEMU in existance up until iscsi protocol support was added, so it is not a new issue. That doesn't justify choosing a default that is guaranteed to not work at all. > Another difference is that direct mode doesn't require the pool to be > started before starting the domain. For authenticated iSCSI LUNs, this > is better because you cannot autostart authenticated iSCSI pools. Autostarting of authenticated pools is simply a bug to be fixed. > > Perhaps the default could be specified in a configuration file (and the > default should be the safe one). No, that is even worse because now the default is not predictable.. We simply default to host mode and if applications want to use the other mode they can configure the XML as desired. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list