[libvirt] [RFC 3/3] lxc: Mount NBD devices before clone

[Radostin Stoyanov]

When user-namespace is enabled we are not allowed
to mount block/NBD devices.

Instead, mount /dev/nbdX to /run/libvirt/lxc/.root
and set:

fs->src->path = /run/libvirt/lxc/.root
fs->type = VIR_DOMAIN_FS_TYPE_MOUNT
---
 src/lxc/lxc_container.c  | 53 
 src/lxc/lxc_controller.c | 49 +---
 2 files changed, 33 insertions(+), 69 deletions(-)

diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 3b8cb966e..420bb20ab 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -658,55 +658,6 @@ static int lxcContainerResolveSymlinks(virDomainFSDefPtr 
fs, bool gentle)
 return 0;
 }
 
-static int lxcContainerPrepareRoot(virDomainDefPtr def,
-   virDomainFSDefPtr root,
-   const char *sec_mount_options)
-{
-char *dst;
-char *tmp;
-
-VIR_DEBUG("Prepare root %d", root->type);
-
-if (root->type == VIR_DOMAIN_FS_TYPE_MOUNT)
-return 0;
-
-if (root->type == VIR_DOMAIN_FS_TYPE_FILE) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("Unexpected root filesystem without loop device"));
-return -1;
-}
-
-if (root->type != VIR_DOMAIN_FS_TYPE_BLOCK) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
-   _("Unsupported root filesystem type %s"),
-   virDomainFSTypeToString(root->type));
-return -1;
-}
-
-if (lxcContainerResolveSymlinks(root, false) < 0)
-return -1;
-
-if (virAsprintf(, "%s/%s.root",
-LXC_STATE_DIR, def->name) < 0)
-return -1;
-
-tmp = root->dst;
-root->dst = dst;
-
-if (lxcContainerMountFSBlock(root, "", sec_mount_options) < 0) {
-root->dst = tmp;
-VIR_FREE(dst);
-return -1;
-}
-
-root->dst = tmp;
-root->type = VIR_DOMAIN_FS_TYPE_MOUNT;
-VIR_FREE(root->src->path);
-root->src->path = dst;
-
-return 0;
-}
-
 static int lxcContainerPivotRoot(virDomainFSDefPtr root)
 {
 int ret;
@@ -1755,10 +1706,6 @@ static int lxcContainerSetupPivotRoot(virDomainDefPtr 
vmDef,
 if (virFileResolveAllLinks(LXC_STATE_DIR, ) < 0)
 goto cleanup;
 
-/* Ensure the root filesystem is mounted */
-if (lxcContainerPrepareRoot(vmDef, root, sec_mount_options) < 0)
-goto cleanup;
-
 /* Gives us a private root, leaving all parent OS mounts on /.oldroot */
 if (lxcContainerPivotRoot(root) < 0)
 goto cleanup;
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 61d9ed07b..d1ae60b1d 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -530,9 +530,12 @@ static int 
virLXCControllerAppendNBDPids(virLXCControllerPtr ctrl,
 }
 
 
-static int virLXCControllerSetupNBDDeviceFS(virDomainFSDefPtr fs)
+static int virLXCControllerSetupNBDDeviceFS(virLXCControllerPtr ctrl,
+virDomainFSDefPtr fs)
 {
-char *dev;
+char *dev, *dst, *tmp, *sec_mount_options;
+virDomainDefPtr def = ctrl->def;
+virSecurityManagerPtr securityDriver = ctrl->securityManager;
 
 if (fs->format <= VIR_STORAGE_FILE_NONE) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -540,22 +543,42 @@ static int 
virLXCControllerSetupNBDDeviceFS(virDomainFSDefPtr fs)
 return -1;
 }
 
+if (virAsprintf(, "%s/%s.root/",
+LXC_STATE_DIR, def->name) < 0)
+return -1;
+
+if (!(sec_mount_options = 
virSecurityManagerGetMountOptions(securityDriver, def)))
+return -1;
+
 if (virFileNBDDeviceAssociate(fs->src->path,
   fs->format,
   fs->readonly,
   ) < 0)
 return -1;
 
-VIR_DEBUG("Changing fs %s to use type=block for dev %s",
-  fs->src->path, dev);
-/*
- * We now change it into a block device type, so that
- * the rest of container setup 'just works'
- */
-fs->type = VIR_DOMAIN_FS_TYPE_BLOCK;
 VIR_FREE(fs->src->path);
 fs->src->path = dev;
 
+tmp = fs->dst;
+fs->dst = dst;
+
+if (lxcContainerMountFSBlock(fs, "", sec_mount_options) < 0) {
+fs->dst = tmp;
+VIR_FREE(dst);
+return -1;
+}
+
+fs->dst = tmp;
+fs->type = VIR_DOMAIN_FS_TYPE_MOUNT;
+
+/* The NBD device will be cleaned up while the cgroup will end.
+ * For this we need to remember the qemu-nbd pid and add it to
+ * the cgroup*/
+if (virLXCControllerAppendNBDPids(ctrl, fs->src->path) < 0)
+
+VIR_FREE(fs->src->path);
+fs->src->path = dst;
+
 return 0;
 }
 
@@ -637,13 +660,7 @@ static int 
virLXCControllerSetupLoopDevices(virLXCControllerPtr ctrl)
 }
 ctrl->loopDevFds[ctrl->nloopDevs - 1] = fd;
 } else if (fs->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_NBD) {
-  

[libvirt] [RFC 2/3] lxc: Move up virLXCControllerAppendNBDPids

[Radostin Stoyanov]

There is no functional change in this patch.

It only moves virLXCControllerAppendNBDPids above
virLXCControllerSetupNBDDeviceFS.
---
 src/lxc/lxc_controller.c | 96 
 1 file changed, 49 insertions(+), 47 deletions(-)

diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 507bffda0..61d9ed07b 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -481,6 +481,55 @@ static int 
virLXCControllerSetupLoopDeviceDisk(virDomainDiskDefPtr disk)
 }
 
 
+static int virLXCControllerAppendNBDPids(virLXCControllerPtr ctrl,
+ const char *dev)
+{
+char *pidpath = NULL;
+pid_t *pids = NULL;
+size_t npids = 0;
+size_t i;
+int ret = -1;
+size_t loops = 0;
+pid_t pid;
+
+if (!STRPREFIX(dev, "/dev/") ||
+virAsprintf(, "/sys/devices/virtual/block/%s/pid", dev + 5) < 
0)
+goto cleanup;
+
+/* Wait for the pid file to appear */
+while (!virFileExists(pidpath)) {
+/* wait for 100ms before checking again, but don't do it for ever */
+if (errno == ENOENT && loops < 10) {
+usleep(100 * 1000);
+loops++;
+} else {
+virReportSystemError(errno,
+ _("Cannot check NBD device %s pid"),
+ dev + 5);
+goto cleanup;
+}
+}
+
+if (virPidFileReadPath(pidpath, ) < 0)
+goto cleanup;
+
+if (virProcessGetPids(pid, , ) < 0)
+goto cleanup;
+
+for (i = 0; i < npids; i++) {
+if (VIR_APPEND_ELEMENT(ctrl->nbdpids, ctrl->nnbdpids, pids[i]) < 0)
+goto cleanup;
+}
+
+ret = 0;
+
+ cleanup:
+VIR_FREE(pids);
+VIR_FREE(pidpath);
+return ret;
+}
+
+
 static int virLXCControllerSetupNBDDeviceFS(virDomainFSDefPtr fs)
 {
 char *dev;
@@ -545,53 +594,6 @@ static int 
virLXCControllerSetupNBDDeviceDisk(virDomainDiskDefPtr disk)
 return 0;
 }
 
-static int virLXCControllerAppendNBDPids(virLXCControllerPtr ctrl,
- const char *dev)
-{
-char *pidpath = NULL;
-pid_t *pids = NULL;
-size_t npids = 0;
-size_t i;
-int ret = -1;
-size_t loops = 0;
-pid_t pid;
-
-if (!STRPREFIX(dev, "/dev/") ||
-virAsprintf(, "/sys/devices/virtual/block/%s/pid", dev + 5) < 
0)
-goto cleanup;
-
-/* Wait for the pid file to appear */
-while (!virFileExists(pidpath)) {
-/* wait for 100ms before checking again, but don't do it for ever */
-if (errno == ENOENT && loops < 10) {
-usleep(100 * 1000);
-loops++;
-} else {
-virReportSystemError(errno,
- _("Cannot check NBD device %s pid"),
- dev + 5);
-goto cleanup;
-}
-}
-
-if (virPidFileReadPath(pidpath, ) < 0)
-goto cleanup;
-
-if (virProcessGetPids(pid, , ) < 0)
-goto cleanup;
-
-for (i = 0; i < npids; i++) {
-if (VIR_APPEND_ELEMENT(ctrl->nbdpids, ctrl->nnbdpids, pids[i]) < 0)
-goto cleanup;
-}
-
-ret = 0;
-
- cleanup:
-VIR_FREE(pids);
-VIR_FREE(pidpath);
-return ret;
-}
 
 static int virLXCControllerSetupLoopDevices(virLXCControllerPtr ctrl)
 {
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 0/3] LXC with block device and enabled userns

[Radostin Stoyanov]

Problem background
--

The LXC driver has support for the filesystem types "file" and "block"
that allow a disk image to be mounted in the guest (container). [1]

However, when user-namespace is enabled (uid/gid mapping is used) the
mount of the root filesystem block device fails. [2]

According to "man 7 user_namespaces":

Mounting block-based filesystems can be done only by a process that 
holds
CAP_SYS_ADMIN in the initial user namespace.


Suggested approach
--
Mount the root file system block device before the clone() call, then set
filesystem type to VIR_DOMAIN_FS_TYPE_MOUNT and filesystem source to the folder
where it was mounted.


Issues encountered


This patch series implements the basic idea of the mentioned approach.
In result, a container with configured idmap and NBD filesystem is able to 
start.

However, on guest shutdown this kernel error [3] occurs.

Similar messages [4] occur on shutdown when NBD filesystem is used with LXC
container without idmap.

Perhaps, one reason could be that on guest shutdown the LXC driver kills 
qemu-nbd
process without sending disconnect for the specified device.


References
-- 

[1] https://libvirt.org/formatdomain.html#elementsFilesystems
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1328946
[3] https://pastebin.com/raw/jMBk5mtG
[4] https://pastebin.com/raw/wTKbuRP9

Radostin Stoyanov (3):
  lxc: Make lxcContainerMountFSBlock non static
  lxc: Move up virLXCControllerAppendNBDPids
  lxc: Mount NBD devices before clone

 src/lxc/lxc_container.c  |  58 +--
 src/lxc/lxc_container.h  |   4 ++
 src/lxc/lxc_controller.c | 145 +++
 3 files changed, 87 insertions(+), 120 deletions(-)

-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 1/3] lxc: Make lxcContainerMountFSBlock non static

[Radostin Stoyanov]

---
 src/lxc/lxc_container.c | 5 +
 src/lxc/lxc_container.h | 4 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 532fd0be0..3b8cb966e 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -113,9 +113,6 @@ struct __lxc_child_argv {
 int *nsInheritFDs;
 };
 
-static int lxcContainerMountFSBlock(virDomainFSDefPtr fs,
-const char *srcprefix,
-const char *sec_mount_options);
 
 
 /*
@@ -1499,7 +1496,7 @@ static int 
lxcContainerMountFSBlockHelper(virDomainFSDefPtr fs,
 }
 
 
-static int lxcContainerMountFSBlock(virDomainFSDefPtr fs,
+int lxcContainerMountFSBlock(virDomainFSDefPtr fs,
 const char *srcprefix,
 const char *sec_mount_options)
 {
diff --git a/src/lxc/lxc_container.h b/src/lxc/lxc_container.h
index 641e2d460..3a3564b79 100644
--- a/src/lxc/lxc_container.h
+++ b/src/lxc/lxc_container.h
@@ -68,4 +68,8 @@ int lxcContainerChown(virDomainDefPtr def, const char *path);
 
 bool lxcIsBasicMountLocation(const char *path);
 
+int lxcContainerMountFSBlock(virDomainFSDefPtr fs,
+ const char *srcprefix,
+ const char *sec_mount_options);
+
 #endif /* LXC_CONTAINER_H */
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 0/2] Trivial fixes

[Radostin Stoyanov]

Radostin Stoyanov (2):
  lxc: s/subtreee/subtree/
  lxc: Clean up /.oldroot

 src/lxc/lxc_container.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/2] lxc: s/subtreee/subtree/

[Radostin Stoyanov]

Signed-off-by: Radostin Stoyanov 
---
 src/lxc/lxc_container.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 532fd0be0..665b93a0a 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -574,7 +574,7 @@ static int lxcContainerUnmountSubtree(const char *prefix,
 const char *failedUmount = NULL;
 int ret = -1;
 
-VIR_DEBUG("Unmount subtreee from %s", prefix);
+VIR_DEBUG("Unmount subtree from %s", prefix);
 
 if (virFileGetMountReverseSubtree("/proc/mounts", prefix,
   , ) < 0)
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/2] lxc: Clean up /.oldroot

[Radostin Stoyanov]

Remove the /.oldroot directory after it has been unmounted (at the end
of lxcContainerSetupPivotRoot). Ignore errors silently.

Signed-off-by: Radostin Stoyanov 
---
 src/lxc/lxc_container.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 665b93a0a..dd4e38703 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -1811,6 +1811,9 @@ static int lxcContainerSetupPivotRoot(virDomainDefPtr 
vmDef,
 if (lxcContainerUnmountSubtree("/.oldroot", true) < 0)
 goto cleanup;
 
+if (virFileRemove("/.oldroot", 0, 0) < 0)
+VIR_DEBUG("Failed to remove /.oldroot after start");
+
 ret = 0;
 
  cleanup:
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/6] tests: qemuxm2argv: Add infrastructure for testing with real qemuCaps

[Ján Tomko]

On Wed, Apr 11, 2018 at 11:16:27AM -0400, John Ferlan wrote:



On 04/04/2018 04:13 AM, Peter Krempa wrote:

Allow testing of XML->argv conversion with using a real capability map
as used in the qemucapabilitiestest. This allows specifying the required
qemu version with the test rather than having to enumerate all the
required capabilities.

Signed-off-by: Peter Krempa 
---
 tests/qemuxml2argvtest.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index d79913dd0a..c540ce2f50 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -654,6 +654,37 @@ mymain(void)
 if (VIR_STRDUP_QUIET(driver.config->memoryBackingDir, 
"/var/lib/libvirt/qemu/ram") < 0)
 return EXIT_FAILURE;

+
+# define DO_TEST_CAPS_ARCH(name, migrateFrom, flags, \
+   parseFlags, gic, arch, ver) \
+do { \
+static struct testInfo info = { \
+name, NULL, migrateFrom, migrateFrom ? 7 : -1, (flags), 
parseFlags, \
+false, NULL \
+}; \
+info.skipLegacyCPUs = skipLegacyCPUs; \
+if (testInitQEMUCaps(, gic) < 0) \
+return EXIT_FAILURE; \
+if (!(info.qemuCaps = 
qemuTestParseCapabilitiesArch(virArchFromString(arch), \
+  abs_srcdir 
"/qemucapabilitiesdata/caps_" \
+  ver "." arch ".xml"))) \
+return EXIT_FAILURE; \
+if (virTestRun("QEMU XML-2-ARGV " name, \
+   testCompareXMLToArgv, ) < 0) \
+ret = -1; \
+if (info.vm && virTestRun("QEMU XML-2-startup-XML " name, \
+  testCompareXMLToStartupXML, ) < 0) \
+ret = -1; \
+virObjectUnref(info.qemuCaps); \
+virObjectUnref(info.vm); \
+} while (0)
+
+# define DO_TEST_CAPS_FULL(name, flags, parseFlags, ver) \
+DO_TEST_CAPS_ARCH(name, NULL, flags, parseFlags, GIC_NONE, "x86_64", ver)


Assumes x64_64...


+
+# define DO_TEST_CAPS(name, ver) \
+DO_TEST_CAPS_FULL(name, 0, 0, ver)
+
 # define DO_TEST_FULL(name, migrateFrom, migrateFd, flags, \
   parseFlags, gic, ...) \
 do { \



Do you expect to see wide spread and future use of this model as opposed
to the existing DO_TEST model? Shouldn't at least some of the existing
tests be converted, then?


Yes to both.



Perhaps the macro(s) should be DO_TEST_VERS[ION] or DO_TEST__VERS
instead since DO_TEST runs the test with specific capabilities and this
new model runs the test with a specific version for a specific platform.

How do or should we enforce that when adding a new test from this point
forward that the DO_TEST_CAPS model is chosen over DO_TEST?  I suppose
there is still value in DO_TEST since one can pick and choose which CAP
is needed - although I'll freely admit that's usually a cut-n-paste from
some other test and change the name type activity.


The problem with that approach is that we're testing against
capability combinations that might never occur in the wild.

I actually remember fixing some bug that was supposed to be covered by
a unit test, but it was missing the important capability.

Enforcement by review ought to be enough for everybody.

Though there still might be features that you can compile out even from
QEMU versions that otherwise have the capability, but we don't add
negative tests for that often.

Jano



I think I have too many questions for an R-b at this point.


John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 60/73] qemu: Check remote caps when enabling always-on capabilities

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:50PM +0200, Jiri Denemark wrote:

When an always-on migration capability is supposed to be enabled on both
sides of migration, each side can only enable the feature if it is
enabled by the other side.

Thus the source host sends a list of supported migration capabilities in
the migration cookie generated in the Begin phase. The destination host
consumes the list in the Prepare phase and decides what capabilities can
be enabled when starting a QEMU process for incoming migration. Once
done the destination sends the list of supported capabilities back to
the source where it is used during the Perform phase to determine what
capabilities can be automatically enabled.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c| 17 -
src/qemu/qemu_migration_params.c | 22 --
src/qemu/qemu_migration_params.h |  3 ++-
3 files changed, 34 insertions(+), 8 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 61/73] qemu: Generalize qemuMigrationParamsGetDowntimeLimit

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:51PM +0200, Jiri Denemark wrote:

The API is renamed as qemuMigrationParamsGetULL and it can be used with
any migration parameter stored as unsigned long long.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c   |  9 -
src/qemu/qemu_migration_params.c | 15 ++-
src/qemu/qemu_migration_params.h |  5 +++--
3 files changed, 21 insertions(+), 8 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: remove obsolete qemuMonitorMigrateToCommand

[Ján Tomko]

On Thu, Apr 12, 2018 at 11:10:34AM +0100, Daniel P. Berrangé wrote:

The last use of qemuMonitorMigrateToCommand was removed years back in

 commit 2e90c9daf9eabe15d826a48c06607acb9d18fda6
 Author: Daniel P. Berrange 
 Date:   Fri Nov 6 16:50:26 2015 +

   qemu: assume support for all migration protocols except rdma

Prior to that commit, 'exec:' to used to replicate the 'unix:' protocol
by spawning 'nc'.

Signed-off-by: Daniel P. Berrangé 
---
src/qemu/qemu_monitor.c | 31 ---
src/qemu/qemu_monitor.h |  4 
2 files changed, 35 deletions(-)

;

Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] apparmor: add rules to use qemu_bridge_helper

[Guido Günther]

On Mon, Apr 09, 2018 at 08:34:06AM +0200, Christian Ehrhardt wrote:
> Due to mediation of socket and signal activity currently qemu:///session
> connections calling qemu_bridge_helper fail.
> 
> We need the profile for libvirtd itself and the subprofile for
> qemu-bridge-helper to be able to talk/notify to each other via unix socket and
> signals.
> 
> Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1754871
> 
> Signed-off-by: Christian Ehrhardt 
> ---
>  examples/apparmor/usr.sbin.libvirtd | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/examples/apparmor/usr.sbin.libvirtd 
> b/examples/apparmor/usr.sbin.libvirtd
> index be4fabf..3102cab 100644
> --- a/examples/apparmor/usr.sbin.libvirtd
> +++ b/examples/apparmor/usr.sbin.libvirtd
> @@ -65,6 +65,10 @@
>signal (read, send) peer=libvirt-*,
>signal (send) set=("kill", "term") peer=unconfined,
>  
> +  # For communication/control to qemu-bridge-helper
> +  unix (send, receive) type=stream addr=none 
> peer=(label=/usr/sbin/libvirtd//qemu_bridge_helper),
> +  signal (send) set=("term") peer=/usr/sbin/libvirtd//qemu_bridge_helper,
> +
># Very lenient profile for libvirtd since we want to first focus on 
> confining
># the guests. Guests will have a very restricted profile.
>/ r,
> @@ -112,6 +116,10 @@
>  
> network inet stream,
>  
> +   # For communication/control from libvirtd
> +   unix (send, receive) type=stream addr=none 
> peer=(label=/usr/sbin/libvirtd),
> +   signal (receive) set=("term") peer=/usr/sbin/libvirtd,
> +
> /dev/net/tun rw,
> /etc/qemu/** r,
> owner @{PROC}/*/status r,

Reviewed-by: Guido Günther 

> -- 
> 2.7.4
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 14/14] qemu: Detect pr-manager-helper capability

[John Ferlan]

On 04/10/2018 10:58 AM, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik 
> ---
>  src/qemu/qemu_capabilities.c   | 1 +
>  tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml   | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  | 1 +
>  6 files changed, 6 insertions(+)
> 

Reviewed-by: John Ferlan 

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] acl: remove various left over Xen ACL whitelist entries

[Ján Tomko]

On Thu, Apr 12, 2018 at 04:24:18PM +0100, Daniel P. Berrangé wrote:

The legacy xen driver is removed, so these ACLL hacks can be removed


s/LL/L/


too now.

Signed-off-by: Daniel P. Berrangé 
---
src/check-aclrules.pl | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] bhyve: add support for passing stdin to loader

[Fabian Freyer]

This commit adds the  node to the domain definition,
with the following semantics:

To pass standard input verbatim to the bootloader, set

some stdin

Multiline standard input can be set using a CDATA tag:



Standard input can be read from a file as follows:



Signed-off-by: Fabian Freyer 
---
 docs/formatdomain.html.in  | 19 ++
 docs/schemas/domaincommon.rng  | 10 
 src/bhyve/bhyve_driver.c   | 10 
 src/bhyve/bhyve_parse_command.c| 70 ++
 src/bhyve/bhyve_process.c  | 22 +++
 src/conf/domain_conf.c | 41 +
 src/conf/domain_conf.h | 11 
 .../bhyveargv2xml-loader-stdin-file.args   |  9 +++
 .../bhyveargv2xml-loader-stdin-file.xml| 19 ++
 .../bhyveargv2xml-loader-stdin-multiline.args  | 13 
 .../bhyveargv2xml-loader-stdin-multiline.xml   | 21 +++
 .../bhyveargv2xml-loader-stdin-oneline.args| 11 
 .../bhyveargv2xml-loader-stdin-oneline.xml | 19 ++
 tests/bhyveargv2xmltest.c  |  3 +
 .../bhyvexml2argv-grub-stdin-file.args |  9 +++
 .../bhyvexml2argv-grub-stdin-file.devmap   |  1 +
 .../bhyvexml2argv-grub-stdin-file.ldargs   |  4 ++
 .../bhyvexml2argv-grub-stdin-file.xml  | 25 
 .../bhyvexml2argv-grub-stdin-multiline.args|  9 +++
 .../bhyvexml2argv-grub-stdin-multiline.devmap  |  1 +
 .../bhyvexml2argv-grub-stdin-multiline.ldargs  |  4 ++
 .../bhyvexml2argv-grub-stdin-multiline.xml | 30 ++
 .../bhyvexml2argv-grub-stdin-oneline.args  |  9 +++
 .../bhyvexml2argv-grub-stdin-oneline.devmap|  1 +
 .../bhyvexml2argv-grub-stdin-oneline.ldargs|  4 ++
 .../bhyvexml2argv-grub-stdin-oneline.xml   | 25 
 tests/bhyvexml2argvtest.c  |  3 +
 .../bhyvexml2xmlout-grub-stdin-file.xml| 34 +++
 .../bhyvexml2xmlout-grub-stdin-multiline.xml   | 39 
 .../bhyvexml2xmlout-grub-stdin-oneline.xml | 34 +++
 tests/bhyvexml2xmltest.c   |  3 +
 31 files changed, 513 insertions(+)
 create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-loader-stdin-file.args
 create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-loader-stdin-file.xml
 create mode 100644 
