Re: [PATCH 2/3] conf, docs: Add support for dummy network interface
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(a)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.
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.
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.
Thanks,
Martin
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 :|
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)