[libvirt] Re: Supporting vhost-net and macvtap in libvirt for QEMU

Daniel P. Berrange wrote: >>The more interesting invocation of vhost-net though is one where the >>vhost-net device backs directly to a physical network card. In this >>mode, vhost should get considerably better performance than the current >>implementation. I don't know the syntax yet, but I think it's >>reasonable to assume that it will look something like -net >>tap,dev=eth0. The effect will be that eth0 is dedicated to the guest. >> > >Ok, so in this model you have to create a dedicated ethXX device for >every guest, no sharing ? > Yup. You may be sharing a physical network device via SR-IOV, but from libvirt's perspective, we're dedicating a physical device to a guest virtual nic. >>I think there are a few ways libvirt could support vhost-net in this >>second mode. The simplest would be to introduce a new tag similar to >><source network='br0'>. In fact, if you probed the device type for the >>network parameter, you could probably do something like <source >>network='eth0'> and have it Just Work. >> >>Another model would be to have libvirt see an SR-IOV adapter as a >>network pool whereas it handled all of the VF management. Considering >>how inflexible SR-IOV is today, I'm not sure whether this is the best >>model. >> > >Agreed, given the hardware limitations I don't see that it is worth the >bother. > >This new mode is not really what we'd call 'bridging' in libvirt network >XML format, so I think we'll want to define a new type of network config >for it in libvirt. Perhaps > > <network type='physical'> > <source dev='eth0'/> > </network>

> >Or type='passthru' > That certainly simplifies the problem. I don't know whether SR-IOV requires additional setup though wrt programming the VF's mac address. It may make sense for libvirt to at least do that.