tests/bhyveargv2xmldata/bhyveargv2xml-loader-stdin-multiline.args
 create mode 100644 
tests/bhyveargv2xmldata/bhyveargv2xml-loader-stdin-multiline.xml
 create mode 100644 
tests/bhyveargv2xmldata/bhyveargv2xml-loader-stdin-oneline.args
 create mode 100644 
tests/bhyveargv2xmldata/bhyveargv2xml-loader-stdin-oneline.xml
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-file.args
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-file.devmap
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-file.ldargs
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-file.xml
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-multiline.args
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-multiline.devmap
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-multiline.ldargs
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-multiline.xml
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-oneline.args
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-oneline.devmap
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-oneline.ldargs
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-grub-stdin-oneline.xml
 create mode 100644 
tests/bhyvexml2xmloutdata/bhyvexml2xmlout-grub-stdin-file.xml
 create mode 100644 
tests/bhyvexml2xmloutdata/bhyvexml2xmlout-grub-stdin-multiline.xml
 create mode 100644 
tests/bhyvexml2xmloutdata/bhyvexml2xmlout-grub-stdin-oneline.xml

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 5e99884dc..cea024235 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -245,6 +245,11 @@
 ...
 bootloader/usr/bin/pygrub/bootloader
 bootloader_args--append single/bootloader_args
+bootloader_stdin![CDATA[
+kernel (hd)/path/to/kernel
+initrd (host)/path/to/initrd
+boot
+]]
 ...
 
 
@@ -259,6 +264,20 @@
 command line arguments to be passed to the bootloader.
 Since 0.2.3
 
+  bootloader_stdin
+  The optional bootloader_stdin element specifies
+standard input to be passed to the bootloader. To pass multiple
+lines of standard input to the bootloader, wrap the content in
+a CDATA tag. Instead of specifying the standard input in the
+domain XML, the path to a file to be read may be given using the
+file 

[libvirt] [PATCH v2 2/2] vmware: Failures in cache info init are non-fatal

[Rainer Müller]

This is also not fatal on other drivers.

Signed-off-by: Rainer Müller 
---
 src/vmware/vmware_conf.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/vmware/vmware_conf.c b/src/vmware/vmware_conf.c
index 891d9a47f..b9f18e6ac 100644
--- a/src/vmware/vmware_conf.c
+++ b/src/vmware/vmware_conf.c
@@ -33,6 +33,11 @@
 #include "vmx.h"
 #include "vmware_conf.h"
 #include "virstring.h"
+#include "virlog.h"
+
+#define VIR_FROM_THIS VIR_FROM_VMWARE
+
+VIR_LOG_INIT("vmware.vmware_conf");
 
 VIR_ENUM_IMPL(vmwareDriver, VMWARE_DRIVER_LAST,
   "player",
@@ -69,7 +74,7 @@ vmwareCapsInit(void)
 goto error;
 
 if (virCapabilitiesInitCaches(caps) < 0)
-goto error;
+VIR_WARN("Failed to get host CPU cache info");
 
 /* i686 guests are always supported */
 if ((guest = virCapabilitiesAddGuest(caps,
-- 
2.17.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC v2] external (pull) backup API

[John Snow]

On 04/13/2018 05:47 AM, Nikolay Shirokovskiy wrote:
>>> However as we use chain of disabled bitmaps with one active bitmap on tip
>>> of the chain and qemu does not track their order we need to do it in
>>> libvirt.
>>>
>> Well, you seem to be tracking it in *qemu*, by using the name field.
>> Should we not make a commitment to whether or not we store this lineage
>> information in either qemu OR libvirt, but not distributed across both...?
>>
> I don't know actual use cases to decide. A commitment that this meta is stored
> in disks like proposed can be useful IMHO so that mgmt can expect that dumb 
> reinserting
> disks to a different domain (recreated for example) keep all checkpoints.

What I am asking rather indirectly is if it would be useful to elevate
this to a *real* metadata field in QEMU so that you don't have to hack
it by using the name field,

OR

cease using the name field for this purpose and store the data entirely
within libvirt.

It sounds like you want the flexibility of the first option. I think
Vladimir had an argument against this though, I need to go back and read it.

--js

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC v2] external (pull) backup API

[Vladimir Sementsov-Ogievskiy]

13.04.2018 21:02, John Snow wrote:


On 04/13/2018 08:01 AM, Vladimir Sementsov-Ogievskiy wrote:

1. It looks unsafe to use nbd server + backup(sync=none) on same node,
synchronization is needed, like in block/replication, which uses
backup_wait_for_overlapping_requests, backup_cow_request_begin,
backup_cow_request_end. We have a filter driver for this thing, not yet
in upstream.

Is it the case that blockdev-backup sync=none can race with read
requests on the NBD server?

i.e. we can get temporarily inconsistent data before the COW completes?
Can you elaborate?

I'm not sure but looks possible:

1. start NBD read, find that there is a hole in temporary image, decide
to read from active image (or even start read) and yield
2. guest writes to the same are (COW happens, but it doesn't help)
3. reduce point (1.), read invalid (already updated by 2.) data

And similar place in block/replication, which uses backup(sync=none) too
is protected from such situation.

I'll have to look into this one -- were you seeing problems in practice
before you implemented your proprietary filter node?

--js


I didn't see problems, I just noted, that it is done in 
block/replication and looked through corresponding commit messages.


--
Best regards,
Vladimir

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 01/14] virstoragefile: Introduce virStoragePRDef

[John Ferlan]

On 04/10/2018 10:58 AM, Michal Privoznik wrote:
> This is a definition that holds information on SCSI persistent
> reservation settings. The XML part looks like this:
> 
>   
> 
>   
> 
> If @managed is set to 'yes' then the  is not parsed.
> This design was agreed on here:
> 
> https://www.redhat.com/archives/libvir-list/2017-November/msg01005.html
> 
> Signed-off-by: Michal Privoznik 
> ---
>  docs/formatdomain.html.in  |  25 +++-
>  docs/schemas/domaincommon.rng  |  34 +-
>  docs/schemas/storagecommon.rng |  50 
>  src/conf/domain_conf.c |  38 ++
>  src/libvirt_private.syms   |   3 +
>  src/util/virstoragefile.c  | 131 
> +
>  src/util/virstoragefile.h  |  14 +++
>  .../disk-virtio-scsi-reservations.xml  |  49 
>  .../disk-virtio-scsi-reservations.xml  |   1 +
>  tests/qemuxml2xmltest.c|   2 +
>  10 files changed, 316 insertions(+), 31 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/disk-virtio-scsi-reservations.xml
>  create mode 12 tests/qemuxml2xmloutdata/disk-virtio-scsi-reservations.xml
> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 5e99884dc5..c20e98b4ef 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -2563,7 +2563,10 @@
>/disk
>disk type='block' device='lun'
>  driver name='qemu' type='raw'/
> -source dev='/dev/sda'/
> +source dev='/dev/sda'
> +  reservations enabled='yes' managed='no'
> +source type='unix' path='/path/to/qemu-pr-helper' 
> mode='client'/
> +  /reservations
>  target dev='sda' bus='scsi'/
>  address type='drive' controller='0' bus='0' target='3' unit='0'/
>/disk
> @@ -2926,6 +2929,26 @@
>  Storage Encryption
>  page for more information.
>
> +  reservations
> +  Since libvirt 4.1.0, the

Now at least 4.3

> +reservations can be a sub-element of the
> +source element for storage sources (QEMU driver 
> only).
> +If present (and enabled) it enabled persistent reservations for

s/enabled/enables

> +SCSI based disks. The element has one mandatory attribute
> +enabled with accepted values yes and
> +no. If the feature is enabled, then there's another

I wish we were consistent about using  around 'yes'
and 'no' - some places use "yes" and/or "no".

> +mandatory attribute managed (accepted values are the
> +same as for enabled) that enables or disables 
> libvirt
> +spawning any helper process (should one be needed). However, if

s/any/a/ ?

s/(should one be needed)//

IOW: What really decides if one is needed?

> +libvirt is not enabled spawning helper process (i.e. hypervisor

Starting from "However, if.. " This reads strange - why not just
indicate "If enabled is yes, then libvirt will ...; otherwise, libvirt
will 

Taken from patch 4:

+/* Managed PR means there's one pr-manager object per domain
+ * and the pr-helper process is spawned and managed by
+ * libvirt.
+ * If PR is unmanaged there's one pr-manager object per disk
+ * (in general each disk can have its own pr-manager) and
+ * it's user's responsibility to start the pr-helper process.
+ */

When the PR is unmanaged, then the path to its socket...

> +should just use one which is already running), path to its socket
> +must be provided in child element source, which
> +currently accepts only the following attributes: 
> type
> +with one value unix, path with path the
> +socket, and finally mode which accepts either
> +server or client and specifies the role
> +of hypervisor.

mode only Parse's and Format's "client"... Perhaps the best thing to
indicate here is that since libvirt is then a client of the user
provided pr-helper process and will use a unix socket to connect to the
process, the type must be unix and the mode must be client with the path
being the path to the socket which libvirt will attempt to connect to.

> +  
>  
>  
>  

[...]

> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index d23182f18a..5943d05e0e 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -5210,6 +5210,13 @@ virDomainDiskDefValidate(const virDomainDiskDef *disk)
>  }
>  }
>  
> +if (disk->src->pr &&
> +disk->device != VIR_DOMAIN_DISK_DEVICE_LUN) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> +   _(" allowed only for lun disks"));

allowed or required ;-)

s/disks/devices/

