2:34 a.m.
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