- Devel - libvirt List Archives

[libvirt] [PATCH] domain_conf: Unref video private data in virDomainVideoDefClear()
by Michal Privoznik 26 Sep '19

26 Sep '19

The private data for video definition is created in virDomainVideoDefNew() and we attempt to free it in virDomainVideoDefFree(). This seems to work, except the free function calls clear function which zeroes out the whole structure and thus virObjectUnref() which is called on private data does nothing. 2,568 bytes in 107 blocks are definitely lost in loss record 207 of 213 at 0x4A35476: calloc (vg_replace_malloc.c:752) by 0x50A6048: virAllocVar (viralloc.c:346) by 0x513CC5A: virObjectNew (virobject.c:243) by 0x4DC1DEE: qemuDomainVideoPrivateNew (qemu_domain.c:1337) by 0x51A6BD6: virDomainVideoDefNew (domain_conf.c:2831) by 0x51B9F06: virDomainVideoDefParseXML (domain_conf.c:15541) by 0x51CB761: virDomainDefParseXML (domain_conf.c:21158) by 0x51C5973: virDomainDefParseNode (domain_conf.c:21708) by 0x51C583A: virDomainDefParse (domain_conf.c:21663) by 0x51C58AE: virDomainDefParseFile (domain_conf.c:21688) Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 67555c9be3..c290baf953 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2853,6 +2853,7 @@ virDomainVideoDefClear(virDomainVideoDefPtr def) if (def->driver) VIR_FREE(def->driver->vhost_user_binary); VIR_FREE(def->driver); + virObjectUnref(def->privateData); memset(def, 0, sizeof(*def)); } @@ -2864,7 +2865,6 @@ void virDomainVideoDefFree(virDomainVideoDefPtr def) return; virDomainVideoDefClear(def); - virObjectUnref(def->privateData); VIR_FREE(def); } -- 2.21.0

2 3

[libvirt] [glib PATCH] gconfig-domain-video: Add bochs video device
by Fabiano Fidêncio 26 Sep '19

26 Sep '19

https://bugzilla.redhat.com/show_bug.cgi?id=1753670 Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> --- libvirt-gconfig/libvirt-gconfig-domain-video.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libvirt-gconfig/libvirt-gconfig-domain-video.h b/libvirt-gconfig/libvirt-gconfig-domain-video.h index 973ba72..8431f6b 100644 --- a/libvirt-gconfig/libvirt-gconfig-domain-video.h +++ b/libvirt-gconfig/libvirt-gconfig-domain-video.h @@ -63,7 +63,8 @@ typedef enum { GVIR_CONFIG_DOMAIN_VIDEO_MODEL_XEN, GVIR_CONFIG_DOMAIN_VIDEO_MODEL_VBOX, GVIR_CONFIG_DOMAIN_VIDEO_MODEL_QXL, - GVIR_CONFIG_DOMAIN_VIDEO_MODEL_VIRTIO + GVIR_CONFIG_DOMAIN_VIDEO_MODEL_VIRTIO, + GVIR_CONFIG_DOMAIN_VIDEO_MODEL_BOCHS, } GVirConfigDomainVideoModel; GType gvir_config_domain_video_get_type(void); -- 2.23.0

2 1

[libvirt] [PATCH 1/1] conf: handle empty string in interface target name
by Nikolay Shirokovskiy 26 Sep '19

26 Sep '19

Empty name is not allowed by schema but qemu is able to start with such a config (and I guess some other hypervisors too). As a result name will be generated by kernel and have form 'tap<N>'. At the same time if target element is ommited in config the name will be generated by libvirt and have form 'vnet<N>'. Let's have only the latter pattern for autogenerated names by treating empty name as ommited. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com> --- There is a RFS for the issue - https://www.redhat.com/archives/libvir-list/2019-September/msg00645.html src/conf/domain_conf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 76aaa63f57..7ff3972cbb 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -11592,6 +11592,8 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, } else if (!ifname && virXMLNodeNameEqual(cur, "target")) { ifname = virXMLPropString(cur, "dev"); + if (ifname[0] == '\0') + VIR_FREE(ifname); managed_tap = virXMLPropString(cur, "managed"); } else if ((!ifname_guest || !ifname_guest_actual) && virXMLNodeNameEqual(cur, "guest")) { -- 2.23.0

3 5

[libvirt] [PATCH v3 00/11] remove repetition of URI path validation
by Daniel Henrique Barboza 26 Sep '19

26 Sep '19

This is a code repetition that I crossed a few times, then I noticed that Cole Robinson suggested a solution for it in the wiki. Here it is. changes from v2: - use a boolean to determine 'QEMU' and 'vbox' case to avoid block repetition (patch 8) - avoid 80+ chars lines in all patches changes from v1: - handle QEMU and vbox cases separately inside the validation function v2: https://www.redhat.com/archives/libvir-list/2019-September/msg01007.html v1: https://www.redhat.com/archives/libvir-list/2019-September/msg00983.html Daniel Henrique Barboza (11): src/driver.c: add virConnectValidateURIPath() interface_backend_netcf.c: use virConnectValidateURIPath() interface_backend_udev.c: use virConnectValidateURIPath() bridge_driver.c: virConnectValidateURIPath() node_device_driver.c: use virConnectValidateURIPath() secret_driver.c: use virConnectValidateURIPath() storage_driver.c: use virConnectValidateURIPath() driver.c: change URI validation to handle QEMU and vbox case qemu_driver.c: use virConnectValidateURIPath() vbox_common.c: use virConnectValidateURIPath() vbox_driver.c: use virConnectValidateURIPath() src/driver.c | 38 +++++++++++++++++++++++++ src/driver.h | 4 +++ src/interface/interface_backend_netcf.c | 19 +++---------- src/interface/interface_backend_udev.c | 19 +++---------- src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 19 +++---------- src/node_device/node_device_driver.c | 19 +++---------- src/qemu/qemu_driver.c | 20 +++---------- src/secret/secret_driver.c | 19 +++---------- src/storage/storage_driver.c | 19 +++---------- src/vbox/vbox_common.c | 16 ++--------- src/vbox/vbox_driver.c | 16 ++--------- 12 files changed, 75 insertions(+), 134 deletions(-) -- 2.21.0

2 13

[libvirt] [libvirt-rust PATCH 0/1] Fix unsoundness in wrapper new constructor
by Linus Färnstrand 25 Sep '19

25 Sep '19

There are safety issues with all wrapper type constructors. All safe wrappers can be created without `unsafe` from raw pointers. Meaning any subsequent use will cause undefined behavior if the pointer does not point to a valid object: ```rust // This will segfault / Cause undefined behavior virt::connect::Connect::new(ptr::null_mut()).get_hostname() ``` These methods to create safe wrappers from raw pointers must be `unsafe`. And optimally is if all unsafe methods have a `# Safety` section explaining what conditions must hold to call them. Since these methods should not be the main way of instantiating these types, they should likely not be called `new`, but rather something like `from_ptr`. Let's see if I manage to make the patch appear under the same email thread this time. Linus Färnstrand (1): Make creating safe wrapper from raw pointer unsafe src/connect.rs | 10 ++++++++-- src/domain.rs | 10 ++++++++-- src/domain_snapshot.rs | 10 ++++++++-- src/interface.rs | 10 ++++++++-- src/network.rs | 10 ++++++++-- src/nodedev.rs | 10 ++++++++-- src/nwfilter.rs | 10 ++++++++-- src/secret.rs | 10 ++++++++-- src/storage_pool.rs | 10 ++++++++-- src/storage_vol.rs | 10 ++++++++-- src/stream.rs | 8 +++++++- 11 files changed, 87 insertions(+), 21 deletions(-) -- 2.21.0

1 0

[libvirt] QEMU bitmap backup usability FAQ
by John Snow 25 Sep '19

25 Sep '19

