Thanks alot for the reply,
This sounds like a valid use case (not sure it is that useful), but we
> need to be careful. But we should make sure implementing this does not
> break anything. This means, we need to do different things depending on
> the type of the CPU definition we are asked to
This patch was originally submitted via
https://gitlab.com/libvirt/libvirt/-/merge_requests/19
That merge request contains additional information, if you find the
commit message of the patch lacking in some way. It did pass CI and
the test suite four weeks ago, seems small enough, and the rebase
If a USB cdrom is configured, the media type is silently ignored,
when generating the QEMU command, so libvirt actually generates
USB disks. The main problem is, that -blockdev mechanism relies
on the device type to handle the media type, like ide-cd and
ide-hd. But there is just usb-storage.
As
On Fri, Sep 04, 2020 at 04:37:06PM +0200, Ján Tomko wrote:
virResetLastError clears the thread-local error structure, but it has no
power to remove the error from the log. It mostly should not be used
outside of public APIs where it makes sure we don't leave an error
from a previous API
On Sun, Sep 06, 2020 at 01:36:06PM +0200, Martin Kletzander wrote:
Suggested-by: Ján Tomko
Signed-off-by: Martin Kletzander
---
src/lxc/lxc_controller.c | 2 +-
src/qemu/qemu_driver.c | 7 ---
src/qemu/qemu_process.c | 10 +-
src/util/virprocess.c| 32
This was supposed to be done in commit 3791f29b085c, but I missed a spot.
Signed-off-by: Martin Kletzander
---
Pushed as trivial, also suggested here:
https://www.redhat.com/archives/libvir-list/2020-September/msg00275.html
src/qemu/qemu_process.c | 5 ++---
1 file changed, 2 insertions(+),
Suggested-by: Ján Tomko
Signed-off-by: Martin Kletzander
---
src/lxc/lxc_controller.c | 2 +-
src/qemu/qemu_driver.c | 7 ---
src/qemu/qemu_process.c | 10 +-
src/util/virprocess.c| 32 +++-
src/util/virprocess.h| 2 +-
5 files changed, 34
