On Sat, Aug 13, 2016 at 03:29:11PM +0200, Martin Kletzander wrote:
On Fri, Aug 12, 2016 at 05:27:28PM +0200, Pavel Hrdina wrote:
>Setting heads to 0 in case that *max_outputs* is not supported while building
>command line doesn't have any real effect. It only removes *heads* attribute
>from live XML, but after restarting libvirt the default value is restored.
>
So that the XML reflects how the guest was started instead of
arbitrarily showing some number that wasn't used for the guest
initialization at all.
This is the only thing what it does and it also has a side effect on downstream
screenshot API [1].
Moreover the zero will be sent in the migratable XML when migrating
to
another host, hence keeping the setting disabled (so that some screens
that are running already will not be removed). At least that's what I
had in mind, maybe the behaviour changed in the meantime.
In migratable XML there is the default heads='1', because our parser set this
default if "heads" is missing in the XML and we don't print
heads='0' to XML.
I've just tested it, to be sure, that the heads attribute doesn't have effect on
migration. If you start a guest on libvirt where *heads* isn't passed to qemu,
use virt-viewer and open two displays, and migrate to second host with newer
libvirt where *heads* is passed to qemu, it still have all the heads from
the source and no opened screen is removed.
It was also written during one of the review of the original patches that this
can be changed while the guest is running and from what I know there is no way
how to get the current number of heads back to track the correct number in
libvirt's XML.
[1] <
https://bugzilla.redhat.com/show_bug.cgi?id=1366119>
Pavel