[libvirt] configuring a disconnected <interface>

[Stefan Hajnoczi]

On Wed, Jul 03, 2013 at 10:43:22AM -0400, Laine Stump wrote:
> On 07/03/2013 05:27 AM, Daniel P. Berrange wrote:
> > On Wed, Jul 03, 2013 at 09:39:57AM +0300, Dan Kenigsberg wrote:
> >> On Tue, Jul 02, 2013 at 05:32:20PM -0400, Laine Stump wrote:
> >>> On 07/02/2013 04:07 PM, Dan Kenigsberg wrote:
> >>>> On Mon, Jun 24, 2013 at 11:22:16AM +0100, Daniel P. Berrange wrote:
> >>>>> On Sun, Jun 23, 2013 at 03:34:06PM +0300, Dan Kenigsberg wrote:
> >>>>>> On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote:
> >>>>>>> So I'm not inclined to support this disconnected mode.
> >>>>>> Disconnected mode exists in actuality. It has valid use cases in the
> >>>>>> virtual world as well. I would like to discuss the domxml schema for
> >>>>>> representing it, and then, hopefully find the menpower to implement it
> >>>>>> outside the core libvirt team. So please, reconsider.
> >>>>> The XML schema is easy enough - it is just a new  <interface type=none>.
> >>>>> Ideally we would want some kind of support in QEMU for this, concept
> >>>>> so that we don't have to have a hidden dangling tap device
> >>>> That would be cool indeed. It would make it possible to
> >>>> virDomainUpdateDevice() from a tap-based connectivity to non-tap one.
> >>>>
> >>>> Until we have something like that in qemu, would it be reasonable to
> >>>> implement <interface type=none> via a dangling tap? Wouldn't it be fine
> >>>> to limit changing type=none to type=network only to bridge-based
> >>>> networks?
> >>> Well, that *is* how virDomainUpdateDevice behaves when switching from
> >>> one network connection to another - if the source and destination are
> >>> both implemented with tap, it works, otherwise it returns
> >>> OPERATION_UNSUPPORTED.
> >> My question is slightly different: it's about switching from one
> >> interface type (=none) to another (=network), not between two networks.
> >>
> >> I am asking whether it would be fine to implement type=none with tap,
> >> given this unsupportedness.
> > No, it doesn't really work properly. Not all type=network configs
> > are based on tap devices. We need to be able to ask QEMU to remove
> > the netdev backend, without affecting the guest device, and then 
> > add in a new netdev backend.
> >
> > We should have asked for this when we first did dynamic network
> > re-configuration, but we took the easy way out back then. We need
> > to fix this properly so that all possible config changes work.
> 
> Actually we did ask for that (basically, for the ability to change the
> frontend of a network device without changing the backend), and stefanha
> kindly produced a patch that *kind of* did it, but due to internal
> limitations of qemu, it wasn't fully functional; it worked for some
> limited cases but not for everything. If I recall correctly, the split
> between frontend and backend in qemu wasn't as clear cut and total as
> the commands led us to believe, and even once Stefan's patch was in
> place, switching from tap to macvtap (or vice versa) still didn't work
> properly (am I remembering that correctly, Stefan?).

Hi Laine,
I sent a patch for testing in October 2012 but did not get a response:

http://comments.gmane.org/gmane.comp.emulators.qemu/177516

This patch makes "netdev_del netdev0" disconnect a NIC from its backend
and deletes the backend.  The link will be down and the guest will be
notified if the emulated NIC supports link state change interrupts.

A new backend can be added later and this will bring the link back up.

The (solvable) limitation is when the NIC has told the guest to use
vnet_hdr offload:

  The current code is not safe with virtio-net + tap, where the
  virtio-net device reports offload features from the tap device to the
  guest.  If you try to switch to a -netdev user or -netdev socket
  device, those offload capabilities are not present and network
  communication will fail.

The issue with virtio-net is that there is no way to disable vnet_hdr
offload without resetting the device.  This means QEMU would need to
emulate vnet_hdr offload itself to generate the packets that are
compatible with -netdev user or other non-vnet_hdr backends.

This is doable but someone needs to volunteer to implement it.  Here is
the vnet_hdr structure:

/* This is the first element of the scatter-gather list.  If you don't
 * specify GSO or CSUM features, you can simply ignore the header. */
struct virtio_net_hdr {
#define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	// Use csum_start, csum_offset
#define VIRTIO_NET_HDR_F_DATA_VALID	2	// Csum is valid
	__u8 flags;
#define VIRTIO_NET_HDR_GSO_NONE		0	// Not a GSO frame
#define VIRTIO_NET_HDR_GSO_TCPV4	1	// GSO frame, IPv4 TCP (TSO)
#define VIRTIO_NET_HDR_GSO_UDP		3	// GSO frame, IPv4 UDP (UFO)
#define VIRTIO_NET_HDR_GSO_TCPV6	4	// GSO frame, IPv6 TCP
#define VIRTIO_NET_HDR_GSO_ECN		0x80	// TCP has ECN set
	__u8 gso_type;
	__u16 hdr_len;		/* Ethernet + IP + tcp/udp hdrs */
	__u16 gso_size;		/* Bytes to append to hdr_len per frame */
	__u16 csum_start;	/* Position to start checksumming from */
	__u16 csum_offset;	/* Offset after that to place checksum */
};

Stefan