[openstack-dev] [nova] libvirt driver: who should create the libvirt.xml file?

Matthew Booth mbooth at redhat.com
Wed Jun 22 08:30:35 UTC 2016

On Mon, Jun 20, 2016 at 4:47 PM, Markus Zoeller <mzoeller at linux.vnet.ibm.com
> wrote:

> White working on the change series to implement the virtlogd feature I
> got feedback [1] to move code which creates parts of the libvirt.xml
> file from the "driver" module into the "guest" module. I'm a bit
> hesitant to do so as the responsibility of creating a valid libvirt.xml
> file is then spread across 3 modules:
> * driver.py
> * guest.py
> * designer.py

I'm only looking for a guideline here (The "driver" module is humongous
> and I think it would be a good thing to have the "libvirt.xml" creation
> code outside of it). Thoughts?

I'm also not a huge fan of the division of code for generating libvirt info
different backends in imagebackend. I'm not familiar enough with the xml
generation code to have a firm opinion on how it should be.

My concern looking at [1] is that to the greatest possible extent libvirt
should be a data sink, not a data source. That is: Nova is the canonical
source of truth. In terms of configuration, there should be nothing that
libvirt knows that Nova didn't tell it first, so it should never be
necessary to ask for it. The only reason this might not be true would be
legacy instances, and we should be fixing them up.

So, eg, guest.get_path() shouldn't exist.


> References:
> [1]
> https://review.openstack.org/#/c/323761/2/nova/virt/libvirt/driver.py@4190
> --
> Regards, Markus Zoeller (markus_z)
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160622/eee34cde/attachment.html>

More information about the OpenStack-dev mailing list