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 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
On Wed, Jul 03, 2013 at 09:39:57AM +0300, Dan Kenigsberg wrote: 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