> +return -1;
> +}
> +
>  /* Reject 

Re: [libvirt] [RFC v2] external (pull) backup API

[John Snow]

On 04/12/2018 10:08 AM, Vladimir Sementsov-Ogievskiy wrote:
> It's not easier, as we'll have to implement either separate of bitmaps
> concept of checkpoints, which will be based on bitmaps, and we'll have
> to negotiate and implement storing these objects to qcow2 and migrate
> them. Or we'll go through proposed by Kevin (If I remember correctly)
> way of adding something like "backing" or "parent" pointer to
> BdrvDirtyBitmap, and anyway store to qcow2, migrate and expose qapi for
> them. The other (more hard way) is move to multi-bit bitmaps (like in
> vmware), where for each granularity-chunk we store a number,
> representing "before which checkpoint was the latest change of this
> chunk", and the same, qapi+qcow2+migration.
> 
> It's all not easier than call several simple qmp commands.

OK, I just wanted to explore the option before we settled on using the
name as metadata.

What are the downsides to actually including a predecessor/successor*
pointer in QEMU?

(1) We'd need to amend the bitmap persistence format
(2) We'd need to amend some of the bitmap management commands
(3) We'd need to make sure it migrates correctly:
(A) Shared storage should be fine; just flush to disk and pivot
(B) Live storage needs to learn a new field to migrate.

Certainly it's not ...trivial, but not terribly difficult either. I
wonder if it's the right thing to do in lieu of the naming hacks in libvirt.

There wasn't really a chorus of applause for the idea of having
checkpoints more officially implemented in QEMU, but... abusing the name
metadata still makes me feel like we're doing something wrong --
especially if a third party utility that doesn't understand the concept
of your naming scheme comes along and modifies a bitmap.

It feels tenuous and likely to break, so I'd like to formalize it more.
We can move this discussion over to the QEMU lists if you think it's
worth talking about.

Or I'll just roll with it. I'll see what Eric thinks, I guess? :)



*(Uh-oh, that term is overloaded for QEMU bitmap internals... we can
address that later...)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 03/14] qemu: Introduce pr-manager-helper capability

[John Ferlan]

On 04/10/2018 10:58 AM, Michal Privoznik wrote:
> The capability tracks if qemu has pr-manager-helper object. At
> this time don't actually detect if qemu has the capability. Not
> just yet. Only after the code is written the feature will be
> enabled.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  src/qemu/qemu_capabilities.c | 1 +
>  src/qemu/qemu_capabilities.h | 1 +
>  2 files changed, 2 insertions(+)
> 

Reviewed-by: John Ferlan 

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH] guests: Only attempt to fix intltool-update if it exists

[Andrea Bolognani]

If we're running against a freshly-provisioned FreeBSD guest,
intltool won't have been installed yet and attempts to fix it
will fail. Make sure the file exists.

Signed-off-by: Andrea Bolognani 
---
 guests/tasks/kludges.yml | 8 
 1 file changed, 8 insertions(+)

diff --git a/guests/tasks/kludges.yml b/guests/tasks/kludges.yml
index 4dd06a4..0ad61a7 100644
--- a/guests/tasks/kludges.yml
+++ b/guests/tasks/kludges.yml
@@ -52,6 +52,13 @@
 # wait for the port to be fixed, we can patch things up ourselves.
 #
 # See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227444
+- name: Look for intltool-update
+  stat:
+path: /usr/local/bin/intltool-update
+  register: intltoolupdate
+  when:
+- os_name == 'FreeBSD'
+
 - name: Fix intltool-update
   replace:
 path: /usr/local/bin/intltool-update
@@ -59,3 +66,4 @@
 replace: '\1 !~ /\\$\\{?$2}?/;'
   when:
 - os_name == 'FreeBSD'
+- intltoolupdate.stat.exists
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 53/73] qemu: Move migration parameters JSON formatting

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:43PM +0200, Jiri Denemark wrote:

We want to have all migration parameters parsing and formatting at one
place, i.e., in qemu_migration_params.c.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration_params.c | 68 +++-
src/qemu/qemu_monitor.c  | 35 
src/qemu/qemu_monitor.h  |  2 +-
src/qemu/qemu_monitor_json.c | 56 ++
src/qemu/qemu_monitor_json.h |  2 +-
5 files changed, 90 insertions(+), 73 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 46/73] qemu: Replace qemuMigrationAnyCompressionDump

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:36PM +0200, Jiri Denemark wrote:

Since every parameter or capability set in qemuMigrationCompression
structure is now reflected in qemuMigrationParams structure, we can
replace qemuMigrationAnyCompressionDump with a new API which will work
on qemuMigrationParams.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c   |  6 ++--
src/qemu/qemu_migration.c| 16 --
src/qemu/qemu_migration.h|  1 -
src/qemu/qemu_migration_params.c | 52 ++--
src/qemu/qemu_migration_params.h | 10 +++---
5 files changed, 37 insertions(+), 48 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 5/9] src: Unify dispose function names

[Michal Privoznik]

If a function is disposing virSomething it should be called
virSomethingDispose(). There are two offenders:
virCapabilitiesDispose(virCapsPtr) and
virDomainXMLOptionClassDispose(virDomainXMLOptionPtr).

Signed-off-by: Michal Privoznik 
---
 src/conf/capabilities.c | 6 +++---
 src/conf/domain_conf.c  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c
index edf9f54f77..33b9194041 100644
--- a/src/conf/capabilities.c
+++ b/src/conf/capabilities.c
@@ -58,14 +58,14 @@ VIR_ENUM_IMPL(virCapsHostPMTarget, 
VIR_NODE_SUSPEND_TARGET_LAST,
   "suspend_mem", "suspend_disk", "suspend_hybrid");
 
 static virClassPtr virCapsClass;
-static void virCapabilitiesDispose(void *obj);
+static void virCapsDispose(void *obj);
 
 static int virCapabilitiesOnceInit(void)
 {
 if (!(virCapsClass = virClassNew(virClassForObject(),
  "virCaps",
  sizeof(virCaps),
- virCapabilitiesDispose)))
+ virCapsDispose)))
 return -1;
 
 return 0;
@@ -215,7 +215,7 @@ virCapabilitiesClearSecModel(virCapsHostSecModelPtr 
secmodel)
 }
 
 static void
-virCapabilitiesDispose(void *object)
+virCapsDispose(void *object)
 {
 virCapsPtr caps = object;
 size_t i;
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index d23182f18a..4dad8e3b20 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -934,7 +934,7 @@ VIR_ENUM_IMPL(virDomainShmemModel, 
VIR_DOMAIN_SHMEM_MODEL_LAST,
 static virClassPtr virDomainObjClass;
 static virClassPtr virDomainXMLOptionClass;
 static void virDomainObjDispose(void *obj);
-static void virDomainXMLOptionClassDispose(void *obj);
+static void virDomainXMLOptionDispose(void *obj);
 
 static int virDomainObjOnceInit(void)
 {
@@ -947,7 +947,7 @@ static int virDomainObjOnceInit(void)
 if (!(virDomainXMLOptionClass = virClassNew(virClassForObject(),
 "virDomainXMLOption",
 sizeof(virDomainXMLOption),
-
virDomainXMLOptionClassDispose)))
+virDomainXMLOptionDispose)))
 return -1;
 
 return 0;
@@ -957,7 +957,7 @@ VIR_ONCE_GLOBAL_INIT(virDomainObj)
 
 
 static void
-virDomainXMLOptionClassDispose(void *obj)
+virDomainXMLOptionDispose(void *obj)
 {
 virDomainXMLOptionPtr xmlopt = obj;
 
-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 4/9] src: Unify virObject member name

[Michal Privoznik]

Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.

The unified name is 'parent'.

Signed-off-by: Michal Privoznik 
---
 src/datatypes.h   | 28 ++--
 src/libvirt-admin.c   |  2 +-
 src/libvirt-domain-snapshot.c |  2 +-
 src/libvirt-domain.c  |  2 +-
 src/libvirt-host.c|  2 +-
 src/libvirt-interface.c   |  2 +-
 src/libvirt-network.c |  2 +-
 src/libvirt-nodedev.c |  2 +-
 src/libvirt-nwfilter.c|  2 +-
 src/libvirt-secret.c  |  2 +-
 src/libvirt-storage.c |  4 ++--
 src/libvirt-stream.c  |  2 +-
 src/qemu/qemu_capabilities.c  |  2 +-
 src/rpc/virnetclientprogram.c |  2 +-
 src/rpc/virnetserverprogram.c |  2 +-
 src/rpc/virnetserverservice.c |  2 +-
 src/util/virdnsmasq.c |  2 +-
 src/util/virfilecache.c   |  2 +-
 tests/virfilecachetest.c  |  2 +-
 19 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/src/datatypes.h b/src/datatypes.h
index 66733b075c..192c86be80 100644
--- a/src/datatypes.h
+++ b/src/datatypes.h
@@ -453,7 +453,7 @@ struct _virAdmConnectCloseCallbackData {
  * Internal structure associated to a connection
  */
 struct _virConnect {
-virObjectLockable object;
+virObjectLockable parent;
 
 /* All the variables from here, until declared otherwise in one of
  * the following comments, are setup at time of connection open
@@ -496,7 +496,7 @@ struct _virConnect {
  * Internal structure associated to an admin connection
  */
 struct _virAdmConnect {
-virObjectLockable object;
+virObjectLockable parent;
 virURIPtr uri;
 
 void *privateData;
@@ -512,7 +512,7 @@ struct _virAdmConnect {
  * Internal structure associated to a daemon server
  */
 struct _virAdmServer {
-virObject object;
+virObject parent;
 virAdmConnectPtr conn;  /* pointer back to the admin connection */
 char *name; /* the server external name */
 };
@@ -523,7 +523,7 @@ struct _virAdmServer {
  * Internal structure associated to a client connected to daemon
  */
 struct _virAdmClient {
-virObject object;
+virObject parent;
 virAdmServerPtr srv;/* pointer to the server client is
  * connected to, which also holds a
  * reference back to the admin connection
@@ -539,7 +539,7 @@ struct _virAdmClient {
 * Internal structure associated to a domain
 */
 struct _virDomain {
-virObject object;
+virObject parent;
 virConnectPtr conn;  /* pointer back to the connection */
 char *name;  /* the domain external name */
 int id;  /* the domain ID */
@@ -552,7 +552,7 @@ struct _virDomain {
 * Internal structure associated to a domain
 */
 struct _virNetwork {
-virObject object;
+virObject parent;
 virConnectPtr conn;  /* pointer back to the connection */
 char *name;  /* the network external name */
 unsigned char uuid[VIR_UUID_BUFLEN]; /* the network unique identifier */
@@ -564,7 +564,7 @@ struct _virNetwork {
 * Internal structure associated to a physical host interface
 */
 struct _virInterface {
-virObject object;
+virObject parent;
 virConnectPtr conn;  /* pointer back to the connection */
 char *name;  /* the network external name */
 char *mac;   /* the interface MAC address */
@@ -576,7 +576,7 @@ struct _virInterface {
 * Internal structure associated to a storage pool
 */
 struct _virStoragePool {
-virObject object;
+virObject parent;
 virConnectPtr conn;  /* pointer back to the connection */
 char *name;  /* the storage pool external name */
 unsigned char uuid[VIR_UUID_BUFLEN]; /* the storage pool unique identifier 
*/
@@ -595,7 +595,7 @@ struct _virStoragePool {
 * Internal structure associated to a storage volume
 */
 struct _virStorageVol {
-virObject object;
+virObject parent;
 virConnectPtr conn;  /* pointer back to the connection */
 char *pool;  /* Pool name of owner */
 char *name;  /* the storage vol external name */
@@ -615,7 +615,7 @@ struct _virStorageVol {
  * Internal structure associated with a node device
  */
 struct _virNodeDevice {
-virObject object;
+virObject parent;
 virConnectPtr conn; /* pointer back to the connection */
 char *name; /* device name (unique on node) */
 char *parentName;   /* parent device name */
@@ -627,7 +627,7 

Re: [libvirt] [PATCH v2 48/73] qemu: Introduce qemuMigrationParamsFetch

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:38PM +0200, Jiri Denemark wrote:

Let's separate the code which queries QEMU for migration parameters from
qemuMigrationParamsCheck into a dedicated function.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration_params.c | 56 +++-
src/qemu/qemu_migration_params.h |  6 
2 files changed, 40 insertions(+), 22 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 56/73] qemu: Refactor qemuMigrationParams

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:46PM +0200, Jiri Denemark wrote:

Adding support for new migration parameter requires a lot of places to
be changed (most likely by copy engineering): new variables to
store the parameter value and the associated *_set bool, JSON formatter
and parser, XML formatter and parser (to be added soon), and the actual
code to set the parameter. It's pretty easy to forget about some of the
places which need to be updated and end up with incorrect support. The
goal of this patch is to let most of the places do their job without any
modifications when new parameters are added.

To achieve the goal, a new qemuMigrationParam enum is introduced and all
parameters are stored in an array indexed by the items of this enum.
This will also allow us to automatically set the migration parameters
which directly correspond to libvirt's typed parameters accepted by
virDomainMigrate* APIs.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration_params.c | 470 ---
src/qemu/qemu_migration_params.h |  20 ++
2 files changed, 328 insertions(+), 162 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv2 4/4] qemu: deny privilege elevation and spawn in seccomp

[Daniel P . Berrangé]

On Fri, Apr 13, 2018 at 10:08:34AM -0400, John Ferlan wrote:
> 
> 
> On 04/10/2018 10:49 AM, Ján Tomko wrote:
> > If QEMU uses a seccomp blacklist (since 2.11), -sandbox on
> > no longer tries to whitelist all the calls, but uses sets
> > of blacklists:
> > default (always blacklisted with -sandbox on)
> > obsolete (defaults to deny)
> > elevateprivileges (setuid & co, default: allow)
> > spawn (fork & execve, default: allow)
> > resourcecontrol (setaffinity, setscheduler, default: allow)
> > 
> > If these are supported, default to sandbox with all four
> > categories blacklisted.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1492597
> > 
> > Signed-off-by: Ján Tomko 
> > ---
> >  src/qemu/qemu.conf  |  7 +++---
> >  src/qemu/qemu_command.c | 10 +
> >  tests/qemuxml2argvdata/minimal-sandbox.args | 29 
> >  tests/qemuxml2argvdata/minimal-sandbox.xml  | 34 
> > +
> >  tests/qemuxml2argvtest.c| 11 ++
> >  5 files changed, 88 insertions(+), 3 deletions(-)
> >  create mode 100644 tests/qemuxml2argvdata/minimal-sandbox.args
> >  create mode 100644 tests/qemuxml2argvdata/minimal-sandbox.xml
> > 
> > diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> > index 07eab7eff..740129cf5 100644
> > --- a/src/qemu/qemu.conf
> > +++ b/src/qemu/qemu.conf
> > @@ -669,9 +669,10 @@
> >  
> >  
> >  
> > -# Use seccomp syscall whitelisting in QEMU.
> > -# 1 = on, 0 = off, -1 = use QEMU default
> > -# Defaults to -1.
> > +# Use seccomp syscall sandbox in QEMU.
> > +# 1 = on, 0 = off, -1 = use the default
> > +# For QEMUs using a whitelist, the default (-1) is off.
> > +# For QEMUs using a blacklist, the default (-1) is on.
> 
> Not sure it's even possible to provide any sort of details, but suffice
> to say the description here is really lacking. One of those things that
> if you know and care, then you use, if you don't you ignore. Maybe it's
> just me being dense ;-).
> 
> Still if someone supplies 0 or 1 does that now mean the opposite of what
> it did before 2.11? That is if I had this set to 1 in my qemu.conf -
> does that mean that now I'm using a blacklist instead of a whitelist?

Yes, setting this to '1' just means "enable use of seccomp". We explicitly
never defined what kind of seccomp rules would be enabled - only that
something seccomp related is on. Whether its a blacklist or a whitelist
is a low level impl detail that we don't expect users to care about.

> As an Admin trying to decipher this - what would each setting mean to me
> and if going with the new -1 default, then that means libvirt is going
> to set "on" w/ a list of 4 to deny.

Essentially the default (-1) means "do the best thing". On old QEMU the
best thing was to disable it because it was horribly unreliable with a
whitelist. On modern QEMU the best thing is to enable it because the
blacklist is much saner


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 45/73] qemu: Hide qemuMigrationParamsSetCompression

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:35PM +0200, Jiri Denemark wrote:

There's no need to call this API explicitly in the migration code. We
can pass the compression parameters to qemuMigrationParamsFromFlags and
it can internally call qemuMigrationParamsSetCompression to apply them
to the qemuMigrationParams structure.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c   | 30 -
src/qemu/qemu_migration.c| 38 ++--
src/qemu/qemu_migration.h|  2 --
src/qemu/qemu_migration_params.c | 11 +
src/qemu/qemu_migration_params.h |  8 ++-
5 files changed, 36 insertions(+), 53 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 49/73] qemu: Limit usage of qemuMonitorMigrationParams

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:39PM +0200, Jiri Denemark wrote:

Use this internal structure only in qemu_migration_params.c and change
other non-test users to use the high level qemuMigrationParams struct.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c   | 26 +++---
src/qemu/qemu_migration_params.c | 16 
src/qemu/qemu_migration_params.h |  4 
3 files changed, 31 insertions(+), 15 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC v2] external (pull) backup API

[Vladimir Sementsov-Ogievskiy]

13.04.2018 12:16, Nikolay Shirokovskiy wrote:


On 13.04.2018 00:16, John Snow wrote:


On 04/03/2018 08:01 AM, Nikolay Shirokovskiy wrote:

Hi, all.
  
This is another RFC on pull backup API. This API provides means to read domain

disks in a snapshotted state so that client can back them up as well as means
to write domain disks to revert them to backed up state. The previous version
of RFC is [1]. I'll also describe the API implementation details to shed light
on misc qemu dirty bitmap commands usage.
  
This API does not use existent disks snapshots. Instead it introduces snapshots

provided by qemu's blockdev-backup command. The reason is we need snapshotted
disk state only temporarily for duration of backup operation and newly
introduced snapshots can be easily discarded at the end of operation without
block commit operation. Technically difference is next. On usual snapshot we
create new image backed by original and all new data goes to the new image thus
original image stays in a snapshotted state. In temporary snapshots we create
new image backed by original and all new data still goes to the original image
but before new data is written old data to be overwritten is popped out to the 
new
image thus we get snapshotted state thru new image.
  
Disks snapshots as well as disks itself are avaiable to read/write thru qemu

NBD server.

[snip!]

Do you think it's possible to characterize this API proposal as two
mechanisms:

(1) A mechanism for creating and manipulating "checkpoints" -- which are
book-ended by bitmap objects in QEMU -- implemented by the creation,
deletion, 'disabling' and 'merging' of bitmaps, and

(2) A mechanism for the consumption of said checkpoints via NBD / the
"fleecing" mechanisms that allow a live export of a static view of the
disk at that time (block snapshots + NBD exports)

I can't share this view because checkpoints and snapshots are created
in one transation in pull scheme so you can't not move these two to
different mechs.

I'll rather see 2 mechanism here at least for pull scheme.

1. create snapshots (and optionally checkpoints)
2. export snapshots


If this is the case, do you think it is possible to consider (1) and (2)
somewhat orthogonal items -- in so far as it might be possible to add
support to libvirt directly to add push-model support for writing out
these checkpoints?

i.e.

once you have created a temporary snapshot and merged the various
component bitmaps into it, instead of creating an ephemeral block
snapshot and exporting it via NBD, we request a `blockdev-backup` with a
libvirt-specified target instead?

You don't have to add support for this right away, but I would really
enjoy if any API we check in here has the capacity to support both
push-and-pull paradigms without getting too ugly.

Does that sound like it can easily fit in with your designs so far?


I think push scheme require 3rd (1st is fleece snapshots, 2nd is exporting
snapshots) API. First push backup has nothing to do with exporting of course. 
Second
contrary to fleece snapshots it will require additional parameter - a checkpoint
in past in case of incremental backup. It also have quite different image 
parameter.
In case of fleece snapshot fleece image will only store small delta even in 
case of
full backups. In case of push backup image will store full disk in case of full
backups.

Nikolay


Hmm, to use checkpoints with push backups, we just need to start normal 
incremental backups in transaction with checkpoint creation.


So. Checkpoint is a separate thing, but it is useless, if we didn't 
create some kind of backup (push or pull) in same transaction with it.


If we in future, implement checkpoints support in qemu, libvirt api 
realization will become simpler. But anyway, we should not create 
checkpoints

separately in libvirt, as they will useless in this case.

--
Best regards,
Vladimir

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH jenkins-ci 2/2] Enable mingw build for virt-viewer project

[Andrea Bolognani]

On Thu, 2018-04-12 at 15:28 +0100, Daniel P. Berrangé wrote:
> diff --git a/guests/vars/projects/virt-viewer.yml 
> b/guests/vars/projects/virt-viewer.yml
> index 6f3dbf9..85d1589 100644
> --- a/guests/vars/projects/virt-viewer.yml
> +++ b/guests/vars/projects/virt-viewer.yml
> @@ -6,5 +6,29 @@ packages:
>- intltool
>- libgovirt
>- libxml2
> +  - mingw32-adwaita-icon-theme
> +  - mingw32-glib2

Forgot to mention: mingw*-glib2 is not necessary here based on our
discussion, as it's already required to build libvirt-glib :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 44/73] qemu: Move qemuMigrationAnyCompression*

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:34PM +0200, Jiri Denemark wrote:

The code really belongs to qemu_migration_params.c.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c| 140 -
src/qemu/qemu_migration.h|  19 
src/qemu/qemu_migration_params.c | 147 +++
src/qemu/qemu_migration_params.h |  11 +++
4 files changed, 158 insertions(+), 159 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv2 1/4] Introduce QEMU_CAPS_SECCOMP_BLACKLIST

[John Ferlan]

On 04/10/2018 10:49 AM, Ján Tomko wrote:
> QEMU commit 1bd6152 changed the default behavior from whitelist
> to blacklist and introduced a few sets of system calls.
> 
> Use the 'elevateprivileges' parameter of -sandbox as a witness
> of this change.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1492597
> 
> Signed-off-by: Ján Tomko 
> ---
>  src/qemu/qemu_capabilities.c   | 2 ++
>  src/qemu/qemu_capabilities.h   | 1 +
>  tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml   | 1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  | 1 +
>  7 files changed, 8 insertions(+)
> 

Reviewed-by: John Ferlan 

John

Although I think this should be patch 3...  not that it really matters.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 40/73] qemu: Call qemuMigrationAnyCompressionParse only from driver

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:30PM +0200, Jiri Denemark wrote:

Propagate the calls up the stack to the point where
qemuMigrationParamsFromFlags is called. The end goal achieved in the
following few patches is to merge compression parameters into the
general migration parameters code.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c| 21 ++---
src/qemu/qemu_migration.c | 25 +++--
src/qemu/qemu_migration.h |  1 +
3 files changed, 26 insertions(+), 21 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 39/73] qemu: Set migration capabilities automatically

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:29PM +0200, Jiri Denemark wrote:

Most migration capabilities are directly connected with
virDomainMigrateFlags so qemuMigrationParamsFromFlags can automatically
enable them.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c| 30 -
src/qemu/qemu_migration_params.c | 45 +++-
src/qemu/qemu_migration_params.h |  6 -
3 files changed, 39 insertions(+), 42 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 33/73] qemu: Check supported caps in qemuMigrationParamsCheck

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:23PM +0200, Jiri Denemark wrote:

Instead of checking each capability at the time we want to set it in
qemuMigrationParamsSetCapability we can check all of them at once in
qemuMigrationParamsCheck.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c|  6 --
src/qemu/qemu_migration_params.c | 33 ++--
src/qemu/qemu_migration_params.h |  3 ++-
3 files changed, 25 insertions(+), 17 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH jenkins-ci 2/2] Enable mingw build for virt-viewer project

[Daniel P . Berrangé]

On Fri, Apr 13, 2018 at 02:36:57PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-04-12 at 15:28 +0100, Daniel P. Berrangé wrote:
> [...]
> > +  mingw32-gtk-vnc:
> > +FedoraRawhide: mingw32-gtk-vnc
> 
> This (and the corresponding mingw64 entry) will drag in the version
> of the library based on GTK+ 2 rather than the one based on GTK+ 3,
> which is not what we want. It should look like
> 
>   mingw32-gtk-vnc:
> FedoraRawhide: mingw32-gtk-vnc2
> 
> Because of the missing dependencies mentioned below, you also need
> 
>   mingw32-hicolor-icon-theme:
> FedoraRawhide: mingw32-hicolor-icon-theme

There's no such package AFAIK

> 
>   mingw32-spice-glib:
> FedoraRawhide: mingw32-spice-glib

That's not required - it is a dependency of spice-gtk3

> 
> plus of course the mingw64 equivalents.
> 
> [...]
> > diff --git a/guests/vars/projects/virt-viewer.yml 
> > b/guests/vars/projects/virt-viewer.yml
> > index 6f3dbf9..85d1589 100644
> > --- a/guests/vars/projects/virt-viewer.yml
> > +++ b/guests/vars/projects/virt-viewer.yml
> > @@ -6,5 +6,29 @@ packages:
> >- intltool
> >- libgovirt
> >- libxml2
> > +  - mingw32-adwaita-icon-theme
> > +  - mingw32-glib2
> > +  - mingw32-glib-networking
> > +  - mingw32-gstreamer1-plugins-bad-free
> > +  - mingw32-gstreamer1-plugins-good
> > +  - mingw32-gtk3
> > +  - mingw32-gtk-vnc
> > +  - mingw32-libgovirt
> > +  - mingw32-libusbx
> > +  - mingw32-rest
> > +  - mingw32-spice-gtk3
> > +  - mingw32-usbredir
> > +  - mingw64-adwaita-icon-theme
> > +  - mingw64-glib2
> > +  - mingw64-glib-networking
> > +  - mingw64-gstreamer1-plugins-bad-free
> > +  - mingw64-gstreamer1-plugins-good
> > +  - mingw64-gtk3
> > +  - mingw64-gtk-vnc
> > +  - mingw64-libgovirt
> > +  - mingw64-libusbx
> > +  - mingw64-rest
> > +  - mingw64-spice-gtk3
> > +  - mingw64-usbredir
> >- spice-gtk3
> >- xmllint
> 
> Same as the previous patch, you need to include also the packages
> MinGW builds for libvirt and libvirt-glib already depend on.

Why would we want to duplicate that ?  This job depends on tje libvirt
job, so that will have already pulled in all those RPMs. Listing them
again just creates the opportunity for the many duplicated listings to
get out of date.

> 
> Additionally, a couple more (optional?) dependencies can be
> discovered thanks to the mingw-virt-viewer.spec.in file included
> in the repository.
> 
> The full list should look like:
> 
>   - mingw32-adwaita-icon-theme
>   - mingw32-glib2
>   - mingw32-curl
>   - mingw32-dbus
>   - mingw32-dlfcn
>   - mingw32-gcc
>   - mingw32-gettext
>   - mingw32-glib-networking
>   - mingw32-glib2
>   - mingw32-gstreamer1-plugins-bad-free
>   - mingw32-gstreamer1-plugins-good
>   - mingw32-gtk3
>   - mingw32-gtk-vnc
>   - mingw32-gtk3
>   - mingw32-hicolor-icon-theme
>   - mingw32-libgovirt
>   - mingw32-libssh2
>   - mingw32-libusbx
>   - mingw32-libxml2
>   - mingw32-pkg-config
>   - mingw32-portablexdr
>   - mingw32-readline
>   - mingw32-rest
>   - mingw32-spice-glib
>   - mingw32-spice-gtk3
>   - mingw32-usbredir
>   - mingw64-adwaita-icon-theme
>   - mingw64-glib2
>   - mingw64-curl
>   - mingw64-dbus
>   - mingw64-dlfcn
>   - mingw64-gcc
>   - mingw64-gettext
>   - mingw64-glib-networking
>   - mingw64-glib2
>   - mingw64-gstreamer1-plugins-bad-free
>   - mingw64-gstreamer1-plugins-good
>   - mingw64-gtk3
>   - mingw64-gtk-vnc
>   - mingw64-gtk3
>   - mingw64-hicolor-icon-theme
>   - mingw64-libgovirt
>   - mingw64-libssh2
>   - mingw64-libusbx
>   - mingw64-libxml2
>   - mingw64-pkg-config
>   - mingw64-portablexdr
>   - mingw64-readline
>   - mingw64-rest
>   - mingw64-spice-glib
>   - mingw64-spice-gtk3
>   - mingw64-usbredir
> 
> The icotool command also becomes mandatory rather than optional
> when building with MinGW, but I have already posted a separate
> patch that takes care of the issue[1] so you should not concern
> yourself with that here.
> 
> Provided you've taken care of all of the above,
> 
>   Reviewed-by: Andrea Bolognani 
> 
> 
> [1] https://www.redhat.com/archives/libvir-list/2018-April/msg01164.html
> -- 
> Andrea Bolognani / Red Hat / Virtualization

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH v3 00/20] More APIs for Domain Interface

[Pavel Hrdina]

On Fri, Apr 13, 2018 at 01:15:11PM +0200, Katerina Koukiou wrote:
> Changes from v2:
> Adjusted to reviews.
> 
> Katerina Koukiou (20):
>   Implement Setter for Autostart property for Domain interface
>   Implement SchedulerType property for Domain Interface
>   Implement MemoryStats for Domain Interface
>   Implement AttachDevice method for Domain Interface
>   Implement DetachDevice method for Domain Interface
>   Implement GetJobInfo method for Domain interface
>   Implement AbortJob for Domain interface
>   Implement MigrateSetMaxDowntime method for Domain interface
>   Implement MigrateGetMaxDowntime method for Domain Interface
>   Implement ManagedSave method for Domain Interface
>   Implement HasManagedSaveImage method for Domain Interface
>   Implement ManagedSaveRemove method for Domain Interface
>   Implement SetVcpus method for Domain Interface
>   Implement GetMemoryParameters method for Domain Interface
>   Implement GetBlkioParameters method for domain Interface
>   Implement Updated property for Domain Interface
>   Implement MigrateGetMaxSpeed method for Domain Interface
>   Implement MigrateSetMaxSpeed method for Domain Interface
>   Implement SetMemory method for Domain Interface
>   Implement GetSchedulerParameters method for Domain Interface

There are some small issues along the series but you can fix it before
pushing, no need to repost.

Nice series, a lot of new domain APIs!

Reviewed-by: Pavel Hrdina 


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH jenkins-ci 1/2] Enable mingw build for libvirt-glib project

[Daniel P . Berrangé]

On Fri, Apr 13, 2018 at 02:17:45PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-04-12 at 15:28 +0100, Daniel P. Berrangé wrote:
> > diff --git a/guests/vars/projects/libvirt-glib.yml 
> > b/guests/vars/projects/libvirt-glib.yml
> > index 13a5128..bb21ae0 100644
> > --- a/guests/vars/projects/libvirt-glib.yml
> > +++ b/guests/vars/projects/libvirt-glib.yml
> > @@ -5,4 +5,6 @@ packages:
> >- gtk-doc
> >- intltool
> >- libxml2
> > +  - mingw32-glib2
> > +  - mingw64-glib2
> >- vala
> 
> You're missing a lot of packages here, probably because they are
> already used for the libvirt MinGW build and you didn't reset your
> test machine between builds, thus masking the issue.

No I didn't miss them, I only listed stuff that's unique to
libvirt-glib - duplicating everything used by libvirt mingw
builds, under libvirt-glib mingw builds is not required, as
they're already present, and most are not even used by
libvirt-glib

> 
> The list of additional packages should look like:
> 
>   - mingw32-curl
>   - mingw32-dbus
>   - mingw32-dlfcn
>   - mingw32-gcc
>   - mingw32-gettext
>   - mingw32-glib2
>   - mingw32-gnutls
>   - mingw32-libssh2
>   - mingw32-libxml2
>   - mingw32-pkg-config
>   - mingw32-portablexdr
>   - mingw64-curl
>   - mingw64-dbus
>   - mingw64-dlfcn
>   - mingw64-gcc
>   - mingw64-gettext
>   - mingw64-glib2
>   - mingw64-gnutls
>   - mingw64-libssh2
>   - mingw64-libxml2
>   - mingw64-pkg-config
>   - mingw64-portablexdr



> 
> With that fixed,
> 
>   Reviewed-by: Andrea Bolognani 
> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH v3 18/20] Implement MigrateSetMaxSpeed method for Domain Interface

[Pavel Hrdina]

On Fri, Apr 13, 2018 at 01:15:29PM +0200, Katerina Koukiou wrote:
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Domain.xml |  6 ++
>  src/domain.c| 25 +
>  2 files changed, 31 insertions(+)

[...]

> +static void
> +virtDBusDomainMigrateSetMaxSpeed(GVariant *inArgs,
> + GUnixFDList *inFDs G_GNUC_UNUSED,
> + const gchar *objectPath,
> + gpointer userData,
> + GVariant **outArgs G_GNUC_UNUSED,
> + GUnixFDList **outFDs G_GNUC_UNUSED,
> + GError **error)
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virDomain) domain = NULL;
> +gulong bandwidth;
> +guint flags;
> +
> +g_variant_get(inArgs, "(tu)", , );
> +
> +domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
> +if (!domain)
> +return;
> +
> +if (virDomainMigrateSetMaxSpeed(domain, bandwidth, flags) < 0)
> +return virtDBusUtilSetLastVirtError(error);

Here you missed removing 'return'.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC v2] external (pull) backup API

[Nikolay Shirokovskiy]

On 13.04.2018 12:07, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 03:01:22PM +0300, Nikolay Shirokovskiy wrote:
>> *Temporary snapshot API*
>>
>> In previous version it is called 'Fleece API' after qemu terms and I'll still
>> use BlockSnapshot prefix for commands as in previous RFC instead of
>> TmpSnapshots which I inclined more now.
>>
>> virDomainBlockSnapshotPtr
>> virDomainBlockSnapshotCreateXML(virDomainPtr domain,
>> const char *xmlDesc,
>> unsigned int flags);
>>
>> virDomainBlockSnapshotDelete(virDomainBlockSnapshotPtr snapshot,
>>  unsigned int flags);
>>
>> virDomainBlockSnapshotList(virDomainPtr domain,
>>virDomainBlockSnapshotPtr **snaps,
>>unsigned int flags);
>>
>> virDomainBlockSnapshotGetXMLDesc(virDomainBlockSnapshotPtr snapshot,
>>  unsigned int flags);
>>
>> virDomainBlockSnapshotPtr
>> virDomainBlockSnapshotLookupByName(virDomainPtr domain,
>>const char *name,
>>unsigned int flags);
>>
>> Here is an example of snapshot xml description:
>>
>> 
>> d068765e-8b50-4d74-9b72-1e55c663cbf8
>> 
>> 
> 
> Can we just call this which is how we name
> things in normal  elements.  'fleece' in particular is an awful
> name giving no indication of what is being talked about unless you've
> already read the QEMU low levels, so I'd rather we don't use the word
> "fleece" anywhere in API or XML or docs at the libvirt level.

It would be easiest thing to do) Let me explain.

"source" in plain external snapshots for example feels awkward to me. It is 
read like "make a
snapshot of disk sda which source file is like that". IMHO it would be better 
if xml is read 
like "make a snapshot of disk sda and put it into dest|target file. Then for 
block snapshot xml would read like "make a snapshot 
of disk sda and put fleece there". Fleece may be a new term but it only costs 
one-two 
sentences to define it. And it is better to have this definition so that user 
knows what the nature of this image,
so that user have correct assumptions on image size, lifetime... If fleece word 
itself unfortunate
then we can coin another one.

Looks like "source" takes root in domain xml where it reads well.

> 
>> 
>> 
>> 
>> 
>> 
> 
>>
>> Temporary snapshots are indepentent thus they are not organized in tree 
>> structure
>> as usual snapshots, so the 'list snapshots' and 'lookup' function will 
>> suffice.
>>
>> Qemu can track what disk's blocks are changed from snapshotted state so on 
>> next
>> backup client can backup only changed blocks. virDomainBlockSnapshotCreateXML
>> accepts VIR_DOMAIN_BLOCK_SNAPSHOT_CREATE_CHECKPOINT flag to turn this option
>> for snapshot which means to track changes from this particular snapshot. I 
>> used
>> checkpoint term and not [dirty] bitmap because many qemu dirty bitmaps are 
>> used
>> to provide changed blocks from the given checkpoint to current snapshot in
>> current implementation (see *Implemenation* section for more details). Also
>> bitmap keeps block changes and thus itself changes in time and checkpoint is
>> a more statical terms means you can query changes from that moment in time.
>>
>> Checkpoints are visible in active domain xml:
>>
>> 
>>   ..
>>   
>>   
>>   
>>   
> 
> How are these checkpoints recorded / associated to actual storage
> on disk ? What happens across restarts of the VM if this is only
> in the live XML.
> 

Checkpoints reside in qcow2 image entirely. Internally they
represented as dirty bitmaps with specially constructed names
(name scheme is explained in *checkpoints* subsection of
*implementation details* section).

After VM restart checkpoints are reread from qemu.

Hmm, it strikes me that it is good idea to provide checkpoints info
in domain stats rather then domain xml just like image size etc.

On the other hand disk backing chain is expanded in live xml so
having checkpoints in domain xml not too unexpected...

>>   ..
>> 
> 
> 
>> *Block export API*
>>
>> I guess it is natural to treat qemu NBD server as a domain device. So
> 
> A domain device is normally something that is related to the guest
> machine ABI. This is entirely invisible to the guest, just a backend
> concept, so this isn't really a natural fit as a domain device.

I have VNC in mind as a precedent.

> 
>> we can use virDomainAttachDeviceFlags/virDomainDetachDeviceFlags API to 
>> start/stop NBD
>> server and virDomainUpdateDeviceFlags to add/delete disks to be exported.
>> While I'm have no doubts about start/stop operations using 
>> virDomainUpdateDeviceFlags 
>> looks a bit inconvinient so I decided to add a pair of API functions just
>> to add/delete disks to be exported:
>>
>> int
>> virDomainBlockExportStart(virDomainPtr domain,
>>

Re: [libvirt] [PATCH v2 22/73] qemu: Hide cfg inside qemuMigrationParamsEnableTLS

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:12PM +0200, Jiri Denemark wrote:

There's no real reason for qemuMigrationParamsEnableTLS to require the
callers to pass a valid virQEMUDriverConfigPtr, it can just call
virQEMUDriverGetConfig.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c| 10 ++
src/qemu/qemu_migration_params.c | 12 
src/qemu/qemu_migration_params.h |  1 -
3 files changed, 10 insertions(+), 13 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv2] Remove redundant virFileIsExecutable check

