[libvirt] qemuParseCommandLine and virDomainDefPostParse (and virDomaniDefAddImplicitControllers)

Michal Privoznik mprivozn at redhat.com
Thu Nov 19 10:12:29 UTC 2015


On 18.11.2015 21:19, Laine Stump wrote:
> 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()).

I'm afraid you are touching area of the code that is not maintained.
Brace yourself :)

> 
> 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?)

Hold on, so they are not even visible in the guest? I mean, if I run
qemu by hand, don't I always get virtio-serial? If not, then we should
not add them during cmd line parse.

> 
> 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.

Correct.

> 
> Does anyone else have an opinion about this?
> 

I believe there's not much gain in calling post parse callbacks during
cmd line parsing.

Michal




More information about the libvir-list mailing list