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

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Mon Sep 16 14:44:15 UTC 2019


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




More information about the libvir-list mailing list