GNOME Bugzilla – Bug 685377
Handle topology node missing from libvirt capabilities
Last modified: 2016-03-31 13:54:19 UTC
The <topology> node is not always present in libvirt capabilities XML (happened to me when running virsh capabilities in a F18 VM running on a F18 host). Boxes does not handle this situation, and tries to use the NULL capabilities pointer, which causes it to try to create a box with 0 vcpus, which is rejected by libvirt. This patch checks for NULL capabilities pointers, and falls back to creating a VM with 1 vcpu and no topology when this happens. With this change, I can successfully create a box when Boxes is running in a VM.
Created attachment 225675 [details] [review] Handle topology node missing from libvirt capabilities
Review of attachment 225675 [details] [review]: Assuming the setting of vcpus in the domain is mandatory, ACK!
Created attachment 225687 [details] [review] Handle topology node missing from libvirt capabilities The <topology> node is not always present in libvirt capabilities XML (happened to me when running virsh capabilities in a F18 VM running on a F18 host). Boxes does not handle this situation, and tries to use the NULL capabilities pointer, which causes it to try to create a box with 0 vcpus, which is rejected by libvirt. This patch checks for NULL capabilities pointers, and falls back to not setting vcpu count nor topology when this happens as both attributes are optional. With this change, I can successfully create a box when Boxes is running in a VM.
Review of attachment 225687 [details] [review]: ACK with this minor nitpick corrected. ::: src/vm-configurator.vala @@ +165,3 @@ var topology = caps.get_host ().get_cpu ().get_topology (); + if (topology == null) { coding-style nitpick: no '{' needed.