[Michal Privoznik]

On 04/13/2018 09:34 AM, Radostin Stoyanov wrote:
> Remove unnecessary virFileIsExecutable check after virFindFileInPath.
> Since commit 9ae992f, virFindFileInPath will reject non-executables.
> 
> 9ae992f24353d6506f570fc9dd58355b165e4472
> virFindFileInPath: only find executable non-directory
> 
> Signed-off-by: Radostin Stoyanov 
> ---
>  src/bhyve/bhyve_capabilities.c | 4 
>  src/qemu/qemu_capabilities.c   | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)

I've already pushed your previous patch.

> 
> diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
> index 381cc0de3..e13085b1d 100644
> --- a/src/bhyve/bhyve_capabilities.c
> +++ b/src/bhyve/bhyve_capabilities.c
> @@ -179,8 +179,6 @@ virBhyveProbeGrubCaps(virBhyveGrubCapsFlags *caps)
>  binary = virFindFileInPath("grub-bhyve");
>  if (binary == NULL)
>  goto out;
> -if (!virFileIsExecutable(binary))
> -goto out;
>  
>  cmd = virCommandNew(binary);
>  virCommandAddArg(cmd, "--help");
> @@ -315,8 +313,6 @@ virBhyveProbeCaps(unsigned int *caps)
>  binary = virFindFileInPath("bhyve");
>  if (binary == NULL)
>  goto out;
> -if (!virFileIsExecutable(binary))
> -goto out;
>  
>  if ((ret = bhyveProbeCapsRTC_UTC(caps, binary)))
>  goto out;
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 27180e850..13c6c85d8 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -653,7 +653,7 @@ virQEMUCapsFindBinary(const char *format,
>  
>  ret = virFindFileInPath(binary);
>  VIR_FREE(binary);
> -if (ret && virFileIsExecutable(ret))
> +if (ret)
>  goto out;
>  
>  VIR_FREE(ret);
> 

This whole function can be simplified. Just look at the diff I squashed in.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 20/20] Implement GetSchedulerParameters method for Domain Interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 36 
 2 files changed, 42 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index dc1df26..98e2873 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -87,6 +87,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetSchedulerParametersFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainListGetStats"/>
diff --git a/src/domain.c b/src/domain.c
index 72d5775..ce19e89 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -549,6 +549,41 @@ virtDBusDomainGetMemoryParameters(GVariant *inArgs,
 *outArgs = g_variant_new_tuple(, 1);
 }
 
+static void
+virtDBusDomainGetSchedulerParameters(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+g_autofree virTypedParameterPtr params = NULL;
+gint nparams;
+guint flags;
+GVariant *grecords;
+g_autofree gchar *ret = NULL;
+
+g_variant_get(inArgs, "(u)", );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+ret = virDomainGetSchedulerType(domain, );
+if (ret && nparams != 0) {
+params = g_new0(virTypedParameter, nparams);
+if (virDomainGetSchedulerParametersFlags(domain, params, , 0))
+return virtDBusUtilSetLastVirtError(error);
+}
+
+grecords = virtDBusUtilTypedParamsToGVariant(params, nparams);
+
+*outArgs = g_variant_new_tuple(, 1);
+}
+
 G_DEFINE_AUTOPTR_CLEANUP_FUNC(virDomainStatsRecordPtr, 
virDomainStatsRecordListFree);
 
 static void
@@ -1062,6 +1097,7 @@ static virtDBusGDBusMethodTable 
virtDBusDomainMethodTable[] = {
 { "GetBlkioParameters", virtDBusDomainGetBlkioParameters },
 { "GetJobInfo", virtDBusDomainGetJobInfo },
 { "GetMemoryParameters", virtDBusDomainGetMemoryParameters },
+{ "GetSchedulerParameters", virtDBusDomainGetSchedulerParameters },
 { "GetStats", virtDBusDomainGetStats },
 { "GetVcpus", virtDBusDomainGetVcpus },
 { "GetXMLDesc", virtDBusDomainGetXMLDesc },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3] qemu: add virQEMUBuildBufferEscapeComma in qemu_command.c

[John Ferlan]

On 04/12/2018 05:40 PM, Sukrit Bhatnagar wrote:
> Incremental patches do look better. Just to make sure I am on the right
> track, I have some queries.
> 
> I have to apply the changes one function at a time, and these changes
> will be the same ones I made in the v2 and v3 patches, right?

yes, combined

> If that is the case, do I need the next patch to be v4 or can the series
> of patches start from v1?

v4 and in this case you'd generate a cover letter along with your git
send-email to describe the changes and can then point at the v2 and v3
of the series for which the v4 will combine the changes.

> I can start afresh with the patches and this might save some confusion
> later.
> 
> Thanks.
> 

John

FWIW: top posting is another one of those "things" not to do in a
technical news group

[...]

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 26/73] qemu: Set migration caps via migration params APIs

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:16PM +0200, Jiri Denemark wrote:

Migration capabilities are closely related to migration parameters and
it makes sense to keep them in a single data structure. Similarly to
migration parameters the capabilities are all send to QEMU at once in
qemuMigrationParamsApply, all other APIs operate on the
qemuMigrationParams structure.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c| 100 ++-
src/qemu/qemu_migration.h|   7 ---
src/qemu/qemu_migration_params.c |  99 +++---
src/qemu/qemu_migration_params.h |  11 
4 files changed, 107 insertions(+), 110 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 17/20] Implement MigrateGetMaxSpeed method for Domain Interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 28 
 2 files changed, 34 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 21eb162..eec9dcb 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -134,6 +134,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateGetMaxSpeed"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateSetMaxDowntime"/>
diff --git a/src/domain.c b/src/domain.c
index 5a2dbfb..46a8c03 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -780,6 +780,33 @@ virtDBusDomainMigrateGetMaxDowntime(GVariant *inArgs,
 *outArgs = g_variant_new("(t)", downtime);
 }
 
+static void
+virtDBusDomainMigrateGetMaxSpeed(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+gulong bandwidth;
+guint flags;
+
+g_variant_get(inArgs, "(u)", );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainMigrateGetMaxSpeed(domain, , flags) < 0)
+return virtDBusUtilSetLastVirtError(error);
+
+*outArgs = g_variant_new("(t)", bandwidth);
+}
+
 static void
 virtDBusDomainMigrateSetMaxDowntime(GVariant *inArgs,
 GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -994,6 +1021,7 @@ static virtDBusGDBusMethodTable 
virtDBusDomainMethodTable[] = {
 { "ManagedSaveRemove", virtDBusDomainManagedSaveRemove },
 { "MemoryStats", virtDBusDomainMemoryStats },
 { "MigrateGetMaxDowntime", virtDBusDomainMigrateGetMaxDowntime },
+{ "MigrateGetMaxSpeed", virtDBusDomainMigrateGetMaxSpeed },
 { "MigrateSetMaxDowntime", virtDBusDomainMigrateSetMaxDowntime },
 { "Reboot", virtDBusDomainReboot },
 { "Reset", virtDBusDomainReset },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 25/73] qemu: Introduce qemuMonitorSetMigrationCapabilities

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:15PM +0200, Jiri Denemark wrote:

Our current monitor API forces the caller to call
migrate-set-capabilities QMP command for each capability separately,
which is quite suboptimal. Let's add a new API for setting all
capabilities at once.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_monitor.c  | 19 +++
src/qemu/qemu_monitor.h  |  3 ++
src/qemu/qemu_monitor_json.c | 63 
src/qemu/qemu_monitor_json.h |  3 ++
4 files changed, 88 insertions(+)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 19/20] Implement SetMemory method for Domain Interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 26 ++
 2 files changed, 32 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 838ebed..dc1df26 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -166,6 +166,12 @@
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainResume"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetMemoryFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetVcpusFlags"/>
diff --git a/src/domain.c b/src/domain.c
index b7bc10c..72d5775 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -923,6 +923,31 @@ virtDBusDomainResume(GVariant *inArgs G_GNUC_UNUSED,
 virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainSetMemory(GVariant *inArgs,
+GUnixFDList *inFDs G_GNUC_UNUSED,
+const gchar *objectPath,
+gpointer userData,
+GVariant **outArgs G_GNUC_UNUSED,
+GUnixFDList **outFDs G_GNUC_UNUSED,
+GError **error)
+
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+gulong memory;
+guint flags;
+
+g_variant_get(inArgs, "(tu)", , );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainSetMemoryFlags(domain, memory, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
 static void
 virtDBusDomainSetVcpus(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -1052,6 +1077,7 @@ static virtDBusGDBusMethodTable 
virtDBusDomainMethodTable[] = {
 { "Reset", virtDBusDomainReset },
 { "Resume", virtDBusDomainResume },
 { "SetVcpus", virtDBusDomainSetVcpus },
+{ "SetMemory", virtDBusDomainSetMemory },
 { "Shutdown", virtDBusDomainShutdown },
 { "Suspend", virtDBusDomainSuspend },
 { "Undefine", virtDBusDomainUndefine },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 16/20] Implement Updated property for Domain Interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  4 
 src/domain.c| 22 ++
 test/test_domain.py |  1 +
 3 files changed, 27 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 243a978..21eb162 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -36,6 +36,10 @@
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetState"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainIsUpdated"/>
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetUUIDString"/>
diff --git a/src/domain.c b/src/domain.c
index 9cf691a..5a2dbfb 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -266,6 +266,27 @@ virtDBusDomainGetState(const gchar *objectPath,
 *value = g_variant_new("s", string);
 }
 
+static void
+virtDBusDomainGetUpdated(const gchar *objectPath,
+ gpointer userData,
+ GVariant **value,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+gint updated;
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+updated = virDomainIsUpdated(domain);
+if (updated < 0)
+return virtDBusUtilSetLastVirtError(error);
+
+*value = g_variant_new("b", !!updated);
+}
+
 static void
 virtDBusDomainGetUUID(const gchar *objectPath,
   gpointer userData,
@@ -951,6 +972,7 @@ static virtDBusGDBusPropertyTable 
virtDBusDomainPropertyTable[] = {
 { "Persistent", virtDBusDomainGetPersistent, NULL },
 { "SchedulerType", virtDBusDomainGetSchedulerType, NULL},
 { "State", virtDBusDomainGetState, NULL },
+{ "Updated", virtDBusDomainGetUpdated, NULL },
 { "UUID", virtDBusDomainGetUUID, NULL },
 { 0 }
 };
diff --git a/test/test_domain.py b/test/test_domain.py
index 31e09bf..f2ae215 100755
--- a/test/test_domain.py
+++ b/test/test_domain.py
@@ -20,6 +20,7 @@ class TestDomain(libvirttest.BaseTestClass):
 isinstance(props['SchedulerType'][0], dbus.String),
 isinstance(props['SchedulerType'][1], dbus.Int32)])
 assert isinstance(props['State'], dbus.String)
+assert isinstance(props['Updated'], dbus.Boolean)
 assert isinstance(props['UUID'], dbus.String)
 
 # Call all methods except Reset and GetStats, because the test backend
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 15/73] qemu: Pass job object to qemuProcessRecoverMigration{In, Out}

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:05PM +0200, Jiri Denemark wrote:

Currently, only job->phase is passed and both APIs will need to look at
more details about the job.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_process.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 13/20] Implement SetVcpus method for Domain Interface

[Katerina Koukiou]

Move testing of [Get,Set]Vcpus to seperate test.

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 26 ++
 test/test_domain.py |  9 +++--
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index f300b59..41814c7 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -138,6 +138,12 @@
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainResume"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetVcpusFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainShutdownFlags"/>
diff --git a/src/domain.c b/src/domain.c
index 5f83b33..9b8779b 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -781,6 +781,31 @@ virtDBusDomainResume(GVariant *inArgs G_GNUC_UNUSED,
 virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainSetVcpus(GVariant *inArgs,
+   GUnixFDList *inFDs G_GNUC_UNUSED,
+   const gchar *objectPath,
+   gpointer userData,
+   GVariant **outArgs G_GNUC_UNUSED,
+   GUnixFDList **outFDs G_GNUC_UNUSED,
+   GError **error)
+
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+guint vcpus;
+guint flags;
+
+g_variant_get(inArgs, "(uu)", , );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainSetVcpusFlags(domain, vcpus, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
 static void
 virtDBusDomainShutdown(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -879,6 +904,7 @@ static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] 
= {
 { "Reboot", virtDBusDomainReboot },
 { "Reset", virtDBusDomainReset },
 { "Resume", virtDBusDomainResume },
+{ "SetVcpus", virtDBusDomainSetVcpus },
 { "Shutdown", virtDBusDomainShutdown },
 { "Suspend", virtDBusDomainSuspend },
 { "Undefine", virtDBusDomainUndefine },
diff --git a/test/test_domain.py b/test/test_domain.py
index 45a99f9..31e09bf 100755
--- a/test/test_domain.py
+++ b/test/test_domain.py
@@ -27,8 +27,6 @@ class TestDomain(libvirttest.BaseTestClass):
 
 xml = domain.GetXMLDesc(0)
 assert isinstance(xml, dbus.String)
-vcpus = domain.GetVcpus(0)
-assert isinstance(vcpus, dbus.UInt32)
 
 domain.Reboot(0)
 domain.Shutdown(0)
@@ -123,5 +121,12 @@ class TestDomain(libvirttest.BaseTestClass):
 
 self.main_loop()
 
+def test_domain_vcpus(self):
+obj, domain = self.domain()
+vcpus_expected = 2
+domain.SetVcpus(vcpus_expected, 0)
+assert domain.GetVcpus(0) == dbus.Int32(vcpus_expected)
+
+
 if __name__ == '__main__':
 libvirttest.run()
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH v2 21/22] Implement SetMemory method for Domain Interface

[Pavel Hrdina]

On Thu, Apr 12, 2018 at 04:33:00PM +0200, Katerina Koukiou wrote:
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Domain.xml |  6 ++
>  src/domain.c| 26 ++
>  2 files changed, 32 insertions(+)

[...]

> +static void
> +virtDBusDomainSetMemory(GVariant *inArgs,
> +GUnixFDList *inFDs G_GNUC_UNUSED,
> +const gchar *objectPath,
> +gpointer userData,
> +GVariant **outArgs G_GNUC_UNUSED,
> +GUnixFDList **outFDs G_GNUC_UNUSED,
> +GError **error)
> +
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virDomain) domain = NULL;
> +gulong memory;
> +guint flags;
> +
> +g_variant_get(inArgs, "(tu)", , );
> +
> +domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
> +if (!domain)
> +return;
> +
> +if (virDomainSetMemoryFlags(domain, memory, flags) < 0)
> +return virtDBusUtilSetLastVirtError(error);

No need to use 'return'.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 13/73] qemu: Store original migration params in job

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:03PM +0200, Jiri Denemark wrote:

Any job which touches migration parameters will first store their
original values (i.e., QEMU defaults) to qemuDomainJobObj to make it
easier to reset them back once the job finishes.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_domain.c   |  3 +++
src/qemu/qemu_domain.h   |  3 +++
src/qemu/qemu_migration.c|  9 
src/qemu/qemu_migration_params.c | 38 
src/qemu/qemu_migration_params.h |  5 +
5 files changed, 58 insertions(+)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 09/73] qemu: Drop qemuMigrationParamsClear

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:40:59PM +0200, Jiri Denemark wrote:

It's no longer used since we do not store the struct on a stack anymore.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration_params.c | 12 +---
src/qemu/qemu_migration_params.h |  3 ---
2 files changed, 1 insertion(+), 14 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 19/73] qemu: Rename qemuMigrationParamsSetEmptyTLS

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:09PM +0200, Jiri Denemark wrote:

The new name is qemuMigrationParamsDisableTLS.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c| 4 ++--
src/qemu/qemu_migration_params.c | 6 +++---
src/qemu/qemu_migration_params.h | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 12/73] qemu: Reset migration parameters in qemuMigrationSrcCleanup

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:02PM +0200, Jiri Denemark wrote:

When connection to the client which controls a non-p2p migration gets
closed between Perform and Confirm phase, we don't know whether the
domain was successfully migrated or not. Thus, we have to leave the
domain paused and just cleanup the migration job and reset migration
parameters.

Previously we didn't reset the parameters and future save or snapshot
operations would see wrong environment (and could fail because of it) in
case the domain stayed running on the source host.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.c | 1 +
1 file changed, 1 insertion(+)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 18/73] qemu: Drop qemuMigrationParamsCheckTLSCreds

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:08PM +0200, Jiri Denemark wrote:

The function checks whether QEMU supports TLS migration and stores the
original value of tls-creds parameter to priv->migTLSAlias. This is no
longer needed because we already have the original value stored in
priv->migParams.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_domain.c   |  2 --
src/qemu/qemu_domain.h   |  4 ---
src/qemu/qemu_migration.c|  8 ++---
src/qemu/qemu_migration_params.c | 62 ++--
src/qemu/qemu_migration_params.h |  4 +--
5 files changed, 6 insertions(+), 74 deletions(-)



Worth it.

Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 08/20] Implement MigrateSetMaxDowntime method for Domain interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 25 +
 2 files changed, 31 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 074dd62..c3c64fa 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -96,6 +96,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateSetMaxDowntime"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainReboot"/>
diff --git a/src/domain.c b/src/domain.c
index b55a615..88e6aaa 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -585,6 +585,30 @@ virtDBusDomainMemoryStats(GVariant *inArgs,
 *outArgs = g_variant_new_tuple(, 1);
 }
 
+static void
+virtDBusDomainMigrateSetMaxDowntime(GVariant *inArgs,
+GUnixFDList *inFDs G_GNUC_UNUSED,
+const gchar *objectPath,
+gpointer userData,
+GVariant **outArgs G_GNUC_UNUSED,
+GUnixFDList **outFDs G_GNUC_UNUSED,
+GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+gulong downtime;
+guint flags;
+
+g_variant_get(inArgs, "(tu)", , );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainMigrateSetMaxDowntime(domain, downtime, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
 static void
 virtDBusDomainReboot(GVariant *inArgs,
  GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -743,6 +767,7 @@ static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] 
= {
 { "GetVcpus", virtDBusDomainGetVcpus },
 { "GetXMLDesc", virtDBusDomainGetXMLDesc },
 { "MemoryStats", virtDBusDomainMemoryStats },
+{ "MigrateSetMaxDowntime", virtDBusDomainMigrateSetMaxDowntime },
 { "Reboot", virtDBusDomainReboot },
 { "Reset", virtDBusDomainReset },
 { "Resume", virtDBusDomainResume },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC v2] external (pull) backup API

[Nikolay Shirokovskiy]

On 13.04.2018 02:53, John Snow wrote:

>>
> First a few facts about qemu dirty bitmaps.
>
> Bitmap can be either in active or disable state. In disabled state it 
> does not
> get changed on guest writes. And oppositely in active state it tracks 
> guest
> writes. This implementation uses approach with only one active bitmap at
> a time. This should reduce guest write penalties in the presence of
> checkpoints. So on first snapshot we create bitmap B_1. Now it tracks 
> changes
> from the snapshot 1. On second snapshot we create bitmap B_2 and disable 
> bitmap
> B1 and so on. Now bitmap B1 keep changes from snaphost 1 to snapshot 2, B2
> - changes from snaphot 2 to snapshot 3 and so on. Last bitmap is active 
> and
> gets most disk change after latest snapshot.
>>>
>>> So you are trying to optimize away write penalties if you have, say, ten
>>> bitmaps representing checkpoints so we don't have to record all new
>>> writes to all ten.
>>>
>>> This makes sense, and I would have liked to formalize the concept in
>>> QEMU, but response to that idea was very poor at the time.
>>>
>>> Also my design was bad :)
>>>
>
> Getting changed blocks bitmap from some checkpoint in past till current 
> snapshot
> is quite simple in this scheme. For example if the last snapshot is 7 then
> to get changes from snapshot 3 to latest snapshot we need to merge 
> bitmaps B3,
> B4, B4 and B6. Merge is just logical OR on bitmap bits.
>
> Deleting a checkpoint somewhere in the middle of checkpoint sequence 
> requires
> merging correspondent bitmap to the previous bitmap in this scheme.
>
>>>
>>> Previous, or next?
>>
>> In short previous.
>>
>>>
>>> Say we've got bitmaps (in chronological order from oldest to newest)
>>>
>>> A B C D E F G H
>>>
>>> and we want to delete bitmap (or "checkpoint") 'C':
>>>
>>> A B   D E F G H
>>>
>>> the bitmap representing checkpoint 'D' should now contain the bits that
>>> used to be in 'C', right? That way all the checkpoints still represent
>>> their appropriate points in time.
>>
>> I merge to previous due to definition above. "A" contains changes from
>> point in time A to point in time B an so no. So if you delete C in
>> order for B to keep changes from point in time B to point in time D
>> (next in checkpoint chain) you need merge C to B.
>>
> 
> I'm not sure the way it's explained here makes sense to me, but
> Vladimir's explanation does.
> 
>>>
>>>
>>> The only problem comes when you delete a checkpoint on the end and the
>>> bits have nowhere to go:
>>>
>>> A B C
>>>
>>> A B _
>>>
>>> In this case you really do lose a checkpoint -- but depending on how we
>>> annotate this, it may or may not be possible to delete the most recent
>>> checkpoint. Let's assume that the currently active bitmap that doesn't
>>> represent *any* point in time yet (because it's still active and
>>> recording new writes) is noted as 'X':
>>>
>>> A B C X
>>>
>>> If we delete C now, then, that bitmap can get re-merged into the *active
>>> bitmap* X:
>>>
>>> A B _ X
>>
>> You can delete any bitmap (and accordingly any checkpoint). If checkpoint
>> is last we just merge last bitmap to previous and additioanlly make the
>> previous bitmap active.
>>
>>>
> We use persitent bitmaps in the implementation. This means upon qemu 
> process
> termination bitmaps are saved in disks images metadata and restored back 
> on
> qemu process start. This makes checkpoint a persistent property that is we
> keep them across domain start/stops. Qemu does not try hard to keep 
> bitmaps.
> If upon save something goes wrong bitmap is dropped. The same is applied 
> to the
> migration process too. For backup process it is not critical. If we don't
> discover a checkpoint we always can make a full backup. Also qemu 
> provides no
> special means to track order of bitmaps. These facts are critical for
> implementation with one active bitmap at a time. We need right order of 
> bitmaps upon
> merge - for snapshot N and block changes from snanpshot K, K < N to N we 
> need
> to merge bitmaps B_{K}, ..., B_{N-1}. Also if one of the bitmaps to be 
> merged
> is missing we can't calculate desired block changes too.
>
>>>
>>> Right. A missing bitmap anywhere in the sequence invalidates the entire
>>> sequence.
>>>
> So the implementation encode bitmap order in their names. For snapshot 
> A1, bitmap
> name will be A1, for snapshot A2 bitmap name will be A2^A1 and so on. 
> Using this naming
> encoding upon domain start we can find out bitmap order and check for 
> missing
> ones. This complicates a bit bitmap removing though. For example removing
> a bitmap somewhere in the middle looks like this:
>
> - removing bitmap K (bitmap name is NAME_{K}^NAME_{K-1}
> - create new bitmap named 

Re: [libvirt] [dbus PATCH v2 15/22] Implement SetVcpus method for Domain Interface

[Pavel Hrdina]

On Thu, Apr 12, 2018 at 04:32:54PM +0200, Katerina Koukiou wrote:
> Move testing of [Get,Set]Vcpus to seperate test.
> 
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Domain.xml |  6 ++
>  src/domain.c| 26 ++
>  test/test_domain.py |  9 +++--
>  3 files changed, 39 insertions(+), 2 deletions(-)

[...]

> +static void
> +virtDBusDomainSetVcpus(GVariant *inArgs,
> +   GUnixFDList *inFDs G_GNUC_UNUSED,
> +   const gchar *objectPath,
> +   gpointer userData,
> +   GVariant **outArgs G_GNUC_UNUSED,
> +   GUnixFDList **outFDs G_GNUC_UNUSED,
> +   GError **error)
> +
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virDomain) domain = NULL;
> +guint vcpus;
> +guint flags;
> +
> +g_variant_get(inArgs, "(uu)", , );
> +
> +domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
> +if (!domain)
> +return;
> +
> +if (virDomainSetVcpusFlags(domain, vcpus, flags) < 0)
> +return virtDBusUtilSetLastVirtError(error);

No need to use 'return'.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 15/20] Implement GetBlkioParameters method for domain Interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 36 
 2 files changed, 42 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 36167d8..243a978 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -66,6 +66,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetBlkioParameters"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetJobInfo"/>
