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

Hi, all I recently discovered that <target dev=''/> input is allowed[*] by qemu driver's defineXML for <interface> element. On start it will turn into 'tap<N>'. 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 for dev attribute. Additionally fix migrating to clear out this autogenerated name. This way we have 2 options to autogenerate dev name. First as described above. Second is by ommiting target element. The naming will be 'vnet<N>' in the latter case. Having these 2 options looks redundant. 2. Don't allow to start domains with such configuration. We can not fail definition because disappearing VMs on libvirt update looks too unpleasant. This way we don't have two different set of autogenerated names. This can even go unnoticed given we fail such starts anyway after [1] (which is fixed by [*]). [1] is commited on 2018 Jul 23 and released in 4.6.0. However Centos 7 is based on 4.5.0 and virNetDevTapCreate has logic to copy generated tap name from kernel like since the beginning (I managed to follow the history to 2011). Nikolay [*] at least with recent "virStrncpy: fix to successfully copy empty string" applied [1] 7d70a63b util: Improve virStrncpy() implementation