June 2018 - Devel - libvirt List Archives

[libvirt] [PATCH] util: storage: remove virStorageSource->tlsVerify
by Peter Krempa 01 Jun '18

01 Jun '18

Disks are client-only so we don't need to have this variable. We also always pass false for 'isListen' to qemuBuildTLSx509BackendProps for all disk-related code-paths. --- This applies on top of my branch collecting all ACKed postings of recent blockdev-related work. Current version can be fetched by: git fetch git://pipo.sk/pipo/libvirt.git blockdev-staging src/qemu/qemu_command.c | 2 +- src/qemu/qemu_domain.c | 2 -- src/qemu/qemu_hotplug.c | 3 +-- src/util/virstoragefile.c | 1 - src/util/virstoragefile.h | 1 - 5 files changed, 2 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 26e61f26f4..c75595ca6d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -774,7 +774,7 @@ qemuBuildDiskSrcTLSx509CommandLine(virCommandPtr cmd, return 0; return qemuBuildTLSx509CommandLine(cmd, src->tlsCertdir, - false, src->tlsVerify, + false, true, NULL, src->tlsAlias, qemuCaps); } diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 4368e9be35..873bcec50d 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9928,8 +9928,6 @@ qemuProcessPrepareStorageSourceTLSVxhs(virStorageSourcePtr src, if (src->haveTLS == VIR_TRISTATE_BOOL_YES) { if (VIR_STRDUP(src->tlsCertdir, cfg->vxhsTLSx509certdir) < 0) return -1; - - src->tlsVerify = true; } return 0; diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index c656409eaa..2f76c048aa 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -164,8 +164,7 @@ qemuDomainAddDiskSrcTLSObject(virQEMUDriverPtr driver, if (qemuDomainGetTLSObjects(priv->qemuCaps, NULL, src->tlsCertdir, - false, - src->tlsVerify, + false, true, src->tlsAlias, &tlsProps, NULL) < 0) goto cleanup; diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 54de2c1c30..10fe0f201a 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -2171,7 +2171,6 @@ virStorageSourceCopy(const virStorageSource *src, ret->shared = src->shared; ret->haveTLS = src->haveTLS; ret->tlsFromConfig = src->tlsFromConfig; - ret->tlsVerify = src->tlsVerify; ret->detected = src->detected; ret->debugLevel = src->debugLevel; ret->debug = src->debug; diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 1631c4cf66..4591e6e213 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -310,7 +310,6 @@ struct _virStorageSource { * certificate directory with listen and verify bools. */ char *tlsAlias; char *tlsCertdir; - bool tlsVerify; bool detected; /* true if this entry was not provided by the user */ -- 2.16.2

2 1

[libvirt] [RFC PATCH 0/9] tests: Record commands used to gather capability replies
by Peter Krempa 01 Jun '18

01 Jun '18

De-confusify the 'replies' files for human usage by recording which commands were used for gathering given block. Additionally this tests that the commands emitted by libvirt are as recorded. This series is in RFC state, since it creates some churn in the capability files and also 'tests/qemucapsfixreplies' will no longer work. Patch 8 contains the changed files for ease of review and patch 9 contains the tool used to regenerate them from the current state. Peter Krempa (9): qemu: monitor: Add possibility to reset command sequence in tests tests: qemumonitor: Simplify handling of end of file in full file test tests: qemumonitor: Optimize control flow when concatenating replies tests: qemucapsprobemock: Simplify and extract skipping of empty lines tests: qemucapsprobemock: Fail if JSON reply from qemu can't be reformatted tests: qemucapsprobemock: Prepare 'qemucapsprobe' for the new format tests: qemucapabilities: Test commands used to query capabilities FIXUP: Tweak capability files to conform to the new approach DO_NOT_APPLY: HACK: Regenerate qemucapabilitiestest data fix-files.sh | 1 + src/qemu/qemu_monitor.c | 11 + src/qemu/qemu_monitor_priv.h | 31 + tests/Makefile.am | 1 + .../qemucapabilitiesdata/caps_1.5.3.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_1.6.0.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_1.7.0.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 2 +- .../caps_2.10.0.aarch64.replies | 319 +++++- tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.10.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.10.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 +- .../caps_2.10.0.x86_64.replies | 1120 ++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.11.0.s390x.replies | 350 +++++- tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 +- .../caps_2.12.0.aarch64.replies | 328 +++++- tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.12.0.ppc64.replies | 331 +++++- tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.12.0.s390x.replies | 358 +++++- tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 +- .../caps_2.12.0.x86_64.replies | 1173 +++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 341 +++++- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 2 +- .../caps_2.6.0.aarch64.replies | 319 +++++- tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.7.0.s390x.replies | 306 ++++- tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.8.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.8.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 1120 ++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +- tests/qemucapabilitiestest.c | 17 +- tests/qemucapsprobemock.c | 77 +- tests/qemumonitortestutils.c | 52 +- 57 files changed, 10564 insertions(+), 385 deletions(-) create mode 100755 fix-files.sh create mode 100644 src/qemu/qemu_monitor_priv.h -- 2.16.2

1 10

[libvirt] Why does vnc show blackscreen after using mstsc to connect to a windows vm with a nvidia gpu passtrough
by Wu Zongyong 01 Jun '18

01 Jun '18

Hi, As the title says, VNC inside a windows virtual machine doesn’t work after I try to use mstsc to access the vm with a gpu passthrough. It seems that the scenario is normal, but could someone tell me something deeply about the reason why vnc shows blackscreen? Thanks.

1 0