Re: [Libguestfs] [libguestfs PATCH 7/7] lib/launch-direct: support networking with passt
On 7/14/23 11:53, Richard W.M. Jones wrote:
> On Thu, Jul 13, 2023 at 07:10:52PM +0200, Laszlo Ersek wrote:
>> On QEMU 7.2.0+, if "passt" is available, ask QEMU for passt ("stream")
>> rather than SLIRP ("user") networking.
>>
>> For this, we need to run passt ourselves. Given that passt daemonizes by
>> default, start it with our traditional function guestfs_int_cmd_run(). Ask
>> passt to save its PID file, because in case something goes wrong before
>> we're completely sure the appliance (i.e. QEMU) is up and running, we'll
>> need to kill passt, the *grandchild*, ourselves.
>>
>> Pass "--one-off" to passt (same as libvirt). This way, once we have proof
>> that QEMU has connected to passt (because the appliance shows signs of
>> life), we need not clean up passt ourselves -- once QEMU exits, passt will
>> see an EOF on the unix domain socket, and exit as well.
>>
>> Passt is way more flexible than SLIRP, and passt normally intends to
>> imitate the host environment in the guest as much as possible. This means
>> that, when switching from SLIRP to passt, the guest would see changes to
>> the following:
>>
>> - guest IP address,
>>
>> - guest subnet mask,
>>
>> - host (= gateway) IP address,
>>
>> - host (= gateway) MAC address.
>>
>> Extract the SLIRP defaults into the new macros NETWORK_GW_IP and
>> NETWORK_GW_MAC, and pass them explicitly to passt. In particular,
>> "tests/rsync/test-rsync.sh" fails without setting the host address
>> (NETWORK_GW_IP) properly.
>
> What really matters is that programs like 'dnf' and 'apt' can be run.
> Nothing that uses libguestfs networking ought to depend on the exact
> IP address or other details of the current SLIRP implementation. So
> these changes are fine. (rsync is a weird feature that we should have
> pushed back on and not added ...)
OK, dnf does work (just tested it with "virt-builder --update" under the
cover letter).
>
>> (These artifacts can be verified in the appliance with "virt-rescue
>> --network", by running "ip addr", "ip route", and "ip neighbor" at the
>> virt-rescue prompt. There are four scenarios: two libguest backends, times
>> passt being installed or not installed.)
>>
>> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184967
>> Signed-off-by: Laszlo Ersek
>> ---
>> lib/guestfs-internal.h | 26
>> lib/launch-direct.c| 147 +++-
>> 2 files changed, 168 insertions(+), 5 deletions(-)
>>
>> diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h
>> index 9ba4d4ad46cf..9f4f800e6d6e 100644
>> --- a/lib/guestfs-internal.h
>> +++ b/lib/guestfs-internal.h
>> @@ -158,6 +158,32 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr)
>> #define NETWORK_ADDRESS "169.254.2.15"
>> #define NETWORK_PREFIX "16"
>>
>> +/* The IP address and the MAC address of the host, as seen from the
>> appliance.
>> + *
>> + * NETWORK_GW_IP should be the same as NETWORK_ADDRESS, only replacing
>> ".15" in
>> + * the rightmost octet with ".2". NETWORK_GW_MAC cannot be changed. These
>> + * restrictions are a consequence of the following landscape:
>> + *
>> + * libguestfs backend userspace network stack restrictions
>> + * -- ---
>>
>> + * direct passtNone; both NETWORK_GW_IP and
>> + * NETWORK_GW_MAC can be set
>> on the
>> + * passt command line.
>> + *
>> + * direct SLIRPSLIRP hard-codes
>> NETWORK_GW_MAC.
>> + *
>> + * libvirt passtThe domain XML does not
>> expose
>> + * either knob (RHBZ#766),
>> even
>> + * though passt could accept
>> both.
>> + *
>> + * libvirt SLIRPThe domain XML does not
>> expose
>> + * either knob (RHBZ#766),
>> and
>> + * SLIRP hard-codes
>> NETWORK_GW_MAC
>> + * anyway.
>> + */
>> +#define NETWORK_GW_IP "169.254.2.2"
>> +#define NETWORK_GW_MAC "52:56:00:00:00:02"
>> +
>> /* Guestfs handle and associated structures. */
>>
>> /* State. */
>> diff --git a/lib/launch-direct.c b/lib/launch-direct.c
>> index 3f46f0509736..8d6ad025a4e1 100644
>> --- a/lib/launch-direct.c
>> +++ b/lib/launch-direct.c
>> @@ -32,6 +32,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -48,6 +49,7 @@
>> #include "guestfs-internal.h"
>> #include "guestfs_protocol.h"
>> #include "qemuopts.h"
>> +#include "ignore-value.h"
>>
>> /* Per-handle data. */
>> struct backend_direct_data {
>> @@ -333,6 +335,110 @@ add_drives (guestfs_h *g, struct backend_direct_data
>> *data,
>>return 0;
>> }
>>
>> +/**
>> + * Launch passt such that
Re: [Libguestfs] [libguestfs PATCH 7/7] lib/launch-direct: support networking with passt
On Thu, Jul 13, 2023 at 07:10:52PM +0200, Laszlo Ersek wrote:
> On QEMU 7.2.0+, if "passt" is available, ask QEMU for passt ("stream")
> rather than SLIRP ("user") networking.
>
> For this, we need to run passt ourselves. Given that passt daemonizes by
> default, start it with our traditional function guestfs_int_cmd_run(). Ask
> passt to save its PID file, because in case something goes wrong before
> we're completely sure the appliance (i.e. QEMU) is up and running, we'll
> need to kill passt, the *grandchild*, ourselves.
>
> Pass "--one-off" to passt (same as libvirt). This way, once we have proof
> that QEMU has connected to passt (because the appliance shows signs of
> life), we need not clean up passt ourselves -- once QEMU exits, passt will
> see an EOF on the unix domain socket, and exit as well.
>
> Passt is way more flexible than SLIRP, and passt normally intends to
> imitate the host environment in the guest as much as possible. This means
> that, when switching from SLIRP to passt, the guest would see changes to
> the following:
>
> - guest IP address,
>
> - guest subnet mask,
>
> - host (= gateway) IP address,
>
> - host (= gateway) MAC address.
>
> Extract the SLIRP defaults into the new macros NETWORK_GW_IP and
> NETWORK_GW_MAC, and pass them explicitly to passt. In particular,
> "tests/rsync/test-rsync.sh" fails without setting the host address
> (NETWORK_GW_IP) properly.
What really matters is that programs like 'dnf' and 'apt' can be run.
Nothing that uses libguestfs networking ought to depend on the exact
IP address or other details of the current SLIRP implementation. So
these changes are fine. (rsync is a weird feature that we should have
pushed back on and not added ...)
> (These artifacts can be verified in the appliance with "virt-rescue
> --network", by running "ip addr", "ip route", and "ip neighbor" at the
> virt-rescue prompt. There are four scenarios: two libguest backends, times
> passt being installed or not installed.)
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184967
> Signed-off-by: Laszlo Ersek
> ---
> lib/guestfs-internal.h | 26
> lib/launch-direct.c| 147 +++-
> 2 files changed, 168 insertions(+), 5 deletions(-)
>
> diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h
> index 9ba4d4ad46cf..9f4f800e6d6e 100644
> --- a/lib/guestfs-internal.h
> +++ b/lib/guestfs-internal.h
> @@ -158,6 +158,32 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr)
> #define NETWORK_ADDRESS "169.254.2.15"
> #define NETWORK_PREFIX "16"
>
> +/* The IP address and the MAC address of the host, as seen from the
> appliance.
> + *
> + * NETWORK_GW_IP should be the same as NETWORK_ADDRESS, only replacing ".15"
> in
> + * the rightmost octet with ".2". NETWORK_GW_MAC cannot be changed. These
> + * restrictions are a consequence of the following landscape:
> + *
> + * libguestfs backend userspace network stack restrictions
> + * -- ---
>
> + * direct passtNone; both NETWORK_GW_IP and
> + * NETWORK_GW_MAC can be set on
> the
> + * passt command line.
> + *
> + * direct SLIRPSLIRP hard-codes
> NETWORK_GW_MAC.
> + *
> + * libvirt passtThe domain XML does not
> expose
> + * either knob (RHBZ#766),
> even
> + * though passt could accept
> both.
> + *
> + * libvirt SLIRPThe domain XML does not
> expose
> + * either knob (RHBZ#766),
> and
> + * SLIRP hard-codes
> NETWORK_GW_MAC
> + * anyway.
> + */
> +#define NETWORK_GW_IP "169.254.2.2"
> +#define NETWORK_GW_MAC "52:56:00:00:00:02"
> +
> /* Guestfs handle and associated structures. */
>
> /* State. */
> diff --git a/lib/launch-direct.c b/lib/launch-direct.c
> index 3f46f0509736..8d6ad025a4e1 100644
> --- a/lib/launch-direct.c
> +++ b/lib/launch-direct.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -48,6 +49,7 @@
> #include "guestfs-internal.h"
> #include "guestfs_protocol.h"
> #include "qemuopts.h"
> +#include "ignore-value.h"
>
> /* Per-handle data. */
> struct backend_direct_data {
> @@ -333,6 +335,110 @@ add_drives (guestfs_h *g, struct backend_direct_data
> *data,
>return 0;
> }
>
> +/**
> + * Launch passt such that it daemonizes.
> + *
> + * On error, -1 is returned; C and C are not modified.
> + *
> + * On success, 0 is returned. C contains the PID of the passt
> + * background process. C contains the pathname of the unix domain
> + * socket where passt will accept
Re: [Libguestfs] [libguestfs PATCH 7/7] lib/launch-direct: support networking with passt
On 7/13/23 19:10, Laszlo Ersek wrote:
> On QEMU 7.2.0+, if "passt" is available, ask QEMU for passt ("stream")
> rather than SLIRP ("user") networking.
>
> For this, we need to run passt ourselves. Given that passt daemonizes by
> default, start it with our traditional function guestfs_int_cmd_run(). Ask
> passt to save its PID file, because in case something goes wrong before
> we're completely sure the appliance (i.e. QEMU) is up and running, we'll
> need to kill passt, the *grandchild*, ourselves.
>
> Pass "--one-off" to passt (same as libvirt). This way, once we have proof
> that QEMU has connected to passt (because the appliance shows signs of
> life), we need not clean up passt ourselves -- once QEMU exits, passt will
> see an EOF on the unix domain socket, and exit as well.
>
> Passt is way more flexible than SLIRP, and passt normally intends to
> imitate the host environment in the guest as much as possible. This means
> that, when switching from SLIRP to passt, the guest would see changes to
> the following:
>
> - guest IP address,
>
> - guest subnet mask,
>
> - host (= gateway) IP address,
>
> - host (= gateway) MAC address.
>
> Extract the SLIRP defaults into the new macros NETWORK_GW_IP and
> NETWORK_GW_MAC, and pass them explicitly to passt. In particular,
> "tests/rsync/test-rsync.sh" fails without setting the host address
> (NETWORK_GW_IP) properly.
>
> (These artifacts can be verified in the appliance with "virt-rescue
> --network", by running "ip addr", "ip route", and "ip neighbor" at the
> virt-rescue prompt. There are four scenarios: two libguest backends, times
> passt being installed or not installed.)
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184967
> Signed-off-by: Laszlo Ersek
> ---
> lib/guestfs-internal.h | 26
> lib/launch-direct.c| 147 +++-
> 2 files changed, 168 insertions(+), 5 deletions(-)
>
> diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h
> index 9ba4d4ad46cf..9f4f800e6d6e 100644
> --- a/lib/guestfs-internal.h
> +++ b/lib/guestfs-internal.h
> @@ -158,6 +158,32 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr)
> #define NETWORK_ADDRESS "169.254.2.15"
> #define NETWORK_PREFIX "16"
>
> +/* The IP address and the MAC address of the host, as seen from the
> appliance.
> + *
> + * NETWORK_GW_IP should be the same as NETWORK_ADDRESS, only replacing ".15"
> in
> + * the rightmost octet with ".2". NETWORK_GW_MAC cannot be changed. These
> + * restrictions are a consequence of the following landscape:
> + *
> + * libguestfs backend userspace network stack restrictions
> + * -- ---
>
> + * direct passtNone; both NETWORK_GW_IP and
> + * NETWORK_GW_MAC can be set on
> the
> + * passt command line.
> + *
> + * direct SLIRPSLIRP hard-codes
> NETWORK_GW_MAC.
> + *
> + * libvirt passtThe domain XML does not
> expose
> + * either knob (RHBZ#766),
> even
> + * though passt could accept
> both.
> + *
> + * libvirt SLIRPThe domain XML does not
> expose
> + * either knob (RHBZ#766),
> and
> + * SLIRP hard-codes
> NETWORK_GW_MAC
> + * anyway.
> + */
> +#define NETWORK_GW_IP "169.254.2.2"
> +#define NETWORK_GW_MAC "52:56:00:00:00:02"
> +
> /* Guestfs handle and associated structures. */
>
> /* State. */
> diff --git a/lib/launch-direct.c b/lib/launch-direct.c
> index 3f46f0509736..8d6ad025a4e1 100644
> --- a/lib/launch-direct.c
> +++ b/lib/launch-direct.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -48,6 +49,7 @@
> #include "guestfs-internal.h"
> #include "guestfs_protocol.h"
> #include "qemuopts.h"
> +#include "ignore-value.h"
>
> /* Per-handle data. */
> struct backend_direct_data {
> @@ -333,6 +335,110 @@ add_drives (guestfs_h *g, struct backend_direct_data
> *data,
>return 0;
> }
>
> +/**
> + * Launch passt such that it daemonizes.
> + *
> + * On error, -1 is returned; C and C are not modified.
> + *
> + * On success, 0 is returned. C contains the PID of the passt
> + * background process. C contains the pathname of the unix domain
> + * socket where passt will accept a single connection.
> + */
Arguably, I should have typed C<-1> and C<0> above; I can fix those up,
upon pushing, in case no more changes were requested.
Laszlo
> +static int
> +launch_passt (guestfs_h *g, long *passt_pid, char (*sockpath)[UNIX_PATH_MAX])
> +{
> + int rc;
> + char sockpath_local[sizeof *sockpath];
> + char
[Libguestfs] [libguestfs PATCH 7/7] lib/launch-direct: support networking with passt
On QEMU 7.2.0+, if "passt" is available, ask QEMU for passt ("stream")
rather than SLIRP ("user") networking.
For this, we need to run passt ourselves. Given that passt daemonizes by
default, start it with our traditional function guestfs_int_cmd_run(). Ask
passt to save its PID file, because in case something goes wrong before
we're completely sure the appliance (i.e. QEMU) is up and running, we'll
need to kill passt, the *grandchild*, ourselves.
Pass "--one-off" to passt (same as libvirt). This way, once we have proof
that QEMU has connected to passt (because the appliance shows signs of
life), we need not clean up passt ourselves -- once QEMU exits, passt will
see an EOF on the unix domain socket, and exit as well.
Passt is way more flexible than SLIRP, and passt normally intends to
imitate the host environment in the guest as much as possible. This means
that, when switching from SLIRP to passt, the guest would see changes to
the following:
- guest IP address,
- guest subnet mask,
- host (= gateway) IP address,
- host (= gateway) MAC address.
Extract the SLIRP defaults into the new macros NETWORK_GW_IP and
NETWORK_GW_MAC, and pass them explicitly to passt. In particular,
"tests/rsync/test-rsync.sh" fails without setting the host address
(NETWORK_GW_IP) properly.
(These artifacts can be verified in the appliance with "virt-rescue
--network", by running "ip addr", "ip route", and "ip neighbor" at the
virt-rescue prompt. There are four scenarios: two libguest backends, times
passt being installed or not installed.)
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184967
Signed-off-by: Laszlo Ersek
---
lib/guestfs-internal.h | 26
lib/launch-direct.c| 147 +++-
2 files changed, 168 insertions(+), 5 deletions(-)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h
index 9ba4d4ad46cf..9f4f800e6d6e 100644
--- a/lib/guestfs-internal.h
+++ b/lib/guestfs-internal.h
@@ -158,6 +158,32 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr)
#define NETWORK_ADDRESS "169.254.2.15"
#define NETWORK_PREFIX "16"
+/* The IP address and the MAC address of the host, as seen from the appliance.
+ *
+ * NETWORK_GW_IP should be the same as NETWORK_ADDRESS, only replacing ".15" in
+ * the rightmost octet with ".2". NETWORK_GW_MAC cannot be changed. These
+ * restrictions are a consequence of the following landscape:
+ *
+ * libguestfs backend userspace network stack restrictions
+ * -- ---
+ * direct passtNone; both NETWORK_GW_IP and
+ * NETWORK_GW_MAC can be set on
the
+ * passt command line.
+ *
+ * direct SLIRPSLIRP hard-codes
NETWORK_GW_MAC.
+ *
+ * libvirt passtThe domain XML does not expose
+ * either knob (RHBZ#766),
even
+ * though passt could accept both.
+ *
+ * libvirt SLIRPThe domain XML does not expose
+ * either knob (RHBZ#766), and
+ * SLIRP hard-codes NETWORK_GW_MAC
+ * anyway.
+ */
+#define NETWORK_GW_IP "169.254.2.2"
+#define NETWORK_GW_MAC "52:56:00:00:00:02"
+
/* Guestfs handle and associated structures. */
/* State. */
diff --git a/lib/launch-direct.c b/lib/launch-direct.c
index 3f46f0509736..8d6ad025a4e1 100644
--- a/lib/launch-direct.c
+++ b/lib/launch-direct.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,6 +49,7 @@
#include "guestfs-internal.h"
#include "guestfs_protocol.h"
#include "qemuopts.h"
+#include "ignore-value.h"
/* Per-handle data. */
struct backend_direct_data {
@@ -333,6 +335,110 @@ add_drives (guestfs_h *g, struct backend_direct_data
*data,
return 0;
}
+/**
+ * Launch passt such that it daemonizes.
+ *
+ * On error, -1 is returned; C and C are not modified.
+ *
+ * On success, 0 is returned. C contains the PID of the passt
+ * background process. C contains the pathname of the unix domain
+ * socket where passt will accept a single connection.
+ */
+static int
+launch_passt (guestfs_h *g, long *passt_pid, char (*sockpath)[UNIX_PATH_MAX])
+{
+ int rc;
+ char sockpath_local[sizeof *sockpath];
+ char *pid_path;
+ struct command *cmd;
+ int passt_status;
+ int passt_exit;
+ char *pid_str;
+ long passt_pid_local;
+ char *endptr;
+
+ rc = -1;
+ if (guestfs_int_create_socketname (g, "passt.sock", _local) == -1)
+return rc;
+
+ pid_path = guestfs_int_make_pid_path (g, "passt");
+ if (pid_path == NULL)
+return rc;
+
+ cmd = guestfs_int_new_command (g);
+ if (cmd == NULL)
+goto free_pid_path;
+
+ guestfs_int_cmd_add_arg
