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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list