[PATCH 2/3] conf, docs: Add support for dummy network interface

[Daniel P. Berrangé]

On Wed, Aug 24, 2022 at 04:09:31PM +0200, Martin Kletzander wrote:
> On Tue, Aug 23, 2022 at 12:10:14PM +0100, Daniel P. Berrangé wrote:
> > On Tue, Aug 23, 2022 at 01:01:49PM +0200, Martin Kletzander wrote:
> > > On Tue, Aug 23, 2022 at 11:39:10AM +0100, Daniel P. Berrangé wrote:
> > > > On Thu, Aug 04, 2022 at 03:07:17PM +0200, Martin Kletzander wrote:
> > > > > Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> > > > > ---
> > > > >  docs/formatdomain.rst             | 24 ++++++++++++++++++++++++
> > > > >  src/ch/ch_monitor.c               |  1 +
> > > > >  src/conf/domain_conf.c            | 10 ++++++++++
> > > > >  src/conf/domain_conf.h            |  1 +
> > > > >  src/conf/netdev_bandwidth_conf.c  |  1 +
> > > > >  src/conf/schemas/domaincommon.rng |  7 +++++++
> > > > >  src/libxl/libxl_conf.c            |  1 +
> > > > >  src/libxl/xen_common.c            |  1 +
> > > > >  src/lxc/lxc_controller.c          |  1 +
> > > > >  src/lxc/lxc_driver.c              |  3 +++
> > > > >  src/lxc/lxc_process.c             |  4 +++-
> > > > >  src/qemu/qemu_command.c           |  4 ++++
> > > > >  src/qemu/qemu_domain.c            |  1 +
> > > > >  src/qemu/qemu_hotplug.c           |  3 +++
> > > > >  src/qemu/qemu_interface.c         |  2 ++
> > > > >  src/qemu/qemu_process.c           |  2 ++
> > > > >  src/qemu/qemu_validate.c          |  1 +
> > > > >  src/vmx/vmx.c                     |  1 +
> > > > >  tools/virsh-domain.c              |  1 +
> > > > >  19 files changed, 68 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> > > > > index adfdd7b7a5ac..ed0d9c19593b 100644
> > > > > --- a/docs/formatdomain.rst
> > > > > +++ b/docs/formatdomain.rst
> > > > > @@ -5240,6 +5240,30 @@ which the UDP socket packets will originate from the QEMU host. :since:`Since
> > > > >     </devices>
> > > > >     ...
> > > > >
> > > > > +Dummy network interface
> > > > > +^^^^^^^^^^^^^^^^^^^^^^^
> > > > > +
> > > > > +An unconnected network interface sounds pretty pointless, but can show up for
> > > > > +example with VMWare when libvirt does not have any more information to provide.
> > > > > +Two such scenarios are currently known:
> > > > > +
> > > > > +1) network interface exists, but is not connected to any existing network
> > > > > +2) the interface is connected to something known as VMWare Distributed Switch
> > > > > +
> > > > > +The difference between these two is not (yet?) discoverable by libvirt, so at
> > > > > +least the information gathered from the hypervisor is provided in the
> > > > > +element. :since:`Since 8.7.0`
> > > > > +
> > > > > +::
> > > > > +
> > > > > +   ...
> > > > > +   <devices>
> > > > > +     <interface type='dummy'>
> > > > > +       <mac address='52:54:00:22:c9:42'/>
> > > > > +     </interface>
> > > > > +   </devices>
> > > > > +   ...
> > > >
> > > > Calling this 'dummy' is not very desirable naming. Especially since
> > > > the distributed switch config is handled separately, we're just left
> > > > with the case of a network interface without any host backend.
> > > >
> > > 
> > > I'll gladly rename this, I don't like dummy neither, but the only thing
> > > I can think of is "unconnected".  At first I went with existing type=direct,
> > > but without <target dev=/>, only with <target managed='no'/>, but that
> > > did not really make sense in my opinion.
> > > 
> > > > IMHO this should just be type="none", and would likely be viable for
> > > > QEMU too.
> > > >
> > > 
> > > Unfortunately type="none" usually (in our XML) means there is none of
> > > this type of device (usb, memballoon, etc.), so I don't think that would
> > > make sense compared to rest of our XML.
> > 
> > Hmm, yes, good point. Some other ideas including yours..
> > 
> >  type='unconnected'
> >  type='disconnected'
> >  type='unplugged'
> 
> These seem to collide with <link state='down'/>, even though it really
> is what VMWare seems to do on the NIC as well, just that you cannot
> "plug" it anywhere.
> 
> >  type='null'      (as in /dev/null alike)
> > 
> 
> but together with this they are all better than "dummy", I agree.  Any
> preference before I send a rename patch?

Perhaps a mild preference for  the shorter names 'null' or 'unplugged'.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|