diff --git a/src/domain.c b/src/domain.c
index 7ab832b..9cf691a 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -420,6 +420,41 @@ virtDBusDomainDetachDevice(GVariant *inArgs,
 virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainGetBlkioParameters(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+g_autofree virTypedParameterPtr params = NULL;
+gint nparams = 0;
+guint flags;
+gint ret;
+GVariant *grecords;
+
+g_variant_get(inArgs, "(u)", );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+ret = virDomainGetBlkioParameters(domain, NULL, , flags);
+if (ret == 0 && nparams != 0) {
+params = g_new0(virTypedParameter, nparams);
+if (virDomainGetBlkioParameters(domain, params, , flags) < 0)
+return virtDBusUtilSetLastVirtError(error);
+}
+
+grecords = virtDBusUtilTypedParamsToGVariant(params, nparams);
+
+*outArgs = g_variant_new_tuple(, 1);
+}
+
 static void
 virtDBusDomainGetJobInfo(GVariant *inArgs G_GNUC_UNUSED,
  GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -926,6 +961,7 @@ static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] 
= {
 { "Create", virtDBusDomainCreate },
 { "Destroy", virtDBusDomainDestroy },
 { "DetachDevice", virtDBusDomainDetachDevice },
+{ "GetBlkioParameters", virtDBusDomainGetBlkioParameters },
 { "GetJobInfo", virtDBusDomainGetJobInfo },
 { "GetMemoryParameters", virtDBusDomainGetMemoryParameters },
 { "GetStats", virtDBusDomainGetStats },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v3 05/20] Implement DetachDevice method for Domain Interface

[Katerina Koukiou]

This method is not tested for now since the test driver
doesn't suport this API.

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 25 +
 2 files changed, 31 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 9360cbf..5c310ad 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -56,6 +56,12 @@
 value="See 
https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainDestroyFlags"/>
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainDetachDeviceFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainListGetStats"/>
diff --git a/src/domain.c b/src/domain.c
index dccba94..2c3174b 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -366,6 +366,30 @@ virtDBusDomainDestroy(GVariant *inArgs,
 virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainDetachDevice(GVariant *inArgs,
+   GUnixFDList *inFDs G_GNUC_UNUSED,
+   const gchar *objectPath,
+   gpointer userData,
+   GVariant **outArgs G_GNUC_UNUSED,
+   GUnixFDList **outFDs G_GNUC_UNUSED,
+   GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+const gchar *xml;
+guint flags;
+
+g_variant_get(inArgs, "()", , );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainDetachDeviceFlags(domain, xml, flags) < 0)
+virtDBusUtilSetLastVirtError(error);
+}
+
 G_DEFINE_AUTOPTR_CLEANUP_FUNC(virDomainStatsRecordPtr, 
virDomainStatsRecordListFree);
 
 static void
@@ -644,6 +668,7 @@ static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] 
= {
 { "AttachDevice", virtDBusDomainAttachDevice },
 { "Create", virtDBusDomainCreate },
 { "Destroy", virtDBusDomainDestroy },
+{ "DetachDevice", virtDBusDomainDetachDevice },
 { "GetStats", virtDBusDomainGetStats },
 { "GetVcpus", virtDBusDomainGetVcpus },
 { "GetXMLDesc", virtDBusDomainGetXMLDesc },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Remove redundant virFileIsExecutable check

[Radostin Stoyanov]

On 13/04/18 08:35, Michal Privoznik wrote:
> On 04/13/2018 08:01 AM, Radostin Stoyanov wrote:
>> Remove unnecessary virFileIsExecutable check after virFindFileInPath.
>> Since the commit 9ae992f virFindFileInPath will reject non-executables.
>>
>> 9ae992f24353d6506f570fc9dd58355b165e4472
>> virFindFileInPath: only find executable non-directory
>>
>> Signed-off-by: Radostin Stoyanov 
>> ---
>>  src/bhyve/bhyve_capabilities.c | 4 
>>  src/qemu/qemu_capabilities.c   | 2 +-
>>  2 files changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
>> index 381cc0de3..e13085b1d 100644
>> --- a/src/bhyve/bhyve_capabilities.c
>> +++ b/src/bhyve/bhyve_capabilities.c
>> @@ -179,8 +179,6 @@ virBhyveProbeGrubCaps(virBhyveGrubCapsFlags *caps)
>>  binary = virFindFileInPath("grub-bhyve");
>>  if (binary == NULL)
>>  goto out;
>> -if (!virFileIsExecutable(binary))
>> -goto out;
>>  
>>  cmd = virCommandNew(binary);
>>  virCommandAddArg(cmd, "--help");
>> @@ -315,8 +313,6 @@ virBhyveProbeCaps(unsigned int *caps)
>>  binary = virFindFileInPath("bhyve");
>>  if (binary == NULL)
>>  goto out;
>> -if (!virFileIsExecutable(binary))
>> -goto out;
> These twp ^^ make sense.
>
>>  
>>  if ((ret = bhyveProbeCapsRTC_UTC(caps, binary)))
>>  goto out;
>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>> index 27180e850..5ebc72f6f 100644
>> --- a/src/qemu/qemu_capabilities.c
>> +++ b/src/qemu/qemu_capabilities.c
>> @@ -653,7 +653,7 @@ virQEMUCapsFindBinary(const char *format,
>>  
>>  ret = virFindFileInPath(binary);
>>  VIR_FREE(binary);
>> -if (ret && virFileIsExecutable(ret))
>> +if (ret == NULL)
>>  goto out;
>>  
>>  VIR_FREE(ret);
>>
> However, this one does not. With this change, if virFindFileInPath()
> returned something, VIR_FREE() is called over it and NULL is returned.
> So the condition should be reversed. But looking at whole function, it's
> insane code and the if() statement is not needed at all.
>
> I'm squashing this in:
>
> diff --git i/src/qemu/qemu_capabilities.c w/src/qemu/qemu_capabilities.c
> index 5ebc72f6f4..c8488f875d 100644
> --- i/src/qemu/qemu_capabilities.c
> +++ w/src/qemu/qemu_capabilities.c
> @@ -649,16 +649,10 @@ virQEMUCapsFindBinary(const char *format,
>  char *binary = NULL;
>  
>  if (virAsprintf(, format, archstr) < 0)
> -goto out;
> +return NULL;
>  
>  ret = virFindFileInPath(binary);
>  VIR_FREE(binary);
> -if (ret == NULL)
> -goto out;
> -
> -VIR_FREE(ret);
> -
> - out:
>  return ret;
>  }
>
>
> ACKing and pushing.
Thanks :)

Radostin
> Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 10/73] qemu: Move qemuMigrationCompression struct

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:41:00PM +0200, Jiri Denemark wrote:

It provides just another view on some migration parameters so let's move
it close to them. The end goal is to merge compression parameters with
the rest of migration parameters since it doesn't make any sense to
handle them differently.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_migration.h| 20 +---
src/qemu/qemu_migration_params.h | 19 +++
2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/src/qemu/qemu_migration_params.h b/src/qemu/qemu_migration_params.h
index f11315cb9d..bb38d34cd6 100644
--- a/src/qemu/qemu_migration_params.h
+++ b/src/qemu/qemu_migration_params.h
@@ -28,6 +28,25 @@
# include "qemu_conf.h"


+typedef struct _qemuMigrationCompression qemuMigrationCompression;
+typedef qemuMigrationCompression *qemuMigrationCompressionPtr;
+struct _qemuMigrationCompression {
+unsigned long long methods;
+
+bool level_set;
+int level;
+
+bool threads_set;
+int threads;
+
+bool dthreads_set;
+int dthreads;
+
+bool xbzrle_cache_set;
+unsigned long long xbzrle_cache;


I'm still impressed by your ability to pronounce this [0]

Reviewed-by: Ján Tomko 

Jano

[0] https://tools.ietf.org/html/rfc5513#section-2.1


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH v2 10/22] Implement MigrateSetMaxDowntime method for Domain interface

[Pavel Hrdina]

On Thu, Apr 12, 2018 at 04:32:49PM +0200, Katerina Koukiou wrote:
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Domain.xml |  6 ++
>  src/domain.c| 25 +
>  2 files changed, 31 insertions(+)

[...]

> +static void
> +virtDBusDomainMigrateSetMaxDowntime(GVariant *inArgs,
> +GUnixFDList *inFDs G_GNUC_UNUSED,
> +const gchar *objectPath,
> +gpointer userData,
> +GVariant **outArgs G_GNUC_UNUSED,
> +GUnixFDList **outFDs G_GNUC_UNUSED,
> +GError **error)
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virDomain) domain = NULL;
> +guint64 downtime;
> +guint flags;
> +
> +g_variant_get(inArgs, "(tu)", , );
> +
> +domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
> +if (!domain)
> +return;
> +
> +if (virDomainMigrateSetMaxDowntime(domain, downtime, flags) < 0)
> +return virtDBusUtilSetLastVirtError(error);

No need for 'return'.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 08/73] qemu: Allocate struct for migration parameters

[Ján Tomko]

On Wed, Apr 11, 2018 at 04:40:58PM +0200, Jiri Denemark wrote:

It will get a bit more complicated soon and storing it on a stack with
{0} initializer will no longer work. We need a proper constructor.

Signed-off-by: Jiri Denemark 
---
src/qemu/qemu_driver.c   | 20 +++--
src/qemu/qemu_migration.c| 28 ++-
src/qemu/qemu_migration_params.c | 38 +++-
src/qemu/qemu_migration_params.h |  3 +++
4 files changed, 61 insertions(+), 28 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC v2] external (pull) backup API

[Nikolay Shirokovskiy]

On 13.04.2018 03:04, John Snow wrote:
> 
> 
> On 04/12/2018 10:08 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
>> I propose, not to say that bitmap represents a checkpoint. It is simpler
>> to say (and it reflects the reality) that bitmap is a difference between
>> two consecutive checkpoints. And we can say, that active state is some
>> kind of a checkpoint, current point in time.
>>
>> So, we have checkpoints (5* is an active state) which are points in time:
>>
>> 1 2 3 4 5*
>>
> 
> Oh -- the most recent checkpoint there doesn't belong to a ***specific
> time*** yet. It's a floating checkpoint -- it always represents the most
> current version. It's not really a checkpoint at all.
> 
> 1, 2, 3, and 4 however are associated with a specific timestamp though.
> 
>> And bitmaps, first three are disabled, last is enabled:
>>
>> "1->2", "2->3", "3->4", "4->5*"
>>
> 
> OK; so 1->2, 2->3 and 3->4 define deltas between two ***defined***
> points in time.
> 
> 4->5* however is only anchored by one specific point in time, and is
> floating just like the most recent checkpoint is floating.
> 
>> So, remove first checkpoint: just remove bitmap "A->B".
> 
> I assume you mean "1->2" here.
> 
> And... yes, I agree -- if you don't care about your very first
> checkpoint anymore, you can just delete the first bitmap, too.
> 
>> Remove any other checkpoint N: create new bitmap "(N-1)->(N+1)" =
>> merge("(N-1)->N", "N->(N+1)"), drop bitmaps "(N-1)->N" and "N->(N+1)".
> 
> err, okay, so let's say we want to drop checkpoint 3:
> 
> create: "2->4"
> merge: "2->3", "3->4" [and presumably store in "2->4"]
> drop: 2->3, 3->4
> 
> OK, that makes more sense to me. In essence;
> 
> (1) We could consider this 2->3 absorbing 3->4, or
> (2) 3->4 absorbing 2->3
> 
> and in either case it's the same, really.
> 
>> If the latter was active, the new one becomes active. And we cant remove
>> 5* checkpoint, as it is an active state, not an actual checkpoint.
> 
> OK, crystal.
> 
> --js
> 

I prefer not talking of active checkpoint. It is a kind of controversial.
Better just keep in mind that last bitmap is active one. So for checkpoints 1 2 
3 4
we have bitmaps:

1 1->2 2->3 3->4

Note the first bitmap name. When it was created name 2 was unknown so we'd 
better
have this name for the first bitmap. 

Checkpoint 4 can not be used without checkpoint 5 by design to it is not a 
problem
that 3->4 is active.

Nikolay

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH v2 05/22] Implement AttachDevice method for Domain Interface

[Pavel Hrdina]

On Thu, Apr 12, 2018 at 04:32:44PM +0200, Katerina Koukiou wrote:
> This method is not tested for now since the test driver
> doesn't suport this API.
> 
> Signed-off-by: Katerina Koukiou 
> ---
>  data/org.libvirt.Domain.xml |  6 ++
>  src/domain.c| 25 +
>  2 files changed, 31 insertions(+)

[...]

> +static void
> +virtDBusDomainAttachDevice(GVariant *inArgs,
> +   GUnixFDList *inFDs G_GNUC_UNUSED,
> +   const gchar *objectPath,
> +   gpointer userData,
> +   GVariant **outArgs G_GNUC_UNUSED,
> +   GUnixFDList **outFDs G_GNUC_UNUSED,
> +   GError **error)
> +{
> +virtDBusConnect *connect = userData;
> +g_autoptr(virDomain) domain = NULL;
> +const gchar *xml;
> +guint flags;
> +
> +g_variant_get(inArgs, "()", , );
> +
> +domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
> +if (!domain)
> +return;
> +
> +if (virDomainAttachDeviceFlags(domain, xml, flags) == -1)
> +return virtDBusUtilSetLastVirtError(error);

There is no need to use 'return'.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3] qemu: add virQEMUBuildBufferEscapeComma in qemu_command.c

[Sukrit Bhatnagar]

Incremental patches do look better. Just to make sure I am on the right
track, I have some queries.

I have to apply the changes one function at a time, and these changes will
be the same ones I made in the v2 and v3 patches, right?
If that is the case, do I need the next patch to be v4 or can the series of
patches start from v1?
I can start afresh with the patches and this might save some confusion
later.

Thanks.

On Wed, Apr 11, 2018 at 3:52 AM, John Ferlan  wrote:

>
>
> On 04/02/2018 04:17 PM, Sukrit Bhatnagar wrote:
> > This patch adds virQEMUBuildBufferEscapeComma to properly
> > escape commas in user provided data fields for qemu command
> > line processing.
> >
> > Signed-off-by: Sukrit Bhatnagar 
> > ---
> >
> > Thank you for the helpful feedback and apologies for the delay.
>
> Well we all get busy and delayed by other things! It's been a week since
> you posted and well, I know I'm behind doing reviews!
>
> Nice on the using the --- for your adjustments and the issue you
> discovered.
>
> What happened to the changes from your previous version? They don't seem
> to be included in this patch and they weren't pushed upstream. This
> patch is all new changes.
>
> The "next" step is to attempt to generate patches that make incremental
> progress towards the end goal. Not all your changes need to go in one
> pile especially if something is separable - there's a methodology one
> develops over time. Changes don't need to be "so separated" that you get
> very large series, but you can create smaller patches, altering single
> API's/helpers and adjusting anything called by them to handle the
> changes. Some times it's a changed result and other times it's doing
> nothing because the patch fixes something. Again, it's one of those over
> time things.
>
> In this case, almost every function could have had it's own patch. That
> way a reviewer can ACK/Reviewed-by and push part of the series while
> perhaps asking for respins on other parts. It also allows for a NACK of
> a specific area. Much easier to change and review smaller things too!
>
> Since this is a GSOC type activity I won't "do" the work for you, but I
> will help "guide" you to the answer. First things first - hopefully you
> haven't lost your original patch. It's easily recreateable at least. We
> will start easy/slow... Using that patch as a starting point, create a
> series of 5 patches
>
>  patch 1: Changes for qemuBuildRomStr
>  patch 2: Changes for qemuBuildDriveDevStr
>  patch 3: Changes for qemuBuildFSStr and qemuBuildFSDevStr
>  patch 4: Changes for qemuBuildGraphicsVNCCommandLine
>  patch 5: Changes for qemuBuildDomainLoaderCommandLine
>
> Hold onto the changes for qemuBuildHostNetStr,
> qemuBuildChrChardevFileStr, qemuBuildChrChardevStr, and
> qemuBuildGraphicsSPICECommandLine as they'll be combined with separated
> patches from this patch.
>
> Post the above 5 - I've included patch 1 & 2 for you as an attachment to
> this reply so you can see the format... It should be fairly easy to copy
> from there and post as a v4.
>
> Once you've done that - work through the rest of this using similar
> context - although a few of these will be a bit larger and more
> complicated (especially the first one for build network drive.
>
> >
> > Changes in v3:
> > virQEMUBuildBufferEscapeComma was applied to:
> > - src->hosts->socket in qemuBuildNetworkDriveURI
> > - src->path, src->configFile in qemuBuildNetworkDriveStr
> > - disk->blkdeviotune.group_name in qemuBuildDiskThrottling
> > - net->data.socket.address, net->data.socket.localaddr in
> >   qemuBuildHostNetStr
> > - dev->data.file.path in qemuBuildChrChardevStr
> > - graphics->data.spice.rendernode in
> >   qemuBuildGraphicsSPICECommandLine
> > - smartcard->data.cert.file[i], smartcard->data.cert.database in
> >   qemuBuildSmartcardCommandLine
> >
> > Changes in v2:
> > virQEMUBuildBufferEscapeComma was applied to:
> > - info->romfile in qemuBuildRomStr
> > - disk->vendor, disk->product in qemuBuildDriveDevStr
> > - fs->src->path in qemuBuildFSStr
> > - fs->dst in qemuBuildFSDevStr
> > - connect= in qemuBuildHostNetStr
> > - fileval handling in qemuBuildChrChardevStr
> > - TYPE_DEV, TYPE_PIPE handling in qemuBuildChrChardevStr
> > - cfg->vncTLSx509certdir in qemuBuildGraphicsVNCCommandLine
> > - cfg->spiceTLSx509certdir in qemuBuildGraphicsSPICECommandLine
> > - loader->path, loader->nvram usage in
> >   qemuBuildDomainLoaderCommandLine
> >
> > Link to v2: https://www.redhat.com/archives/libvir-list/2018-
> March/msg00965.html
> >
> >
> > When I tried to change src->path in qemuBuildNetworkDriveStr
> > for this portion
> >
> > 961 } else if (src->nhosts == 1) {
> > 962 if (virAsprintf(, "sheepdog:%s:%u:%s",
> > 963 src->hosts->name, src->hosts->port,
> > 964 src->path) < 0)
> > 965 goto cleanup;
> > 966 } else {
> >
> > make 

Re: [libvirt] [RFC v2] external (pull) backup API

[John Snow]

On 04/12/2018 08:26 AM, Vladimir Sementsov-Ogievskiy wrote:
> 1. It looks unsafe to use nbd server + backup(sync=none) on same node,
> synchronization is needed, like in block/replication, which uses
> backup_wait_for_overlapping_requests, backup_cow_request_begin,
> backup_cow_request_end. We have a filter driver for this thing, not yet
> in upstream.

Is it the case that blockdev-backup sync=none can race with read
requests on the NBD server?

i.e. we can get temporarily inconsistent data before the COW completes?
Can you elaborate?

> 2. If we use filter driver anyway, it may be better to not use backup at
> all, and do all needed things in a filter driver.

if blockdev-backup sync=none isn't sufficient to get the semantics we
want, it may indeed be more appropriate to just leave the entire task to
a new filter node.

> 3. It may be interesting to implement something like READ_ONCE for NBD,
> which means, that we will never read these clusters again. And after
> such command, we don't need to copy corresponding clusters to temporary
> image, if guests decides to write them (as we know, that client already
> read them and don't going to read again).

That would be a very interesting optimization indeed; but I don't think
we have any kind of infrastructure for such things currently. It's
almost like a TRIM on which regions need to perform COW for the
BlockSnapshot.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 2/2] qemu: conf: Network stats support for VF Representors

[John Ferlan]

On 04/04/2018 12:29 PM, Jai Singh Rana wrote:
> In case of pci SR-IOV device with interface_type as 'hostdev', return
> network stats if it has a VF Representor interface on host for
> pci SR-IOV device according to switchdev model.
> ---
> v3 includes changes based on v2's[1] feedback and suggestions. Includes
> fix for hostdev to net mapping in a given domain.
> [1] https://www.redhat.com/archives/libvir-list/2018-February/msg00563.html
> 
>  docs/news.xml  |  9 +
>  src/conf/domain_conf.c | 15 +++
>  src/qemu/qemu_driver.c | 33 +
>  3 files changed, 53 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/news.xml b/docs/news.xml
> index 87f52e83e..04c18495f 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -47,6 +47,15 @@
>supported. In fact, kernel has been supporting this since 4.10.
>  
>
> +  
> +
> +  qemu: Support interface network stats for VF Representors
> +
> +
> +  Interface network stats are supported now for SR-IOV 
> device(hostdev)
> +  if this interface has VF representor on host in switchdev mode.
> +
> +  
>  
>  
>  

This needs to be it's own separate and last patch.

> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index ef16431aa..50813701c 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -56,6 +56,7 @@
>  #include "virsecret.h"
>  #include "virstring.h"
>  #include "virnetdev.h"
> +#include "virnetdevhostdev.h"
>  #include "virnetdevmacvlan.h"
>  #include "virhostdev.h"
>  #include "virmdev.h"
> @@ -28264,12 +28265,26 @@ virDomainNetFindByName(virDomainDefPtr def,
> const char *ifname)
>  {
>  size_t i;
> +size_t j;
>  
>  for (i = 0; i < def->nnets; i++) {
>  if (STREQ_NULLABLE(ifname, def->nets[i]->ifname))
>  return def->nets[i];
>  }
>  
> +/* Give a try to hostdev */
> +for (i = 0; i < def->nhostdevs; i++) {
> +if (virNetdevHostdevCheckVFRIfName(def->hostdevs[i], ifname)) {

You probably need to gate the above a bit more as a hostdev can be non
network... No sense in calling the very heavy above function for scsi
disks is there?

There's also interesting relationship between nnets and nhostdevs - see
virDomainNetInsert, which is something I think you need to understand
before unnecessarily walking this hostdev's list.

> +for (j = 0; j < def->nnets; j++) {
> +if (def->nets[j]->type != VIR_DOMAIN_NET_TYPE_HOSTDEV)
> +continue;

We already walked the nnets and what about virDomainNetGetActualType...

Not so sure about this. Laine perhaps understand all these relationships
a bit better than I do.

> +if (memcmp(def->hostdevs[i], >nets[j]->data.hostdev,
> +   sizeof(virDomainHostdevDef)) == 0)
> +return def->nets[j];
> +}
> +}
> +}
> +
>  return NULL;
>  }

If it stays, I think this hunk is separable into it's own patch...

>  
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 5c31dfdd5..f2f9d290b 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -66,6 +66,7 @@
>  #include "virbuffer.h"
>  #include "virhostcpu.h"
>  #include "virhostmem.h"
> +#include "virnetdevhostdev.h"
>  #include "virnetdevtap.h"
>  #include "virnetdevopenvswitch.h"
>  #include "capabilities.h"
> @@ -11156,6 +11157,11 @@ qemuDomainInterfaceStats(virDomainPtr dom,
>  if (virDomainNetGetActualType(net) == VIR_DOMAIN_NET_TYPE_VHOSTUSER) {
>  if (virNetDevOpenvswitchInterfaceStats(net->ifname, stats) < 0)
>  goto cleanup;
> +} else if (virDomainNetGetActualType(net) == 
> VIR_DOMAIN_NET_TYPE_HOSTDEV) {

bool swapped = virDomainNetTypeSharesHostView(net);

> +if (virNetdevHostdevVFRIfStats(device, stats,
> +   !virDomainNetTypeSharesHostView(net))

  ^^

Prefer to see a local "swapped" boolean used/defined than a function
call within a function call.

> +   < 0)

That would at least not leave this naked < 0) on one line

> +goto cleanup;
>  } else {
>  if (virNetDevTapInterfaceStats(net->ifname, stats,
> !virDomainNetTypeSharesHostView(net)) 
> < 0)
> @@ -19818,6 +19824,7 @@ qemuDomainGetStatsInterface(virQEMUDriverPtr driver 
> ATTRIBUTE_UNUSED,
>  {
>  size_t i;
>  struct _virDomainInterfaceStats tmp;
> +char *vf_ifname = NULL;
>  int ret = -1;
>  
>  if (!virDomainObjIsActive(dom))
> @@ -19830,21 +19837,39 @@ qemuDomainGetStatsInterface(virQEMUDriverPtr driver 
> ATTRIBUTE_UNUSED,
>  virDomainNetDefPtr net = dom->def->nets[i];
>  virDomainNetType actualType;
>  
> -

[libvirt] [PATCH v1 7/7] qemu: Enable memory-backend-file.discard-data whenever possible

[Michal Privoznik]

https://bugzilla.redhat.com/show_bug.cgi?id=1480668

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_command.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f864350bd5..67350719aa 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3148,6 +3148,12 @@ qemuBuildMemoryBackendStr(virJSONValuePtr *backendProps,
   NULL) < 0)
 goto cleanup;
 
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD) &&
+virJSONValueObjectAdd(props,
+  "B:discard-data", true,
+  NULL) < 0)
+goto cleanup;
+
 switch (memAccess) {
 case VIR_DOMAIN_MEMORY_ACCESS_SHARED:
 if (virJSONValueObjectAdd(props, "b:share", true, NULL) < 0)
-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v1 6/7] tests: Update qemucapabilitiesdata

[Michal Privoznik]

Signed-off-by: Michal Privoznik 
---
 .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies |  20 +-
 tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml   |   2 +-
 .../caps_2.10.0.aarch64.replies|  30 +-
 tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml |   2 +-
 .../qemucapabilitiesdata/caps_2.10.0.ppc64.replies |  28 +-
 tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.10.0.s390x.replies |  32 +-
 tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml   |   2 +-
 .../caps_2.10.0.x86_64.replies | 540 +-
 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml  |   2 +-
 .../qemucapabilitiesdata/caps_2.11.0.s390x.replies |  26 +-
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   |   2 +-
 .../caps_2.12.0.aarch64.replies|  24 +-
 tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml |   2 +-
 .../qemucapabilitiesdata/caps_2.12.0.ppc64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.12.0.s390x.replies |  24 +-
 .../caps_2.12.0.x86_64.replies | 612 +++--
 tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  |   3 +-
 .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies |  20 +-
 tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml   |   2 +-
 .../caps_2.6.0.aarch64.replies |  30 +-
 tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml  |   2 +-
 .../qemucapabilitiesdata/caps_2.6.0.ppc64.replies  |  28 +-
 tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.7.0.s390x.replies  |  28 +-
 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.8.0.s390x.replies  |  32 +-
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.8.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.ppc64.replies  |  28 +-
 tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.s390x.replies  |  32 +-
 tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 536 +-
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml   |   2 +-
 43 files changed, 1223 insertions(+), 1000 deletions(-)

diff --git a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.replies 
b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.replies
index 543bce9def..eeb5dd2582 100644
--- a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.replies
+++ b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.replies
@@ -2523,6 +2523,14 @@
   "id": "libvirt-36"
 }
 
+{
+"id": "libvirt-37",
+"error": {
+"class": "CommandNotFound",
+"desc": "The command qom-list-properties has not been found"
+}
+}
+
 {
   "return": [
 {
@@ -2625,7 +2633,7 @@
   "cpu-max": 255
 }
   ],
-  "id": "libvirt-37"
+  "id": "libvirt-38"
 }
 
 {
@@ -2706,21 +2714,21 @@
   "name": "qemu64"
 }
   ],