Hi, downstream here at Red Hat I've been fielding some questions about the usability and feature readiness of Bitmaps (and related features) in QEMU. Here are some questions I answered internally that I am copying to the list for two reasons: (1) To make sure my answers are actually correct, and (2) To share this pseudo-reference with the community at large. This is long, and mostly for reference. There's a summary at the bottom with some todo items and observations about the usability of the feature as it exists in QEMU. Before too long, I intend to send a more summarized "roadmap" mail which details all of the current and remaining work to be done in and around the bitmaps feature in QEMU. Questions: > "What format(s) is/are required for this functionality?" >From the QEMU API, any format can be used to create and author incremental backups. The only known format limitations are: 1. Persistent bitmaps cannot be created on any format except qcow2, although there are hooks to add support to other formats at a later date if desired. DANGER CAVEAT #1: Adding bitmaps to QEMU by default creates transient bitmaps instead of persistent ones. Possible TODO: Allow users to 'upgrade' transient bitmaps to persistent ones in case they made a mistake. 2. When using push backups (blockdev-backup, drive-backup), you may use any format as a target format. DANGER CAVEAT #2: without backing file and/or filesystem-less sparse support, these images will be unusable. EXAMPLE: Backing up to a raw file loses allocation information, so we can no longer distinguish between zeroes and unallocated regions. The cluster size is also lost. This file will not be usable without additional metadata recorded elsewhere.* (* This is complicated, but it is in theory possible to do a push backup to e.g. an NBD target with custom server code that saves allocation information to a metadata file, which would allow you to reconstruct backups. For instance, recording in a .json file which extents were written out would allow you to -- with a custom binary -- write this information on top of a base file to reconstruct a backup.) 3. Any format can be used for either shared storage or live storage migrations. There are TWO distinct mechanisms for migrating bitmaps: A) The bitmap is flushed to storage and re-opened on the destination. This is only supported for qcow2 and shared-storage migrations. B) The bitmap is live-migrated to the destination. This is supported for any format and can be used for either shared storage or live storage migrations. DANGER CAVEAT #3: The second bitmap migration technique there is an optional migration capability that must be enabled explicitly. Otherwise, some migration combinations may drop bitmaps. Matrix: > migrate = migrate_capability or (persistent and shared_storage) Enumerated: live storage + raw : transient + no-capability: Dropped live-storage + raw : transient + bm-capability: Migrated live-storage + qcow2 : transient + no-capability: Dropped live-storage + qcow2 : transient + bm-capability: Migrated live-storage + qcow2 : persistent + no-capability: Dropped (!) live-storage + qcow2 : persistent + bm-capability: Migrated shared-storage + raw : transient - no-capability: Dropped shared-storage + raw : transient + bm-capability: Migrated shared-storage + qcow2 : transient + no-capability: Migrated shared-storage + qcow2 : transient + bm-capability: Migrated shared-storage + qcow2 : persistent + no-capability: Migrated shared-storage + qcow2 : persistent + bm-capability: Migrated Enabling the bitmap migration capability will ALWAYS migrate the bitmap. If it's disabled, we will only migrate the bitmaps for shared storage migrations where the bitmap is persistent, which is a qcow2-only case. There is no warning or error if you attempt to migrate in a manner that loses your bitmaps. (I might be persuaded to add a case for when you are doing a live storage migration of qcow2 with persistent bitmaps, which is somewhat a conflicting case: you've asked for the bitmap to be persistent, but it seems likely that if this ever happens in practice, it's because you have neglected to ask for it to be migrated to the new host.) See iotest 169 for more details on this. At present, these are the only format limitations I am consciously aware of. From a management API/GUI perspective, it makes sense to restrict the feature set to "qcow2 only" to minimize edge cases. > "Is libvirt aware of these 'gotcha' cases?" >From talks I've had with Eric Blake and Peter Krempa, they certainly are now. > "Is it possible to make persistent the default?" Not quickly. In QEMU, not without a deprecation period or some other incompatibility. Default values are not (yet?) introspectable via the schema. We need (possibly) up to two QAPI extensions: I) The ability to return deprecation warnings when issuing a command that will cease to work in the future. This has been being discussed somewhat on-list recently. It seems like there is not a big appetite for tackling something perceived as low-value because it is likely to be ignored. II) The ability to document default values in the QAPI schema for the purposes of introspection. With one or both of these extensions, we could remove the default value for persistence and promote it to a required argument with a transitionary period where it will work with a warning. Then, in the future, users will be forced to specify if they want persistent=true or persistent=false. This is not on my personal roadmap to implement. > "Is it possible to make bitmap migration the default?" I don't know at present. Migration capabilities are either "on" or "off" and the existing negotiation mechanisms for capabilities are extremely rudimentary. Changing this might require fiddling with machine compat properties, adding features to the migration protocol, or more. I don't know what I don't know, so I will estimate this change as likely invasive. I've discussed this with David Gilbert and it seems like a complicated project for the benefit of this sub-project alone, so this isn't on my personal roadmap to resolve. The general consensus appears to be that protecting the user is libvirt's job. > "Where do we stand with external snapshot support?" Still broken. In the aftermath of 4.1, it's the most obvious outstanding broken feature. Vladimir has patches to fix it, but they need some attention. > "What needs to happen to bitmaps when doing stream or commit?" Uncertain in QEMU; creating an external snapshot implicitly ends the timeslice represented by the old bitmap, but an explicit checkpoint is better. I think some little ascii charts will help people understand what we're talking about here, so let's cover some examples. SCENARIO 1) Here's a timeline for a single node (one image, no backing files), with some points in time highlighted: Time T = 0.........................n +rec: [--X------Y------Z--------] -rec: [---------x------y--------] region: [aabbbbbbbcccccccddddddddd] X, Y, and Z are points in time where bitmaps 'x', 'y', and 'z' were created and began recording. x and y are points in time where bitmaps 'x' and 'y' stopped recording. This creates a few distinct regions / timeslices. a: Data written before we began tracking writes. b: Data written to bitmap 'x' c: Data written to bitmap 'y' d: data written to bitmap 'z' region 'a' is of an unknown size and indeterminate length, because there is no reference point (checkpoint) prior to it. regions 'b' and 'c' are of finite size and determinate length, because they have fixed reference points on either sides of their timeslice. region 'd' is also of an unknown size and indeterminate length, because it is actively recording and has no checkpoint to its right. It may be fixed at any time by disabling bitmap 'z'. In QEMU, generally what we want to do is to do several things at one atomic moment to keep these regions adjacent, contiguous, and disjoint. So from a high-level (using a fictional simplified syntax), we do: Transaction( create('y'), disable('x'), backup('x') ) which together performs a backup+checkpoint. We can do a backup without a checkpoint: 4.1: Transaction( create('tmp') merge('tmp', 'x') backup('tmp') ) 4.2: > backup('x', bitmap_sync=never) Or a checkpoint without a backup: Transaction( create('y'), disable('x') ) SCENARIO 2) Now, what happens when we make an external snapshot and do nothing at all to our bitmaps? Time T = 0.......................................n +rec: [--X------Y------Z--------] <-- [-------] -rec: [---------x------y--------] <-- [-------] region: [aabbbbbbbcccccccddddddddd] <-- [eeeeeee] { base } <-- { top } We've created a new implicit timeslice, "e" without creating a new bitmap. Because the bitmap 'z' was still active at the time of the snapshot, it now has a temporarily-determinate endpoint to its region. This is kind of like an "implied checkpoint", but it's a very poor one because it's not really addressable. DANGER CAVEAT #4: We have no way to create incremental backups anymore, because the current moment in time has no addressable point. That's not great; but it is likely a fixable scenario when commit is fixed: committing the top layer back down into the base layer will add all new writes to the end of the old region; restoring our backup chain: Time T = 0.........................C.......n +rec: [--X------Y------Z-------- -------] -rec: [---------x------y-------- -------] region: [aabbbbbbbcccccccddddddddd ddddddd] Here, region 'e' just gets appended to region d, and we can make incremental backups from any checkpoint X, Y, Z to the current moment again. SCENARIO 3) What happens if we make a firm checkpoint at the same time we make the snapshot? Transaction( disable('z'), snapshot('top'), create('w') ) Time T = 0......................... ......n +rec: [--X------Y------Z-------- ] <-- [W------] -rec: [---------x------y--------z] <-- [-------] region: [aabbbbbbbcccccccddddddddd ] <-- [eeeeeee] { base } <-- { top } Now instead of the new region 'e' being implied, it's explicit. We can make backups between any point and the current moment *across* the gap. It was my thought that this was the most preferable method that libvirt should use, but there is some doubt from Peter Krempa. We'll see how it shakes out. There are questions about what QEMU should do by default, without libvirt's help. At the moment, it's "nothing" but there have been questions about "something". Keeping in mind that we likely can't change our existing behavior without some kind of flag, there are still some API/usability questions: > If we create an external snapshot on top of an image with actively > recording bitmaps, should we disable them? We can leave them enabled, but they'll never see any writes. Or we can explicitly disable them. Explicitly disabling them may make more sense to prevent modifying bitmaps accidentally on commit. My guess: No. we should leave them alone; allow checkpoint creation mechanisms to do the disable+create dance for bitmaps as needed. Potential problems: The backing image is read-only, and if we change our mind later, we will need to find a way to re-open the backing image as read-write for the purposes of toggling the recording bit prior to any legitimate guest usage of that node. Then, re-open as RO again. > Should we fork bitmaps (on snapshot)? If a bitmap named 'z' is recording when we create an external snapshot, should that bitmap be *copied* into the top layer? My guess: No. This would allow us to create external snapshots *without* creating a checkpoint, but conceptually that's a nightmare: It would allow for mutually independent creation of snapshots OR checkpoints. This would be hard to corral when undoing a snapshot, for instance. In my opinion, snapshots MUST be checkpoints, and therefore allowing a snapshot without creating a checkpoint is a no-go. > (Should we fork bitmaps) if we're not using checkpoints? If we are using a checkpoint-less paradigm (i.e. the rolling incremental backup using only one bitmap) we might want to copy the bitmap up to make the next incremental backup as if nothing ever happened. However, rolling incremental backups doesn't need any kind of auto-copy feature. This is possible today: > create('base', 'A') > transact(snapshot('top'), create('top', 'B')) > merge('B', [('base', 'A'), ('top', 'B')]) i.e., we create a new bitmap on the top layer, then merge in the old data from the backing file, which remains addressable. Whether the user wants to copy up or not, there are commands that will do that already. > Should we create new bitmaps by default when we can? If a backing image has bitmaps, should QEMU automatically create a new bitmap for the top layer? Should it be named something new, something user-provided, or based on existing active bitmaps? If a user creates a new external snapshot with no consideration paid to bitmaps (like "SCENARIO 2" above), they temporarily lose the ability to do incremental backups. They might be able to commit the image back to "try again." That's not great. Here are some options for resolving this: - Automatic names: Might cause collisions out-of-band with management tooling by accident, tooling has to query to discover what bitmaps were automatically created. - Same names: Can create namespace confusion when committing snapshots later; although each layer of a backing chain can have bitmaps named the same thing, it causes future problems when committing together that can be hard to resolve. - User-provided name: This is workable, and requires an amendment to the snapshot command to automatically create a new bitmap on the snapshot. My guess: No, we can't automatically create a new bitmap for the user. We can amend the snapshot commands to accept bitmap names, but at that point we've just duplicated transactions: Transact( snapshot('top'), create('top', 'new-bitmap') ) All that said (Mostly a lot "No, let's not do anything"), maybe there's room for an "assistive" mode for users, a bitmap-aware snapshot creation command. It could do the following well-defined magic: bitmap-snapshot(base, top, bitmap_name): 1. disable any active bitmaps in the base node. 2. create a bitmap named "bitmap_name" in the top node, failing if a bitmap by that name already exists on either node. What this accomplishes: - Disables any bitmaps in the base layer ahead of time, in preparation for an eventual commit operation. - Always creates a new, enabled bitmap on the snapshot mode which is guaranteed not to conflict with a name on the base node. This bitmap can be used to create additional copies post-hoc, if desired. - Formalizes our "best practice" suggestion for mixing bitmaps and snapshots into a single, documented command. Is this strictly needed? No, if you have the foresight, you can do this instead: Transact( disable('a'), disable('b'), disable('c'), # plus however many more ... snapshot('top', ...), create('top', 'd') ) but a convenience command might still have a role to play in helping take the guesswork out for non-libvirt users. That's the bulk of what was discussed. Summary: GOTCHAs: #1: Bitmaps are created non-persistent by default, and can't be changed. #2: Push backup destination formats will happily back up to a format that isn't semantically useful. #3: Migrating non-shared block storage can drop even persistent bitmaps if you don't pass the bitmap migration capability flag to both QEMU instances. #4: Creating a snapshot without doing some bitmap manipulation beforehand can temporarily render your bitmaps unusable. Failing to disable bitmaps before creating a snapshot might make commits very tricky later on. Gotchas 1 and 4 can be at least partially alleviated. gotcha 2 remains a pain point we cannot intercept at the QEMU layer. gotcha 3 has potential remedies, but they are complicated. QEMU todo items: - Fix bitmap data corruption on commit (Ongoing, by Vladimir@Virtuozzo) - add a set_persistence method for bitmaps that allows us to change the storage class of a bitmap after creation. (Helps alleviate gotcha #1.) - Add a command that allows us to merge allocation data into a bitmap. This helps alleviate gotcha #4: If we create a new image but neglected to do the proper transaction dance, we can simply copy the allocation data into a new bitmap. (Note, we'd still need set_persistence to help us disable the old bitmap before any commit happens.) - Add convenience command for easy + safe combination of bitmaps + snapshots. Helps prevent #4. Research items: - How hard is it to reopen a backing image as RW while it's in-use, disable a bitmap, and then reopen as RO? This is to partially address gotcha #4; if we forget to disable bitmaps before creating the snapshot. - How hard is the reverse operation? Can we reopen a backing image RW, enable a bitmap, and then reopen as RO? This gives us better control over what happens on commit. - After we fix the commit bug, what does/should commit actually do with bitmaps? What about bitmaps that collide? The current behavior is that any bitmaps don't transfer from top to base. Any bitmaps active in the base record all the new writes from the top. That's all! --js

