From 4e3aae62425d7175f63aee8f0c3a2018a2a82750 Mon Sep 17 00:00:00 2001 From: Adam Glasgall Date: Tue, 3 Sep 2013 15:52:58 -0400 Subject: [PATCH] add long comment to vif-invirtroute explaining the metric trickery --- vif-invirtroute | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/vif-invirtroute b/vif-invirtroute index 49a7e4c..d1c5216 100755 --- a/vif-invirtroute +++ b/vif-invirtroute @@ -54,6 +54,28 @@ if [ ${vif_type} != "ioemu" -o x${qemu_online} = xyes ] ; then # If we've been given a list of IP addresses, then add routes from dom0 to # the guest using those addresses. for addr in ${ip} ; do + # When PVHVM is enabled, Xen plugs two interfaces into + # HVMs - an emulated tap device and a paravirt vif device. + # vif-invirtroute (and vif-route, for that matter!) will + # fail when the second one is brought up, because the + # second invocation of 'ip route add' is identical to the + # first (same source and destination IPs) and the kernel + # rejects the new route. + # + # We work around this by adding the routes with different metrics. + # This should work because: + # + # 1) In the case of a pv-aware guest, the kernel will + # unplug the tap interface, which will bring down the tap + # interface's route, leaving only the one via the vif (and + # so the metric shouldn't matter, because it's the only + # route) + # + # 2) In the case of a non-pv-aware guest, the tap route + # (with metric 1) should take precedence over the vif + # route and carry all the traffic. + + if [ $ipcmd == "add" ]; then case $dev in vif*) -- 1.7.9.5