qemuParseCommandLine and virDomainDefPostParse (and virDomaniDefAddImplicitControllers)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While playing with the idea of forcing explicit USB controller models, I ended up with the qemuargv2xml test failing; it ended up that this was because changes I had made to qemuDomainDefPostParse() were affecting the XML produced by qemuParseCommandline(). The reason - after constructing a virDomainDef object by parsing a qemu commandline, qemuParseCommandline() calls two functions that are supposed to be called after parsing domain XML - virDomainDefPostParse() (which calls qemuDomainDefPostParse()).

In my opinion, qemuParseCommandLine() shouldn't be calling virDomainDefPostParse() (or virDomainefAddImplicitControllers(), which it calls in the wrong order relative to virDomainDefPostParse() BTW). The reasons are:

1) this is causing the argv-to-xml conversion to include things in the XML that were not on the original commandline, in particular "default" devices like PCI and USB controllers (added in qemuDomainDefPostParse() based on machinetype) as well as disk, smartcard, virtio-serial, and hostdev-scsi controllers in virDomainDefAddImplicitControllers() (why the duality there, anyway?)

2) If the output of argv-to-xml is used for a virDomainDefine, those post-parse functions will be called then, and the implicit/auto devices will be added at that time anyway, so in practice nothing is gained by adding them during argv-to-xml.

Does anyone else have an opinion about this?

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]