<tt>Daniel,</tt> <tt> some of this code doesn't build anymore due to the recent changes with the conn parameter being removed. </tt> <tt>Do you want me to re-submit?</tt> <tt> I actually liked the conn parameter for error reporting and handling in the return path. Any function</tt> <tt>where the conn parameter was needed, I anticipated a simple return code for success and failure with the </tt> <tt>error already attached to the 'conn' parameter via one of the error reporting functions. Other functions </tt> <tt>where the conn parameter was not passed, the return value was anticipated to have an 'errno meaning'. Now </tt> <tt>that meaning seems lost. I am wondering whether I can still leave the conn parameter as an ATTRIBUTE_UNUSED</tt> <tt>for those functions where I only anticipate a success/failure return and error already being reported</tt> <tt>via a function?</tt> <tt>Regards,</tt> <tt> Stefan</tt> <tt>libvir-list-bounces@redhat.com wrote on 02/08/2010 02:35:43 PM: </tt> <tt>> > 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@redhat.com > </tt><a href="https://www.redhat.com/mailman/listinfo/libvir-list"><tt>https://www.redhat.com/mailman/listinfo/libvir-list</tt></a><tt> </tt>