[libvirt] [PATCH] util: storage: remove virStorageSource->tlsVerify
by Peter Krempa
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
7 years, 1 month
- 2
- 1
[libvirt] [RFC PATCH 0/9] tests: Record commands used to gather capability replies
by Peter Krempa
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
7 years, 1 month
- 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
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.
7 years, 1 month
- 1
- 0