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