3 7

[libvirt] [jenkins-ci PATCH] jenkins: Don't try to build libosinfo on Debian sid
by Andrea Bolognani 25 Sep '19

25 Sep '19

We support the platform as a target for lcitool-driven builds, but we don't have a corresponding worker in the CentOS CI environment. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as a fix to the CI environment. jenkins/projects/libosinfo.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/jenkins/projects/libosinfo.yaml b/jenkins/projects/libosinfo.yaml index c744b38..b38524e 100644 --- a/jenkins/projects/libosinfo.yaml +++ b/jenkins/projects/libosinfo.yaml @@ -5,7 +5,6 @@ # CentOS 7, Debian 9, Ubuntu 18; machines: - libvirt-debian-10 - - libvirt-debian-sid - libvirt-fedora-29 - libvirt-fedora-30 - libvirt-fedora-rawhide -- 2.21.0

1 0

[libvirt] [PATCH] domain_conf: Fix str2enum translation of video driver name
by Michal Privoznik 25 Sep '19

25 Sep '19

In bc1e924cf0d we've introduced video driver name and whilst doing so we've utilized VIR_ENUM_IMPL() macro. Then, in domain XML parsing code the generated virDomainVideoBackendTypeFromString() is called and its return value is assigned directly to an unsigned int variable which is wrong. Also, the video driver enum has 'default' value which is not formatted into domain XML but is accepted during parsing. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial & build breaker rules. src/conf/domain_conf.c | 4 +++- src/conf/domain_conf.h | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 6dea670257..67555c9be3 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -15504,11 +15504,13 @@ virDomainVideoDefParseXML(virDomainXMLOptionPtr xmlopt, } if (driver_name) { - if ((def->backend = virDomainVideoBackendTypeFromString(driver_name)) < 0) { + int backend; + if ((backend = virDomainVideoBackendTypeFromString(driver_name)) <= 0) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("unknown video driver '%s'"), driver_name); goto error; } + def->backend = backend; } else { def->backend = VIR_DOMAIN_VIDEO_BACKEND_TYPE_DEFAULT; } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index cff33f6682..53bdee22fb 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1378,7 +1378,7 @@ struct _virDomainWatchdogDef { /* the backend driver used for virtio interfaces */ typedef enum { - VIR_DOMAIN_VIDEO_BACKEND_TYPE_DEFAULT, + VIR_DOMAIN_VIDEO_BACKEND_TYPE_DEFAULT = 0, VIR_DOMAIN_VIDEO_BACKEND_TYPE_QEMU, VIR_DOMAIN_VIDEO_BACKEND_TYPE_VHOSTUSER, -- 2.21.0

1 0

[libvirt] [PATCH] qemu_blockjob: Remove secdriver metadata for whole backing chain on job completion
by Michal Privoznik 25 Sep '19

25 Sep '19

Turns out, block mirror is not the only job a disk can have. It can also do commits of one layer into the other. Or possibly some other tricks too. Problem is that while we set seclabels on given layers of backing chain when the job is starting (via qemuDomainStorageSourceAccessAllow()) we don't restore them when job finishes. This leaves XATTRs set and corresponding images unusable. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Not sure if we want to remove XATTRs for the top layer too or just the rest of the backing chain (n=disk->src vs. n=disk->src->backingStore). Peter? src/qemu/qemu_blockjob.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c index a991309ee7..6408f95e4e 100644 --- a/src/qemu/qemu_blockjob.c +++ b/src/qemu/qemu_blockjob.c @@ -658,9 +658,9 @@ qemuBlockJobEventProcessLegacyCompleted(virQEMUDriverPtr driver, virObjectUnref(disk->src); disk->src = disk->mirror; } else { + virStorageSourcePtr n; + if (disk->mirror) { - virStorageSourcePtr n; - virDomainLockImageDetach(driver->lockManager, vm, disk->mirror); /* Ideally, we would restore seclabels on the backing chain here @@ -678,6 +678,16 @@ qemuBlockJobEventProcessLegacyCompleted(virQEMUDriverPtr driver, virObjectUnref(disk->mirror); } + + for (n = disk->src; virStorageSourceIsBacking(n); n = n->backingStore) { + if (qemuSecurityMoveImageMetadata(driver, vm, n, NULL) < 0) { + VIR_WARN("Unable to remove disk metadata on " + "vm %s from %s (disk target %s)", + vm->def->name, + NULLSTR(n->path), + disk->dst); + } + } } /* Recompute the cached backing chain to match our -- 2.21.0

2 2

[libvirt] [PATCH] spec: Drop unittest overrides
by Cole Robinson 25 Sep '19

25 Sep '19

nodinfotest.c doesn't exist anymore seclabeltest.c has changed substantially since this behavior was added to the spec, and in my testing doesn't have any problems running in mock Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- libvirt.spec.in | 9 --------- 1 file changed, 9 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index e2f2a40238..2e1d575663 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1313,15 +1313,6 @@ mv $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes.stp \ %endif %check -cd tests -# These tests don't current work in a mock build root -for i in nodeinfotest seclabeltest -do - rm -f $i - printf 'int main(void) { return 0; }' > $i.c - printf '#!/bin/sh\nexit 0\n' > $i - chmod +x $i -done if ! make %{?_smp_mflags} check VIR_TEST_DEBUG=1 then cat test-suite.log || true -- 2.23.0

2 1

[libvirt] [PATCH v2 00/11] remove repetition of URI path validation
by Daniel Henrique Barboza 24 Sep '19

24 Sep '19

This is a code repetition that I crossed a few times, then I noticed that Cole Robinson suggested a solution for it in the wiki. Here it is. changes from v1: - handle QEMU and vbox cases separately inside the validation function v1: https://www.redhat.com/archives/libvir-list/2019-September/msg00983.html Daniel Henrique Barboza (11): src/driver.c: add virConnectValidateURIPath() interface_backend_netcf.c: use virConnectValidateURIPath() interface_backend_udev.c: use virConnectValidateURIPath() bridge_driver.c: virConnectValidateURIPath() node_device_driver.c: use virConnectValidateURIPath() secret_driver.c: use virConnectValidateURIPath() storage_driver.c: use virConnectValidateURIPath() driver.c: change URI validation to handle QEMU and vbox case qemu_driver.c: use virConnectValidateURIPath() vbox_common.c: use virConnectValidateURIPath() vbox_driver.c: use virConnectValidateURIPath() src/driver.c | 40 +++++++++++++++++++++++++ src/driver.h | 4 +++ src/interface/interface_backend_netcf.c | 17 ++--------- src/interface/interface_backend_udev.c | 17 ++--------- src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 19 +++--------- src/node_device/node_device_driver.c | 17 ++--------- src/qemu/qemu_driver.c | 20 +++---------- src/secret/secret_driver.c | 17 ++--------- src/storage/storage_driver.c | 17 ++--------- src/vbox/vbox_common.c | 16 ++-------- src/vbox/vbox_driver.c | 16 ++-------- 12 files changed, 67 insertions(+), 134 deletions(-) -- 2.21.0

2 12

[libvirt] [PATCH v5 00/20] Hi,
by marcandre.lureau＠redhat.com 24 Sep '19

24 Sep '19

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> This series adds support for running virtio GPUs in seperate processes, thanks to vhost-user backend. The QEMU support landed for 4.1. There are several benefits of running the GPU/virgl in an external process, since Mesa is rather heavy on the qemu main loop, and may block for a while, or crash. The external GPU process is started with one end of a socket pair, the other end is given to a QEMU chardev attached to a device. The external process is also added to the cgroup to limit resources usage. vhost-user is a generic mechanism that allows implementing virtio device dataplane handling in a separate userspace process. vhost-user-gpu here notably moves the virgl 3d handling out of the main qemu process. The external process will be /usr/libexec/vhost-user-gpu, which comes from qemu.git contrib/vhost-user-gpu code, first released in qemu-4.1. Part of this series deals with discovering the location on disk of the vhost-user-gpu binary, and what capabilities it provides. This uses a similar mechanism to firmware.json, described in qemu docs/interop/vhost-user.json https://github.com/qemu/qemu/blob/master/docs/interop/vhost-user.json qemu 4.1 ships a 50-qemu-gpu.json to match. I believe virtio-fs will use a similar mechanism when it lands in upstream qemu, as virtiofsd is a separate process that communicates with qemu over vhost-user. For a bit more background on vhost-user-gpu process handling and the json interop motivation, here's some of the qemu discussion: https://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg02610.html https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg00807.html For this series, the XML to enable this is: <video model='virtio'> <driver name='vhostuser'/> <acceleration accel3d='yes' rendernode='/path/to/rendernode'/> </video> rendernode is optional qemu_vhost_user.c handles vhost-user.json qemu_vhost_user_gpu.c handles the process management for vhost-user-gpu v5: addressing v4 reviews - replaced "util: ignore EACCESS in virDirOpenIfExists" with more specific "qemu-interop: ignore non-readable directories" - use virFileSanitizePath & virBufferEscapeString on rendernode path - fix ->accel NULL crash, replace qemuSetupVideoAccelCgroup with qemuSetupVideoCgroup - fix src/vz virDomainDefAddImplicitVideo usage - few indent changes, rebased, added r-b tags v4: - rebased - simplify vhost-user-gpu pidfile checking - fix check/syntax-check v3: - rename qemu_configs -> qemu_interop_config - replace <model .. vhostuser='yes'/> with <driver name='vhostuser'/> - move vhost_user_binary to virDomainVideoDriverDef - some VIR_AUTO usage improvements - introduce qemuDomainVideoPrivate to store vhost-user fd - improved selection of -device model - use DO_TEST_CAPS_LATEST - allocate a rendernode with virHostGetDRMRenderNode() - but no clear idea how to have a test - add a patch to ignore EPERM in virDirOpenIfExists() - better domain checks/validate - added Ján r-b - no s-o-b from Cole, per request and commits taken from his git branch - rebase, indentation/style fixes, update doc, version.. v2: - rebase to master - if test file build by dropping LDADDS usage - syntax-check issues: * use #pragma once * if () bracket issues * jump label indent issues * error message %s usage * size_t for loops Marc-André Lureau (20): qemu: generalize qemuFetchConfigs qemu-interop: ignore non-readable directories conf: format/parse/rng/docs for video <driver name='qemu|vhostuser'/> domain: add rendernode attribute on <accel> qemu-cgroup: allow accel rendernode access qemu: add vhost-user-gpu capabilities checks qemu: check that qemu is vhost-user-vga capable qemu: validate virtio-gpu with vhost-user qemu: restrict 'virgl=' option to non-vhostuser video type qemu: add vhost-user helpers qemu: add qemuSecurityStartVhostUserGPU helper conf: add privateData to virDomainVideoDef qemu: add qemuDomainVideoPrivate qemu: add vhost-user-gpu helper unit tests: mock execv/execve tests: wrap vhost-user paths in qemuxml2argvtest qemu: prepare domain for vhost-user GPU qemu: start/stop the vhost-user-gpu external device qemu: build vhost-user GPU devices tests: add vhost-user-gpu xml2argv tests docs/formatdomain.html.in | 18 +- docs/schemas/domaincommon.rng | 13 + src/conf/domain_conf.c | 85 +++- src/conf/domain_conf.h | 22 +- src/qemu/Makefile.inc.am | 6 + src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 28 ++ src/qemu/qemu_command.c | 65 ++- src/qemu/qemu_domain.c | 52 ++- src/qemu/qemu_domain.h | 12 + src/qemu/qemu_extdevice.c | 74 ++- src/qemu/qemu_extdevice.h | 5 + src/qemu/qemu_firmware.c | 144 +----- src/qemu/qemu_interop_config.c | 189 ++++++++ src/qemu/qemu_interop_config.h | 25 ++ src/qemu/qemu_process.c | 61 ++- src/qemu/qemu_security.c | 40 ++ src/qemu/qemu_security.h | 6 + src/qemu/qemu_vhost_user.c | 422 ++++++++++++++++++ src/qemu/qemu_vhost_user.h | 48 ++ src/qemu/qemu_vhost_user_gpu.c | 275 ++++++++++++ src/qemu/qemu_vhost_user_gpu.h | 49 ++ src/vz/vz_sdk.c | 2 +- tests/Makefile.am | 9 + .../caps_4.1.0.x86_64.xml | 2 + .../etc/qemu/vhost-user/40-gpu.json | 1 + .../etc/qemu/vhost-user/50-gpu.json | 0 .../qemu/vhost-user/test-vhost-user-gpu | 11 + .../usr/share/qemu/vhost-user/30-gpu.json | 1 + .../usr/share/qemu/vhost-user/50-gpu.json | 8 + .../usr/share/qemu/vhost-user/60-gpu.json | 1 + tests/qemuvhostusertest.c | 132 ++++++ ...host-user-gpu-secondary.x86_64-latest.args | 43 ++ .../vhost-user-gpu-secondary.xml | 46 ++ .../vhost-user-vga.x86_64-latest.args | 40 ++ tests/qemuxml2argvdata/vhost-user-vga.xml | 42 ++ tests/qemuxml2argvdata/virtio-options.args | 5 +- tests/qemuxml2argvdata/virtio-options.xml | 4 +- tests/qemuxml2argvtest.c | 16 +- tests/virfilewrapper.c | 22 + 41 files changed, 1828 insertions(+), 206 deletions(-) create mode 100644 src/qemu/qemu_interop_config.c create mode 100644 src/qemu/qemu_interop_config.h create mode 100644 src/qemu/qemu_vhost_user.c create mode 100644 src/qemu/qemu_vhost_user.h create mode 100644 src/qemu/qemu_vhost_user_gpu.c create mode 100644 src/qemu/qemu_vhost_user_gpu.h create mode 120000 tests/qemuvhostuserdata/etc/qemu/vhost-user/40-gpu.json create mode 100644 tests/qemuvhostuserdata/etc/qemu/vhost-user/50-gpu.json create mode 100755 tests/qemuvhostuserdata/usr/libexec/qemu/vhost-user/test-vhost-user-gpu create mode 120000 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/30-gpu.json create mode 100644 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/50-gpu.json create mode 120000 tests/qemuvhostuserdata/usr/share/qemu/vhost-user/60-gpu.json create mode 100644 tests/qemuvhostusertest.c create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.xml create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.xml -- 2.23.0

4 25

[libvirt] [PATCH 00/22] qemu: Clean up typed parameter handling in bulk stats
by Peter Krempa 24 Sep '19

24 Sep '19

While investigating whether block bulk stats work properly with blockdev I got irritated by macros hiding gotos. Refactor the stats tracking by introducing few new typed parameter handlers. Peter Krempa (22): util: typedparam: Split out public APIs into a separate file util: typedparam: Purge public bits from virTypedParamsGetStringList util: typedparam: Move and unexport virTypedParameterAssignFromStr util: typedparam: Remove pointless cleanup label from virTypedParameterAssignFromStr docs: apibuild: Purge irrelevant typed parameter APIs from ignore util: typedparam: Separate code to assign value to typed parameter util: typedparam: Optionally copy strings passed to virTypedParameterAssignValue util: typedparam: Simplify handling of lists of typed parameters qemu: Remove stale comment for qemuDomainBlockStats qemu: monitor: Refactor cleanup in qemuMonitorJSONBlockStatsCollectData qemu: monitor: Refactor cleanup in qemuMonitorJSONGetOneBlockStatsInfo qemu: monitor: Refactor cleanup in qemuMonitorJSONGetAllBlockStatsInfo qemu: monitor: Change fields in qemuBlockStats to 'unsigned' qemu: driver: Remove pointless macro QEMU_BLOCK_STAT_TOTAL qemu: driver: Don't return anything from qemuDomainBlockStatsGatherTotals qemu: driver: Remove QEMU_ADD_BLOCK_PARAM_LL macro qemu: Use virTypedParamList in the bulk stats gathering functions qemu: driver: Stop using QEMU_ADD_BLOCK_PARAM_ULL in qemuDomainGetStatsOneBlockFallback qemu: driver: Stop using QEMU_ADD_BLOCK_PARAM_ULL in qemuDomainGetStatsOneBlock qemu: driver: Stop using QEMU_ADD_BLOCK_PARAM_ULL in qemuDomainGetStatsBlockExportBackendStorage qemu: driver: Stop using QEMU_ADD_BLOCK_PARAM_ULL in qemuDomainGetStatsBlockExportFrontend qemu: driver: Remove unused cleanup labels in stats gathering functions docs/Makefile.am | 2 +- docs/apibuild.py | 7 +- src/libvirt_private.syms | 10 +- src/qemu/qemu_driver.c | 635 ++++++----------- src/qemu/qemu_monitor.h | 16 +- src/qemu/qemu_monitor_json.c | 57 +- src/util/Makefile.inc.am | 1 + src/util/virtypedparam-public.c | 886 ++++++++++++++++++++++++ src/util/virtypedparam.c | 1129 +++++++------------------------ src/util/virtypedparam.h | 67 +- 10 files changed, 1440 insertions(+), 1370 deletions(-) create mode 100644 src/util/virtypedparam-public.c -- 2.21.0

2 44

[libvirt] [libvirt-tck PATCH] conf: Drop UML from the suite
by Erik Skultety 24 Sep '19

24 Sep '19

Libvirt dropped UML in v5.0.0 so there's no reason for us not to follow along. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- conf/default.cfg | 26 -------------------------- lib/Sys/Virt/TCK.pm | 2 -- 2 files changed, 28 deletions(-) diff --git a/conf/default.cfg b/conf/default.cfg index d9fd0cb..39d9b04 100644 --- a/conf/default.cfg +++ b/conf/default.cfg @@ -95,32 +95,6 @@ kernels = ( kernel = http://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/… initrd = http://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/… } - # User mode linux i686 needs custom kernel + root filesystem - { - arch = i686 - ostype = uml - kernel = { - source = http://user-mode-linux.sourceforge.net/linux-2.6.24-rc7.bz2 - uncompress = bzip2 - } - disk = { - source = http://fs.devloop.org.uk/filesystems/Fedora13/Fedora13-x86-root_fs.bz2 - uncompress = bzip2 - } - } - # User mode linux x86_64 needs custom kernel + root filesystem - { - arch = x86_64 - ostype = uml - kernel = { - source = http://user-mode-linux.sourceforge.net/linux-2.6.24-x86_64.bz2 - uncompress = bzip2 - } - disk = { - source = http://fs.devloop.org.uk/filesystems/Fedora13/Fedora13-AMD64-root_fs.bz2 - uncompress = bzip2 - } - } # LXC containers need a virtual container filesystem somewhere # { # arch = x86_64 diff --git a/lib/Sys/Virt/TCK.pm b/lib/Sys/Virt/TCK.pm index 3ea06cc..a641d01 100644 --- a/lib/Sys/Virt/TCK.pm +++ b/lib/Sys/Virt/TCK.pm @@ -681,8 +681,6 @@ sub get_disk_dev { my $dev; if ($ostype eq "xen") { $dev = "xvda"; - } elsif ($ostype eq "uml") { - $dev = "ubda"; } elsif ($ostype eq "hvm") { if ($domain eq "kvm" || $domain eq "qemu" || -- 2.20.1

2 1

[libvirt] [libvirt-tck PATCH] domain: Relax the checks matching disk sizes
by Erik Skultety 24 Sep '19

24 Sep '19

There may be some preallocation going on depending on what host filesystem is in place which may mess up the numbers we expect mainly in allocation, so let's stick with exact matching of the capacity and relaxing the checks on allocation and physical size as commit 30beeb2e did. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- scripts/domain/121-block-info.t | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/domain/121-block-info.t b/scripts/domain/121-block-info.t index bfff48c..d9d644e 100644 --- a/scripts/domain/121-block-info.t +++ b/scripts/domain/121-block-info.t @@ -98,8 +98,8 @@ ok_domain(sub { $dom = $conn->create_domain($xml) }, "Create domain"); $xml = $dom->get_xml_description(); is($dom->get_block_info($dst2,0)->{capacity}, 1024*1024*50, "Get disk capacity info"); -is($dom->get_block_info($dst2,0)->{allocation}, 1024*1024, "Get disk allocation info"); -is($dom->get_block_info($dst2,0)->{physical}, 1024*1024*50, "Get disk physical info"); +ok($dom->get_block_info($dst2,0)->{allocation} >= 1024*1024, "Get disk allocation info"); +ok($dom->get_block_info($dst2,0)->{physical} >= 1024*1024*50, "Get disk physical info"); is($dom->get_block_info($dst,0)->{capacity}, 1024*1024*50, "Get disk capacity info"); -- 2.20.1

2 1

[libvirt] [libvirt-tck PATCH] conf: Upgrade the used version of fedora to 30
by Erik Skultety 24 Sep '19

24 Sep '19

Fedora 28 is already EOL and the URLs don't work anymore either because EOL resources eventually move to http://archives.fedoraproject.org/pub/archive/fedora/ from https://dl.fedoraproject.org/pub/fedora/linux/releases/. --- Notes: I'm wondering whether we shouldn't drop the secondary i686 sections as well since i686 will die starting with fedora 31. On a similar note with UML, upstream libvirt dropped it a while ago. conf/default.cfg | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/conf/default.cfg b/conf/default.cfg index b97688e..d9fd0cb 100644 --- a/conf/default.cfg +++ b/conf/default.cfg @@ -49,7 +49,7 @@ images = ( hvm xen ) - osname = fedora-28 + osname = fedora-30 } ) @@ -75,25 +75,25 @@ images = ( # empty sparse root FS will be created # kernels = ( - # Fedora 28 i686 PAE has pv_ops, so one kernel can do both Xen and KVM guests here + # Fedora 30 i686 PAE has pv_ops, so one kernel can do both Xen and KVM guests here { arch = i686 ostype = ( hvm xen ) - kernel = http://dl.fedoraproject.org/pub/fedora-secondary/releases/28/Everything/i38… - initrd = http://dl.fedoraproject.org/pub/fedora-secondary/releases/28/Everything/i38… + kernel = http://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Everything/i38… + initrd = http://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Everything/i38… } - # Fedora 28 x86_64 has pv_ops, so one kernel can do both Xen and KVM guests here + # Fedora 30 x86_64 has pv_ops, so one kernel can do both Xen and KVM guests here { arch = x86_64 ostype = ( hvm xen ) - kernel = http://dl.fedoraproject.org/pub/fedora/linux/releases/28/Everything/x86_64/… - initrd = http://dl.fedoraproject.org/pub/fedora/linux/releases/28/Everything/x86_64/… + kernel = http://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/… + initrd = http://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/… } # User mode linux i686 needs custom kernel + root filesystem { -- 2.20.1

3 3

[libvirt] [libvirt-tck PATCH] TCK.pm: Define libvirt VMs with an RNG device
by Erik Skultety 24 Sep '19

24 Sep '19

The nwfilter 220-no-ip-spoofing.t test relies on an SSH connection to the test VM. However, because the domain definition passed to libvirt lacks an RNG device, the SSH server isn't started inside the guest (even though that is the default on virt-builder images) and therefore: "ssh: connect to host 192.168.122.227 port 22: Connection refused" is returned which in turn makes a bunch of sub tests fail because the very basic premise - a working SSH connection - is false. This patch makes sure a virtio RNG is contained in the XML definition, thus causing the SSH server to be started successfully, thus allowing all the subtests to pass. --- lib/Sys/Virt/TCK.pm | 4 ++++ lib/Sys/Virt/TCK/DomainBuilder.pm | 21 +++++++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/lib/Sys/Virt/TCK.pm b/lib/Sys/Virt/TCK.pm index 389d5cc..3ea06cc 100644 --- a/lib/Sys/Virt/TCK.pm +++ b/lib/Sys/Virt/TCK.pm @@ -807,6 +807,8 @@ sub generic_machine_domain { $b->disk(src => $config{root}, dst => $config{dev}, type => "file"); + $b->rng(backend_model => "random", + backend => "/dev/urandom"); if ($config{firstboot}) { print "# Running the first boot\n"; @@ -865,6 +867,8 @@ sub generic_machine_domain { dst => $config{dev}, type => "file", shareable => $shareddisk); + $b->rng(backend_model => "random", + backend => "/dev/urandom"); return $b; } } diff --git a/lib/Sys/Virt/TCK/DomainBuilder.pm b/lib/Sys/Virt/TCK/DomainBuilder.pm index 45336b5..be8708f 100644 --- a/lib/Sys/Virt/TCK/DomainBuilder.pm +++ b/lib/Sys/Virt/TCK/DomainBuilder.pm @@ -49,6 +49,7 @@ sub new { graphics => [], hostdevs => [], seclabel => {}, + rng => {}, }; bless $self, $class; @@ -328,6 +329,19 @@ sub seclabel { return $self; } +sub rng { + my $self = shift; + my %params = @_; + + die "backend model parameter is required" unless $params{backend_model}; + die "backend parameter is required" unless $params{backend}; + + $self->{rng} = \%params; + $self->{rng}->{model} = "virtio" unless defined $self->{rng}->{model}; + + return $self; +} + sub as_xml { my $self = shift; @@ -504,6 +518,13 @@ sub as_xml { $w->endTag("graphics"); } $w->emptyTag("console", type => "pty"); + + $w->startTag("rng", + model => $self->{rng}->{model}); + $w->dataElement("backend", $self->{rng}->{backend}, + model => $self->{rng}->{backend_model}); + $w->endTag("rng"); + $w->endTag("devices"); if ($self->{seclabel}->{model}) { $w->startTag("seclabel", -- 2.20.1

3 8

[libvirt] [PATCH 0/4] Sanitize restrictions imposed by VIR_DOMAIN_START_AUTODESTROY
by Peter Krempa 24 Sep '19

24 Sep '19

Migration to a different host is the only reasonable restriction that should apply. Fix the wording in the docs and remove the restrictions of saving the VM, taking a snapshot and taking a checkpoint. Peter Krempa (4): lib: Lessen restrictions on VIR_DOMAIN_START_AUTODESTROY qemu: migration: Forbid only remote migration if autodestroy is active for VM qemu: snapshot: Don't forbid snapshot if autodestroy is registered qemu: checkpoint: Don't forbid checkpoint when VM is marked for autodestroy src/libvirt-domain.c | 9 ++++++--- src/qemu/qemu_driver.c | 12 ------------ src/qemu/qemu_migration.c | 3 ++- 3 files changed, 8 insertions(+), 16 deletions(-) -- 2.21.0

2 8

[libvirt] [jenkins-ci PATCH 0/4] Switch libosinfo builds to Meson
by Fabiano Fidêncio 24 Sep '19

24 Sep '19

Subject says it all, basically. It's important to note that we will add the whole machinery to install meson via pip and build the projects in platforms where the minimum required version of meson is not present, I really would like to go ahead with this patch as soon as I can have the libosinfo MR acked. Fabiano Fidêncio (4): libosinfo: Add meson dependency Only build libosinfo on systems with meson >= 0.49.0 Update libosinfo's archive_format Switch libosinfo builds to Meson guests/host_vars/libvirt-centos-7/main.yml | 1 - guests/host_vars/libvirt-debian-9/main.yml | 1 - guests/host_vars/libvirt-ubuntu-16/main.yml | 1 - guests/host_vars/libvirt-ubuntu-18/main.yml | 1 - .../build/projects/libosinfo+mingw32.yml | 6 ++--- .../build/projects/libosinfo+mingw64.yml | 6 ++--- guests/playbooks/build/projects/libosinfo.yml | 26 ++++++++++++++----- guests/vars/projects/libosinfo+mingw32.yml | 1 + guests/vars/projects/libosinfo+mingw64.yml | 1 + guests/vars/projects/libosinfo.yml | 1 + jenkins/projects/libosinfo+mingw32.yaml | 6 ++--- jenkins/projects/libosinfo+mingw64.yaml | 6 ++--- jenkins/projects/libosinfo.yaml | 26 +++++++++++++------ 13 files changed, 52 insertions(+), 31 deletions(-) -- 2.23.0

2 6

[libvirt] [PATCH 00/10] remove repetition of URI path validation
by Daniel Henrique Barboza 23 Sep '19

23 Sep '19

This is a code repetition that I crossed a few times, then I noticed that Cole Robinson suggested a solution for it in the wiki. Here it is. Daniel Henrique Barboza (10): src/driver.c: add virConnectValidateURIPath() interface_backend_netcf.c: use virConnectValidateURIPath() interface_backend_udev.c: use virConnectValidateURIPath() bridge_driver.c: virConnectValidateURIPath() node_device_driver.c: use virConnectValidateURIPath() secret_driver.c: use virConnectValidateURIPath() storage_driver.c: use virConnectValidateURIPath() qemu_driver.c: use virConnectValidateURIPath() vbox_common.c: use virConnectValidateURIPath() vbox_driver.c: use virConnectValidateURIPath() src/driver.c | 25 +++++++++++++++++++++++++ src/driver.h | 4 ++++ src/interface/interface_backend_netcf.c | 17 ++--------------- src/interface/interface_backend_udev.c | 17 ++--------------- src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 19 ++++--------------- src/node_device/node_device_driver.c | 17 ++--------------- src/qemu/qemu_driver.c | 20 ++++---------------- src/secret/secret_driver.c | 17 ++--------------- src/storage/storage_driver.c | 17 ++--------------- src/vbox/vbox_common.c | 16 ++-------------- src/vbox/vbox_driver.c | 16 ++-------------- 12 files changed, 52 insertions(+), 134 deletions(-) -- 2.21.0

2 12

[libvirt] [PATCH] build: ensure Makefile.inc.am is checked for long lines
by Daniel P. Berrangé 23 Sep '19

23 Sep '19

The filename match rule was accidentally excluding the Makefile.inc.am files from the long lines check. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- cfg.mk | 2 +- src/interface/Makefile.inc.am | 6 ++++-- src/libxl/Makefile.inc.am | 5 ++++- src/network/Makefile.inc.am | 6 ++++-- src/node_device/Makefile.inc.am | 6 ++++-- src/nwfilter/Makefile.inc.am | 6 ++++-- src/secret/Makefile.inc.am | 6 ++++-- src/storage/Makefile.inc.am | 27 ++++++++++++++++++--------- 8 files changed, 43 insertions(+), 21 deletions(-) diff --git a/cfg.mk b/cfg.mk index a7c883830f..3731a2830b 100644 --- a/cfg.mk +++ b/cfg.mk @@ -737,7 +737,7 @@ sc_prohibit_long_lines: halt='Wrap long lines in expected output files' \ $(_sc_search_regexp) @prohibit='.{80}' \ - in_vc_files='Makefile\.am' \ + in_vc_files='Makefile(\.inc)?\.am' \ halt='Wrap long lines in Makefiles' \ $(_sc_search_regexp) diff --git a/src/interface/Makefile.inc.am b/src/interface/Makefile.inc.am index a88df0bd11..baa85b4ba9 100644 --- a/src/interface/Makefile.inc.am +++ b/src/interface/Makefile.inc.am @@ -75,10 +75,12 @@ VIRTINTERFACED_UNIT_VARS = \ -e 's|[@]sockprefix[@]|virtinterfaced|g' \ $(NULL) -virtinterfaced.service: interface/virtinterfaced.service.in $(top_builddir)/config.status +virtinterfaced.service: interface/virtinterfaced.service.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTINTERFACED_UNIT_VARS) $< > $@-t && mv $@-t $@ -virtinterface%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status +virtinterface%.socket: remote/libvirt%.socket.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTINTERFACED_UNIT_VARS) $< > $@-t && mv $@-t $@ interface/virtinterfaced.conf: remote/libvirtd.conf.in diff --git a/src/libxl/Makefile.inc.am b/src/libxl/Makefile.inc.am index a2151162e6..18a06a47d1 100644 --- a/src/libxl/Makefile.inc.am +++ b/src/libxl/Makefile.inc.am @@ -80,9 +80,12 @@ SYSTEMD_UNIT_FILES_IN += \ libxl/virtxend.service.in \ $(NULL) +LIBXL_UNIT_COND="ConditionPathExists=/proc/xen/capabilities" +LIBXL_UNIT_CONFLICT="Conflicts=$(LIBVIRTD_SOCKET_UNIT_FILES)" + VIRTXEND_UNIT_VARS = \ $(COMMON_UNIT_VARS) \ - -e 's|[@]deps[@]|Conflicts=$(LIBVIRTD_SOCKET_UNIT_FILES)\nConditionPathExists=/proc/xen/capabilities|g' \ + -e 's|[@]deps[@]|$(LIBXL_UNIT_CONFLICT)\n$(LIBXL_UNIT_COND)|g' \ -e 's|[@]name[@]|Libvirt libxl|g' \ -e 's|[@]service[@]|virtxend|g' \ -e 's|[@]sockprefix[@]|virtxend|g' \ diff --git a/src/network/Makefile.inc.am b/src/network/Makefile.inc.am index 9f20dad7b3..17467a65ad 100644 --- a/src/network/Makefile.inc.am +++ b/src/network/Makefile.inc.am @@ -82,10 +82,12 @@ VIRTNETWORKD_UNIT_VARS = \ -e 's|[@]sockprefix[@]|virtnetworkd|g' \ $(NULL) -virtnetworkd.service: network/virtnetworkd.service.in $(top_builddir)/config.status +virtnetworkd.service: network/virtnetworkd.service.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTNETWORKD_UNIT_VARS) $< > $@-t && mv $@-t $@ -virtnetwork%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status +virtnetwork%.socket: remote/libvirt%.socket.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTNETWORKD_UNIT_VARS) $< > $@-t && mv $@-t $@ network/virtnetworkd.conf: remote/libvirtd.conf.in diff --git a/src/node_device/Makefile.inc.am b/src/node_device/Makefile.inc.am index 5a6525d843..eac7f92e88 100644 --- a/src/node_device/Makefile.inc.am +++ b/src/node_device/Makefile.inc.am @@ -98,10 +98,12 @@ VIRTNODEDEVD_UNIT_VARS = \ -e 's|[@]sockprefix[@]|virtnodedevd|g' \ $(NULL) -virtnodedevd.service: node_device/virtnodedevd.service.in $(top_builddir)/config.status +virtnodedevd.service: node_device/virtnodedevd.service.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTNODEDEVD_UNIT_VARS) $< > $@-t && mv $@-t $@ -virtnodedev%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status +virtnodedev%.socket: remote/libvirt%.socket.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTNODEDEVD_UNIT_VARS) $< > $@-t && mv $@-t $@ node_device/virtnodedevd.conf: remote/libvirtd.conf.in diff --git a/src/nwfilter/Makefile.inc.am b/src/nwfilter/Makefile.inc.am index 7693634e29..6acb45705c 100644 --- a/src/nwfilter/Makefile.inc.am +++ b/src/nwfilter/Makefile.inc.am @@ -83,10 +83,12 @@ VIRTNWFILTERD_UNIT_VARS = \ -e 's|[@]sockprefix[@]|virtnwfilterd|g' \ $(NULL) -virtnwfilterd.service: nwfilter/virtnwfilterd.service.in $(top_builddir)/config.status +virtnwfilterd.service: nwfilter/virtnwfilterd.service.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTNWFILTERD_UNIT_VARS) $< > $@-t && mv $@-t $@ -virtnwfilter%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status +virtnwfilter%.socket: remote/libvirt%.socket.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTNWFILTERD_UNIT_VARS) $< > $@-t && mv $@-t $@ nwfilter/virtnwfilterd.conf: remote/libvirtd.conf.in diff --git a/src/secret/Makefile.inc.am b/src/secret/Makefile.inc.am index 37f816406e..76bc67418c 100644 --- a/src/secret/Makefile.inc.am +++ b/src/secret/Makefile.inc.am @@ -71,10 +71,12 @@ VIRTSECRETD_UNIT_VARS = \ -e 's|[@]sockprefix[@]|virtsecretd|g' \ $(NULL) -virtsecretd.service: secret/virtsecretd.service.in $(top_builddir)/config.status +virtsecretd.service: secret/virtsecretd.service.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTSECRETD_UNIT_VARS) $< > $@-t && mv $@-t $@ -virtsecret%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status +virtsecret%.socket: remote/libvirt%.socket.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTSECRETD_UNIT_VARS) $< > $@-t && mv $@-t $@ secret/virtsecretd.conf: remote/libvirtd.conf.in diff --git a/src/storage/Makefile.inc.am b/src/storage/Makefile.inc.am index fd0d57d2b6..4dccb14ac1 100644 --- a/src/storage/Makefile.inc.am +++ b/src/storage/Makefile.inc.am @@ -175,10 +175,12 @@ VIRTSTORAGED_UNIT_VARS = \ -e 's|[@]sockprefix[@]|virtstoraged|g' \ $(NULL) -virtstoraged.service: storage/virtstoraged.service.in $(top_builddir)/config.status +virtstoraged.service: storage/virtstoraged.service.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTSTORAGED_UNIT_VARS) $< > $@-t && mv $@-t $@ -virtstorage%.socket: remote/libvirt%.socket.in $(top_builddir)/config.status +virtstorage%.socket: remote/libvirt%.socket.in \ + $(top_builddir)/config.status $(AM_V_GEN)$(SED) $(VIRTSTORAGED_UNIT_VARS) $< > $@-t && mv $@-t $@ storage/virtstoraged.conf: remote/libvirtd.conf.in @@ -264,7 +266,8 @@ libvirt_storage_backend_iscsi_la_LIBADD = \ endif WITH_STORAGE_ISCSI if WITH_STORAGE_ISCSI_DIRECT -libvirt_storage_backend_iscsi_direct_la_SOURCES = $(STORAGE_DRIVER_ISCSI_DIRECT_SOURCES) +libvirt_storage_backend_iscsi_direct_la_SOURCES = \ + $(STORAGE_DRIVER_ISCSI_DIRECT_SOURCES) libvirt_storage_backend_iscsi_direct_la_CFLAGS = \ -I$(srcdir)/conf \ -I$(srcdir)/secret \ @@ -346,13 +349,15 @@ libvirt_storage_backend_rbd_la_LDFLAGS = $(AM_LDFLAGS_MOD) endif WITH_STORAGE_RBD if WITH_STORAGE_SHEEPDOG -libvirt_storage_backend_sheepdog_la_SOURCES = $(STORAGE_DRIVER_SHEEPDOG_SOURCES) +libvirt_storage_backend_sheepdog_la_SOURCES = \ + $(STORAGE_DRIVER_SHEEPDOG_SOURCES) libvirt_storage_backend_sheepdog_la_CFLAGS = \ -I$(srcdir)/conf \ $(AM_CFLAGS) \ $(NULL) -libvirt_storage_backend_sheepdog_priv_la_SOURCES = $(STORAGE_DRIVER_SHEEPDOG_SOURCES) +libvirt_storage_backend_sheepdog_priv_la_SOURCES = \ + $(STORAGE_DRIVER_SHEEPDOG_SOURCES) libvirt_storage_backend_sheepdog_priv_la_CFLAGS = \ -I$(srcdir)/conf \ $(AM_CFLAGS) \ @@ -368,7 +373,8 @@ libvirt_storage_backend_sheepdog_la_LIBADD = \ endif WITH_STORAGE_SHEEPDOG if WITH_STORAGE_GLUSTER -libvirt_storage_backend_gluster_la_SOURCES = $(STORAGE_DRIVER_GLUSTER_SOURCES) +libvirt_storage_backend_gluster_la_SOURCES = \ + $(STORAGE_DRIVER_GLUSTER_SOURCES) libvirt_storage_backend_gluster_la_LIBADD = \ libvirt.la \ $(GLUSTERFS_LIBS) \ @@ -384,7 +390,8 @@ storagebackend_LTLIBRARIES += libvirt_storage_backend_gluster.la libvirt_storage_backend_gluster_la_LDFLAGS = $(AM_LDFLAGS_MOD) -libvirt_storage_file_gluster_la_SOURCES = $(STORAGE_FILE_GLUSTER_SOURCES) +libvirt_storage_file_gluster_la_SOURCES = \ + $(STORAGE_FILE_GLUSTER_SOURCES) libvirt_storage_file_gluster_la_LIBADD = \ libvirt.la \ $(GLUSTERFS_LIBS) \ @@ -401,7 +408,8 @@ libvirt_storage_file_gluster_la_LDFLAGS = $(AM_LDFLAGS_MOD) endif WITH_STORAGE_GLUSTER if WITH_STORAGE_ZFS -libvirt_storage_backend_zfs_la_SOURCES = $(STORAGE_DRIVER_ZFS_SOURCES) +libvirt_storage_backend_zfs_la_SOURCES = \ + $(STORAGE_DRIVER_ZFS_SOURCES) libvirt_storage_backend_zfs_la_CFLAGS = \ -I$(srcdir)/conf \ $(AM_CFLAGS) \ @@ -416,7 +424,8 @@ libvirt_storage_backend_zfs_la_LIBADD = \ endif WITH_STORAGE_ZFS if WITH_STORAGE_VSTORAGE -libvirt_storage_backend_vstorage_la_SOURCES = $(STORAGE_DRIVER_VSTORAGE_SOURCES) +libvirt_storage_backend_vstorage_la_SOURCES = \ + $(STORAGE_DRIVER_VSTORAGE_SOURCES) libvirt_storage_backend_vstorage_la_CFLAGS = \ -I$(srcdir)/conf \ $(AM_CFLAGS) \ -- 2.21.0

