search for: guestfsd_path

Error out early if the path to the socket will not fit into sockaddr_un::sun_path, as we will not be able to connect to it. --- src/launch-unix.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/launch-unix.c b/src/launch-unix.c index 740c554..973e14b 100644 --- a/src/launch-unix.c +++ b/src/launch-unix.c @@ -47,6 +47,12 @@ launch_unix (guestfs_h *g, void *datav, const char

...hanged, 10 insertions(+), 2 deletions(-) diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c index 185b44b..8a5d93e 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -397,7 +397,6 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) */ snprintf (data->guestfsd_path, sizeof data->guestfsd_path, "%s/guestfsd.sock", g->tmpdir); - unlink (data->guestfsd_path); set_socket_create_context (g); @@ -424,7 +423,6 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) /* For the serial console. */ snprintf (d...

...74) - * but there's no sane way to test for that. - */ - if (params.current_proc_is_root) { - /* Current process is root, so try to create sockets that are - * owned by root.qemu with mode 0660 and hence accessible to qemu. - */ - struct group *grp; - - if (chmod (data->guestfsd_path, 0660) == -1) { - perrorf (g, "chmod: %s", data->guestfsd_path); - goto cleanup; - } - - if (chmod (data->console_path, 0660) == -1) { - perrorf (g, "chmod: %s", data->console_path); - goto cleanup; - } - - grp = getgrnam ("qemu&quot...

libvirt doesn't have a concept of "session qemu" for root: https://bugzilla.redhat.com/show_bug.cgi?id=890291 When a libguestfs-using process runs as root, and libvirt runs a qemu subprocess, the qemu subprocess is run as a non-root user (typically qemu.qemu). This causes various problems, for example if we try to open a file which is readable by root but unreadable by qemu.qemu

...a/src/launch-libvirt.c > +++ b/src/launch-libvirt.c > @@ -395,8 +395,9 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) > /* Using virtio-serial, we need to create a local Unix domain socket > * for qemu to connect to. > */ > - snprintf (data->guestfsd_path, sizeof data->guestfsd_path, > - "%s/guestfsd.sock", g->tmpdir); > + if (guestfs_int_create_socketname (g, "guestfsd.sock", > + &data->guestfsd_path) == -1) > + goto cleanup; > > set_socket_cr...

...ex 8a5d93e..376bd80 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -395,8 +395,9 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) /* Using virtio-serial, we need to create a local Unix domain socket * for qemu to connect to. */ - snprintf (data->guestfsd_path, sizeof data->guestfsd_path, - "%s/guestfsd.sock", g->tmpdir); + if (guestfs_int_create_socketname (g, "guestfsd.sock", + &data->guestfsd_path) == -1) + goto cleanup; set_socket_create_context (g); @@ -421,8...

...ex 8a5d93e..376bd80 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -395,8 +395,9 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) /* Using virtio-serial, we need to create a local Unix domain socket * for qemu to connect to. */ - snprintf (data->guestfsd_path, sizeof data->guestfsd_path, - "%s/guestfsd.sock", g->tmpdir); + if (guestfs_int_create_socketname (g, "guestfsd.sock", + &data->guestfsd_path) == -1) + goto cleanup; set_socket_create_context (g); @@ -421,8...

...ex 8a5d93e..376bd80 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -395,8 +395,9 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) /* Using virtio-serial, we need to create a local Unix domain socket * for qemu to connect to. */ - snprintf (data->guestfsd_path, sizeof data->guestfsd_path, - "%s/guestfsd.sock", g->tmpdir); + if (guestfs_int_create_socketname (g, "guestfsd.sock", + &data->guestfsd_path) == -1) + goto cleanup; set_socket_create_context (g); @@ -421,8...

...a/src/launch-libvirt.c > +++ b/src/launch-libvirt.c > @@ -395,8 +395,9 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri) > /* Using virtio-serial, we need to create a local Unix domain socket > * for qemu to connect to. > */ > - snprintf (data->guestfsd_path, sizeof data->guestfsd_path, > - "%s/guestfsd.sock", g->tmpdir); > + if (guestfs_int_create_socketname (g, "guestfsd.sock", > + &data->guestfsd_path) == -1) > + goto cleanup; > > set_socket_cr...

I've been taking a long hard look at the protocol layer. It has evolved over a long time without any particular direction, and the result is, to say the least, not very organized. These patches take a first step at cleaning up the mess by abstracting out socket operations from the rest of the code. The purpose of this is to allow us to slot in a different connection layer under the

Starting with 5.2.0, libvirt has a way to select the firmware by specifying its type, provided configuration files for the firmware are shipped. Currently we start the appliance as UEFI if any of the firmware are found, so instead we can try to just set the firmware type iff: - the libvirt autoselection works - the 'efi' firmware is available The only behaviour change is that the default

In case you configure libguestfs with a custom QEMU, e.g.: $ ./configure [...] QEMU=/path/to/qemu then the libvirt backend did not use to override it, launching the appliance with the default QEMU for libvirt. This does not change the manual emulator overriding using set-hv. Pino Toscano (2): launch: libvirt: get default QEMU from domcapabilities launch: libvirt: fix custom hypervisor

...ot;sclp"); @@ -1373,7 +1310,7 @@ construct_libvirt_xml_devices (guestfs_h *g, attribute ("type", "unix"); start_element ("source") { attribute ("mode", "connect"); - attribute ("path", params->data->guestfsd_path); + attribute ("path", "%s", params->data->guestfsd_path); } end_element (); start_element ("target") { attribute ("type", "virtio"); @@ -1386,7 +1323,7 @@ construct_libvirt_xml_devices (guestfs_h *g, start...

Consolidate and extend the use of funky start_element() etc macros. Rich.

These patches contain the beginnings of discard (a.k.a. trim or unmap) support. This will allow us to change virt-sparsify to work on disk images in-place (instead of using slow & inefficient copying). The approach used is to add an optional 'discard' parameter to add-drive. It has 3 possible settings: - 'disable' : the default, no discard is done - 'besteffort' :

v1 was here: https://www.redhat.com/archives/libguestfs/2018-October/msg00047.html However it was broken in a few ways. First of all the documentation was broken because "/**" enhanced comments were not permitted on macros. This is fixed in the new 1/4 patch. Secondly we didn't use single_element() everywhere possible, which is fixed in the new 4/4 patch. Lastly I've

Hi, continuing what started a couple of weeks ago [1], the attached patch series continues the work in making it easier to build and run libguestfs (in fixed appliance mode) on OSes different than Linux. The provided changes should cause no functional changes on Linux. [1] https://www.redhat.com/archives/libguestfs/2014-October/msg00176.html Thanks, -- Pino Pino Toscano (9): build: check

This still isn't working at the moment. See: http://marc.info/?t=139457409300003&r=1&w=2 This set of patches: - Adds new APIs to support discard in libguestfs. - Adds discard support to virt-format. - Adds discard support to virt-sysprep. - Implements virt-sparsify --in-place. Rich.