[PATCH v2 0/3] ui: add support for 'secret' object to provide VNC/SPICE passwords
by Daniel P. Berrangé
This fixes a long standing limitation of the VNC/SPICE code which was
unable to securely accept passswords on the CLI, instead requiring use
of separate monitor commands after startup.
In v2:
- Dropped patch removing ACL commands, as it will move to a bigger
deprecation cleanup series
- Rebased and resolved conflicts
Daniel P. Berrangé (3):
ui: introduce "password-secret" option for VNC servers
ui: introduce "password-secret" option for SPICE server
ui: deprecate "password" option for SPICE server
docs/system/deprecated.rst | 8 ++++++++
qemu-options.hx | 18 ++++++++++++++++--
ui/spice-core.c | 32 ++++++++++++++++++++++++++++++--
ui/vnc.c | 23 ++++++++++++++++++++++-
4 files changed, 76 insertions(+), 5 deletions(-)
--
2.29.2
3 years, 8 months
[PATCH 0/4] ui: add support for 'secret' object to provide VNC/SPICE passwords
by Daniel P. Berrangé
This fixes a long standing limitation of the VNC/SPICE code which was
unable to securely accept passswords on the CLI, instead requiring use
of separate monitor commands after startup.
This takes the opportunity to also remove previously deprecated ACL
functionality from VNC.
Daniel P. Berrangé (4):
ui: introduce "password-secret" option for VNC servers
ui: introduce "password-secret" option for SPICE server
ui: deprecate "password" option for SPICE server
ui, monitor: remove deprecated VNC ACL option and HMP commands
docs/system/deprecated.rst | 24 ++--
docs/system/removed-features.rst | 13 +++
hmp-commands.hx | 76 -------------
monitor/misc.c | 187 -------------------------------
qemu-options.hx | 17 ++-
ui/spice-core.c | 32 +++++-
ui/vnc.c | 61 ++++------
7 files changed, 88 insertions(+), 322 deletions(-)
--
2.29.2
3 years, 8 months
[PATCH 00/23] RFC: get rid of macros when dealing with block io tunes
by Nikolay Shirokovskiy
Hi, all.
I started this work as adding missing parts/fixing issues/etc in block iotune
code but then turned to refactoring code. We use a lot of macros in this place
and if we get rid of them I belive we will have much more readable/reusable/
extendable code.
Most of macros usage is for iterating over unsigned long long values. I'm
talking about parsing/formating xml, converting from/to virTypedParameterPtr
list etc. These places do not care about tune semantics and thus we can
add tools for the said iteration. See patch [1] for the first such conversion.
Patches before it partially prepare for this conversion, partially just
improve code reuse and add missing parts.
The work on removing macros in code handling iotunes is not finished as
I wanted to get an approvement that I have taken a right direction. At the
same time series shows the potential of the approach (take a look on how
qemuDomainSetBlockIoTune and testDomainSetBlockIoTune are looking now!).
Some places like qemuDomainSetBlockIoTuneDefaults deal with fields semantics.
So we need another approach to remove macros there but it is a matter of
a different RFC.
Nikolay Shirokovskiy (23):
qemu: pass supportGroupNameOption as expected
qemu: factor out qemuValidateDomainBlkdeviotune
qemu: reuse validation in qemuDomainSetBlockIoTune
qemu: remove extra check for QEMU_BLOCK_IOTUNE_MAX
conf: factor out virDomainBlockIoTuneValidate
qemu: reuse virDomainBlockIoTuneValidate
test driver: reuse virDomainBlockIoTuneValidate
qemu: reset max iotune setting when needed
qemu: add max iotune settings check to virDomainBlockIoTuneValidate
qemu: remove iotune max checks
test driver: remove iotune max checks
qemu: prepare for removing qemuBlockIoTuneSetFlags
qemu: use group_name instead of QEMU_BLOCK_IOTUNE_SET_GROUP_NAME
qemu: remove qemuBlockIoTuneSetFlags usage in qemuDomainSetBlockIoTune
qemu: remove qemuBlockIoTuneSetFlags enum completly
conf: get rid of macros in virDomainDiskDefIotuneParse [1]
conf: get rid of macros in virDomainDiskDefFormatIotune
conf: add virDomainBlockIoTuneFromParams
conf: add virDomainBlockIoTuneToEventParams
qemu: qemuDomainSetBlockIoTune use functions to convert to/from params
test driver: remove TEST_BLOCK_IOTUNE_MAX checks
test driver: prepare to delete macros in testDomainSetBlockIoTune
test driver: testDomainSetBlockIoTune: use functions to convert
to/from params
src/conf/domain_conf.c | 303 +++++++++++++++++++++++++++++++++--------------
src/conf/domain_conf.h | 16 +++
src/libvirt_private.syms | 3 +
src/qemu/qemu_driver.c | 281 ++++++++++++-------------------------------
src/qemu/qemu_validate.c | 100 +++++++++-------
src/qemu/qemu_validate.h | 4 +
src/test/test_driver.c | 156 ++----------------------
7 files changed, 380 insertions(+), 483 deletions(-)
--
1.8.3.1
3 years, 8 months
[PATCH v3 0/4] Drop deprecated floppy config & bogus -drive if=T
by Markus Armbruster
v3:
* PATCH 1: New [Daniel]
v2:
* Rebased, straightforward conflict with commit f5d33dd51f
"hw/block/fdc: Remove the check_media_rate property" resolved
* PATCH 2: Commit message fixed [Kevin]
Markus Armbruster (3):
fdc: Drop deprecated floppy configuration
fdc: Inline fdctrl_connect_drives() into fdctrl_realize_common()
blockdev: Drop deprecated bogus -drive interface type
docs/system/deprecated.rst | 33 --
docs/system/removed-features.rst | 33 ++
include/sysemu/blockdev.h | 1 -
blockdev.c | 37 +-
hw/block/fdc.c | 73 +---
softmmu/vl.c | 8 +-
tests/qemu-iotests/172 | 31 +-
tests/qemu-iotests/172.out | 562 +------------------------------
8 files changed, 59 insertions(+), 719 deletions(-)
--
2.26.2
3 years, 8 months
[PATCH v2 00/12] qemu: Prepare for QAPIfied object-add
by Peter Krempa
QEMU plans to QAPIfy object add. This series prepares for the API change
(drop of 'props' wrapper for the object) and adds testing based on our
qemuxml2argv test data which forces the output to JSON and validates it
agains the schema.
Based on Kevin's qemu patches:
https://listman.redhat.com/archives/libvir-list/2021-February/msg01168.html
Last patch forces more files to be processed and as the summary suggest
will not be pushed.
The patch updating qemucapabilitiesdata will be updated after Kevin's
patches hit upstream repo.
Peter Krempa (12):
qemu: command: Generate commandline of 'masterKey0' secret via JSON
qemu: command: Generate commandline of 'sev0' sev-guest object via
JSON
qemu: command: Generate commandline of iothread objects JSON
qemu: capabilities: Introduce QEMU_CAPS_OBJECT_QAPIFIED
tests: qemuxml2argv: Validate generation of JSON props for object-add
qemu: command: Introduce raw JSON passthrough for '-object' for
testing
qemu: monitor: Make wrapping of 'props' of 'object-add' optional
qemuMonitorCreateObjectPropsWrap: Open-code in
qemuBuildMemoryBackendProps
qemu: monitor: Don't add 'props' wrapper if qemu has
QEMU_CAPS_OBJECT_QAPIFIED
qemumonitorjsontest: Remove bomb guarding object-add
tests: qemucapabilities: Update qemu caps for object-add qapification
[DON'T PUSH] Force-check all configs with latest capabilities
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_command.c | 326 +-
src/qemu/qemu_monitor.c | 78 +-
src/qemu/qemu_monitor.h | 4 -
src/util/virqemu.c | 48 +-
src/util/virqemu.h | 3 +-
.../caps_6.0.0.x86_64.replies | 3238 ++++++++++++-----
.../caps_6.0.0.x86_64.xml | 83 +-
tests/qemumonitorjsontest.c | 14 -
...v-missing-platform-info.x86_64-2.12.0.args | 2 +-
.../launch-security-sev.x86_64-2.12.0.args | 2 +-
tests/qemuxml2argvtest.c | 24 +-
13 files changed, 2775 insertions(+), 1054 deletions(-)
--
2.29.2
3 years, 8 months
[PATCH] XML validate that 'ramfb' has no address
by Kristina Hanicova
With this, XML fails if config video type 'ramfb' contains
address, since address is not supported for 'ramfb' video
devices. Previously it didn't raise error.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1891416
Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com>
---
src/conf/domain_validate.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c
index b4e09e21fe..c9c677ddf5 100644
--- a/src/conf/domain_validate.c
+++ b/src/conf/domain_validate.c
@@ -151,6 +151,14 @@ virDomainVideoDefValidate(const virDomainVideoDef *video,
}
}
+ if (video->type == VIR_DOMAIN_VIDEO_TYPE_RAMFB) {
+ if (video->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("address not supported for video type ramfb"));
+ return -1;
+ }
+ }
+
return 0;
}
--
2.29.2
3 years, 8 months
[PATCH] virQEMUCapsInitQMPArch: Refactor cleanup
by Yi Li
Switch to using the 'g_auto*' helpers.
Signed-off-by: Yi Li <yili(a)winhong.com>
---
src/qemu/qemu_capabilities.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 790375ac38..447cf77875 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -5044,23 +5044,18 @@ static int
virQEMUCapsInitQMPArch(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
- char *archstr = NULL;
- int ret = -1;
+ g_autofree char *archstr = NULL;
if (!(archstr = qemuMonitorGetTargetArch(mon)))
- goto cleanup;
+ return -1;
if ((qemuCaps->arch = virQEMUCapsArchFromString(archstr)) == VIR_ARCH_NONE) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Unknown QEMU arch %s"), archstr);
- goto cleanup;
+ return -1;
}
- ret = 0;
-
- cleanup:
- VIR_FREE(archstr);
- return ret;
+ return 0;
}
--
2.25.3
3 years, 8 months
[PATCH 0/4] Discourage use of some GLib functions
by Michal Privoznik
See 4/4 for the list and explanation.
Michal Prívozník (4):
qemu_shim: Replace g_file_get_contents() with virFileReadAll()
virutil: Do not use g_get_host_name() to obtain hostname
syntax-check: Update list of gethostname exceptions
docs: Discourage use of some glib functions
build-aux/syntax-check.mk | 2 +-
docs/glib-adoption.rst | 17 +++++++++++++++++
src/qemu/qemu_shim.c | 18 +++++++++++-------
src/util/virutil.c | 12 +++++++++---
4 files changed, 38 insertions(+), 11 deletions(-)
--
2.26.2
3 years, 8 months
[PATCH 00/16] Improve virStrcpy and remove virStrncpy
by Peter Krempa
Peter Krempa (16):
util: virstring: Always copy string in virStrcpy
virProcessRunInForkHelper: Use virStrcpyStatic for static buffers
sanlock: Use virStrcpy instead of virStrncpy
virDevMapperGetTargetsImpl: Use virStrcpy instead of virStrncpy
virFileLoopDeviceAssociate: Use virStrcpy instead of virStrncpy
xenParseXMDisk: Replace g_new + virStrncpy by g_strndup
test_driver: Rewrite testBuildFilename
xenParseVif: Refactor parser
xenParseSxprSound: Refactor parsing of model list
openvzReadNetworkConf: Rework parser
xenParseXLChannel: Use g_strndup instead of virStrndup
xenParseXLUSBController: Avoid use of virStrndup
xenParseXLUSB: Rewrite to avoid virStrncpy
virNetLibsshAuthenticatePrivkeyCb: Use g_autofree for 'actual_prompt'
virNetLibsshAuthenticatePrivkeyCb: Use virStrcpy instead of virStrncpy
util: virstring: Remove virStrncpy
docs/coding-style.rst | 13 ---
src/libvirt_private.syms | 1 -
src/libxl/xen_common.c | 182 +++++++++++-------------------
src/libxl/xen_xl.c | 84 ++++----------
src/libxl/xen_xm.c | 9 +-
src/locking/lock_driver_sanlock.c | 4 +-
src/openvz/openvz_conf.c | 77 +++++--------
src/rpc/virnetlibsshsession.c | 17 +--
src/test/test_driver.c | 35 +-----
src/util/virdevmapper.c | 2 +-
src/util/virfile.c | 3 +-
src/util/virprocess.c | 8 +-
src/util/virstring.c | 54 +--------
src/util/virstring.h | 5 +-
14 files changed, 137 insertions(+), 357 deletions(-)
--
2.29.2
3 years, 8 months
RFC: do we want/need the "Ptr" typedefs for internal code ?
by Daniel P. Berrangé
One of the conventions we have had since the early days of libvirt is
that every struct typedef, has a corresponding "Ptr" typedef too.
For example
typedef struct _virDomainDef virDomainDef;
typedef virDomainDef *virDomainDefPtr;
Periodically someone has questioned what the purpose of these Ptr
typedefs is, and we've not had an compelling answer, other than
that's what we've always done.
There are a few things that make me question the status quo
- If we want a const pointer, we can't use
const virDomainDefPtr def
because that expands to "struct _virDomainDef * const", which
is not what we need semantically. Instead we must write
const virDomainDef *def
It is not at all obvious why these two are different, but
none the less they are, which is confusing to contributors
To me this a compelling reason to consider the "Ptr" typedefs
a waste of time, if not actively harmful.
Please don't suggest adding virDomainDefConstPtr too !
- Writing 'virDomainDefPtr' is actually two characters more
typing than 'virDomainDef *'.
IOW these "Ptr" typedefs aren't saving us time when writing
code.
- This convention of having "Ptr" typedefs is atypical among
C projects I've worked on.
Anything that is peculiar to libvirt is another item that
new contributors need to learn, so has a cost to the
project that must be weighed against its benefit.
We can't do anything about the use "Ptr" in the include/ files because
that is public ABI. We can potentially eliminate "Ptr" types everywhere
else in the codebase, even the src/libvirt*.c files corresponding to
the public includes.
Does anyone have suggestions for how these "Ptr" typedefs are
benefiting libvirt ? Would anyone miss them ?
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 :|
3 years, 8 months
