dev June 2022

passt-dev@passt.top

4 participants
14 discussions

[PATCH] qrap: Add probe retry on connection reset from passt for KubeVirt integration
by Stefano Brivio 16 Jun '22

16 Jun '22

KubeVirt uses libvirt to start qrap in its current draft integration (https://github.com/kubevirt/kubevirt/pull/7849/), and libvirtd starts qrap three times every time a new virtual machine is created: once on domain creation, and twice on domain start (for "probing") and to finally start it for real. Very often, a subsequent invocation of qrap happen before the previously running instance of qemu terminates, which means that passt will refuse the new connection as the old one is still active. Introduce a single retry with a 100ms delay to work around this. This should be checked again once native libvirt support is there, and that point qrap will have no reason to exist anymore. Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- qrap.c | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/qrap.c b/qrap.c index 17cc472..303e981 100644 --- a/qrap.c +++ b/qrap.c @@ -25,6 +25,7 @@ #include <net/if_arp.h> #include <netinet/in.h> #include <netinet/if_ether.h> +#include <time.h> #include "util.h" #include "passt.h" @@ -112,7 +113,7 @@ void usage(const char *name) int main(int argc, char **argv) { struct timeval tv = { .tv_sec = 0, .tv_usec = (long)(500 * 1000) }; - int i, s, qemu_argc = 0, addr_map = 0, has_dev = 0; + int i, s, qemu_argc = 0, addr_map = 0, has_dev = 0, retry_on_reset; char *qemu_argv[ARG_MAX], dev_str[ARG_MAX]; struct sockaddr_un addr = { .sun_family = AF_UNIX, @@ -233,6 +234,9 @@ int main(int argc, char **argv) valid_args: for (i = 1; i < UNIX_SOCK_MAX; i++) { + retry_on_reset = 1; + +retry: s = socket(AF_UNIX, SOCK_STREAM, 0); if (s < 0) { perror("socket"); @@ -254,6 +258,34 @@ valid_args: else break; + /* FIXME: in a KubeVirt environment, libvirtd invokes qrap three + * times in a strict sequence when a virtual machine needs to + * be started, namely, when: + * - the domain XML is saved + * - the domain is started (for "probing") + * - the virtual machine is started for real + * and it often happens that the qemu process is still running + * when qrap is invoked again, so passt will refuse the new + * connection because the previous one is still active. This + * overlap seems to be anywhere between 0 and 3ms. + * + * If we get a connection reset, retry, just once, after 100ms, + * to allow for the previous qemu instance to terminate and, in + * turn, for the connection to passt to be closed. + * + * This should be fixed in libvirt instead. It probably makes + * sense to check this behaviour once native libvirt support is + * there, and this implies native qemu support too, so at that + * point qrap will have no reason to exist anymore -- that is, + * this FIXME will probably remain until the tool itself is + * obsoleted. + */ + if (retry_on_reset && errno == ECONNRESET) { + retry_on_reset = 0; + usleep(100 * 1000); + goto retry; + } + fprintf(stderr, "Probe of %s failed\n", addr.sun_path); close(s); -- 2.35.1

1 0

passt & mbuto
by David Gibson 16 Jun '22

16 Jun '22

Hi again, I realized I wasn't quite right when I said that qrap problems where what was currently stopping me running the passt (not pasta) tests. I did hit qrap issues somewhere, but the current stumbling block is that mbuto looks for udhcpc to put into the guest image, which I can't easily put onto my host system. Now, in the short term, once my patch to remove usage of udhcpc from the passt/pasta tests is applied, we could just remove udhcpc from the mbuto profile as well. However, that raises a wider scope issue: The passt testing profile for mbuto appliances is in the mbuto tree, not the passt tree. That doesn't realy make sense, since it means any change to what we need for the passt tests requires a synchronized change with mbuto. Particularly for a pretty young and project like passt, that's not really tenable. Plus, slurping an external tool from some random URL in the tests is just kinda ugly. I'm not immediately sure how best to to address this: * We could make mbuto take the profiles as some sort of external file, so they can be provided by the user, rather than built into the mbuto repository. * We could just fork a copy of mbuto into the passt tree, making local modifications for the profile, and only manually updating it to match upstream mbuto changes. * We could use an entirely different and more established tool for building our testing guest images in passt (e.g. supermin, buildroot or just picking a standard distro guest image) -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson

2 4

[PATCH] Makefile: Suppress unusedStructMember Cppcheck warning in dhcp.c
by Stefano Brivio 14 Jun '22

14 Jun '22

New from Cppcheck 2.8: all the fields of struct msg that are not directly manipulated are now reported as unused, which is kind of correct as those fields are used as a blob "copied" from request to response and not as separate fields. However, keeping the message composition explicit is probably desirable, and adding inline suppressions makes the whole thing rather unreadable, so just suppress unusedStructMember warnings for dhcp.c, while also adding a suppression for unmatched suppressions to keep earlier versions of Cppcheck happy. Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 9f2ec3a..b0de1ec 100644 --- a/Makefile +++ b/Makefile @@ -259,8 +259,10 @@ cppcheck: $(wildcard *.c) $(wildcard *.h) --suppress=localtimeCalled:pcap.c \ --suppress=unusedStructMember:pcap.c \ --suppress=funcArgNamesDifferent:util.h \ + --suppress=unusedStructMember:dhcp.c \ \ --suppress=unmatchedSuppression:conf.c \ + --suppress=unmatchedSuppression:dhcp.c \ --suppress=unmatchedSuppression:passt.c \ --suppress=unmatchedSuppression:pcap.c \ --suppress=unmatchedSuppression:qrap.c \ -- 2.35.1

1 0

Bugzilla complains about invalid content-type
by Carl Winbäck 09 Jun '22

09 Jun '22

Hi all! When I try to interact with Bugzilla, this error pops up at various locations: “Software error: Invalid Content-Type 'subtype' parameter at Bugzilla/BugMail.pm line 499. For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.” [URL: https://bugs.passt.top/process_bug.cgi] How to reproduce: * Go to a ticket, e.g. https://bugs.passt.top/show_bug.cgi?id=6 * Write a comment in the Additional Comments textarea. * Click on the button labeled “Save Changes” Despite the error message, my comment was saved sucessfully. The above error message also showed when I (sucessfully) attempted to add my self to the CC list of this ticket. Best regards, Carl Winbäck

2 3

2024

2023

2022

2021

dev June 2022