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@xxxxxxxxxx> --- 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 :|
Attachment:
signature.asc
Description: PGP signature
