[libvirt] qemuParseCommandLine and virDomainDefPostParse (and virDomaniDefAddImplicitControllers)

Laine Stump laine at laine.org
Thu Nov 19 17:08:30 UTC 2015


On 11/19/2015 10:29 AM, Peter Krempa wrote:
> On Thu, Nov 19, 2015 at 10:15:25 -0500, Laine Stump wrote:
>> On 11/19/2015 07:50 AM, Peter Krempa wrote:
>>> On Thu, Nov 19, 2015 at 11:12:29 +0100, Michal Privoznik wrote:
>>>> On 18.11.2015 21:19, Laine Stump wrote:
>>> [...]
>>>
>>>>> Does anyone else have an opinion about this?
>>>>>
>>>> I believe there's not much gain in calling post parse callbacks during
>>>> cmd line parsing.
>>> Well, then you have to extract all the code that is setting the
>>> hypervisor-specific defaults that can be omitted on the commandline but
>>> need to be present in the definition (e.g. default network card model)
>>> into the command line parser, otherwise certain parts of the code will
>>> crash (e.g. network card model formatter).
>> Ugh. Right - once you've got the XML out it will get all the defaults
>> when it is fed back in to the parser with a virDomainDefine. But the
>> very first time it is formatted, right at the end of the argv-to-xml,
>> that could cause a problem.
> That is the same case as when you try to attach to a existing process.
> It's very unlikely to actually work, but there is a possibility to reuse
> the object created from argv parsing directly. In that case we probably
> do need to have the definiton working.

That could be handled by either adding the post-parse stuff into 
qemuDomainAttach(), or alternately by doing a format-parse cycle on the 
object (again, in qemuDomainAttach()) rather than using it directly 
(which I actually think could give better results, as long as 
qemuParseCommandLine() itself is doing the right stuff).

Note that in the case where the original commandline doesn't include the 
PCI addresses of devices, we're very likely to end up with incorrect 
address info in the XML, so hopefully nobody relies on that...




More information about the libvir-list mailing list