On Tue, Nov 20, 2018 at 1:26 PM Daniel P. Berrangé
wrote:
> On Tue, Nov 20, 2018 at 01:25:46PM +0100, Christian Ehrhardt wrote:
> > There are certain cases e.g. containers where the sysfs path might
> > exists, but might fail. Unfortunately the exact restrictions are only
> > known to libvirt whe
On Thu, Nov 22, 2018 at 05:35:58PM +0100, Erik Skultety wrote:
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892.
The problem is that we didn't put the DRI device into the namespace for QEMU to
access, but that was only a part of the issue. The other part of the issue is
that QEMU doesn't
On Thu, Nov 22, 2018 at 17:36:01 +0100, Erik Skultety wrote:
> QEMU 3.1 introduced the 'query-display-options' QMP command which in
> itself isn't of any use to us since it can only provide information
> during runtime as the information is based on what appears on the
> cmdline. However, just by h
On Thu, Nov 22, 2018 at 05:36:07PM +0100, Erik Skultety wrote:
+
+/* Until QEMU 3.1, there wasn't any support for the 'rendernode' option on
+ * the cmdline, so don't bother picking one, the user is responsible for
+ * ensuring the correct permissions on the DRI devices.
+ */
+
On Thu, Nov 22, 2018 at 05:36:05PM +0100, Erik Skultety wrote:
Just like for SPICE, we need to put the DRI device into the namespace,
otherwise it will be left out from the DAC relabeling process.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_domain.c | 15 +++
1 file changed, 11 in
On Thu, Nov 22, 2018 at 05:36:02PM +0100, Erik Skultety wrote:
Now that we have QAPI introspection of display types in QEMU upstream,
we can check whether the 'rendernode' option is supported with
egl-headless display type.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_capabilities.c | 2 ++
sr
On Thu, Nov 22, 2018 at 05:36:01PM +0100, Erik Skultety wrote:
QEMU 3.1 introduced the 'query-display-options' QMP command which in
itself isn't of any use to us since it can only provide information
during runtime as the information is based on what appears on the
cmdline. However, just by havin
[I see you're taking the Peter approach to prefixes]
On Thu, Nov 22, 2018 at 05:36:00PM +0100, Erik Skultety wrote:
Up until now, we formatted 'rendernode=' onto QEMU cmdline only if the
user specified it in the XML, otherwise we let QEMU do it for us. This
causes permission issues because by de
On Thu, Nov 22, 2018 at 05:35:59PM +0100, Erik Skultety wrote:
+char *
+virHostGetDRMRenderNode(void)
+{
+char *ret = NULL;
+DIR *driDir = NULL;
+const char *driPath = "/dev/dri";
+struct dirent *ent = NULL;
+int dirErr = 0;
+bool have_rendernode = false;
+
+if (virDir
On Thu, Nov 22, 2018 at 04:46:33PM +0100, Jiri Denemark wrote:
Since commit v4.3.0-336-gc84726fbdd all
{hypervisor-,}cpu-{baseline,compare} commands use a generic
vshExtractCPUDefXMLs helper for extracting individual CPU definitions
from the provided input file. The helper wraps the input file in
QEMU 3.1 introduced the 'query-display-options' QMP command which in
itself isn't of any use to us since it can only provide information
during runtime as the information is based on what appears on the
cmdline. However, just by having the command in place allows us to
introspect the @DisplayOption
Just like for SPICE, we need to change the permissions on the DRI device
used as the @rendernode for egl-headless graphics type.
Signed-off-by: Erik Skultety
---
src/security/security_dac.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/security/se
Now that we have QAPI introspection of display types in QEMU upstream,
we can check whether the 'rendernode' option is supported with
egl-headless display type.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
2 files changed, 3 insertions
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892.
The problem is that we didn't put the DRI device into the namespace for QEMU to
access, but that was only a part of the issue. The other part of the issue is
that QEMU doesn't support specifying 'rendernode' for egl-headless yet (some
patch
Just like for SPICE, we need to put the render node DRI device into the
the cgroup list so that users don't need to add it manually via
qemu.conf file.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_cgroup.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src
Signed-off-by: Erik Skultety
---
docs/news.xml | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 4406aeb775..0a98e5b963 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -70,6 +70,19 @@
+
+
+ Start sel
Up until now, we formatted 'rendernode=' onto QEMU cmdline only if the
user specified it in the XML, otherwise we let QEMU do it for us. This
causes permission issues because by default the /dev/dri/renderDX
permissions are as follows:
crw-rw. 1 root video
There's literally no reason why it s
Just like for SPICE, we need to put the DRI device into the namespace,
otherwise it will be left out from the DAC relabeling process.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_domain.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_domain.
We don't need a new input source, hence the symlink, we just need a new
.args output, since the functionality is determined by a QEMU capability.
Signed-off-by: Erik Skultety
---
src/util/virutil.h| 2 +-
...cs-egl-headless-rendernode-autoselect.args | 26 +++
This is the first step towards libvirt picking the first available
render node instead of QEMU. It also makes sense for us to be able to do
that, since we allow specifying the node directly for SPICE, so if
there's no render node specified by the user, we should pick the first
available one. The al
We're going to need a bit more logic for egl-headless down the road so
prepare a helper just like for the other display types.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_command.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_command.c
Since we need to specify the rendernode option onto QEMU cmdline, we
need this union member to retain consistency in how we build the
cmdline.
Signed-off-by: Erik Skultety
---
src/conf/domain_conf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_c
Depending on whether QEMU actually supports the option, we need to pick
the first available rendernode first.
Signed-off-by: Erik Skultety
---
src/qemu/qemu_command.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_command.
Since commit v4.3.0-336-gc84726fbdd all
{hypervisor-,}cpu-{baseline,compare} commands use a generic
vshExtractCPUDefXMLs helper for extracting individual CPU definitions
from the provided input file. The helper wraps the input file in a
element so that several independent elements can be easily
pa
On Thu, Nov 22, 2018 at 01:55:02PM +0100, Christian Ehrhardt wrote:
> virt-aa-helper needs to grant QEMU access to VFIO MDEV devices.
>
> This extends commit 74e86b6b which only covered PCI hostdevs for VFIO-PCI
> assignment by now also covering vfio MDEVs.
> It has still the same limitations regar
There are some checks done when parsing a migration cookie. For
instance, one of the checks ensures that the domain is not being
migrated onto the same host. If that is the case, then we are in
big trouble because the @vm is the same domain object used by
source and it has some jobs sets and everyt
There are several functions called in the cleanup path. Some of
them do report error (e.g. qemuDomainRemoveInactiveJob()) which
may result in overwriting an error reported earlier with some
less useful message.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_migration.c | 3 +++
1 file changed
If migration is cancelled or confirm phase fails the domain
should be kept on the source even if VIR_MIGRATE_UNDEFINE_SOURCE
was requested.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_migration.c
This started as a report on #virt that the following command makes
libvirt lose domain and which is worse - remove its XML!
virsh migrate --offline --undefinesource --persistent $dom
qemu+tcp://localhost/system
Turns out, there are two problems. The first one is that we try to add
incoming dom
The function currently takes virDomainObjPtr because it's using
both: the domain definition and domain private data.
Unfortunately, this means that in prepare phase we can't parse
migration cookie before putting incoming domain def onto domain
objects list (addressed in the very next commit). Chang
virt-aa-helper needs to grant QEMU access to VFIO MDEV devices.
This extends commit 74e86b6b which only covered PCI hostdevs for VFIO-PCI
assignment by now also covering vfio MDEVs.
It has still the same limitations regarding the device lifecycle, IOW we're
unable to predict the actual VFIO device
On 11/22/18 11:32 AM, Christian Ehrhardt wrote:
On Thu, Nov 22, 2018 at 11:27 AM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
For vfio MDEVs we need to allow qemu the vfio access in apparmor.
This is extending the older fix 74e86b6b: "Fix apparmor profile
to make vfio pci pass
On Thu, Nov 22, 2018 at 11:27:36AM +0100, Christian Ehrhardt wrote:
> For vfio MDEVs we need to allow qemu the vfio access in apparmor.
How about:
"Apparmor needs to be able to grant QEMU access to VFIO MDEV devices."
>
> This is extending the older fix 74e86b6b: "Fix apparmor profile
This exten
On Thu, Nov 22, 2018 at 11:27 AM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
> For vfio MDEVs we need to allow qemu the vfio access in apparmor.
>
> This is extending the older fix 74e86b6b: "Fix apparmor profile
> to make vfio pci passthrough work" which was for VFIO PCI
> passt
For vfio MDEVs we need to allow qemu the vfio access in apparmor.
This is extending the older fix 74e86b6b: "Fix apparmor profile
to make vfio pci passthrough work" which was for VFIO PCI
passthrough on static hostdevs to now also cover vfio MDEVs.
It is having the same limitations of the lifecycl
hi,
after watching Johns slides from the kvm forum (thanks for that) i had
some quick look at the backup-v3 branch. Just to provide some feebdack
for you guys, and some questions.
My main question is about the part of the NBD backup. By default what
you get from reading all the NDB data is a thic
36 matches
Mail list logo
