On Wed, Sep 21, 2016 at 04:01:23PM +0100, Daniel P. Berrange wrote:
I'm not a fan of the idea of silently picking a different device
for the guest behind the applications back. By not exposing the
different device types with a "model" attribute, we miss a way
to report to the application which models are supported by the
QEMU they're using - eg via domain capabilities.

This in turn means the application doesn't know whether they're
getting the new or old version, and so don't know if they're going
to have working migration or not.

If we expanded the XML to include model, then application can
explicitly request the new model (which supports migration) and
know that they'll get a startup failure if not supported, as
opposed to silently falling back to the non-migratable version.

Also, it makes life hard for us if the ivshmem-plain device wants
to support use of the 'server' attribute in the future, as we will
then not know which to create.

We've often been burnt in the past by trying todo magic like this,
instead of explicitly representing stuff in the XML, so I think we
should be being explicit about ivshmem models here.

Of course, if we do add <model> support, we have to allow for it
to be missing for sake of upgrades. So there's a question of which
model we should select as the default, if not seen in the XML.

If selecting the newest one whenever the element is missing is fine,
then I'm OK with that.  But that would change the device when upgrading
libvirt (without user intervention), which you didn't like IIUC.

|: 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 :|

Attachment: signature.asc
Description: Digital signature

libvir-list mailing list

Reply via email to