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(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.
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 :|