On 06/09/2018 09:29 PM, intrigeri+libv...@boum.org wrote:
> From: intrigeri
>
> As reported on https://bugs.debian.org/892431, without this rule, when
> launching
> a QEMU KVM instance, an error occurs immediately upon launching the QEMU
> process such as:
>
> Could not open backing file:
Hi Intrigeri and Michal,
IMHO this is the right path as it is stage one of the two stage process to
allow images for guests with apparmor.
Stage 1:
Virt-aa-helper has to be allowed to access the paths to evaluate images for
some attributes and e.g. backing chains.
Due to that virt-aa-helper needs
---
src/lxc/lxc_container.c | 5 +
src/lxc/lxc_container.h | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 665b93a0ac..3f6be9f44d 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -113,9
Hi all,
This patch series aims to resolve
https://bugzilla.redhat.com/show_bug.cgi?id=1328946
For background information about the issue see v1 of this RFC.
https://www.redhat.com/archives/libvir-list/2018-April/msg01270.html
The current state of this series enables the start of LXC container
There is no functional change in this patch.
It only moves virLXCControllerAppendNBDPids above
virLXCControllerSetupNBDDeviceFS.
---
src/lxc/lxc_controller.c | 96
1 file changed, 49 insertions(+), 47 deletions(-)
diff --git a/src/lxc/lxc_controller.c
When user-namespace is enabled we are not allowed
to mount block/NBD devices.
Instead, mount /dev/nbdX to /run/libvirt/lxc/.root
and set:
fs->src->path = /run/libvirt/lxc/.root
fs->type = VIR_DOMAIN_FS_TYPE_MOUNT
---
src/lxc/lxc_controller.c | 62
lxcContainerPrepareRoot was introduced with commit 8dbe858
Ensure root filesystem is mounted if a file/block mount.
For a root filesystem with type=file or type=block, the LXC
container was forgetting to actually mount it, before doing
the pivot root step.
However, this method
On 06/07/18 23:14, Martin Kletzander wrote:
> @Laszlo: When thinking about it, even though it is a very stupid idea,
> technically there isn't really a difference between
> 'extended-tseg-mbytes=0' and
> 'extended-tseg-mbytes=8'
that's correct
> (of course the second option will still provide a
