Re: [Spice-devel] [PATCH v4] qemu: Use heads parameter for QXL driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 21, 2015 at 01:50:22PM +0100, Daniel P. Berrange wrote:
On Tue, Jul 21, 2015 at 11:44:27AM +0200, Martin Kletzander wrote:
On Tue, Jul 21, 2015 at 09:36:55AM +0200, Christophe Fergeau wrote:
>On Mon, Jul 20, 2015 at 11:25:52AM +0200, Martin Kletzander wrote:
>>I spend all morning fixing this to be installed properly in the
>>system.  Anyway, I finally managed to make this work and found out the
>>guest I used for it is not ready to have multiple monitors.  Anyway,
>>looking at everything else this definitely works, so ACK, I'll push it
>>in a while.
>
>I'm still a bit worried that all existing guests will have heads='1' in
>their XML as libvirt is adding that by default, but I don't really see a
>way around it :-/ We should make sure libvirt stops adding it from now
>on though ;)
>

Well, how would you then limit the outputs to 1?  Having said that, I
have no idea why we started adding heads="1" automatically and playing
with different changes, we have another bug in the parsing/formatting
code.  You'll also won't be able to migrate from older libvirt with
heads='1' to newer ones.  I haven't realized that.  I'm thinking about
reverting the change in libvirt or even using heads > 1.  Although
that won't migrate either.  So the only other thing that we can do is
to introduce new parameter, like maxHeads.  The sound you just heard
is me slapping my face because again there will multiple parameters
meaning similar things...

Introducing a new parameter is not really viable IMHO, because as you
say it'll leave us with two things meaning the same, and will not be
compatible with existing apps that know about the current parameter.

I think we need to figure out a way to drop the 'heads=1' from any
existing configs in /etc/libvirt/qemu when we start up with the new
libvirtd for the first time.


I'm already working on an RFC that would differentiate between loading
XMLs on daemon start-up and defining them.  The purpose of that is so
that we can make incompatible XML changes without losing any domains,
but that's not the point here.  If we were to drop heads='1' anywhere,
this is the place.  The ABI change would be minimal for the guest.

To make this work we probably need to write a magic attribute or
comment into the XML configs to record which version of libvirt
saved it to disk. That way we know whether this is the first time
loading the config with the new libvirt. It will help us with
similar situations in the future. In this case, we'd just look
to see if the libvirt version number was missing from the XML,
and if so, then drop heads=1. If a version number is present, then
we're new enough, so we can keep it.  We'd also ned to pass this
version number in the XML when migrating, or possibly via the
migration cookie.


And you're suggesting to differentiate this by a comment?  That's
really, *really* hacky.  Anyway, do you agree on temporarily reverting
the commit so we don't release another version with it?  The changes
will also be clearer when they will not modify what this commit
changed.

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

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]