On Sat, Jul 2, 2011 at 3:27 PM, Justin Pettit <jpet...@nicira.com> wrote:
> On Jul 2, 2011, at 2:24 PM, Piotr Kandziora wrote: > > > This situation happens usually after I restart my testing server. What is > reason of this? How can I fix it? Maybe this is connected to brcompatd mode. > If it were possible to use OVS with LibVirt (maybe am I wrong here that this > is not possible?) I would not use this mode. > > My guess is that when you reboot, a new interface record is getting created > but nothing is cleaning up the old records. I doubt the old record is being > referenced, which is why nothing complained about the duplicate name and > ovs-vswitchd did not fille the record with useful information (e.g., ofport, > statistics, and status). This isn't really a problem other than filling > your database with discarded records. > > We generally recommend people avoid brcompatd whenever possible. Others on > this list can answer better than I (please jump in!), but I believe you can > configure libvirt to use an Ethernet device model. You then write > ifup/ifdown scripts that make the appropriate ovs-vsctl calls. > There are two ways I've seen OVS used with libvirt <interface type=ethernet >. The first approach that Justin mentioned was to just to change the qemu ifup scripts (e.g., /etc/qemu-ifup) to add the port to the bridge using ovs-vsctl instead of brctl. To be honest, I'm not 100% sure that /etc/qemu-ifup is called by default when libvirt is used, but at the least you can definitely specify <script path="/etc/qemu-ifup"> in the libvirt interface XML. If you want to configure each port differently, you can generate a vif-specific ifup script, set it as executable, and point to it using the script element (e.g., <script path="/etc/tenantA-VM1-vif1-ifup">). The downside here, I believe, is that qemu must be run as root and have cap_net_admin in order to perform privileged operations like running ovs-vsctl in the ifup script and creating a tap device. /etc/libvirt/qemu.conf can be tweaked to allow this, but it means your qemu guests will run as root, which has negative security implications if code on the guest were to ever break qemu's isolation. You also may have to tweak your SELinux or apparmor config (depending on your platform), otherwise it can prevent the qemu guest from performing certain operations. The second approach is to create the linux device (e.g., tap0) outside of of libvirt, configure it, attach it to an OVS bridge, then invoke libvirt with type=ethernet and use a <target device="tap0"> element to instruct KVM to use the already created interface. This approach let's you create, configure and attach devices as root, then invoke qemu as a less privileged user, which is nice. The downside here is that you have to manage the linux device yourself, for example, destroying it once the VM is done, and recreating it if needed if the physical server reboots and the guests are set to automatically restart. I'd be curious to hear if anyone else has comments or other techniques for handling libvirt and OVS. Dan > > --Justin > > > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
