GNOME Bugzilla – Bug 767613
Boxes unconditionnally change <graphics> node of VMs
Last modified: 2016-06-24 17:41:15 UTC
- edit VM with virsh - change graphics node to autoport="yes", remove any liste node, remove Boxes metada - start this VM with Boxes -> Boxes replaces the graphics node with one not listening anywhere I understand Boxes wants to upgrade VMs it created in the past, however in this case I don't think it should assume it owns it as it does not have its metadata, so it should not change its config. (and would a bug to allow to make the SPICE connection to a VM available on the network be useful?)
(In reply to Christophe Fergeau from comment #0) > - edit VM with virsh > - change graphics node to autoport="yes", remove any liste node, remove > Boxes metada > - start this VM with Boxes > -> Boxes replaces the graphics node with one not listening anywhere > > I understand Boxes wants to upgrade VMs it created in the past, however in > this case I don't think it should assume it owns it as it does not have its > metadata, so it should not change its config. Hmm.. What do you mean by "not have it's metadata"? > (and would a bug to allow to make the SPICE connection to a VM available on > the network be useful?) Yes but it already exists. :) bug#694854.
(In reply to Zeeshan Ali (Khattak) from comment #1) > (In reply to Christophe Fergeau from comment #0) > > - edit VM with virsh > > - change graphics node to autoport="yes", remove any liste node, remove > > Boxes metada > > - start this VM with Boxes > > -> Boxes replaces the graphics node with one not listening anywhere > > > > I understand Boxes wants to upgrade VMs it created in the past, however in > > this case I don't think it should assume it owns it as it does not have its > > metadata, so it should not change its config. > > Hmm.. What do you mean by "not have it's metadata"? > This node: <metadata> <boxes:gnome-boxes xmlns:boxes="https://wiki.gnome.org/Apps/Boxes"> <os-state>installed</os-state> <os-id>http://fedoraproject.org/fedora/22</os-id> <media-id>http://fedoraproject.org/fedora/22:1</media-id> <media>/home/teuf/redhat/isos/Fedora-Live-Workstation-x86_64-22-3.iso</media> </boxes:gnome-boxes> </metadata> which could be a way to differentiate between a VM Boxes "owns" and one it does not. Maybe there are better ways of doing that.
Thinking about this a bit more, the correct long term fix is to have some way in the UI to enable/disable VM exposure on the network, then this bug will get automatically fixed. I don't know what the 3.22 plans are, but the workaround discussed in this bug would probably good to have there if bug #694854 is not fixed by then.
(In reply to Christophe Fergeau from comment #3) > Thinking about this a bit more, the correct long term fix is to have some > way in the UI to enable/disable VM exposure on the network, then this bug > will get automatically fixed. I don't know what the 3.22 plans are, but the > workaround discussed in this bug would probably good to have there if bug > #694854 is not fixed by then. Agreed.
commit: 912ff3ec520e2767dc8763523eca1a60a79e2a92 vm-configurator: Don't ignore custom XML on old VMs Our homepage URL changed in Dec 2014 and that is what we use as namespace URL in our custom XML. This meant that we were ignoring custom XML on VMs created before that time cause we were only looking for new URL. Let's fix this by also look for custom XML by old URL. commit: ef23a98c76ac42904d8e74f9464c391ec6e3046d configure: Add a comment about home page URL changes Let's ensure whenever someone updates home page URL, they know they have to modify code to keep compatibility with existing VMs. commit: 63f73ea92d091fac311519498f21498ddb591085 vm-configurator: Only update config of our VMs Only update domain config if the domain in question was created and managed by us.