2 1

[libvirt] [jenkins-ci PATCH] Switch libvirt-dbus builds to Meson
by Fabiano Fidêncio 23 Sep '19

23 Sep '19

libvirt-dbus has switched its build system to meson and requires 0.49.0 or newer. It means, let's *not* build libvirt-dbus on: - Debian 9 (or older); - Ubuntu 18 (or older); - CentOS 7 Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> --- .../playbooks/build/projects/libvirt-dbus.yml | 37 +++---------------- guests/vars/projects/libvirt-dbus.yml | 1 + jenkins/projects/libvirt-dbus.yaml | 30 +++------------ 3 files changed, 12 insertions(+), 56 deletions(-) diff --git a/guests/playbooks/build/projects/libvirt-dbus.yml b/guests/playbooks/build/projects/libvirt-dbus.yml index a6ff025..a031ba7 100644 --- a/guests/playbooks/build/projects/libvirt-dbus.yml +++ b/guests/playbooks/build/projects/libvirt-dbus.yml @@ -1,9 +1,9 @@ --- - set_fact: name: libvirt-dbus + # libvirt-dbus depends on meson 0.49.0 which is not available on + # CentOS 7, Debian 9, Ubuntu 18; machines: - - libvirt-centos-7 - - libvirt-debian-9 - libvirt-debian-10 - libvirt-debian-sid - libvirt-fedora-29 @@ -12,42 +12,15 @@ - libvirt-freebsd-11 - libvirt-freebsd-12 - libvirt-freebsd-current - - libvirt-ubuntu-16 - - libvirt-ubuntu-18 archive_format: xz git_url: '{{ git_urls["libvirt-dbus"][git_remote] }}' - include: '{{ playbook_base }}/jobs/prepare.yml' -- include: '{{ playbook_base }}/jobs/autotools-build-job.yml' -- include: '{{ playbook_base }}/jobs/autotools-syntax-check-job.yml' +- include: '{{ playbook_base }}/jobs/meson-build-job.yml' +- include: '{{ playbook_base }}/jobs/meson-check-job.yml' +- include: '{{ playbook_base }}/jobs/meson-rpm-job.yml' vars: - # CentOS 7 doesn't include Python 3, while the versions of flake8 - # and pyflakes currently available on FreeBSD (3.5.0 and 2.0.0 - # respectively) are not compatible machines: - - libvirt-debian-9 - - libvirt-debian-10 - - libvirt-debian-sid - libvirt-fedora-29 - libvirt-fedora-30 - libvirt-fedora-rawhide - - libvirt-ubuntu-16 - - libvirt-ubuntu-18 -- include: '{{ playbook_base }}/jobs/autotools-check-job.yml' - vars: - # CentOS 7 doesn't include Python 3 and the version in Ubuntu - # 16.04 is too old - machines: - - libvirt-debian-9 - - libvirt-debian-10 - - libvirt-debian-sid - - libvirt-fedora-29 - - libvirt-fedora-30 - - libvirt-fedora-rawhide - - libvirt-freebsd-11 - - libvirt-freebsd-12 - - libvirt-freebsd-current - - libvirt-ubuntu-18 -- include: '{{ playbook_base }}/jobs/autotools-rpm-job.yml' - vars: - machines: '{{ rpm_machines }}' diff --git a/guests/vars/projects/libvirt-dbus.yml b/guests/vars/projects/libvirt-dbus.yml index ce902cb..406ad86 100644 --- a/guests/vars/projects/libvirt-dbus.yml +++ b/guests/vars/projects/libvirt-dbus.yml @@ -3,6 +3,7 @@ packages: - dbus-daemon - flake8 - glib2 + - meson - python3 - python3-dbus - python3-gi diff --git a/jenkins/projects/libvirt-dbus.yaml b/jenkins/projects/libvirt-dbus.yaml index 2b72fb4..82eb892 100644 --- a/jenkins/projects/libvirt-dbus.yaml +++ b/jenkins/projects/libvirt-dbus.yaml @@ -1,9 +1,9 @@ --- - project: name: libvirt-dbus + # libvirt-dbus requires meson 0.49.0, which is not available on + # CentOS 7 and Debian 9; machines: - - libvirt-centos-7 - - libvirt-debian-9 - libvirt-debian-10 - libvirt-fedora-29 - libvirt-fedora-30 @@ -14,31 +14,13 @@ archive_format: xz git_url: '{git_urls[libvirt-dbus][default]}' jobs: - - autotools-build-job: + - meson-build-job: parent_jobs: 'libvirt-glib-build' - - autotools-syntax-check-job: + - meson-check-job: parent_jobs: 'libvirt-dbus-build' - # CentOS 7 doesn't include Python 3, while the versions of flake8 - # and pyflakes currently available on FreeBSD (3.5.0 and 2.0.0 - # respectively) are not compatible - machines: - - libvirt-debian-9 - - libvirt-debian-10 - - libvirt-fedora-29 - - libvirt-fedora-30 - - libvirt-fedora-rawhide - - autotools-check-job: - parent_jobs: 'libvirt-dbus-syntax-check' - # CentOS 7 doesn't include Python 3 and the version in Ubuntu - # 16.04 is too old + - meson-rpm-job: + parent_jobs: 'libvirt-dbus-check' machines: - - libvirt-debian-9 - - libvirt-debian-10 - libvirt-fedora-29 - libvirt-fedora-30 - libvirt-fedora-rawhide - - libvirt-freebsd-11 - - libvirt-freebsd-12 - - autotools-rpm-job: - parent_jobs: 'libvirt-dbus-check' - machines: '{rpm_machines}' -- 2.23.0

