Thanks for answers.
Both described solutions are not quite nice for me. First one because of possible security issues. Additionaly as I know LibVirt currently does not support downscript tag specified in Interface section in xml. So if I someone sets up e.g. flow rules in customized ifup script then they will not be removed after destroying VM (for test I checked if flows will expire if given port does not exist longer after VM destroy - they are still present). But this is only example, I do not use this solution. In second solution I think that unecessary complexity is big minus. I'am generally using OpenNebula and my goal is to set up and clear flow rules using hook mechanism provided with this cloud solution. When VM starts, then appropriate rules are set, when it is destroyed then flows are removed. My problem was to get information about port used by given interface as you know. Finally I decided to use brcompat mode (because of some problems with LibVirt) and apply workaround for 'multiple rows ...' syndrome: 1. Get entry in JSON notation (uniq entry): /usr/sbin/ovs-vsctl --format=json --data=json --no-headings find Interface name=vnet0 admin_state=up 2. Load returned data via simplejson python library 3. Get appropriate information (ofport value) from dictionary Good to know that they are some modifications in master branch. In the meantime I will check if 'multiple rows' is still present using version from master branch. Best regards Piotr Kandziora On Tue, Jul 5, 2011 at 5:13 PM, Ben Pfaff <b...@nicira.com> wrote: > On Sat, Jul 02, 2011 at 03:27:43PM -0700, Justin Pettit 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. > > If that's the problem, we fixed that in the Git master branch, by > improving ovs-brcompatd and implementing garbage collection in the > database. >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
