On Wednesday 20 January 2010, Vivek Kashyap wrote: > > > > As you can see, the policy is mostly independent from the qemu > > implementation and even from the kernel implementation. Naming the > > macvtap code in qemu '-net vepa' would completely mix up things > > for people that want to use vepa with an SR-IOV card, or macvtap > > in bridge mode! > > Qemu can continue to name the interface '-net tap'. libvrt can invoke it > as '-net tap, fd=x', whether the fd is of type tap or macvtap. right. > With the above, in the domain xml, we specify: > > <interface type='physical'/> > <name='somename'/> > <type='macvtap|tap'/> // one of the two to be specified > <target mode='vepa|pepa|bridge'/> //specify the mode needed for the VM > </interface> > > With the above, when instantiating a guest libvirt will determine the > type of interface. Example: for a 'vepa' on device eth0, libvirt will > create a macvtap interface while setting the mode to vepa. Sounds good. So you could passs macvtap with any of the target modes or tap with bridge mode to get the current behaviour. > This fd is what is passed to qemu. Since macvtap/tap appear the same to > qemu we should not have to modify anything beyond libvirt. > > thoughts? There is still the question of whether the macvtap devices should be kept persistant and created when the daemon is started or only when instantiating a particular VM. Normal taps are not persistent unless you mark them to be so, while macvtap is persistant by default. We could also add the TUNSETPERSIST ioctl to macvtap to give it autodestruct behavior, but I'd rather avoid that if possible in order to keep the lifetime rules simple. Arnd -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list