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@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. Hmm, yes, good point. Some other ideas including yours.. type='unconnected' type='disconnected' type='unplugged' type='null' (as in /dev/null alike) > 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. > 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 :|