-  "id": "libvirt-38"
+  "id": "libvirt-39"
 }
 
 {
   "return": [
 "tpm-tis"
   ],
-  "id": "libvirt-39"
+  "id": "libvirt-40"
 }
 
 {
   "return": [
 "passthrough"
   ],
-  "id": "libvirt-40"
+  "id": "libvirt-41"
 }
 
 {
@@ -3580,7 +3588,7 @@
   "option": "drive"
 }
   ],
-  "id": "libvirt-41"
+  "id": "libvirt-42"
 }
 
 {
@@ -3602,7 +3610,7 @@
   "capability": "zero-blocks"
 }
   ],
-  "id": "libvirt-42"
+  "id": "libvirt-43"
 }
 
 {
diff --git a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml 
b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
index ca98ee14db..bc82624335 100644
--- a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
@@ -160,7 +160,7 @@
   
   2001001
   0
-  58992
+  59147
   
   x86_64
   
diff --git a/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies 
b/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
index 11171d5b3f..8fc07248c3 100644
--- a/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
+++ b/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
@@ -4948,6 +4948,14 @@
   "id": "libvirt-35"
 }
 
+{
+"id": "libvirt-36",
+"error": {
+"class": "CommandNotFound",
+"desc": "The command qom-list-properties has not been found"
+}
+}
+
 {
   "return": [
 {
@@ -5212,7 +5220,7 @@
   "cpu-max": 1
 }
   ],
-  "id": "libvirt-36"
+  "id": "libvirt-37"
 }
 
 {
@@ -5378,12 +5386,6 @@
   "static": false
 }
   ],
-  "id": "libvirt-37"
-}
-
-{
-  

[libvirt] [PATCH v1 5/7] qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD

[Michal Privoznik]

This capability tracks if memory-backend-file has discard-data
attribute or not.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_capabilities.c | 17 +
 src/qemu/qemu_capabilities.h |  1 +
 2 files changed, 18 insertions(+)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 2d36aeaa54..8117252789 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -468,6 +468,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
   "virtio-tablet-ccw",
   "qcow2-luks",
   "pcie-pci-bridge",
+  "memory-backend-file.discard-data",
 );
 
 
@@ -1367,6 +1368,15 @@ static virQEMUCapsObjectTypeProps 
virQEMUCapsDeviceProps[] = {
   QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW },
 };
 
+static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMemoryBackendFile[] 
= {
+{ "discard-data", QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD },
+};
+
+static virQEMUCapsObjectTypeProps virQEMUCapsObjectProps[] = {
+{ "memory-backend-file", virQEMUCapsObjectPropsMemoryBackendFile,
+  ARRAY_CARDINALITY(virQEMUCapsObjectPropsMemoryBackendFile),
+  QEMU_CAPS_OBJECT_MEMORY_FILE },
+};
 
 static void
 virQEMUCapsProcessStringFlags(virQEMUCapsPtr qemuCaps,
@@ -2128,6 +2138,13 @@ virQEMUCapsProbeQMPDevices(virQEMUCapsPtr qemuCaps,
 if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CHARDEV_SPICEVMC))
 virQEMUCapsClear(qemuCaps, QEMU_CAPS_DEVICE_SPICEVMC);
 
+if (virQEMUCapsProbeQMPGenericProps(qemuCaps,
+mon,
+virQEMUCapsObjectProps,
+
ARRAY_CARDINALITY(virQEMUCapsObjectProps),
+qemuMonitorGetObjectProps) < 0)
+return -1;
+
 return 0;
 }
 
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 3a8ffcd0e7..189ed45de3 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -452,6 +452,7 @@ typedef enum {
 QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW, /* -device virtio-tablet-ccw */
 QEMU_CAPS_QCOW2_LUKS, /* qcow2 format support LUKS encryption */
 QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE, /* -device pcie-pci-bridge */
+QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD, /* -object 
memory-backend-dile,discard-data= */
 
 QEMU_CAPS_LAST /* this must always be the last item */
 } virQEMUCapsFlags;
-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v1 3/7] qemu_capabilities: Separate out device props fetching

[Michal Privoznik]

The code is written generic enough to be reused. Move it into a
separate function.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_capabilities.c | 62 ++--
 1 file changed, 42 insertions(+), 20 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 1d2110eef3..2d36aeaa54 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1250,14 +1250,19 @@ static struct virQEMUCapsStringFlags 
virQEMUCapsQMPSchemaQueries[] = {
 { "blockdev-add/arg-type/+qcow2/encrypt/+luks/key-secret", 
QEMU_CAPS_QCOW2_LUKS },
 };
 
-struct virQEMUCapsObjectTypeProps {
+typedef struct _virQEMUCapsObjectTypeProps virQEMUCapsObjectTypeProps;
+struct _virQEMUCapsObjectTypeProps {
 const char *type;
 struct virQEMUCapsStringFlags *props;
 size_t nprops;
 int capsCondition;
 };
 
-static struct virQEMUCapsObjectTypeProps virQEMUCapsDeviceProps[] = {
+typedef int (*virQEMUCapsObjectTypePropsCB)(qemuMonitorPtr mon,
+const char *type,
+char ***props);
+
+static virQEMUCapsObjectTypeProps virQEMUCapsDeviceProps[] = {
 { "virtio-blk-pci", virQEMUCapsDevicePropsVirtioBlk,
   ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBlk),
   -1 },
@@ -2067,6 +2072,35 @@ virQEMUCapsProbeQMPEvents(virQEMUCapsPtr qemuCaps,
 return 0;
 }
 
+static int
+virQEMUCapsProbeQMPGenericProps(virQEMUCapsPtr qemuCaps,
+qemuMonitorPtr mon,
+virQEMUCapsObjectTypeProps *props,
+size_t nprops,
+virQEMUCapsObjectTypePropsCB propsGetCB)
+{
+int nvalues;
+char **values;
+size_t i;
+
+for (i = 0; i < nprops; i++) {
+const char *type = props[i].type;
+int cap = props[i].capsCondition;
+
+if (cap >= 0 && !virQEMUCapsGet(qemuCaps, cap))
+continue;
+
+if ((nvalues = propsGetCB(mon, type, )) < 0)
+return -1;
+virQEMUCapsProcessStringFlags(qemuCaps,
+  props[i].nprops,
+  props[i].props,
+  nvalues, values);
+virStringListFreeCount(values, nvalues);
+}
+
+return 0;
+}
 
 static int
 virQEMUCapsProbeQMPDevices(virQEMUCapsPtr qemuCaps,
@@ -2074,7 +2108,6 @@ virQEMUCapsProbeQMPDevices(virQEMUCapsPtr qemuCaps,
 {
 int nvalues;
 char **values;
-size_t i;
 
 if ((nvalues = qemuMonitorGetObjectTypes(mon, )) < 0)
 return -1;
@@ -2084,23 +2117,12 @@ virQEMUCapsProbeQMPDevices(virQEMUCapsPtr qemuCaps,
   nvalues, values);
 virStringListFreeCount(values, nvalues);
 
-for (i = 0; i < ARRAY_CARDINALITY(virQEMUCapsDeviceProps); i++) {
-const char *device = virQEMUCapsDeviceProps[i].type;
-int cap = virQEMUCapsDeviceProps[i].capsCondition;
-
-if (cap >= 0 && !virQEMUCapsGet(qemuCaps, cap))
-continue;
-
-if ((nvalues = qemuMonitorGetDeviceProps(mon,
- device,
- )) < 0)
-return -1;
-virQEMUCapsProcessStringFlags(qemuCaps,
-  virQEMUCapsDeviceProps[i].nprops,
-  virQEMUCapsDeviceProps[i].props,
-  nvalues, values);
-virStringListFreeCount(values, nvalues);
-}
+if (virQEMUCapsProbeQMPGenericProps(qemuCaps,
+mon,
+virQEMUCapsDeviceProps,
+
ARRAY_CARDINALITY(virQEMUCapsDeviceProps),
+qemuMonitorGetDeviceProps) < 0)
+return -1;
 
 /* Prefer -chardev spicevmc (detected earlier) over -device spicevmc */
 if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CHARDEV_SPICEVMC))
-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH] guests: Introduce libvirt+mingw project

[Andrea Bolognani]

Instead of cramming the dependencies that we need for a MinGW
build of libvirt along with those we need for a native build,
create a new project for the former.

Signed-off-by: Andrea Bolognani 
---
 guests/host_vars/libvirt-fedora-rawhide/main.yml |  1 +
 guests/vars/projects/libvirt+mingw.yml   | 28 
 guests/vars/projects/libvirt.yml | 24 
 3 files changed, 29 insertions(+), 24 deletions(-)
 create mode 100644 guests/vars/projects/libvirt+mingw.yml

diff --git a/guests/host_vars/libvirt-fedora-rawhide/main.yml 
b/guests/host_vars/libvirt-fedora-rawhide/main.yml
index 3f69f80..c905fb0 100644
--- a/guests/host_vars/libvirt-fedora-rawhide/main.yml
+++ b/guests/host_vars/libvirt-fedora-rawhide/main.yml
@@ -5,6 +5,7 @@ PYTHONPATH: $VIRT_PREFIX/lib64/python3.6/site-packages
 projects:
   - libosinfo
   - libvirt
+  - libvirt+mingw
   - libvirt-cim
   - libvirt-dbus
   - libvirt-glib
diff --git a/guests/vars/projects/libvirt+mingw.yml 
b/guests/vars/projects/libvirt+mingw.yml
new file mode 100644
index 000..0dacb30
--- /dev/null
+++ b/guests/vars/projects/libvirt+mingw.yml
@@ -0,0 +1,28 @@
+---
+packages:
+  - mingw32-curl
+  - mingw32-dbus
+  - mingw32-dlfcn
+  - mingw32-gcc
+  - mingw32-gettext
+  - mingw32-gnutls
+  - mingw32-libssh2
+  - mingw32-libxml2
+  - mingw32-openssl
+  - mingw32-pkg-config
+  - mingw32-portablexdr
+  - mingw32-readline
+  - mingw64-curl
+  - mingw64-dbus
+  - mingw64-dlfcn
+  - mingw64-gcc
+  - mingw64-gettext
+  - mingw64-gnutls
+  - mingw64-libssh2
+  - mingw64-libxml2
+  - mingw64-openssl
+  - mingw64-pkg-config
+  - mingw64-portablexdr
+  - mingw64-readline
+  - rpcgen
+  - xsltproc
diff --git a/guests/vars/projects/libvirt.yml b/guests/vars/projects/libvirt.yml
index 598dfc4..ad42fd5 100644
--- a/guests/vars/projects/libvirt.yml
+++ b/guests/vars/projects/libvirt.yml
@@ -36,30 +36,6 @@ packages:
   - libudev
   - libxml2
   - lvm2
-  - mingw32-curl
-  - mingw32-dbus
-  - mingw32-dlfcn
-  - mingw32-gcc
-  - mingw32-gettext
-  - mingw32-gnutls
-  - mingw32-libssh2
-  - mingw32-libxml2
-  - mingw32-openssl
-  - mingw32-pkg-config
-  - mingw32-portablexdr
-  - mingw32-readline
-  - mingw64-curl
-  - mingw64-dbus
-  - mingw64-dlfcn
-  - mingw64-gcc
-  - mingw64-gettext
-  - mingw64-gnutls
-  - mingw64-libssh2
-  - mingw64-libxml2
-  - mingw64-openssl
-  - mingw64-pkg-config
-  - mingw64-portablexdr
-  - mingw64-readline
   - netcf
   - numad
   - openwsman
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v1 0/7] Enable memory-backend-file.discard-data

[Michal Privoznik]

Qemu introduced this in 11ae6ed8affdd13. A small refactor is needed
however.

Michal Privoznik (7):
  qemu: Rename qemuMonitorGetObjectProps to qemuMonitorGetDeviceProps
  qemu_capabilities: s/ObjectProps/DeviceProps/g
  qemu_capabilities: Separate out device props fetching
  qemu_monitor: Introduce qemuMonitorGetObjectProps
  qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD
  tests: Update qemucapabilitiesdata
  qemu: Enable memory-backend-file.discard-data whenever possible

 src/qemu/qemu_capabilities.c   | 269 +
 src/qemu/qemu_capabilities.h   |   1 +
 src/qemu/qemu_command.c|   6 +
 src/qemu/qemu_monitor.c|  21 +-
 src/qemu/qemu_monitor.h|   5 +-
 src/qemu/qemu_monitor_json.c   |  62 ++-
 src/qemu/qemu_monitor_json.h   |   6 +-
 .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies |  20 +-
 tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml   |   2 +-
 .../caps_2.10.0.aarch64.replies|  30 +-
 tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml |   2 +-
 .../qemucapabilitiesdata/caps_2.10.0.ppc64.replies |  28 +-
 tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.10.0.s390x.replies |  32 +-
 tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml   |   2 +-
 .../caps_2.10.0.x86_64.replies | 540 +-
 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml  |   2 +-
 .../qemucapabilitiesdata/caps_2.11.0.s390x.replies |  26 +-
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   |   2 +-
 .../caps_2.12.0.aarch64.replies|  24 +-
 tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml |   2 +-
 .../qemucapabilitiesdata/caps_2.12.0.ppc64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.12.0.s390x.replies |  24 +-
 .../caps_2.12.0.x86_64.replies | 612 +++--
 tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  |   3 +-
 .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies |  20 +-
 tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml   |   2 +-
 .../caps_2.6.0.aarch64.replies |  30 +-
 tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml  |   2 +-
 .../qemucapabilitiesdata/caps_2.6.0.ppc64.replies  |  28 +-
 tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.7.0.s390x.replies  |  28 +-
 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.8.0.s390x.replies  |  32 +-
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.8.0.x86_64.replies |  22 +-
 tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml   |   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.ppc64.replies  |  28 +-
 tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.s390x.replies  |  32 +-
 tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml|   2 +-
 .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 536 +-
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml   |   2 +-
 50 files changed, 1458 insertions(+), 1135 deletions(-)

-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH v2 0/6] Mostly drop CentOS 6

[Andrea Bolognani]

Changes from [v1]:

  * instead of dropping CentOS 6 altogether, simply stop building
pretty much all projects on it;

  * introduce a new job type specifically for whatever little
stuff we need to ensure still works on CentOS 6;

  * the end result is still a nice cleanup thanks to not repeating
the list of machines all over the place; moreover, the
message about our support of the OS is very clear because it
disappears from all but one page on the CI web interface.

[v1] https://www.redhat.com/archives/libvir-list/2018-April/msg00453.html

Andrea Bolognani (6):
  jobs: Introduce autotools-website-job
  guests: Introduce libvirt+website project
  projects: Add libvirt-master-website job
  projects: Stop building on CentOS 6
  guests: Drop projects from CentOS 6
  jobs: Introduce {all_machines} and {rpm_machines}

 guests/host_vars/libvirt-centos-6/main.yml |  5 +--
 guests/vars/projects/libvirt+website.yml   |  5 +++
 jobs/autotools.yaml| 67 ++
 jobs/defaults.yaml | 14 +++
 projects/libosinfo.yaml| 16 +--
 projects/libvirt-cim.yaml  |  7 +---
 projects/libvirt-glib.yaml | 16 +--
 projects/libvirt-go-xml.yaml   | 10 +
 projects/libvirt-go.yaml   | 10 +
 projects/libvirt-perl.yaml | 17 +---
 projects/libvirt-python.yaml   | 18 +---
 projects/libvirt.yaml  | 34 +++
 projects/osinfo-db-tools.yaml  | 16 +--
 projects/osinfo-db.yaml| 16 +--
 projects/virt-viewer.yaml  | 16 +--
 15 files changed, 119 insertions(+), 148 deletions(-)
 create mode 100644 guests/vars/projects/libvirt+website.yml

-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCHv3 3/6] tests: add qemumonitorjson tests for query-cpus-fast

[John Ferlan]

On 04/04/2018 10:45 AM, Viktor Mihajlovski wrote:
> Extended the json monitor test program with support for query-cpus-fast
> and added a sample file set for x86 data obtained using the it.
> Also extend the test program to recognize the halted property.

This last sentence involves code that probably should be separated into
its own patch since it's unrelated to the new data. If it's moved this
patch into one previously, then this patch/adjustment "proves" nothing
changes (which is good).

I can do that for you so you don't have to post another series.  I would
make you the author and add your S-o-b... Of course I need you to say OK
for that too!

The rest of this shows what I'd extract...

> 
> Signed-off-by: Viktor Mihajlovski 
> ---
>  .../qemumonitorjson-cpuinfo-ppc64-hotplug-4.data   |   8 ++
>  ...emumonitorjson-cpuinfo-x86-basic-pluggable.data |   5 +
>  ...qemumonitorjson-cpuinfo-x86-full-fast-cpus.json | 126 
> +
>  ...umonitorjson-cpuinfo-x86-full-fast-hotplug.json | 115 +++
>  .../qemumonitorjson-cpuinfo-x86-full-fast.data | 109 ++
>  .../qemumonitorjson-cpuinfo-x86-node-full.data |   2 +
>  tests/qemumonitorjsontest.c| 121 +++-
>  tests/qemumonitortestutils.c   |   7 ++
>  tests/qemumonitortestutils.h   |   1 +
>  9 files changed, 468 insertions(+), 26 deletions(-)
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast-cpus.json
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast-hotplug.json
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast.data
> 
> diff --git 
> a/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data 
> b/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data
> index 7c90889..5f6b865 100644
> --- a/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data
> +++ b/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data
> @@ -52,41 +52,49 @@
>  alias='vcpu0'
>  qom_path='/machine/peripheral/vcpu0'
>  topology: core='8' vcpus='8'
> +halted
>  [vcpu libvirt-id='9']
>  online=yes
>  hotpluggable=yes
>  thread-id='23171'
>  query-cpus-id='17'
> +halted
>  [vcpu libvirt-id='10']
>  online=yes
>  hotpluggable=yes
>  thread-id='23172'
>  query-cpus-id='18'
> +halted
>  [vcpu libvirt-id='11']
>  online=yes
>  hotpluggable=yes
>  thread-id='23173'
>  query-cpus-id='19'
> +halted
>  [vcpu libvirt-id='12']
>  online=yes
>  hotpluggable=yes
>  thread-id='23174'
>  query-cpus-id='20'
> +halted
>  [vcpu libvirt-id='13']
>  online=yes
>  hotpluggable=yes
>  thread-id='23175'
>  query-cpus-id='21'
> +halted
>  [vcpu libvirt-id='14']
>  online=yes
>  hotpluggable=yes
>  thread-id='23176'
>  query-cpus-id='22'
> +halted
>  [vcpu libvirt-id='15']
>  online=yes
>  hotpluggable=yes
>  thread-id='23177'
>  query-cpus-id='23'
> +halted
>  [vcpu libvirt-id='16']
>  online=yes
>  hotpluggable=yes> diff --git
a/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data
b/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data
> index 93cefb9..9a1788d 100644
> --- 
> a/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data
> +++ 
> b/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data
> @@ -7,6 +7,7 @@
>  type='qemu64-x86_64-cpu'
>  qom_path='/machine/unattached/device[0]'
>  topology: socket='0' core='0' thread='0' vcpus='1'
> +halted
>  [vcpu libvirt-id='1']
>  online=yes
>  hotpluggable=no
> @@ -16,6 +17,7 @@
>  type='qemu64-x86_64-cpu'
>  qom_path='/machine/unattached/device[2]'
>  topology: socket='0' core='0' thread='1' vcpus='1'
> +halted
>  [vcpu libvirt-id='2']
>  online=yes
>  hotpluggable=no
> @@ -25,6 +27,7 @@
>  type='qemu64-x86_64-cpu'
>  qom_path='/machine/unattached/device[3]'
>  topology: socket='0' core='1' thread='0' vcpus='1'
> +halted
>  [vcpu libvirt-id='3']
>  online=yes
>  hotpluggable=no
> @@ -34,6 +37,7 @@
>  type='qemu64-x86_64-cpu'
>  qom_path='/machine/unattached/device[4]'
>  topology: socket='0' core='1' thread='1' vcpus='1'
> +halted
>  [vcpu libvirt-id='4']
>  online=yes
>  hotpluggable=no
> @@ -43,6 +47,7 @@
>  type='qemu64-x86_64-cpu'
>  qom_path='/machine/unattached/device[5]'
>  topology: socket='1' core='0' thread='0' vcpus='1'
> +halted
>  [vcpu libvirt-id='5']
>  online=no
>  hotpluggable=yes

