1 files changed, 56 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/network/2745 b/results/classifier/zero-shot/118/network/2745
new file mode 100644
index 000000000..cb9e52a2f
--- /dev/null
+++ b/results/classifier/zero-shot/118/network/2745
@@ -0,0 +1,56 @@
+network: 0.922
+virtual: 0.873
+kernel: 0.828
+peripherals: 0.740
+architecture: 0.720
+hypervisor: 0.717
+graphic: 0.715
+performance: 0.708
+device: 0.652
+permissions: 0.622
+PID: 0.611
+semantic: 0.543
+socket: 0.535
+register: 0.429
+ppc: 0.417
+risc-v: 0.387
+user-level: 0.354
+boot: 0.330
+x86: 0.330
+VMM: 0.322
+debug: 0.317
+files: 0.305
+KVM: 0.293
+mistranslation: 0.289
+vnc: 0.281
+assembly: 0.269
+TCG: 0.257
+arm: 0.243
+i386: 0.238
+
+Qemu should send RARP for vhostuser regardless of whether virtio supports GUEST_ANNOUNCE
+Description of problem:
+When virtio reports to qemu that GUEST_ANNOUNCE is supported, qemu will not send RARP. The assumption, I think, is that guest kernel will do whatever is needed to announce the guest. The problem with this assumption is that 1) kernel won't send RARPs; 2) for IPv4 and IPv6 it will send GARPs and NAs; 3) for interfaces with no IP addresses, I think it won't send anything at all.
+
+RARPs are useful because they allow to notify regardless of IP configuration. I've [asked](https://issues.redhat.com/browse/RHEL-71919]) RHEL kernel folks to consider issuing RARPs from the guest kernel, but it won't happen overnight, and regardless, it's not a complete solution since we cannot expect all guests running a patched kernel with such feature.
+
+RARP packets are also often expected by underlying network components. For example, OVN controller has a special "activation-strategy=rarp" configuration that makes OVN wait for a RARP from destination chassis on live migration, and only then unblock traffic for the port. Since RARP is not issed by Qemu nor virtio-net, the OVN port is never unblocked (until its configuration is reset by CMS).
+
+I think what should be done from Qemu side is to send RARP for vhostuser ports regardless of whether virtio supports GUEST_ANNOUNCE. I **think** this can be achieved by removing this code:
+
+```
+    /* If guest supports GUEST_ANNOUNCE do nothing */
+    if (virtio_has_feature(dev->acked_features, VIRTIO_NET_F_GUEST_ANNOUNCE)) {
+        return 0;
+    }
+```
+Steps to reproduce:
+1. Start a VM with vhostuser* port and fresh virtio guest driver.
+2. Live migrate it.
+3. Observe that RARP is not sent from the migrated port. GARP (or NA for IPv6) is sent instead.
+Additional information:
+Some external bugs that may be relevant:
+
+- RHEL kernel request to send RARPs from virtio: https://issues.redhat.com/browse/RHEL-71919 (won't fix the issue for older unpatched kernels)
+- Request for OVN to handle GARPs and NAs: https://issues.redhat.com/browse/FDP-1042 (won't solve for unaddressed ports!)
+- An attempt to work around the issue in OpenStack Neutron OVN env by disabling activation strategy: https://issues.redhat.com/browse/OSPRH-12571 (not a great long term solution)