[PATCH 2/3] conf, docs: Add support for dummy network interface
Martin Kletzander
mkletzan at redhat.com
Wed Aug 24 14:26:30 UTC 2022
On Wed, Aug 24, 2022 at 03:12:53PM +0100, Daniel P. Berrangé wrote:
>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'.
>
OK, thanks, I'll go with 'null' then unless someone else expresses another
preference.
>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/c1d33c33/attachment.sig>
More information about the libvir-list
mailing list