]> git.ipfire.org Git - thirdparty/libvirt.git/commit
qemuDomainChangeGraphics: Check listen address change by listen type
authorMichal Privoznik <mprivozn@redhat.com>
Thu, 20 Jun 2013 16:27:35 +0000 (18:27 +0200)
committerEric Blake <eblake@redhat.com>
Thu, 12 Sep 2013 02:27:22 +0000 (20:27 -0600)
commit073812898ab5c7baaafdd9d878d4f4113a5ff618
tree13b706b67557ccd84a1d620574a6f7f83377254b
parent9a1145a9876f6ab89ca2882962488d8fcb5d17f4
qemuDomainChangeGraphics: Check listen address change by listen type

https://bugzilla.redhat.com/show_bug.cgi?id=1006697

Currently, we have a bug when updating a graphics device. A graphics device can
have a listen address set. This address is either defined by user (in which case
it's type is VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_ADDRESS) or it can be inherited
from a network (in which case it's type is
VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NETWORK). However, in both cases we have a
listen address to process (e.g. during migration, as I've tried to fix in
7f15ebc7).
Later, when a user tries to update the graphics device (e.g. set a password),
we check if listen addresses match the original as qemu doesn't know how to
change listen address yet. Hence, users are required to not change the listen
address. The implementation then just dumps listen addresses and compare them.
Previously, while dumping the listen addresses, NULL was returned for NETWORK.
After my patch, this is no longer true, and we get a listen address for olddev
even if it is a type of NETWORK. So we have a real string on one side, the NULL
from user's XML on the other side and hence we think user wants to change the
listen address and we refuse it.

Therefore, we must take the type of listen address into account as well.

(cherry picked from commit 752596b5dd0b4f3d27defc9e232552ff5a0bf08a)
src/qemu/qemu_hotplug.c