[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] race condition during /etc/xensource/scripts/vif call


  • To: xen-api@xxxxxxxxxxxxxxxxxxx
  • From: George Shuklin <shuklin@xxxxxxxxxxx>
  • Date: Thu, 22 Sep 2011 19:18:07 +0400
  • Delivery-date: Thu, 22 Sep 2011 08:19:49 -0700
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>

Good day. 

Found strange situation for VM with two or more interfaces: data
from /xapi for domain disappear before vif remove called second time.

Here little patch to vif script (against XCP 1.1 beta) to log XenStore
state:

--- vif.orig    2011-05-19 02:32:19.000000000 +0400
+++ vif 2011-09-22 19:11:10.000000000 +0400
@@ -227,6 +227,8 @@
         xenstore-rm "${HOTPLUG}/hotplug"
     fi
     logger -t scripts-vif "${dev} has been removed"
+    echo ====domid=$DOMID===== >>/var/log/vif-race.log
+    xenstore-ls /xapi >>/var/log/vif-race.log
     remove_from_bridge
     ;;
 esac


To see 'strange' add to any vm two interfaces and reboot it.

In vif-race.log for second time vif call:
====domid=3=====
0 = ""
 hotplug = ""
  vbd = ""
 private = ""
  vbd = ""
   51712 = ""
    ref = "OpaqueRef:1a7992ae-a645-acc6-bf51-3a0202bdd4c7"
 frontend = ""
  vbd = ""
3:

(no data for domid 3).

I'm not sure if this is a really serious bug, but I found my
antispoofing patch does not remove rules from OVS for multihomed VM's
due lack of 'bridge' variable for VIF (I'm calling remove_restiction()
function in 'remove' case in vif script).

I got this bug in XCP 1.0 and XCP1.1 beta.



_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.