[...]

> diff --git 
> a/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-node-full.data 
> b/tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-node-full.data
> index 

Re: [libvirt] [PATCHv3 0/6] Use query-cpus-fast instead of query-cpus

[John Ferlan]

On 04/04/2018 10:45 AM, Viktor Mihajlovski wrote:
> The QEMU monitor commmand query-cpus is deprecated starting
> with QEMU 2.12.0 because it can adversely affect the performance of
> a running virtual machine.
> 
> This series enables libvirt to use the new query-cpus-fast interface
> if supported by the local QEMU instance and is required in order
> to support QEMU once the interface has been removed.
> 
> query-cpus-fast doesn't return the halted state for a virtual CPU,
> meaning that the vcpu..halted value won't be reported with
> 'virsh domstats' anymore. This is OK, as stats values are not
> guaranteed to be reported under all circumstances and on all
> architectures.
> 
> Upstream discussion consensus was that the halted state was
> problematic anyway, as it had different semantics per architecture.
> The only known exploitation happened for s390, for this architecture
> the halted state will be computed based on an architecture-specific
> cpu value returned in query-cpus-fast.
> 
> v2 -> v3:
> =
>   Patch changes:
>   1/6:
>   - formatting changes as requested by John Ferlan
>   - updated the qemucapabilitiestest XML files
>   - dropped A/R-bys (due to change above)
>   
>   2/6:
>   - fixed comment to also account for query-cpus-fast
> 
>   3/6:
>   - updated json monitor tests to account for props returned by
> query-cpus and query-cpus-fast
>   - updated json monitor tests to handle the halted property
> (moved here from patch 5)
> 
>   4/6:
>   - removed stale text (about callbacks) from commit message 
>   - simplified qemuMonitorJSONExtractCPUArchInfo call
>   - enhanced sample JSON response in comment
>   - fixed inter-function spacing
> 
>   5/6:
>   - kept s390-specific tests and moved the rest to patch 3
>   - reformatted the JSON responses (indented "props")
>   - dropped R-b
> 
> v1 -> v2:
> =
>   Patch changes:
>   1/6:
>   - add Acked-by: Peter Krempa  
> 
>   2/6:
>   - evaluate capability outside of monitor code (changes signatures
> of qemuMonitorGetCPUInfo and qemuMonitorGetCpuHalted)
>   - remove ternary expressions as requested by review
>   - remove Reviewed-bys due to code changes
> 
>   3/6 
>   - adapt test cases to changes above
>   - remove Reviewed-bys due to code changes
> 
>   4/6
>   - replace callbacks for architecture data extraction with direct
> function calls
>   - remove Reviewed-bys due to code changes
> 
> Viktor Mihajlovski (6):
>   qemu: add capability detection for query-cpus-fast
>   qemu: use query-cpus-fast in JSON monitor
>   tests: add qemumonitorjson tests for query-cpus-fast
>   qemu: add architecture-specific CPU info handling
>   tests: add testcase for s390 query-cpus-fast
>   qemu: refresh vcpu halted state only via query-cpus-fast
> 
>  src/qemu/qemu_capabilities.c   |   2 +
>  src/qemu/qemu_capabilities.h   |   1 +
>  src/qemu/qemu_domain.c |  23 +++-
>  src/qemu/qemu_monitor.c|  30 +++--
>  src/qemu/qemu_monitor.h|   7 +-
>  src/qemu/qemu_monitor_json.c   | 133 
> +++--
>  src/qemu/qemu_monitor_json.h   |   3 +-
>  tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml |   1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   |   1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml   |   1 +
>  tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  |   1 +
>  .../qemumonitorjson-cpuinfo-ppc64-hotplug-4.data   |   8 ++
>  .../qemumonitorjson-cpuinfo-s390-fast-cpus.json|  25 
>  .../qemumonitorjson-cpuinfo-s390-fast-hotplug.json |  21 
>  .../qemumonitorjson-cpuinfo-s390-fast.data |  19 +++
>  ...emumonitorjson-cpuinfo-x86-basic-pluggable.data |   5 +
>  ...qemumonitorjson-cpuinfo-x86-full-fast-cpus.json | 126 +++
>  ...umonitorjson-cpuinfo-x86-full-fast-hotplug.json | 115 ++
>  .../qemumonitorjson-cpuinfo-x86-full-fast.data | 109 +
>  .../qemumonitorjson-cpuinfo-x86-node-full.data |   2 +
>  tests/qemumonitorjsontest.c| 123 +++
>  tests/qemumonitortestutils.c   |   7 ++
>  tests/qemumonitortestutils.h   |   1 +
>  23 files changed, 706 insertions(+), 58 deletions(-)
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-s390-fast-cpus.json
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-s390-fast-hotplug.json
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-s390-fast.data
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast-cpus.json
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast-hotplug.json
>  create mode 100644 
> tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-full-fast.data
> 

With a merge for patch1 to top of tree and a 

[libvirt] [dbus PATCH v2 22/22] Implement GetSchedulerParameters method for Domain Interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 38 ++
 2 files changed, 44 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 0937cbb..5763a8a 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -87,6 +87,12 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetSchedulerParametersFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainListGetStats"/>
diff --git a/src/domain.c b/src/domain.c
index a8d3e6c..0eda7cf 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -543,6 +543,43 @@ virtDBusDomainGetMemoryParameters(GVariant *inArgs,
 *outArgs = g_variant_new_tuple(, 1);
 }
 
+static void
+virtDBusDomainGetSchedulerParameters(GVariant *inArgs,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+g_autofree virTypedParameterPtr params = NULL;
+gint nparams;
+guint flags;
+GVariant *grecords;
+g_autofree gchar *ret = NULL;
+
+g_variant_get(inArgs, "(u)", );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+ret = virDomainGetSchedulerType(domain, );
+if (ret && nparams != 0) {
+if ((params = g_new0(virTypedParameter, nparams)) == NULL)
+return;
+if (virDomainGetSchedulerParametersFlags(domain, params, , 0))
+return virtDBusUtilSetLastVirtError(error);
+}
+
+grecords = virtDBusUtilTypedParamsToGVariant(params,
+ nparams);
+
+*outArgs = g_variant_new_tuple(, 1);
+}
+
 G_DEFINE_AUTOPTR_CLEANUP_FUNC(virDomainStatsRecordPtr, 
virDomainStatsRecordListFree);
 
 static void
@@ -1054,6 +1091,7 @@ static virtDBusGDBusMethodTable 
virtDBusDomainMethodTable[] = {
 { "GetBlkioParameters", virtDBusDomainGetBlkioParameters },
 { "GetJobInfo", virtDBusDomainGetJobInfo },
 { "GetMemoryParameters", virtDBusDomainGetMemoryParameters },
+{ "GetSchedulerParameters", virtDBusDomainGetSchedulerParameters },
 { "GetStats", virtDBusDomainGetStats },
 { "GetVcpus", virtDBusDomainGetVcpus },
 { "GetXMLDesc", virtDBusDomainGetXMLDesc },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt PATCH v2 11/44] Deprecate QEMU_CAPS_NO_USER_CONFIG

[Andrea Bolognani]

On Thu, 2018-04-12 at 17:16 +0200, Ján Tomko wrote:
> On Thu, Apr 12, 2018 at 10:07:50AM +0200, Andrea Bolognani wrote:
> > On Mon, 2018-04-09 at 17:20 +0200, Ján Tomko wrote:
> > > Delete this one first, because QEMU_CAPS_NODEFCONFIG is only used
> > > when QEMU_CAPS_NO_USER_CONFIG is unsupported.
> > 
> > Is there a specific reason for the 6-patch gap between dropping
> > NO_USER_CONFIG and dropping NODEFCONFIG? It would IMHO make more
> > sense to drop them one immediately after the other.
> 
> I originally wrote them in the order they apper in
> virQEMUCapsInitQMPBasic, then relized inserting -nodefconfig everywhere
> just to replace it with -no-user-config later is pointless and moved it
> right after the first patch that touched all the test files
> (QEMU_CAPS_MONITOR_JSON)

So IIUC you would be okay with dropping NODEFCONFIG right after
NO_USER_CONFIG, correct? I would prefer that order - though I
realize I haven't ACKed the other patch yet :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v2 08/22] Implement GetJobInfo method for Domain interface

[Katerina Koukiou]

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  5 +
 src/domain.c| 35 +++
 2 files changed, 40 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 83e37bc..2e0339b 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -62,6 +62,11 @@
   
   
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetJobInfo"/>
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainListGetStats"/>
diff --git a/src/domain.c b/src/domain.c
index bf352a7..e80749b 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -396,6 +396,40 @@ virtDBusDomainDetachDevice(GVariant *inArgs,
 return virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainGetJobInfo(GVariant *inArgs G_GNUC_UNUSED,
+ GUnixFDList *inFDs G_GNUC_UNUSED,
+ const gchar *objectPath,
+ gpointer userData,
+ GVariant **outArgs,
+ GUnixFDList **outFDs G_GNUC_UNUSED,
+ GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+g_autofree virDomainJobInfoPtr jobInfo = NULL;
+const gchar *jobTypeStr;
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+jobInfo = g_new0(virDomainJobInfo, 1);
+if (virDomainGetJobInfo(domain, jobInfo) == -1)
+return virtDBusUtilSetLastVirtError(error);
+
+jobTypeStr = virtDBusDomainJobTypeToString(jobInfo->type);
+if (!jobTypeStr)
+return;
+*outArgs = g_variant_new("((sttt))", jobTypeStr,
+ jobInfo->timeElapsed, jobInfo->timeRemaining,
+ jobInfo->dataTotal, jobInfo->dataProcessed,
+ jobInfo->dataRemaining, jobInfo->memTotal,
+ jobInfo->memProcessed, jobInfo->memRemaining,
+ jobInfo->fileTotal, jobInfo->fileProcessed,
+ jobInfo->fileRemaining);
+}
+
 G_DEFINE_AUTOPTR_CLEANUP_FUNC(virDomainStatsRecordPtr, 
virDomainStatsRecordListFree);
 
 static void
@@ -673,6 +707,7 @@ static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] 
= {
 { "Create", virtDBusDomainCreate },
 { "Destroy", virtDBusDomainDestroy },
 { "DetachDevice", virtDBusDomainDetachDevice },
+{ "GetJobInfo", virtDBusDomainGetJobInfo },
 { "GetStats", virtDBusDomainGetStats },
 { "GetVcpus", virtDBusDomainGetVcpus },
 { "GetXMLDesc", virtDBusDomainGetXMLDesc },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] acl: remove various left over Xen ACL whitelist entries

[Daniel P . Berrangé]

The legacy xen driver is removed, so these ACLL hacks can be removed
too now.

Signed-off-by: Daniel P. Berrangé 
---
 src/check-aclrules.pl | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/src/check-aclrules.pl b/src/check-aclrules.pl
index 5b6c711dc8..374abaa722 100755
--- a/src/check-aclrules.pl
+++ b/src/check-aclrules.pl
@@ -61,26 +61,12 @@ my %whitelist = (
 "interfaceClose" => 1,
 );
 
-# Temp hack - remove it once xen driver is fixed
+# XXX this vzDomainMigrateConfirm3Params looks
+# bogus - determine why it doesn't have a valid
+# ACL check.
 my %implwhitelist = (
-"xenUnifiedDomainRestore" => 1,
-"xenUnifiedDomainRestoreFlags" => 1,
-"xenUnifiedDomainMigratePrepare" => 1,
-"xenUnifiedNodeDeviceDettach" => 1,
-"xenUnifiedNodeDeviceDetachFlags" => 1,
-"xenUnifiedNodeDeviceReset" => 1,
-"xenUnifiedDomainIsActive" => 1,
-"xenUnifiedDomainIsPersistent" => 1,
-"xenUnifiedDomainIsUpdated" => 1,
-"xenUnifiedDomainOpenConsole" => 1,
 "vzDomainMigrateConfirm3Params" => 1,
 );
-my %filterimplwhitelist = (
-"xenUnifiedConnectListDomains" => 1,
-"xenUnifiedConnectNumOfDomains" => 1,
-"xenUnifiedConnectListDefinedDomains" => 1,
-"xenUnifiedConnectNumOfDefinedDomains" => 1,
-);
 
 my $lastfile;
 
@@ -234,8 +220,7 @@ while (<>) {
 }
 
 if (exists $filtered{$api} &&
-!exists $aclfilters{$impl} &&
-!exists $filterimplwhitelist{$impl}) {
+!exists $aclfilters{$impl}) {
 print "$ARGV:$. Missing ACL filter in function '$impl' for 
'$api'\n";
 $status = 1;
 }
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v2 15/22] Implement SetVcpus method for Domain Interface

[Katerina Koukiou]