4 9

[libvirt] [PATCH] qemu: snapshot: Do ACL check prior to checkpoint interlocking
by Peter Krempa 23 Sep '19

23 Sep '19

Commit 7efe930ec3c introduced interlock of snapshots and checkpoints, but the check is executed prior to the snapshot API ACL check. This means that an unauthorized user can see whether a VM exists if it has a checkpoint. Move the checks to proper places. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Given that currently checkpoints by themselves are not very useful I doubt that there are users which could hit this. Thus I'm sending it also directly to the public mailing list for faster turnaround. src/qemu/qemu_driver.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 0753904472..f7f059b6d6 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15902,18 +15902,18 @@ qemuDomainSnapshotCreateXML(virDomainPtr domain, if (!(vm = qemuDomObjFromDomain(domain))) goto cleanup; - if (virDomainListCheckpoints(vm->checkpoints, NULL, domain, NULL, 0) > 0) { - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("cannot create snapshot while checkpoint exists")); - goto cleanup; - } - priv = vm->privateData; cfg = virQEMUDriverGetConfig(driver); if (virDomainSnapshotCreateXMLEnsureACL(domain->conn, vm->def, flags) < 0) goto cleanup; + if (virDomainListCheckpoints(vm->checkpoints, NULL, domain, NULL, 0) > 0) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("cannot create snapshot while checkpoint exists")); + goto cleanup; + } + if (!(caps = virQEMUDriverGetCapabilities(driver, false))) goto cleanup; -- 2.21.0

