[Libvirt] Attach qemu commands to an running xml domain
by Waleed Musa
Hi all,
I see in libvirt you are supporting attach/detach devices to existing xml domain using attachDeviceFlags and detachDeviceFlags APIs.
Now we are adding some qemu command to the xml domain related to some interfaces using alias names before starting the VM, but we will face an issue with hot plug such devices, so I have two question here:
1. Is it applicable to set the alias names for interfaces because I saw it's ignored when I add it to xml domain before starting the VM?
2. Is there a way or API to attach qemu commands to running domain as you are doing in attaching the device using attachDeviceFlags?
Example of my xml
<domain type='kvm' id='5' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<devices>
<interface type='vhostuser'>
<mac address='fa:16:3e:ac:12:4c'/>
<source type='unix' path='/var/lib/vhost_sockets/sockbbb6bbe9-eb5' mode='server'/>
<target dev='tapbbb6bbe9-eb'/>
<model type='virtio'/>
<driver queues='4' rx_queue_size='512' tx_queue_size='512'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
</devices>
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.net0.page-per-vq=on'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.net0.host_mtu=8942'/>
</qemu:commandline>
</domain>
Regards,
Waleed Mousa
Software Engineer,
Nvidia <https://www.nvidia.com/en-me/geforce/>
4 years
[PATCH] news: Update for upcoming release
by Michal Privoznik
Mention some of the stuff we dealt with in this release.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
NEWS.rst | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 71f357e39f..f823fc8575 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -33,6 +33,11 @@ v7.2.0 (unreleased)
backups (where only the difference since the last backup is copied) when
qemu adds the required functionality.
+ * Add support for audio backend specific settings
+
+ With this release new ``<audio/>`` element is introduced that allows users
+ to configure audio output for their guests.
+
* **Improvements**
* qemu: Compatibility with QEMU 6.0 for certain hot-(un)-plug operations
@@ -41,8 +46,54 @@ v7.2.0 (unreleased)
release for hotplug and hotunplug of certain devices and helpers, such as
iothreads, chardevs, RNG devices, disks with secret, ...
+ * Various improvements for embed driver
+
+ The embed driver and ``virt-qemu-run`` tool saw improvements in handling of
+ domain life cycle, temporary directories creation (important when using
+ disk secrets) and other minor fixes.
+
+ * Documentation of split daemon related config files
+
+ Split daemons read configuration files upon their start. These were never
+ documented though.
+
* **Bug fixes**
+ * Check host cpu for forbidden features
+
+ CPU feature policy did not work as expected with host-passthrough and
+ features supported by physical host. CPU features were not filtered out
+ when ``@check`` was set to ``full``.
+
+ * virNetworkUpdate() can not work with the split daemon
+
+ Due to a bug in our code, virNetworkUpdate() did not work with split daemon
+ unless management application connected to virtnetworkd directly.
+
+ * qemu: increase locked memory limit when a vDPA device is present
+
+ Just like VFIO devices, vDPA devices may need to have all guest memory
+ pages locked/pinned in order to operate properly. These devices are now
+ included when calculating the limit for memory lock.
+
+ * Don't log error if SRIOV PF has no associated netdev
+
+ Some SRIOV PFs don't have a netdev associated with them in which case
+ libvirtd reported an error and refused to start. This is now fixed.
+
+ * qemu: Only raise memlock limit if necessary
+
+ Attempting to set the memlock limit might fail if we're running
+ in a containerized environment where CAP_SYS_RESOURCE is not
+ available, and if the limit is already high enough there's no
+ point in trying to raise it anyway.
+
+ * Restore security context of swtpm.log
+
+ If a guest with emulated TPM was started and the daemon was restarted
+ afterwards, the security context of per domain swtmp.log file was not
+ restored on domain shutdown leaving it unable to be started again.
+
* virtlogd|virtlockd: Fixed crash when upgrading the daemons in-place
A bug preventing the in-place upgrade of ``virtlogd`` and ``virtlockd``
--
2.26.3
4 years
[PATCH 0/6] Remove few useless syntax-checks
by Peter Krempa
Peter Krempa (6):
syntax-check: Remove check for proper spelling of 'Red Hat'
syntax-check: Clean up check for g_auto*
syntax-check: Remove used header checks for gnulib modules
syntax-check: Remove check for prohibited 'WITH_MBRTOWC'
syntax-check: Remove unused header check for 'strings.h'
syntax-check: Remove GFDL format check
build-aux/syntax-check.mk | 134 +-------------------------------------
1 file changed, 1 insertion(+), 133 deletions(-)
--
2.29.2
4 years
[PATCH v2 00/12] libxl: bump LIBXL_API_VERSION
by Olaf Hering
Various changes to handle libxl API variants.
Olaf
v2:
- adjust names of wrapper functions
adjust indent
adjust style of braces
rename new header
Olaf Hering (12):
libxl: add API wrapper for libxl_domain_create_restore
libxl: add API wrapper for libxl_retrieve_domain_configuration
libxl: add API wrapper for libxl_domain_shutdown
libxl: add API wrapper for libxl_domain_reboot
libxl: add API wrapper for libxl_domain_pause
libxl: add API wrapper for libxl_domain_unpause
libxl: add API wrapper for libxl_domain_need_memory
libxl: add API wrapper for libxl_get_free_memory
libxl: add API wrapper for libxl_set_vcpuonline
libxl: add API wrapper for libxl_send_trigger
libxl: add API wrapper for libxl_set_memory_target
libxl: use API 4.13 to support domUs with more than 4TB
meson.build | 7 +-
src/libxl/libxl_api_wrapper.h | 217 ++++++++++++++++++++++++++++++++++
src/libxl/libxl_conf.c | 5 +-
src/libxl/libxl_domain.c | 27 +++--
src/libxl/libxl_driver.c | 25 ++--
src/libxl/libxl_migration.c | 3 +-
tests/libxlmock.c | 7 +-
7 files changed, 261 insertions(+), 30 deletions(-)
create mode 100644 src/libxl/libxl_api_wrapper.h
4 years
[PATCH-for-5.2] target/mips: Deprecate nanoMIPS ISA
by Philippe Mathieu-Daudé
The nanoMIPS ISA has been announced in 2018 for various projects:
GCC: https://gcc.gnu.org/legacy-ml/gcc/2018-05/msg00012.html
Linux: https://lwn.net/Articles/753605/
QEMU: https://www.mail-archive.com/qemu-devel@nongnu.org/msg530721.html
Unfortunately the links referenced doesn't work anymore (www.mips.com).
>From this Wayback machine link [1] we can get to a working place to
download a toolchain (a more recent release than the one referenced
in the announcement mails):
http://codescape.mips.com/components/toolchain/nanomips/2018.04-02/downlo...
The toolchain page mention LLVM but simply links http://llvm.org/
where there is no reference on nanoMIPS.
The only reference in the GCC mailing list, is the nanoMIPS
announcement: https://gcc.gnu.org/pipermail/gcc/2018-May.txt
The developer who authored the announcements have been emailed [2]
to ask for more information but all their emails are now bouncing:
- Your message to Stefan.Markovic(a)mips.com couldn't be delivered.
- Your message to smarkovic(a)wavecomp.com couldn't be delivered.
- Couldn't deliver the message to the following recipients:
Robert.Suchanek(a)mips.com, matthew.fortune(a)mips.com,
marcin.nowakowski(a)mips.com
Our deprecation policy do not allow feature removal before 2 release,
therefore declare the nanoMIPS ISA code deprecated as of QEMU 5.2.
This gives time to developers to update the QEMU community, or
interested parties to step in to maintain this code.
[1] https://web.archive.org/web/20180904044530/https://www.mips.com/develop/t...
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg756392.html
Signed-off-by: Philippe Mathieu-Daudé <f4bug(a)amsat.org>
---
docs/system/deprecated.rst | 23 +++++++++++++++++++++++
MAINTAINERS | 6 +++++-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 32a0e620dbb..a26af200c73 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -310,6 +310,13 @@ to build binaries for it.
``Icelake-Client`` CPU Models are deprecated. Use ``Icelake-Server`` CPU
Models instead.
+MIPS ``I7200`` CPU Model (since 5.2)
+''''''''''''''''''''''''''''''''''''
+
+The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated
+(the ISA has never been upstreamed to a compiler toolchain). Therefore
+this CPU is also deprecated.
+
System emulator devices
-----------------------
@@ -413,6 +420,13 @@ The ``ppc64abi32`` architecture has a number of issues which regularly
trip up our CI testing and is suspected to be quite broken. For that
reason the maintainers strongly suspect no one actually uses it.
+MIPS ``I7200`` CPU (since 5.2)
+''''''''''''''''''''''''''''''
+
+The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated
+(the ISA has never been upstreamed to a compiler toolchain). Therefore
+this CPU is also deprecated.
+
Related binaries
----------------
@@ -477,6 +491,15 @@ versions, aliases will point to newer CPU model versions
depending on the machine type, so management software must
resolve CPU model aliases before starting a virtual machine.
+Guest Emulator ISAs
+-------------------
+
+nanoMIPS ISA
+''''''''''''
+
+The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain.
+As it is hard to generate binaries for it, declare it deprecated.
+
Recently removed features
=========================
diff --git a/MAINTAINERS b/MAINTAINERS
index 2c22bbca5ac..4f701012eea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -227,7 +227,7 @@ R: Aleksandar Rikalo <aleksandar.rikalo(a)syrmia.com>
S: Odd Fixes
F: target/mips/
F: default-configs/*mips*
-F: disas/*mips*
+F: disas/mips.c
F: docs/system/cpu-models-mips.rst.inc
F: hw/intc/mips_gic.c
F: hw/mips/
@@ -240,6 +240,10 @@ F: include/hw/timer/mips_gictimer.h
F: tests/tcg/mips/
K: ^Subject:.*(?i)mips
+MIPS TCG CPUs (nanoMIPS ISA)
+S: Orphan
+F: disas/nanomips.*
+
Moxie TCG CPUs
M: Anthony Green <green(a)moxielogic.com>
S: Maintained
--
2.26.2
4 years
[PATCH] vm : forbid to start a removing vm
by Hogan Wang
From: Zhuang Shengen <zhuangshengen(a)huawei.com>
When a vm is doing migration phase confirm, and then start it concurrently,
it will lead to the vm out of libvirtd control.
Cause Analysis:
1. thread1 migrate vm out.
2. thread2 start the migrating vm.
3. thread1 remove vm from domain list after migrate success.
4. thread2 acquired the vm job success and start the vm.
5. cannot find the vm any more by 'virsh list' command. Actually,
the started vm is not exist in the domain list.
Solution:
Check the vm->removing state before start.
Signed-off-by: Zhuang Shengen <zhuangshengen(a)huawei.com>
Reviewed-by: Hogan Wang <hogan.wang(a)huawei.com>
---
src/qemu/qemu_driver.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d1a3659774..a5dfea94cb 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -6637,6 +6637,12 @@ qemuDomainCreateWithFlags(virDomainPtr dom, unsigned int flags)
goto endjob;
}
+ if (vm->removing) {
+ virReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("domain is already removing"));
+ goto endjob;
+ }
+
if (qemuDomainObjStart(dom->conn, driver, vm, flags,
QEMU_ASYNC_JOB_START) < 0)
goto endjob;
--
2.23.0
4 years
Ways to deal with broken machine types
by Igor Mammedov
On Tue, 23 Mar 2021 16:04:11 +0100
Thomas Lamprecht <t.lamprecht(a)proxmox.com> wrote:
> On 23.03.21 15:55, Vitaly Cheptsov wrote:
> >> 23 марта 2021 г., в 17:48, Michael S. Tsirkin <mst(a)redhat.com> написал(а):
> >>
> >> The issue is with people who installed a VM using 5.1 qemu,
> >> migrated to 5.2, booted there and set a config on a device
> >> e.g. IP on a NIC.
> >> They now have a 5.1 machine type but changing uid back
> >> like we do will break these VMs.
> >>
> >> Unlikley to be common but let's at least create a way for these people
> >> to used these VMs.
> >>
> > They can simply set the 5.2 VM version in such a case. I do not want to
> let this legacy hack to be enabled in any modern QEMU VM version, as it violates ACPI specification and makes the life more difficult for various other software like bootloaders and operating systems.
>
> Yeah here I agree with Vitaly, if they already used 5.2 and made some configurations
> for those "new" devices they can just keep using 5.2?
>
> If some of the devices got configured on 5.1 and some on 5.2 there's nothing we can
> do anyway, from a QEMU POV - there the user always need to choose one machine version
> and fix up the device configured while on the other machine.
According to testing it appears that issue affects virtio drivers so it may lead to
failure to boot guest (and there was at least 1 report about virtio-scsi being affected).
Let me hijack this thread for beyond this case scope.
I agree that for this particular bug we've done all we could, but
there is broader issue to discuss here.
We have machine versions to deal with hw compatibility issues and that covers most of the cases,
but occasionally we notice problem well after release(s),
so users may be stuck with broken VM and need to manually fix configuration (and/or VM).
Figuring out what's wrong and how to fix it is far from trivial. So lets discuss if we
can help to ease this pain, yes it will be late for first victims but it's still
better than never.
I'll try to sum up idea Michael suggested (here comes my unorganized brain-dump),
1. We can keep in VM's config QEMU version it was created on
and as minimum warn user with a pointer to known issues if version in
config mismatches version of actually used QEMU, with a knob to silence
it for particular mismatch.
When an issue becomes know and resolved we know for sure how and what
changed and embed instructions on what options to use for fixing up VM's
config to preserve old HW config depending on QEMU version VM was installed on.
some more ideas:
2. let mgmt layer to keep fixup list and apply them to config if available
(user would need to upgrade mgmt or update fixup list somehow)
3. let mgmt layer to pass VM's QEMU version to currently used QEMU, so
that QEMU could maintain and apply fixups based on QEMU version + machine type.
The user will have to upgrade to newer QEMU to get/use new fixups.
In my opinion both would lead to explosion of 'possibly needed' properties for each
change we introduce in hw/firmware(read ACPI) and very possibly a lot of conditional
branches in QEMU code. And I'm afraid it will become hard to maintain QEMU =>
more bugs in future.
Also it will lead to explosion of test matrix for downstreams who care about testing.
If we proactively gate changes on properties, we can just update fixup lists in mgmt,
without need to update QEMU (aka Insite rules) at a cost of complexity on QMEU side.
Alternatively we can be conservative in spawning new properties, that means creating
them only when issue is fixed and require users to update QEMU, so that fixups could
be applied to VM.
Feel free to shoot the messenger down or suggest ways how we can deal with the problem.
4 years
[PATCH] NEWS: Mention fix for exec-restart of virtlo(g|ck)d and 'object_add' improvements
by Peter Krempa
Mention that libvirt-7.2 will be needed to do stuff that executes
'object-add'/'object-del' QMP commands with the upcoming qemu-6.0 and
that exec-restart of virtlockd and virtlogd was fixed.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
NEWS.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 2142cbd21e..1c4186917e 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -35,8 +35,20 @@ v7.2.0 (unreleased)
* **Improvements**
+ * qemu: Compatibility with ``qemu-6.0`` for certain hot-(un)-plug operations
+
+ Libvirt ``7.2.0`` is required for compatibility with the upcoming
+ ``qemu-6.0`` release for hotplug and hotunplug of certain devices and
+ helpers, such as iothreads, chardevs, RNG devices, disks with secret, ...
+
* **Bug fixes**
+ * virtlogd|virtlockd: Fixed crash when upgrading the daemons in-place
+
+ A bug preventing the in-place upgrade of ``virtlogd`` and ``virtlockd``
+ daemons was fixed, so they can again be upgraded without dropping the log
+ file descriptors or locks on files.
+
v7.1.0 (2021-03-01)
===================
--
2.29.2
4 years
Entering freeze for libvirt-7.2.0
by Jiri Denemark
I have just tagged v7.2.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
4 years
[PATCH] qemu: don't reject virtiofs for qemu:///session
by Cole Robinson
Currently libvirt rejects attempts to use virtiofs with
qemu:///session. Indeed virtiofs does not have a chance of working
with typical session usage, because virtiofsd needs multiple linux
capabilities to perform its job. The only way to do this with out
of the box qemu packaging is to run virtiofsd as root, so libvirtd
must run as root, so qemu:///system is required.
But it's possible that a custom environment could setuid or set
file capabilities on the virtiofsd binary. In this case qemu:///session
would work fine. This may be an option for kubevirt to help them
transition to using qemu:///session everywhere
Drop the two pieces that block virtiofs for qemu:///session. Attempts
to use virtiofs for stock qemu:///session will fail at qemu startup,
though it's a bit opaque:
error: Failed to start domain 'f32'
error: internal error: qemu unexpectedly closed the monitor: 2021-03-26T16:26:12.459293Z qemu-system-x86_64: -device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=/foovirtiofs,bus=pci.10,addr=0x0: Failed to write msg. Wrote -1 instead of 12.
2021-03-26T16:26:12.459317Z qemu-system-x86_64: -device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=/foovirtiofs,bus=pci.10,addr=0x0: vhost_dev_init failed: Operation not permitted
Signed-off-by: Cole Robinson <crobinso(a)redhat.com>
---
The SetUID/SetGID bits don't seem to be necessary for qemu:///system
usage AFAICT, but it's a bit tough to decode virSetUIDGIDWithCaps.
virtiofsd is meticulous about managing its capability set though
src/qemu/qemu_validate.c | 7 +------
src/qemu/qemu_virtiofs.c | 4 ----
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index 6043f974ce..d4079f6b67 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -4053,7 +4053,7 @@ qemuValidateDomainDeviceDefGraphics(const virDomainGraphicsDef *graphics,
static int
qemuValidateDomainDeviceDefFS(virDomainFSDefPtr fs,
const virDomainDef *def,
- virQEMUDriverPtr driver,
+ virQEMUDriverPtr driver G_GNUC_UNUSED,
virQEMUCapsPtr qemuCaps)
{
if (fs->type != VIR_DOMAIN_FS_TYPE_MOUNT) {
@@ -4107,11 +4107,6 @@ qemuValidateDomainDeviceDefFS(virDomainFSDefPtr fs,
_("virtiofs does not yet support read-only mode"));
return -1;
}
- if (!driver->privileged) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("virtiofs is not yet supported in session mode"));
- return -1;
- }
if (fs->accessmode != VIR_DOMAIN_FS_ACCESSMODE_PASSTHROUGH) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("virtiofs only supports passthrough accessmode"));
diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c
index 2e239cad66..0bb4e3c0d1 100644
--- a/src/qemu/qemu_virtiofs.c
+++ b/src/qemu/qemu_virtiofs.c
@@ -214,10 +214,6 @@ qemuVirtioFSStart(virLogManagerPtr logManager,
if (!(cmd = qemuVirtioFSBuildCommandLine(cfg, fs, &fd)))
goto cleanup;
- /* so far only running as root is supported */
- virCommandSetUID(cmd, 0);
- virCommandSetGID(cmd, 0);
-
virCommandSetPidFile(cmd, pidfile);
virCommandSetOutputFD(cmd, &logfd);
virCommandSetErrorFD(cmd, &logfd);
--
2.30.2
4 years
