On Wed, Jul 24, 2013 at 12:41:49PM +0200, Paolo Bonzini wrote: > Il 24/07/2013 12:39, Daniel P. Berrange ha scritto: > > On Wed, Jul 24, 2013 at 12:37:10PM +0200, Paolo Bonzini wrote: > >> Il 24/07/2013 12:31, Daniel P. Berrange ha scritto: > >>> breaking the default config for QEMU's without iSCSI support. > >> > >> Understood, that's why I suggested not having a default config at all > >> for type='lun' devices. > > > > As I said before, that causes apps to have to do special handling > > for iSCSI pools, which is not something we want. > > This is not about iSCSI pools, it is about type='lun' devices. > > And as I said before, knowing the kind of pool is something you have to > do anyway for type='lun' devices, because they won't work if the > underlying pool is filesystem- or LVM-based. Regardless of whether all pools types can use type=lun, I don't want to see special case handling of this attribute. If it is optional in the XML schema, it should be unconditionally optional for any usage. > >> Also, can libvirt at least detect using a volume on a pool that wasn't > >> started, and fail unless mode='direct'? > > > > It should always fail to start the guest if the pool is not started, > > regardless of the mode used. > > Another point of mode='direct' is that the pool need not be started. That is not something we can allow in the long term. When we expand our fine grained access control further, we're likely going to need to do ACL checks for the virStorageVolPtr object referenced by the XML config here. We can't do that unless the pool is running. So we cannot set a precedent of allowing use without the pool being active IMHO. 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