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

Wed Aug 24 14:09:31 UTC 2022

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?

>
>> I also thought about having this in QEMU, but given how pointless this
>> configuration is (and we just want to be able to express such
>> configuration so that virt-v2v can convert such domains) I am not sure
>> whether there's a point to adding this support to QEMU.  And looking at
>> the possibilities of what could be done on QEMU cmdline (without
>> modifying QEMU), we would have to create a network device which is not
>> connected anywhere, but QEMU does not support this, so the only way I
>> found out was adding a hubport that's not connected anywhere, something
>> like:
>>
>> -netdev hubport,id=test0,hubid=0 -device e1000e,netdev=test0
>>
>> which emits a warning during startup:
>>
>> qemu-system-x86_64: warning: hub 0 is not connected to host network
>>
>> but as mentioned before, I think that's pointless to try to support it.
>
>You don't need a hub, it is fine to just have  '-device e1000e' with
>no netdev property, but yes, that too generates a warning
>
>   qemu-system-x86_64: warning: nic e1000e.0 has no peer
>
>The warning is trying to be helpful to detect mistakes of course,
>but if someone genuinely wants a disconnected NIC it is annoying.
>
>Anyway, there's no pressing need to implement QEMU support today,
>I just wanted to point out it is relevant to more than just vmware.
>

Sure, it might be, and anyone can implement it later on, that's why I
only used the VMWare scenario as an "example".

>> Let me know what you think, I'm fine with any changes if it supports the
>> now "fixed" scenario, but naming should better be fixed before a
>> release.
>
>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 :|
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220824/84963c6e/attachment.sig>