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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list