search for: libvirt_xml_params

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' :

...string ((str)); \ diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c index f80932001..bf6b01c49 100644 --- a/lib/launch-libvirt.c +++ b/lib/launch-libvirt.c @@ -1053,10 +1053,7 @@ construct_libvirt_xml_name (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo) { - start_element ("name") { - string (params->data->name); - } end_element (); - + single_element ("name", params->data->name); return 0; } @@ -1087,17 +1084,12 @@ construct_libvirt_xml_cpu (gue...

...,6 +801,59 @@ static int construct_libvirt_xml_disk_source_hosts (guestfs_h *g, xmlTextWriterP static int construct_libvirt_xml_disk_source_seclabel (guestfs_h *g, const struct backend_libvirt_data *data, xmlTextWriterPtr xo); static int construct_libvirt_xml_appliance (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo); +/* These macros make it easier to write XML, but they also make a lot + * of assumptions: + * + * - The xmlTextWriterPtr is called 'xo'. It is used implicitly. + * + * - The guestfs handle is called 'g'. It is used implicitly for errors. + * + * -...

Link to version 1: https://www.redhat.com/archives/libguestfs/2013-February/thread.html#00122 Changes since version 1: - I've pushed two (of the three) code refactoring patches. The third one proved rather hard to move. - selinuxnorelabel option is no more. Instead there is a second internal API (internal_set_libvirt_selinux_norelabel_disks). - fixed bogus commit message -

This patch causes aarch64 to use virtio-pci instead of virtio-mmio. Virtio-pci is considerably faster than virtio-mmio, it's more like how other architectures work, and it supports hotplugging (although it's not likely we'd use the latter feature). I'm not necessarily suggesting that we apply this. Laine (CC'd) has some further patches to libvirt lined up which AIUI would

...,79 +966,6 @@ static int construct_libvirt_xml_disk_source_hosts (guestfs_h *g, xmlTextWriterP static int construct_libvirt_xml_disk_source_seclabel (guestfs_h *g, const struct backend_libvirt_data *data, xmlTextWriterPtr xo); static int construct_libvirt_xml_appliance (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo); -/* These macros make it easier to write XML, but they also make a lot - * of assumptions: - * - * - The xmlTextWriterPtr is called 'xo'. It is used implicitly. - * - * - The guestfs handle is called 'g'. It is used implicitly for errors. - * - * -...

.../* false = qemu, true = kvm (from capabilities)*/ unsigned long qemu_version; /* qemu version (from libvirt) */ + struct secret *secrets; /* list of secrets */ + size_t nr_secrets; }; /* Parameters passed to construct_libvirt_xml and subfunctions. We @@ -130,6 +151,9 @@ struct libvirt_xml_params { }; static int parse_capabilities (guestfs_h *g, const char *capabilities_xml, struct backend_libvirt_data *data); +static int add_secret (guestfs_h *g, struct backend_libvirt_data *data, const struct drive *drv); +static int find_secret (guestfs_h *g, const struct backend_libvirt_data *data,...

Since v1: - Base64 decode the Ceph secret before passing it to libvirt. - Don't call virSecretFree (NULL) [libvirt bug?] - Small cleanups.

By passing root=UUID=... to supermin, we make the appliance boot process less sensitive to the non-deterministic process of scanning SCSI disks (of which much more to come). This patch should be tested alongside the supermin patch posted here: https://www.redhat.com/archives/libguestfs/2017-April/msg00174.html which in turn requires this supermin patch series:

...,6 +950,13 @@ static int construct_libvirt_xml_disk_source_hosts (guestfs_h *g, xmlTextWriterP static int construct_libvirt_xml_disk_source_seclabel (guestfs_h *g, const struct backend_libvirt_data *data, xmlTextWriterPtr xo); static int construct_libvirt_xml_appliance (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo); +static int construct_libvirt_xml_virtio_pci_address (guestfs_h *g, xmlTextWriterPtr xo, int slot); +/* Don't use slot 1, since can be used by video. */ +#define VIRTIO_PCI_SLOT_RNG 2 +#define VIRTIO_PCI_SLOT_SCSI 3 +#define VIRTIO_PCI_SLOT_SERIAL 4 +#de...

v1 was here: https://www.redhat.com/archives/libguestfs/2018-October/msg00047.html v2 was here: https://www.redhat.com/archives/libguestfs/2018-October/msg00051.html v3: - Back to using string/string_format and attribute/attribute_format. - Add both single_element and single_element_format. - Rebased and retested. Rich.

...} - } else - debug (g, "cannot find group 'qemu'"); - } - /* Store any secrets in libvirtd, keeping a mapping from the secret * to its UUID. */ @@ -1256,7 +1209,18 @@ construct_libvirt_xml_seclabel (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo) { - if (!params->enable_svirt) { + if (params->current_proc_is_root) { + /* Force libvirt to run qemu as root.root. */ + start_element ("seclabel") { + attribute ("type", "static"); +...

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

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

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

...,79 +919,6 @@ static int construct_libvirt_xml_disk_source_hosts (guestfs_h *g, xmlTextWriterP static int construct_libvirt_xml_disk_source_seclabel (guestfs_h *g, const struct backend_libvirt_data *data, xmlTextWriterPtr xo); static int construct_libvirt_xml_appliance (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo); -/* These macros make it easier to write XML, but they also make a lot - * of assumptions: - * - * - The xmlTextWriterPtr is called 'xo'. It is used implicitly. - * - * - The guestfs handle is called 'g'. It is used implicitly for errors. - * - * -...

This is the libguestfs companion patch to: https://www.redhat.com/archives/libguestfs/2013-September/msg00045.html Rich.

QEMU upstream has broken snapshot=on ... again. These two patches stop using it entirely. Instead we run 'qemu-img create' to create overlay disks as required. Note that the libvirt and UML backends were already doing this: The libvirt backend because <transient/> has never worked, and the UML backend was running uml_mkcow because the UML-equivalent syntax of snapshot=on was

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

...sk_source_hosts (guestfs_h *g, xmlTextWriterPtr xo, const struct drive_source *src); > static int construct_libvirt_xml_disk_source_seclabel (guestfs_h *g, const struct backend_libvirt_data *data, xmlTextWriterPtr xo); > static int construct_libvirt_xml_appliance (guestfs_h *g, const struct libvirt_xml_params *params, xmlTextWriterPtr xo); > @@ -1578,6 +1579,10 @@ construct_libvirt_xml_disk (guestfs_h *g, > if (construct_libvirt_xml_disk_address (g, xo, drv_index) == -1) > return -1; > > + if (construct_libvirt_xml_disk_blockio (g, xo, drv->pblocksize, > +...