2 1

[libvirt] [PATCH] rpm: stop compressing the ChangeLog file
by Daniel P. Berrangé 23 Sep '19

23 Sep '19

We stopped generating a giant ChangeLog file in commit ce97c33a795dec053f1e85c65ecd924b8c6ec4ba Author: Andrea Bolognani <abologna(a)redhat.com> Date: Mon Apr 1 17:33:03 2019 +0200 maint: Stop generating ChangeLog from git so there is no reason to compress it anymore. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- libvirt.spec.in | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index e2f2a40238..c7448ed6a6 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1225,7 +1225,6 @@ rm -f po/stamp-po --with-init-script=systemd \ %{?arg_login_shell} make %{?_smp_mflags} V=1 -gzip -9 ChangeLog %install rm -fr %{buildroot} @@ -1532,7 +1531,7 @@ exit 0 %files %files docs -%doc AUTHORS ChangeLog.gz NEWS README README.md +%doc AUTHORS ChangeLog NEWS README README.md %doc libvirt-docs/* %files daemon -- 2.21.0

2 1

[libvirt] libvirt-lxc broken by new systemd 243
by Christian Ehrhardt 23 Sep '19

23 Sep '19

Hi, with the new systemd 243 libvirt-lxc seems broken. We had the particular symptom already in the past, the TL;DR is: 1. start a lxc guest 2. restart libvirtd 3. guest is gone This particular change is due to [1] fixed by [2] which as a side effect will wipe libvirt-lxc containers on daemon restart. After checking on IRC it seems this wasn't reported to libvirt yet, but for now it is more a start of a discussion than a bug report. I have reported this upstream at [1] and we could keep the "discussion with systemd" there. If you can/want please chime in there. If it turns out we want/need a fix in libvirt we can focus on the thread here then. [1]: https://github.com/systemd/systemd/issues/12386 [2]: https://github.com/systemd/systemd/commit/0219b3524f414e23589e63c6de6a75981… [3]: https://github.com/systemd/systemd/issues/13629 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

1 0