[libvirt] [PATCH 1/1] conf: handle empty string in interface target name

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Thu Sep 26 11:51:12 UTC 2019



On 25.09.2019 15:52, Peter Krempa wrote:
> On Wed, Sep 25, 2019 at 12:42:07 +0000, Nikolay Shirokovskiy wrote:
>>
>>
>> On 23.09.2019 17:44, Peter Krempa wrote:
>>> On Mon, Sep 23, 2019 at 11:21:33 -0300, Daniel Henrique Barboza wrote:
>>>>
>>>>
>>>> On 9/23/19 8:55 AM, Nikolay Shirokovskiy wrote:
>>>>> Empty name is not allowed by schema but qemu is able to start with such
>>>>> a config (and I guess some other hypervisors too). As a result name will
>>>>> be generated by kernel and have form 'tap<N>'. At the same time if
>>>>> target element is ommited in config the name will be generated by
>>>>> libvirt and have form 'vnet<N>'. Let's have only the latter pattern
>>>>> for autogenerated names by treating empty name as ommited.
>>>>>
>>>>> Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy at virtuozzo.com>
>>>>> ---
>>>>
>>>> Reviewed-by: Daniel Henrique Barboza <danielhb413 at gmail.com>
>>>
>>> Change like this usually requires a test XML addition so that we can
>>> validate and prevent regressions.
>>>
>>
>> I would like to, but seems it requires mocking syscalls for
>> dealing with taps/interfaces which is a good deal of work
>> so I guess next time...
> 
> The XML2XML test which does not invoke any preparation code should be
> enough in this case.

xml2xml can only check that dev="" will turn in missing <target> on parse/format round.
But this looks like not enough as we could have dev="" turn in dev="tap0" as now
which is scrapped out on format as autogenerated. Unfortunately dev name is autogenerated
in code xml2xml does not touch. I hoped to use xml2argv test thus the above
words on mocking but I realized this test is of no help too because host dev name
is not present in command line the test checks.

Nikolay 

> 
> Also rather than mocking syscalls libvirt's prepare steps were split up
> so that tests can skip steps which would actually modify the host so
> possibly you'll just need to refactor the setup code to be executed in a
> different place.
> 




More information about the libvir-list mailing list