Hello! This is a re-post of previously posted patches following Daniel Berrange's request for changes along with other fixes. The following patches provide support for making the macvtap networking device type available to Qemu/KVM VMs. The patches rely on the macvtap driver that just became available through the Linux net-next tree (fixes still may be necessary) and make the device available to Qemu/KVM via a tap file descriptor similar to a 'regular' tap device. Following up on previous discussions, the libvirt patches allow using the following XML in the domain description to enable qemu network connectivity via this type of device: <interface type='direct'> <source dev='eth1' mode='vepa'/> <model type='virtio'/> </interface> The above XML indicates that eth1 is the Ethernet interface to link the macvtap device to and communicate to the network. As a consequence, libvirt will create an instance of a macvtap device, assign it the same MAC address as the VM's interface has and open a file descriptor of the associated character device /dev/tap%d and pass it via command line to Qemu/kvm. In the above XML the mode can be chosen as 'vepa', 'private' or 'bridge' and is by default set to 'vepa'(by the driver) if omitted. Attachment and detachment of macvtap to/from a running VM also works. Regards, Stefan -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Feb 09, 2010 at 10:21:20AM -0500, Stefan Berger wrote: > Daniel, > > some of this code doesn't build anymore due to the recent changes with > the conn parameter being removed. > Do you want me to re-submit? Not at this time - there are a whole lot more patches I'm working on to remove 'conn' from many other places which would just break your code again. We can do any neccessary fixup to these macvtap patches at time of commit. > I actually liked the conn parameter for error reporting and handling in > the return path. Any function > where the conn parameter was needed, I anticipated a simple return code > for success and failure with the > error already attached to the 'conn' parameter via one of the error > reporting functions. Other functions > where the conn parameter was not passed, the return value was anticipated > to have an 'errno meaning'. Now > that meaning seems lost. I am wondering whether I can still leave the conn > parameter as an ATTRIBUTE_UNUSED > for those functions where I only anticipate a success/failure return and > error already being reported > via a function? The main problem with the 'conn' parameter is that there are a huge set of circumstances in which it will be 'NULL' and we've had too many bugs where code assumed it would always be non-NULL. By removing the conn parameter (nearly) everywhere in the internal APIs we can get rid of this source of bugs. We've not really enumerated it anywhere, but as a general rule helper functions should set the libvirt full error. I'd like to see the returning of 'errno' reduced to be an exception, just used in places where the caller needs to handle & ignore the potential errno. Again don't worry about updating these patches of yours yet - this error reporting / conn cleanup is a big ongoing project....