Move testing of [Get,Set]Vcpus to seperate test.

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 26 ++
 test/test_domain.py |  9 +++--
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 087b64e..7f58cbd 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -139,6 +139,12 @@
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainResume"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetVcpusFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainShutdownFlags"/>
diff --git a/src/domain.c b/src/domain.c
index 336128e..1896590 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -771,6 +771,31 @@ virtDBusDomainResume(GVariant *inArgs G_GNUC_UNUSED,
 virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainSetVcpus(GVariant *inArgs,
+   GUnixFDList *inFDs G_GNUC_UNUSED,
+   const gchar *objectPath,
+   gpointer userData,
+   GVariant **outArgs G_GNUC_UNUSED,
+   GUnixFDList **outFDs G_GNUC_UNUSED,
+   GError **error)
+
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+guint vcpus;
+guint flags;
+
+g_variant_get(inArgs, "(uu)", , );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainSetVcpusFlags(domain, vcpus, flags) < 0)
+return virtDBusUtilSetLastVirtError(error);
+}
+
 static void
 virtDBusDomainShutdown(GVariant *inArgs,
GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -869,6 +894,7 @@ static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] 
= {
 { "Reboot", virtDBusDomainReboot },
 { "Reset", virtDBusDomainReset },
 { "Resume", virtDBusDomainResume },
+{ "SetVcpus", virtDBusDomainSetVcpus },
 { "Shutdown", virtDBusDomainShutdown },
 { "Suspend", virtDBusDomainSuspend },
 { "Undefine", virtDBusDomainUndefine },
diff --git a/test/test_domain.py b/test/test_domain.py
index 45a99f9..31e09bf 100755
--- a/test/test_domain.py
+++ b/test/test_domain.py
@@ -27,8 +27,6 @@ class TestDomain(libvirttest.BaseTestClass):
 
 xml = domain.GetXMLDesc(0)
 assert isinstance(xml, dbus.String)
-vcpus = domain.GetVcpus(0)
-assert isinstance(vcpus, dbus.UInt32)
 
 domain.Reboot(0)
 domain.Shutdown(0)
@@ -123,5 +121,12 @@ class TestDomain(libvirttest.BaseTestClass):
 
 self.main_loop()
 
+def test_domain_vcpus(self):
+obj, domain = self.domain()
+vcpus_expected = 2
+domain.SetVcpus(vcpus_expected, 0)
+assert domain.GetVcpus(0) == dbus.Int32(vcpus_expected)
+
+
 if __name__ == '__main__':
 libvirttest.run()
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [dbus PATCH v2 05/22] Implement AttachDevice method for Domain Interface

[Katerina Koukiou]

This method is not tested for now since the test driver
doesn't suport this API.

Signed-off-by: Katerina Koukiou 
---
 data/org.libvirt.Domain.xml |  6 ++
 src/domain.c| 25 +
 2 files changed, 31 insertions(+)

diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 6795d30..b620939 100644
--- a/data/org.libvirt.Domain.xml
+++ b/data/org.libvirt.Domain.xml
@@ -40,6 +40,12 @@
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetUUIDString"/>
 
+
+  https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainAttachDeviceFlags"/>
+  
+  
+
 
   https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainCreateWithFlags"/>
diff --git a/src/domain.c b/src/domain.c
index 59118b9..cfdd820 100644
--- a/src/domain.c
+++ b/src/domain.c
@@ -292,6 +292,30 @@ virtDBusDomainSetAutostart(GVariant *value,
 return virtDBusUtilSetLastVirtError(error);
 }
 
+static void
+virtDBusDomainAttachDevice(GVariant *inArgs,
+   GUnixFDList *inFDs G_GNUC_UNUSED,
+   const gchar *objectPath,
+   gpointer userData,
+   GVariant **outArgs G_GNUC_UNUSED,
+   GUnixFDList **outFDs G_GNUC_UNUSED,
+   GError **error)
+{
+virtDBusConnect *connect = userData;
+g_autoptr(virDomain) domain = NULL;
+const gchar *xml;
+guint flags;
+
+g_variant_get(inArgs, "()", , );
+
+domain = virtDBusDomainGetVirDomain(connect, objectPath, error);
+if (!domain)
+return;
+
+if (virDomainAttachDeviceFlags(domain, xml, flags) == -1)
+return virtDBusUtilSetLastVirtError(error);
+}
+
 static void
 virtDBusDomainCreate(GVariant *inArgs,
  GUnixFDList *inFDs G_GNUC_UNUSED,
@@ -611,6 +635,7 @@ static virtDBusGDBusPropertyTable 
virtDBusDomainPropertyTable[] = {
 };
 
 static virtDBusGDBusMethodTable virtDBusDomainMethodTable[] = {
+{ "AttachDevice", virtDBusDomainAttachDevice },
 { "Create", virtDBusDomainCreate },
 { "Destroy", virtDBusDomainDestroy },
 { "GetStats", virtDBusDomainGetStats },
-- 
2.15.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] CfP for VHPC ‘18 - Papers due May 15 (extended) for the 13th Virtualization in High­-Performance Cloud Computing Workshop

[VHPC 18]

*Please accept our apologies if you receive multiple copies of this Call
for
PapersCALL
FOR PAPERS 13th Workshop on Virtualization in High­-Performance Cloud
Computing  (VHPC '18)held in conjunction with the International
Supercomputing Conference - High Performance,June 24-28, 2018, Frankfurt,
Germany.(Springer LNCS Proceedings)
Date:
June 28, 2018Workshop URL: http://vhpc.org Paper
Submission Deadline: May 15, 2018 (extended)Springer LNCS, rolling abstract
submissionAbstract/Paper Submission Link:
https://edas.info/newPaper.php?c=24355
Special Track: GPU - Accelerator
Virtualization Call for PapersVirtualization technologies constitute a key
enabling factor for flexible resource managementin modern data centers, and
particularly in cloud environments. Cloud providers need tomanage complex
infrastructures in a seamless fashion to support the highly dynamic
andheterogeneous workloads and hosted applications customers deploy.
Similarly, HPCenvironments have been increasingly adopting techniques that
enable flexible managementof vast computing and networking resources, close
to marginal provisioning cost, which isunprecedented in the history of
scientific and commercial computing.Various virtualization technologies
contribute to the overall picture in different ways: machinevirtualization,
with its capability to enable consolidation of multiple under­utilized
servers withheterogeneous software and operating systems (OSes), and its
capability to live­-migrate afully operating virtual machine (VM) with a
very short downtime, enables novel and dynamicways to manage physical
servers; OS-­level virtualization (i.e., containerization), with
itscapability to isolate multiple user­-space environments and to allow for
their co­existencewithin the same OS kernel, promises to provide many of
the advantages of machine virtualization with high levels of responsiveness
and performance; I/O Virtualization allows physical network interfaces to
take traffic from multiple VMs or containers; network virtualization, with
its capability to create logical network overlays that are independent of
theunderlying physical topology is furthermore enabling virtualization of
HPC infrastructures. PublicationAccepted papers will be published in a
Springer LNCS proceedings volume.Topics of InterestThe VHPC program
committee solicits original, high-quality submissions related
tovirtualization across the entire software stack with a special focus on
the intersection of HPCand the cloud.Major Topics- Virtualization in
supercomputing environments, HPC clusters, HPC in the cloud and grids-
OS-level virtualization and containers (LXC, Docker, rkt, Singularity,
Shifter, i.a.)- Lightweight/specialized operating systems in conjunction
with virtual machines- Novel unikernels and use cases for virtualized HPC
environments- Performance improvements for or driven by unikernels- Tool
support for unikernels: configuration/build environments, debuggers,
profilers- Hypervisor extensions to mitigate side-channel attacks
 ([micro-]architectural timing attacks, privilege escalation)- VM &
Container trust and security- Containers inside VMs with hypervisor
isolation- GPU virtualization operationalization- Approaches to GPGPU
virtualization including API remoting and hypervisor abstraction-
Optimizations of virtual machine monitor platforms and hypervisors-
Hypervisor support for heterogeneous resources (GPUs, co-processors, FPGAs,
etc.)- Virtualization support for emerging memory technologies-
Virtualization in enterprise HPC and microvisors- Software defined networks
and network virtualization- Management, deployment of virtualized
environments and orchestration (Kubernetes i.a.)- Workflow-pipeline
container-based composability - Checkpointing facilitation utilizing
containers and VMs - Emerging topics including multi-kernel approaches and
NUMA in hypervisors- Operating MPI in containers/VMs and Unikernels  -
Virtualization in data intensive computing (big data) - HPC convergence-
Adaptation of HPC technologies in the cloud (high performance networks,
RDMA, etc.)- Performance measurement, modelling and monitoring of
virtualized/cloud workloads- Latency-and jitter sensitive workloads in
virtualized/containerized environments- I/O virtualization (including
applications, SR-IOV, i.a.) - Hybrid local facility + cloud compute and
based storage systems, cloudbursting- FPGA and many-core accelerator
virtualization- Job scheduling/control/policy and container placement in
virtualized environments- Cloud reliability, fault-tolerance and
high-availability- QoS and SLA in virtualized environments- IaaS platforms,
cloud frameworks and APIs- Energy-efficient and power-aware virtualization-
Configuration management tools for containers (including in OpenStack,
Ansible, i.a.)- 

[libvirt] [PATCH libvirt v2 7/9] rpc: use the return value of virObjectRef directly

[Marc Hartmayer]

Use the return value of virObjectRef directly. This way, it's easier
for another reader to identify the reason why the additional reference
is required.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---
 src/rpc/virnetserver.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/rpc/virnetserver.c b/src/rpc/virnetserver.c
index 47ce88392b24..ec84c1f3d2b5 100644
--- a/src/rpc/virnetserver.c
+++ b/src/rpc/virnetserver.c
@@ -248,7 +248,7 @@ static void 
virNetServerDispatchNewMessage(virNetServerClientPtr client,
 if (VIR_ALLOC(job) < 0)
 goto error;
 
-job->client = client;
+job->client = virObjectRef(client);
 job->msg = msg;
 
 if (prog) {
@@ -256,7 +256,6 @@ static void 
virNetServerDispatchNewMessage(virNetServerClientPtr client,
 priority = virNetServerProgramGetPriority(prog, msg->header.proc);
 }
 
-virObjectRef(client);
 if (virThreadPoolSendJob(srv->workers, priority, job) < 0) {
 virObjectUnref(client);
 VIR_FREE(job);
-- 
2.13.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: use target.port for isa-serial

[thilo.ceston...@ts.fujitsu.com]

Hi!

> We'd generally expect to see a change to tests/qemuxml2argvtest.c for
> this. Either adding a new test data file, or updating existing data
> files if they would cover it.

Sorry! Updated my patch. Have I still missed something?
I checked the valgrind tests, but they don't fail because of my patch.
But the normal "unittest" tests pass.

Cheers,
Thilo

smime.p7s
Description: S/MIME cryptographic signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/5] po: provide custom make rules for po file management

[Daniel P . Berrangé]

Historically we have relied on autopoint/gettextize to install a
standard po/Makefile.in.in. There is very limited scope for customizing
this and it also causes a bunch of extra stuff to be pulled into
configure.ac which potentially clashes with gnulib. Writing make rules
for po file management is no more difficult than any other rules libvirt
has, so stop using autopoint/gettextize.

Signed-off-by: Daniel P. Berrangé 
---
 .gitignore   |  6 +--
 ABOUT-NLS|  1 +
 autogen.sh   |  3 +-
 bootstrap.conf   | 38 -
 configure.ac | 33 +++
 m4/virt-nls.m4   | 70 
 po/Makefile.am   | 97 
 po/{POTFILES.in => POTFILES} |  0
 po/README.md | 36 
 src/internal.h   | 16 
 src/libvirt-admin.c  |  2 +
 src/libvirt.c|  2 +
 src/util/virgettext.c|  3 +-
 tools/virt-host-validate.c   |  4 +-
 14 files changed, 228 insertions(+), 83 deletions(-)
 create mode 12 ABOUT-NLS
 create mode 100644 m4/virt-nls.m4
 create mode 100644 po/Makefile.am
 rename po/{POTFILES.in => POTFILES} (100%)
 create mode 100644 po/README.md

diff --git a/.gitignore b/.gitignore
index dd00fc5ccf..121c2caed1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,7 +37,6 @@
 .memdump
 .sc-start-sc_*
 .ycm_extra_conf.py
-/ABOUT-NLS
 /AUTHORS
 /ChangeLog
 /GNUmakefile
@@ -101,7 +100,7 @@
 /maint.mk
 /mingw-libvirt.spec
 /mkinstalldirs
-/po/*
+/po/*gmo
 /proxy/
 /python/
 /run
@@ -211,6 +210,3 @@ tags
 !/gnulib/lib/Makefile.am
 !/gnulib/tests/Makefile.am
 !/m4/virt-*.m4
-!/po/*.po
-!/po/POTFILES.in
-!/po/libvirt.pot
diff --git a/ABOUT-NLS b/ABOUT-NLS
new file mode 12
index 00..b583e276a7
--- /dev/null
+++ b/ABOUT-NLS
@@ -0,0 +1 @@
+po/README.md
\ No newline at end of file
diff --git a/autogen.sh b/autogen.sh
index 1183b13083..9afad8f9d5 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -127,8 +127,7 @@ if test -d .git || test -f .git; then
 expected_hash=$(cat "$state_file" 2>/dev/null)
 actual_hash=$(gnulib_hash "$no_git")
 
-if test "$actual_hash" = "$expected_hash" && \
-   test -f po/Makevars && test -f AUTHORS; then
+if test "$actual_hash" = "$expected_hash" && test -f AUTHORS; then
 # The gnulib hash matches our expectations, and all the files
 # that can only be generated through bootstrap are present:
 # we just need to run autoreconf. Unless we're performing a
diff --git a/bootstrap.conf b/bootstrap.conf
index 0bfa7941f6..9559922fce 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -58,7 +58,6 @@ getopt-posix
 getpass
 getpeername
 getsockname
-gettext-h
 gettimeofday
 gitlog-to-changelog
 gnumakefile
@@ -132,16 +131,6 @@ waitpid
 warnings
 '
 
-# Additional xgettext options to use.  Use "\\\newline" to break lines.
-XGETTEXT_OPTIONS=$XGETTEXT_OPTIONS'\\\
- --flag=virAsprintf:2:c-format\\\
- --from-code=UTF-8\\\
-'
-
-# This is not a GNU package, so the default bug address is invalid,
-# and the translation project is not in use.
-MSGID_BUGS_ADDRESS=libvir-list@redhat.com
-COPYRIGHT_HOLDER='Red Hat, Inc.'
 SKIP_PO=true
 
 # Enable copy-mode for MSYS/MinGW. MSYS' ln doesn't work well in the way
@@ -150,31 +139,6 @@ if test -n "$MSYSTEM"; then
 copy=true
 fi
 
-# If "AM_GNU_GETTEXT(external" or "AM_GNU_GETTEXT([external]"
-# appears in configure.ac, exclude some unnecessary files.
-# Without grep's -E option (not portable enough, pre-configure),
-# the following test is ugly.  Also, this depends on the existence
-# of configure.ac, not the obsolescent-named configure.in.  But if
-# you're using this infrastructure, you should care about such things.
-
-gettext_external=0
-grep '^[]*AM_GNU_GETTEXT(external\>' configure.ac > /dev/null &&
-  gettext_external=1
-grep '^[]*AM_GNU_GETTEXT(\[external\]' configure.ac > /dev/null &&
-  gettext_external=1
-
-if test $gettext_external = 1; then
-  # Gettext supplies these files, but we don't need them since
-  # we don't have an intl subdirectory.
-  excluded_files='
-  m4/glibc2.m4
-  m4/intdiv0.m4
-  m4/lcmessage.m4
-  m4/uintmax_t.m4
-  m4/ulonglong.m4
-  m4/visibility.m4
-  '
-fi
 
 # Tell gnulib to:
 #   require LGPLv2+
@@ -202,8 +166,6 @@ local_gl_dir=gnulib/local
 buildreq="\
 autoconf   2.59
 automake   1.9.6
-autopoint  -
-gettext0.17
 git1.5.5
 gzip   -
 libtool-
diff --git a/configure.ac b/configure.ac
index ae798faa54..0aecf68c38 100644
--- a/configure.ac
+++ b/configure.ac
@@ -257,6 +257,7 @@ LIBVIRT_ARG_LIBSSH
 LIBVIRT_ARG_LIBXML
 LIBVIRT_ARG_MACVTAP
 LIBVIRT_ARG_NETCF
+LIBVIRT_ARG_NLS
 LIBVIRT_ARG_NSS
 LIBVIRT_ARG_NUMACTL
 LIBVIRT_ARG_OPENWSMAN
@@ -298,6 +299,7 @@ LIBVIRT_CHECK_LIBSSH
 LIBVIRT_CHECK_LIBXML
 LIBVIRT_CHECK_MACVTAP
 LIBVIRT_CHECK_NETCF
+LIBVIRT_CHECK_NLS
 

[libvirt] [PATCH libvirt v2 6/9] remote/rpc: Use virNetServerGetProgram() to determine the program

[Marc Hartmayer]

Use virNetServerGetProgram() to determine the virNetServerProgram
instead of using hard coded global variables. This allows us to remove
the global variables @remoteProgram and @qemuProgram as they're now no
longer necessary.

Signed-off-by: Marc Hartmayer 
Reviewed-by: Boris Fiuczynski 
---

Note: I'm not 100% sure that there is no case where the lock for
@client is already held by the thread which is calling
virNetServerGetProgram and thus the lock order would be violated (the
lock order has to be @server -> @client in the violating case it would
be @client -> @server and therefore a deadlock might occur).

---
 src/libvirt_remote.syms |   1 +
 src/remote/remote_daemon.c  |   4 +-
 src/remote/remote_daemon.h  |   3 -
 src/remote/remote_daemon_dispatch.c | 116 +++-
 src/rpc/gendispatch.pl  |   6 ++
 src/rpc/virnetserver.c  |  23 +++
 src/rpc/virnetserver.h  |   2 +
 7 files changed, 122 insertions(+), 33 deletions(-)

diff --git a/src/libvirt_remote.syms b/src/libvirt_remote.syms
index 97e22275b980..c31b16cd5909 100644
--- a/src/libvirt_remote.syms
+++ b/src/libvirt_remote.syms
@@ -120,6 +120,7 @@ virNetServerGetCurrentUnauthClients;
 virNetServerGetMaxClients;
 virNetServerGetMaxUnauthClients;
 virNetServerGetName;
+virNetServerGetProgram;
 virNetServerGetThreadPoolParameters;
 virNetServerHasClients;
 virNetServerNew;
diff --git a/src/remote/remote_daemon.c b/src/remote/remote_daemon.c
index 31c6ce1b6179..f854a1a6981e 100644
--- a/src/remote/remote_daemon.c
+++ b/src/remote/remote_daemon.c
@@ -71,8 +71,6 @@ VIR_LOG_INIT("daemon.libvirtd");
 #if WITH_SASL
 virNetSASLContextPtr saslCtxt = NULL;
 #endif
-virNetServerProgramPtr remoteProgram = NULL;
-virNetServerProgramPtr qemuProgram = NULL;
 
 volatile bool driversInitialized = false;
 
@@ -1049,6 +1047,8 @@ int main(int argc, char **argv) {
 virNetServerPtr srv = NULL;
 virNetServerPtr srvAdm = NULL;
 virNetServerProgramPtr adminProgram = NULL;
+virNetServerProgramPtr qemuProgram = NULL;
+virNetServerProgramPtr remoteProgram = NULL;
 virNetServerProgramPtr lxcProgram = NULL;
 char *remote_config_file = NULL;
 int statuswrite = -1;
diff --git a/src/remote/remote_daemon.h b/src/remote/remote_daemon.h
index 2834da04a9ae..a2eda209683b 100644
--- a/src/remote/remote_daemon.h
+++ b/src/remote/remote_daemon.h
@@ -88,7 +88,4 @@ struct daemonClientPrivate {
 # if WITH_SASL
 extern virNetSASLContextPtr saslCtxt;
 # endif
-extern virNetServerProgramPtr remoteProgram;
-extern virNetServerProgramPtr qemuProgram;
-
 #endif /* __REMOTE_DAEMON_H__ */
diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index cf2cd0add7d6..94b9cc3377d8 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -3830,15 +3830,16 @@ remoteDispatchNodeDeviceGetParent(virNetServerPtr 
server ATTRIBUTE_UNUSED,
 }
 
 static int
-remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server 
ATTRIBUTE_UNUSED,
+remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server,
virNetServerClientPtr client,
-   virNetMessagePtr msg 
ATTRIBUTE_UNUSED,
+   virNetMessagePtr msg,
virNetMessageErrorPtr rerr)
 {
 int rv = -1;
 daemonClientEventCallbackPtr callback = NULL;
 struct daemonClientPrivate *priv =
 virNetServerClientGetPrivateData(client);
+virNetServerProgramPtr program;
 
 virMutexLock(>lock);
 
@@ -3847,10 +3848,15 @@ 
remoteDispatchConnectRegisterCloseCallback(virNetServerPtr server ATTRIBUTE_UNUS
 goto cleanup;
 }
 
+if (!(program = virNetServerGetProgram(server, msg))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("no matching program 
found"));
+goto cleanup;
+}
+
 if (VIR_ALLOC(callback) < 0)
 goto cleanup;
 callback->client = virObjectRef(client);
-callback->program = virObjectRef(remoteProgram);
+callback->program = virObjectRef(program);
 /* eventID, callbackID, and legacy are not used */
 callback->eventID = -1;
 callback->callbackID = -1;
@@ -3903,9 +3909,9 @@ 
remoteDispatchConnectUnregisterCloseCallback(virNetServerPtr server ATTRIBUTE_UN
 }
 
 static int
-remoteDispatchConnectDomainEventRegister(virNetServerPtr server 
ATTRIBUTE_UNUSED,
+remoteDispatchConnectDomainEventRegister(virNetServerPtr server,
  virNetServerClientPtr client,
- virNetMessagePtr msg ATTRIBUTE_UNUSED,
+ virNetMessagePtr msg,
  virNetMessageErrorPtr rerr 
ATTRIBUTE_UNUSED,
  

Re: [libvirt] [RFC v2] external (pull) backup API

[Nikolay Shirokovskiy]

On 12.04.2018 07:14, John Snow wrote:
> 
> 
> On 04/11/2018 12:32 PM, Eric Blake wrote:
>> On 04/03/2018 07:01 AM, Nikolay Shirokovskiy wrote:
>>> Hi, all.
>>>  
>>> 
>>>  
>>> This is another RFC on pull backup API. This API provides means to read 
>>> domain   
>>> disks in a snapshotted state so that client can back them up as well as 
>>> means
>>> to write domain disks to revert them to backed up state. The previous 
>>> version
>>> of RFC is [1]. I'll also describe the API implementation details to shed 
>>> light   
>>> on misc qemu dirty bitmap commands usage.   
>>>  
>>



[snip]


>>>
>>> Qemu can track what disk's blocks are changed from snapshotted state so on 
>>> next
>>> backup client can backup only changed blocks. 
>>> virDomainBlockSnapshotCreateXML
>>> accepts VIR_DOMAIN_BLOCK_SNAPSHOT_CREATE_CHECKPOINT flag to turn this option
>>> for snapshot which means to track changes from this particular snapshot. I 
>>> used
>>> checkpoint term and not [dirty] bitmap because many qemu dirty bitmaps are 
>>> used
>>> to provide changed blocks from the given checkpoint to current snapshot in
>>> current implementation (see *Implemenation* section for more details). Also
>>> bitmap keeps block changes and thus itself changes in time and checkpoint is
>>> a more statical terms means you can query changes from that moment in time.
>>>
>>> Checkpoints are visible in active domain xml:
>>>
>>> 
>>>   ..
>>>   
>>>   
>>>   
>>>   
>>>   ..
>>> 
>>>
> 
> It makes sense to avoid the bitmap name in libvirt, but do these indeed
> correlate 1:1 with bitmaps?
> 
> I assume each bitmap will have name=%%UUID%% ?

There is 1:1 correlation but names are different. Checkout checkpoints 
subsection
of *implementation details* section below for naming scheme.

> 
>>> Every checkpoint requires qemu dirty bitmap which eats 16MiB of RAM with 
>>> default
>>> dirty block size of 64KiB for 1TiB disk and the same amount of disk space 
>>> is used.
>>> So client need to manage checkpoints and delete unused. Thus next API 
>>> function:
>>>
>>>



[snip]



>>> First a few facts about qemu dirty bitmaps.
>>>
>>> Bitmap can be either in active or disable state. In disabled state it does 
>>> not
>>> get changed on guest writes. And oppositely in active state it tracks guest
>>> writes. This implementation uses approach with only one active bitmap at
>>> a time. This should reduce guest write penalties in the presence of
>>> checkpoints. So on first snapshot we create bitmap B_1. Now it tracks 
>>> changes
>>> from the snapshot 1. On second snapshot we create bitmap B_2 and disable 
>>> bitmap
>>> B1 and so on. Now bitmap B1 keep changes from snaphost 1 to snapshot 2, B2
>>> - changes from snaphot 2 to snapshot 3 and so on. Last bitmap is active and
>>> gets most disk change after latest snapshot.
> 
> So you are trying to optimize away write penalties if you have, say, ten
> bitmaps representing checkpoints so we don't have to record all new
> writes to all ten.
> 
> This makes sense, and I would have liked to formalize the concept in
> QEMU, but response to that idea was very poor at the time.
> 
> Also my design was bad :)
> 
>>>
>>> Getting changed blocks bitmap from some checkpoint in past till current 
>>> snapshot
>>> is quite simple in this scheme. For example if the last snapshot is 7 then
>>> to get changes from snapshot 3 to latest snapshot we need to merge bitmaps 
>>> B3,
>>> B4, B4 and B6. Merge is just logical OR on bitmap bits.
>>>
>>> Deleting a checkpoint somewhere in the middle of checkpoint sequence 
>>> requires
>>> merging correspondent bitmap to the previous bitmap in this scheme.
>>>
> 
> Previous, or next?

In short previous.

> 
> Say we've got bitmaps (in chronological order from oldest to newest)
> 
> A B C D E F G H
> 
> and we want to delete bitmap (or "checkpoint") 'C':
> 
> A B   D E F G H
> 
> the bitmap representing checkpoint 'D' should now contain the bits that
> used to be in 'C', right? That way all the checkpoints still represent
> their appropriate points in time.

I merge to previous due to definition above. "A" contains changes from
point in time A to point in time B an so no. So if you delete C in
order for B to keep changes from point in time B to point in time D
(next in checkpoint chain) you need merge C to B.

> 
> 
> The only problem comes when you delete a checkpoint on the end and the
> bits have nowhere to go:
> 
> A B C
> 
> A B _
> 
> In this case you really do lose a checkpoint -- but depending on how we
> annotate this, it may or may not be possible to delete the most recent
> checkpoint. Let's assume that the currently active bitmap 

Re: [libvirt] [PATCH 08/10] qemu: Handle genid processing during startup/launch

[John Ferlan]

On 04/12/2018 07:13 AM, Daniel P. Berrangé wrote:
> On Wed, Apr 11, 2018 at 04:10:03PM -0400, John Ferlan wrote:
>> Before we generate the command line for qemu, if the domain about to
>> be launched desires to utilize the VM Generation ID functionality, then
>> handle both the regenerating the GUID value for backup recovery (restore
>> operation) and the startup after snapshot as well as checking that the
>> genid value that's about to be placed on the command line doesn't
>> duplicate some other already running domain.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  src/qemu/qemu_driver.c  |  22 +++---
>>  src/qemu/qemu_process.c | 110 
>> +++-
>>  src/qemu/qemu_process.h |   1 +
>>  3 files changed, 126 insertions(+), 7 deletions(-)
> 
> 
>> +/* Now let's make sure the genid this domain has is not duplicitous
>> + * with something else running. */
>> +if (virDomainObjListForEach(driver->domains, qemuProcessCheckGenID, vm) 
>> < 0)
>> +return -1;
> 
> Is this really required  ?   AFAIK, the gen ID merely has to be unique within
> the scope of the installed guest disk image, not amongst all VMs that exist.
> If it was the latter, the check we're doing is pretty weak because it only
> considers one host, not VMs on every other host.   IMHO this check is not
> desirable because it adds mutex contention against every guest, into the
> start up path and other code paths too.
> 

Well it wasn't 100% clear from what I read whether it would be required.
I may have misread something along the way too with how/why the value
was being used with Active Directory and perhaps a cloned domain using
(or needing) some mechanism to distinguish between the two.

Still, in rereading the MS GenID paper again uniqueness between two
domains doesn't seem to be required (which is fine by me - I didn't like
the code either) since the AD issues seem to be time based to rolling
back using a snapshot.

John

FWIW: http://go.microsoft.com/fwlink/?LinkId=260709

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt PATCH v2 13/44] Deprecate QEMU_CAPS_DRIVE_SERIAL

[Ján Tomko]

On Thu, Apr 12, 2018 at 10:41:03AM +0200, Andrea Bolognani wrote:

On Mon, 2018-04-09 at 17:20 +0200, Ján Tomko wrote:

Implied by QEMU >= 1.2.0.

Signed-off-by: Ján Tomko 
---
 src/qemu/qemu_capabilities.c |  1 -
 src/qemu/qemu_capabilities.h |  2 +-
 src/qemu/qemu_command.c  | 20 
 tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml   |  1 -
 tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml|  1 -
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml   |  1 -
 tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml|  1 -
 tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml|  1 -
 tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml  |  1 -
 tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml  |  1 -
 tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml  |  1 -
 tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml |  1 -
 tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml  |  1 -
 tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml  |  1 -
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml |  1 -
 .../disk-drive-network-tlsx509-vxhs.args |  6 +++---
 tests/qemuxml2argvdata/disk-drive-network-vxhs.args  |  2 +-
 tests/qemuxml2argvdata/disk-scsi-disk-wwn.args   |  2 +-
 tests/qemuxml2argvtest.c |  8 +++-
 32 files changed, 17 insertions(+), 49 deletions(-)


I just realized that all of these should have a qemu: prefix in
the first line of the commit message. Before pushing, can you
please make sure they do?



I rarely use prefixes, they take up valuable space in the commit
summary.

'QEMU' is already contained in QEMU_CAPS if you're reading the single
commit summary.

If you want to see changes just from qemu, you can filter by the
src/qemu path

So what is the value they add?

Jano


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/9] Add Jansson support

[Daniel P . Berrangé]

On Thu, Mar 29, 2018 at 01:09:49AM +0200, Ján Tomko wrote:
> Prefer Jansson, but allow fallback/choice of yajl.
> 
> Support for yajl can hopefully be dropped after we ditch CentOS 6
> which has no Jansson.

Seems like we can revisit this patch series given our discusions
about supported platforms.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] conf: Actually make virDomainChrSourceDef an object

[John Ferlan]

On 04/12/2018 04:44 AM, Erik Skultety wrote:
> On Thu, Apr 12, 2018 at 09:14:50AM +0200, Michal Privoznik wrote:
>> In 2ada9ef1465f we've tried to turn virDomainChrSourceDef into
>> virObject. Well, this requires 'virObject' member to be stored on
>> the first position of the struct. This adjustment is missing in
>> the original commit leading to all sorts of funny memleaks and
>> data corruptions.
>>
>> Signed-off-by: Michal Privoznik 
>> ---
>>  src/conf/domain_conf.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>

Doh!  Thanks  I guess not only do we need a way to detect that we're
using VIR_ALLOC on an object (as Eric pointed out in my original
patches), but we really should detect when we use virObjectNew without
the virObject parent. For some reason, I have a recollection of altering
changes during my meanderings through virObject code in order to point
out more directly some misuses, but it was rejected. Although I cannot
recall if this particular instance of not having virObject parent was
addressed...

Tks -

John

>> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
>> index 89a7131fdb..1426f115ed 100644
>> --- a/src/conf/domain_conf.h
>> +++ b/src/conf/domain_conf.h
>> @@ -57,6 +57,7 @@
>>  # include "virtypedparam.h"
>>  # include "virsavecookie.h"
>>  # include "virresctrl.h"
>> +# include "virobject.h"
> 
> syntax-check fails ^here because the header is already included on line 49
> 
> With that fixed:
> Reviewed-by: Erik Skultety 
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: remove obsolete qemuMonitorMigrateToCommand

[Daniel P . Berrangé]

The last use of qemuMonitorMigrateToCommand was removed years back in

  commit 2e90c9daf9eabe15d826a48c06607acb9d18fda6
  Author: Daniel P. Berrange 
  Date:   Fri Nov 6 16:50:26 2015 +

qemu: assume support for all migration protocols except rdma

Prior to that commit, 'exec:' to used to replicate the 'unix:' protocol
by spawning 'nc'.

Signed-off-by: Daniel P. Berrangé 
---
 src/qemu/qemu_monitor.c | 31 ---
 src/qemu/qemu_monitor.h |  4 
 2 files changed, 35 deletions(-)

diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 7b647525b3..22f05222db 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -2730,37 +2730,6 @@ qemuMonitorMigrateToHost(qemuMonitorPtr mon,
 }
 
 
-int
-qemuMonitorMigrateToCommand(qemuMonitorPtr mon,
-unsigned int flags,
-const char * const *argv)
-{
-char *argstr;
-char *dest = NULL;
-int ret = -1;
-VIR_DEBUG("argv=%p flags=0x%x", argv, flags);
-
-QEMU_CHECK_MONITOR(mon);
-
-argstr = virArgvToString(argv);
-if (!argstr)
-goto cleanup;
-
-if (virAsprintf(, "exec:%s", argstr) < 0)
-goto cleanup;
-
-if (mon->json)
-ret = qemuMonitorJSONMigrate(mon, flags, dest);
-else
-ret = qemuMonitorTextMigrate(mon, flags, dest);
-
- cleanup:
-VIR_FREE(argstr);
-VIR_FREE(dest);
-return ret;
-}
-
-
 int
 qemuMonitorMigrateCancel(qemuMonitorPtr mon)
 {
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index d04148e568..9556a51341 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -784,10 +784,6 @@ int qemuMonitorMigrateToHost(qemuMonitorPtr mon,
  const char *hostname,
  int port);
 
-int qemuMonitorMigrateToCommand(qemuMonitorPtr mon,
-unsigned int flags,
-const char * const *argv);
-
 int qemuMonitorMigrateCancel(qemuMonitorPtr mon);
 
 int qemuMonitorGetDumpGuestMemoryCapability(qemuMonitorPtr mon,
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list