Re: [libvirt] [RFC] quirks of interface target device name

2019-09-17 Thread Laine Stump
On 9/16/19 3:44 PM, Laine Stump wrote: I vote for putting a check in virDomainNetDefValidate() that errors out if it finds target dev present but empty. There may be some who would say "it's existing behavior and has been like this for a long time, so we have to preserve it", but since the

Re: [libvirt] [RFC] quirks of interface target device name

2019-09-17 Thread Nikolay Shirokovskiy
On 16.09.2019 22:44, Laine Stump wrote: > On 9/16/19 10:44 AM, Nikolay Shirokovskiy wrote: >> Hi, all >> >> I recently discovered that input is allowed[*] > > > So you're saying this previously failed? Catastrophically (SEGV)? Or did it > log an error and refuse to start the domain? Without

Re: [libvirt] [RFC] quirks of interface target device name

2019-09-16 Thread Laine Stump
On 9/16/19 10:44 AM, Nikolay Shirokovskiy wrote: Hi, all I recently discovered that input is allowed[*] So you're saying this previously failed? Catastrophically (SEGV)? Or did it log an error and refuse to start the domain? by qemu driver's defineXML for element. On start it will

[libvirt] [RFC] quirks of interface target device name

2019-09-16 Thread Nikolay Shirokovskiy
Hi, all I recently discovered that input is allowed[*] by qemu driver's defineXML for element. On start it will turn into 'tap'. At the same time empty value is not allowed by schema. This name is generated by kernel on linux. I wonder how to deal with this. 1. Fix schema to allow empty value