Re: [libvirt] [PATCH 7/8] appmor, libvirt-qemu: Add 9p support

Quoting Guido Günther (a...@sigxcpu.org): > On Thu, May 18, 2017 at 11:21:54AM -0500, Serge E. Hallyn wrote: > > Mind you I'm not crazy about this. If this could be toggled with a > > default-off config option that would seem better than always giving > > these caps to libvi

Re: [libvirt] [PATCH 7/8] appmor, libvirt-qemu: Add 9p support

Mind you I'm not crazy about this. If this could be toggled with a default-off config option that would seem better than always giving these caps to libvirt-qemu. Quoting Stefan Bader (stefan.ba...@canonical.com): > From: Serge Hallyn > > Add fowner and fsetid to

Re: [libvirt] Various apparmor related changes (part 1), version 2

Quoting Stefan Bader (stefan.ba...@canonical.com): > > Over the years there have been a bunch of changes to the > > apparmor profiles and/or virt-aa-helper which have been > > carried in Debian/Ubuntu but never made it upstream. > > > > In an attempt to clean this up and generally improve the > >

Re: [libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm

Quoting Alex Bligh (a...@alex.org.uk): On 29 Sep 2014, at 11:08, Michael S. Tsirkin m...@redhat.com wrote: On Sun, Sep 28, 2014 at 09:33:08PM +0100, Alex Bligh wrote: Hang on a second! v2 of this patch DID use a new virtual machine, called exactly that. I thought you were objecting to

Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Quoting Alex Bligh (a...@alex.org.uk): On 7 Aug 2014, at 20:26, Serge E. Hallyn se...@hallyn.com wrote: A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0

Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Quoting Alex Bligh (a...@alex.org.uk): Serge, On 7 Aug 2014, at 03:50, Serge Hallyn serge.hal...@ubuntu.com wrote: This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or

Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Quoting Alex Bligh (a...@alex.org.uk): Serge, On 7 Aug 2014, at 03:50, Serge Hallyn serge.hal...@ubuntu.com wrote: This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or

Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

Quoting Alex Bligh (a...@alex.org.uk): Serge, I don't think that is in any way a problem. Is migrating to older versions ever actually expected to work? In either case I don't think for this particular case it's a problem. Good; no; and good - respectively. (The how to handle

Re: [libvirt] [PATCH 1/1] lxc: use our own hand-rolled code in place of unlockpt and grantpt (v2)

Quoting Eric Blake (ebl...@redhat.com): +VIR_FORCE_CLOSE(*ttymaster); +VIR_FREE(*ttyName) How did this ever pass compile-testing without that semicolon? It didn't. So I fixed it. Then apparently did not do a new git format-patch before sending. Grr. ... ACK to the

Re: [libvirt] [PATCH 1/1] lxc: use our own hand-rolled code in place of unlockpt and grantpt (v2)

Quoting Eric Blake (ebl...@redhat.com): [but we still have to fix the hard-coding of gid=5 in the mount() option]. I missed something - why do we have to fix that? We don't have to fix it now, but we should fix it someday. There's nothing that says a distro has to map 'tty' to gid 5, and

Re: [libvirt] [PATCH 1/1] lxc: use our own hand-rolled code in place of unlockpt and grantpt (v2)

New version, compile-tested only tonight. I followed the suggestion about using posix_openpt(), though its manpage worries me - does libvirt need to compile on any platforms that don't have that fn? (In which case we can add the trivial define if we need to, but...) Subject: [PATCH 1/1] lxc:

Re: [libvirt] [PATCH 1/1] lxc: use our own hand-rolled code in place of unlockpt and grantpt

Quoting Eli Qiao (ta...@linux.vnet.ibm.com): hi Serge : Thanks for taking a look. I checked the code , only in lxc_controller.c call virFileOpenTtyAt(). I didn't test the path, but my suggestion is that modify the utility function in /src/util/util.c instead of adding a new

[libvirt] [PATCH 1/1] lxc: use our own hand-rolled code in place of unlockpt and grantpt (v2)

The glibc ones cannot handle ptys opened in a devpts not mounted at /dev/pts. Changelog: Oct 17: Per Eli Qiao, use VIR_ALLOC_N when appropriate, make sure to check return values, and follow coding style convention. Change lxcGetTtyGid() to return -1 on error,

Re: [libvirt] [PATCH 1/1] lxc: use our own hand-rolled code in place of unlockpt and grantpt (v2)

Quoting Eric Blake (ebl...@redhat.com): On 10/17/2011 01:04 PM, Serge E. Hallyn wrote: The glibc ones cannot handle ptys opened in a devpts not mounted at /dev/pts. Changelog: Oct 17: Per Eli Qiao, use VIR_ALLOC_N when appropriate, make sure to check return values, and follow

Re: [libvirt] [PATCH 1/2] Fix occasional container creation failure due to misuse of grantpt

Quoting Eric Blake (ebl...@redhat.com): ... of /dev/pts, then passing that fd back to the parent; the alternative solution would be to ditch glibc interfaces and do the raw ioctl calls on the master pty ourselves. Since lxc is already Linux-specific, I think that I would favor this approach

[libvirt] [PATCH 1/2] Fix occasional container creation failure due to misuse of grantpt

glibc's grantpt and ptsname cannot be used on a fd for a pty not in /dev/pts. The lxc controller tries to do just that. So if you try to start a container on a system where /dev/pts/0 is not available, it will fail. You can make this happen by opening a terminal on /dev/pts/0, and doing 'sleep

[libvirt] [PATCH 2/2] Fix type in lxc_controller

s/Mouting/Mounting. Signed-off-by: Serge Hallyn serge.hal...@canonical.com --- src/lxc/lxc_controller.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 1a56e0c..6557c07 100644 --- a/src/lxc/lxc_controller.c +++

Re: [libvirt] virsh bash completion file

Quoting Daniel P. Berrange (berra...@redhat.com): On Wed, Oct 05, 2011 at 03:17:47PM -0500, Serge E. Hallyn wrote: Hi, I've been trying out a bash autocompletion file by Geoff Low (slight hack by me, don't blame him for my hack), and it's working pretty nicely. I'm not sure where

Re: [libvirt] virsh bash completion file

Quoting Eric Blake (ebl...@redhat.com): While I'd love to see better bash completion support, I think that we should be going about it by fixing virsh to make it easier to query what completions make sense, so I'm not going to spend much time further reviewing this. Of course, others are free

Re: [libvirt] [RFC] security_dac: don't chown iso file

Quoting Serge E. Hallyn (serge.hal...@canonical.com): isos are read-only, so libvirt doesn't need to chown them. In one of our testing setups, libvirt uses mirrorred isos. Since libvirt chowns the files, (and especially does not chown them back) the mirror refuses to update the iso

Re: [libvirt] [RFC PATCH] lxc: don't return error on GetInfo when cgroups not yet set up

Quoting Daniel P. Berrange (berra...@redhat.com): The LXC controller 'main' method received the handshake FD and invokes lxcControllerRun(). This method does various setup tasks, in particular the following: if (lxcSetContainerResources(def) 0) goto cleanup;

Re: [libvirt] [Openstack] [RFC PATCH] lxc: don't return error on GetInfo when cgroups not yet set up

Haven't tested this, but I think the following patch should fix the race, by forcing lxc_driver to hang on lxcMonitorClient() until after the lxc_controller has set up the cgroups, ensuring that that happens before the driver is unlocked. (I'll test tomorrow) Index:

Re: [libvirt] [RFC PATCH] lxc: don't return error on GetInfo when cgroups not yet set up

Quoting Daniel P. Berrange (berra...@redhat.com): On Wed, Sep 28, 2011 at 02:14:52PM -0500, Serge E. Hallyn wrote: Nova (openstack) calls libvirt to create a container, then periodically checks using GetInfo to see whether the container is up. If it does this too quickly, then libvirt

Re: [libvirt] [RFC PATCH] lxc: don't return error on GetInfo when cgroups not yet set up

Quoting Daniel P. Berrange (berra...@redhat.com): On Wed, Sep 28, 2011 at 02:14:52PM -0500, Serge E. Hallyn wrote: Nova (openstack) calls libvirt to create a container, then periodically checks using GetInfo to see whether the container is up. If it does this too quickly, then libvirt

[libvirt] [RFC PATCH] lxc: don't return error on GetInfo when cgroups not yet set up

Nova (openstack) calls libvirt to create a container, then periodically checks using GetInfo to see whether the container is up. If it does this too quickly, then libvirt returns an error, which in libvirt.py causes an exception to be raised, the same type as if the container was bad. This may

[libvirt] [PATCH 1/1] lvm storage backend: handle command_names=1 in lvm.conf (v2)

[ Thanks for the feedback, Eric. Hopefully I correctly incorporated it in this version. This version still tests fine with and without lvm.conf command_names=1 ] If the regexes supported (?:pvs)?, then we could handle this by optionally matching but not returning the initial command name. But

[libvirt] [PATCH 1/1] [RFC] lvm storage backend: handle command_names=1 in lvm.conf

If the regexes supported (?:pvs)?, then we could handle this by optionally matching but not returning the initial command name. But it doesn't. So add a new char* argument to virStorageBackendRunProgRegex(). If that argument is NULL then we act as usual. Otherwise, if the string at that

[libvirt] [RFC] security_dac: don't chown iso file

isos are read-only, so libvirt doesn't need to chown them. In one of our testing setups, libvirt uses mirrorred isos. Since libvirt chowns the files, (and especially does not chown them back) the mirror refuses to update the iso. This patch prevents libvirt from chowning files. Does this seem

Re: [libvirt] lvm backed storage

Quoting Daniel P. Berrange (berra...@redhat.com): On Thu, Sep 08, 2011 at 11:00:07AM -0500, Serge Hallyn wrote: Hi, When lvm.conf has 'command_names = 1', then all results are prefixed with the command name. This confuses libvirt which does not ignore those. I thought fixing that

Re: [libvirt] Notes from the KVM Forum relevant to libvirt

Quoting Stefan Hajnoczi (stefa...@gmail.com): On Thu, Aug 25, 2011 at 11:03 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 25, 2011 at 10:10:27AM +0100, Stefan Hajnoczi wrote: On Wed, Aug 24, 2011 at 3:46 PM, Daniel P. Berrange berra...@redhat.com wrote: On Wed, Aug 24,

[libvirt] enumerating disk devices

Hi, Some people appear to have autostart VMs residing on slow storage. If libvirtd starts too early, it'll simply fail trying to start those VMs. It'd be nice to know when all the storage on which autostart containers depend becomes available, so as to safely start libvirt. The python script

Re: [libvirt] [PATCH] RFC: experimental libvirtd upstart job

Quoting Daniel P. Berrange (berra...@redhat.com): On Fri, Feb 18, 2011 at 03:48:29PM -0600, Serge E. Hallyn wrote: Quoting ape...@gmail.com (ape...@gmail.com): From: Alan Pevec ape...@redhat.com = # libvirt-cgred-wait start on starting

Re: [libvirt] [PATCH] RFC: experimental libvirtd upstart job

Quoting ape...@gmail.com (ape...@gmail.com): From: Alan Pevec ape...@redhat.com To install it, disable libvirtd sysv initscript: chkconfig libvirtd off service libvirtd stop and enable libvirtd upstart job: cp /usr/share/doc/libvirt-*/libvirtd.upstart \

Re: [libvirt] libvirt 0.8.7 tests failure on arm and ppc

Quoting Matthias Bolte (matthias.bo...@googlemail.com): 2011/2/15 Serge E. Hallyn serge.hal...@canonical.com: Hi, as per the message after the tests fail, I'm reporting this on the list.  Hopefully someone has seen this before.  I've not yet tried this with the latest git snapshot

Re: [libvirt] libvirt 0.8.7 tests failure on arm and ppc

Quoting Jiri Denemark (jdene...@redhat.com): On Tue, Feb 15, 2011 at 07:37:37 -0600, Serge E. Hallyn wrote: TEST: qemuxml2argvtest QEMU driver capabilities: capabilities host cpu archarmv7l/arch This is the problem. The code does not properly dealing with the case

Re: [libvirt] [PATCH 1/2] tests: Fake host capabilities properly

Quoting Jiri Denemark (jdene...@redhat.com): Since we fake host CPU we should also fake host arch instead of taking the real architecture tests are running on. --- tests/testutilsqemu.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) Tested-by: Serge Hallyn

Re: [libvirt] [PATCH 2/2] qemu: Fix command line generation with faked host CPU

Quoting Jiri Denemark (jdene...@redhat.com): The code expected that host CPU architecture matches the architecture on which libvirt runs. This is normally true but not in tests, where host CPU is faked to produce consistent results. --- src/qemu/qemu_command.c |8 +--- 1 files

[libvirt] libvirt 0.8.7 tests failure on arm and ppc

Hi, as per the message after the tests fail, I'm reporting this on the list. Hopefully someone has seen this before. I've not yet tried this with the latest git snapshot. With 0.8.7, I get: TEST: qemuxml2argvtest

[libvirt] [PATCH RFC] Don't use CLONE_NEWUSER for now

Until now, user namespaces have not done much, but (for that reason) have been innocuous to glob in with other CLONE_ flags. Upcoming userns development, however, will make tasks cloned with CLONE_NEWUSER far more restricted. In particular, for some time they will be unable to access files with

[libvirt] if you use user namespaces

Please let me know. lxc does not use them right now. Libvirt uses them for lxc containers f they are available, but I hope we can essentially have it stop for awhile. In addition, there's tons of software out there that I don't know about, and fear of breaking their use of current user

Re: [libvirt] [PATCH] build: avoid corrupted gnulib/tests/Makefile

Quoting Eric Blake (ebl...@redhat.com): On 01/24/2011 08:27 PM, Daniel Veillard wrote: This may be an upstream gnulib bug, where a more elegant solution will present itself in the future: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/24898 But in the meantime, I was able to

Re: [libvirt] Update to libvirt-lxc driver doc page

Quoting Eric Blake (ebl...@redhat.com): On 06/07/2010 08:55 AM, Serge Hallyn wrote: Here is a new drvlxc.html.in file to make the first example work. I'll play with the second example next. Thanks for the sample text; it looked good to me on a first read. Are you willing to finish out

Re: [libvirt] Update to libvirt-lxc driver doc page

Quoting Eric Blake (ebl...@redhat.com): On 06/07/2010 08:55 AM, Serge Hallyn wrote: Here is a new drvlxc.html.in file to make the first example work. I'll play with the second example next. Thanks for the sample text; it looked good to me on a first read. Are you willing to finish out

Re: [libvirt] Update to libvirt-lxc driver doc page

Quoting Eric Blake (ebl...@redhat.com): http://libvirt.org/git/?p=libvirt.git;a=blob;f=README-hacking Doh - I had no idea the web pages were just sitting in libvirt.git/docs! Now it all makes sense. Thanks. -serge -- libvir-list mailing list libvir-list@redhat.com

Re: [libvirt] [PATCH 2/3] New utility functions virFileCreate and virDirCreate

Quoting Laine Stump (la...@laine.org): These functions create a new file or directory with the given uid/gid. If the flag VIR_FILE_CREATE_AS_UID is given, they do this by forking a new process, calling setuid/setgid in the new process, and then creating the file. This is better than simply

Re: [libvirt] [PATCH 2/3] New utility functions virFileCreate and virDirCreate

Quoting Serge E. Hallyn (se...@us.ibm.com): Quoting Laine Stump (la...@laine.org): These functions create a new file or directory with the given uid/gid. If the flag VIR_FILE_CREATE_AS_UID is given, they do this by forking a new process, calling setuid/setgid in the new process

[libvirt] Re: kernel summit topic - 'containers end-game'

Quoting Daniel Lezcano (dlezc...@fr.ibm.com): Do you plan to do send the minutes of the ksummit ? Absolutely. Of course it's not until October. I'll be sending out a copy of the notes I take with me (including the info from this thread) beforehand. thanks, -serge -- Libvir-list mailing list

Re: [libvirt] Cannot get network to work with LXC

Quoting James Yu (cyu...@gmail.com): Hi all, I tried to use the first xml config in http://libvirt.org/drvlxc.html to Which version of libvirt were you using? Was it the one which came with your distro, and, if so, which distro? You might try installing the version from git clone

[libvirt] Re: kernel summit topic - 'containers end-game'

Quoting Oren Laadan (or...@cs.columbia.edu): Serge E. Hallyn wrote: A topic on ksummit agenda is 'containers end-game and how do we get there'. So for starters, looking just at application (and system) containers, what do the libvirt and liblxc projects want to see in kernel

[libvirt] Re: kernel summit topic - 'containers end-game'

Quoting Daniel Lezcano (dlezc...@fr.ibm.com): Serge E. Hallyn wrote: ... Checkpoint: - The initiator of the checkpoint initialize the barrier and send a signal SIGCKPT to all the checkpointable tasks and these ones will jump on the handler and block on the barrier. - When

[libvirt] Re: kernel summit topic - 'containers end-game'

Quoting Oren Laadan (or...@cs.columbia.edu): Serge E. Hallyn wrote: Quoting Oren Laadan (or...@cs.columbia.edu): Serge E. Hallyn wrote: A topic on ksummit agenda is 'containers end-game and how do we get there'. So for starters, looking just at application (and system

Re: [libvirt] kernel summit topic - 'containers end-game'

Quoting Balbir Singh (bal...@linux.vnet.ibm.com): On Tue, Jun 23, 2009 at 8:26 PM, Serge E. Hallynse...@us.ibm.com wrote: A topic on ksummit agenda is 'containers end-game and how do we get there'. So for starters, looking just at application (and system) containers, what do the

Re: [libvirt] [PATCH 4/3] Control LXC capabilities

Quoting Daniel P. Berrange (berra...@redhat.com): This patch updates the LXC driver to make use of libcap-ng for managing process capabilities. Previously Ryota Ozaki had provided code to remove the CAP_BOOT capabilities inside the container, preventing host reboots. In addition to that one,

Re: [libvirt] PATCH: Remove all getuid==0 checks from code

Quoting Daniel P. Berrange (berra...@redhat.com): This patch is preparing the way for future work on allowing the libvirtd daemon to run as a less-privileged user ID. The idea is that we will switch from 'root' to 'libvirtd', but use Linux capabilties to keep the handful of higher privileges

Re: [libvirt] [PATCH] Fix a compilation problem with LXC drop capabilities

Quoting Daniel Veillard (veill...@redhat.com): On Fri, May 29, 2009 at 04:42:54PM -0500, Serge E. Hallyn wrote: Quoting Ryota Ozaki (ozaki.ry...@gmail.com): On Fri, May 29, 2009 at 9:20 PM, Daniel Veillard veill...@redhat.com wrote:  The lxcContainerDropCapabilities() function

Re: [libvirt] [PATCH] Fix a compilation problem with LXC drop capabilities

Quoting Ryota Ozaki (ozaki.ry...@gmail.com): On Fri, May 29, 2009 at 9:20 PM, Daniel Veillard veill...@redhat.com wrote:  The lxcContainerDropCapabilities() function requires PR_CAPBSET_DROP to be defined in order to compile, but it may not be defined in older kernels. So I made the

Re: [libvirt] [RFC][PATCH] lxc: fix for ns cgroups subsystem

Quoting Ryota Ozaki (ozaki.ry...@gmail.com): I've updated the patch. The change includes support for multiple mount points of cgroups that I didn't cope with in the previous patch. Through the work, I found a bit messy problem. Current lxc controller writes pid in a 'tasks' file multiple

Re: [libvirt] [RFC][PATCH] lxc: fix for ns cgroups subsystem

Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi Serge, On Fri, May 8, 2009 at 11:48 AM, Serge E. Hallyn se...@us.ibm.com wrote: IIUC, the real problem is that src/cgroup.c assumes that the cgroup name should be $CGROUP_MOUNTPOINT/groupname.  But of course if the ns cgroup is enabled

Re: [libvirt] [RFC][PATCH] lxc: fix for ns cgroups subsystem

Quoting Daniel P. Berrange (berra...@redhat.com): On Fri, May 08, 2009 at 08:34:12AM -0500, Serge E. Hallyn wrote: Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi Serge, On Fri, May 8, 2009 at 11:48 AM, Serge E. Hallyn se...@us.ibm.com wrote: IIUC, the real problem is that src

Re: [libvirt] [RFC][PATCH] lxc: drop CAP_SYS_BOOT capability to preventrebooting from inside containers

Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi, Current lxc driver unexpectedly allows users inside containers to reboot host physical machine. This patch prevents this by dropping CAP_SYS_BOOT capability in the bounding set of the init processes in every containers. Note that the patch

Re: [libvirt] [RFC][PATCH] lxc: drop CAP_SYS_BOOT capability to preventrebooting from inside containers

Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi Serge, On Fri, May 8, 2009 at 9:12 AM, Serge E. Hallyn se...@us.ibm.com wrote: Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi, ... +    for (i = 0 ; i ARRAY_CARDINALITY(caps) ; i++) { +        if (prctl(PR_CAPBSET_DROP, caps[i].id, 0

Re: [libvirt] [PATCH] change permissions of directories in cgroups

Quoting Ryota Ozaki (ozaki.ry...@gmail.com): Hi, This patch creates a directory in cgroups with an ordinary permission 0755 (rwxr-xr-x) instead of 0655 (rw-r-xr-x). I guess 0655 is not expected and just a mistake, or is there a special reason? Haha, that sure seems like a mistake. Good

Re: [libvirt] [RFC][PATCH] lxc: fix for ns cgroups subsystem

IIUC, the real problem is that src/cgroup.c assumes that the cgroup name should be $CGROUP_MOUNTPOINT/groupname. But of course if the ns cgroup is enabled, then the unshare(CLONE_NEWNS) to create a new namespace in which to mount the new devpts locks the driver under

Re: [libvirt] PATCH: Allow LXC to use private /dev/pts instance

Quoting Daniel P. Berrange (berra...@redhat.com): This patch attached now just makes it MS_SLAVE. There's no need for the extra SHARED flag, since the only process libvirt_lxc spawns is the 'init' process inside the container and that immediately makes its own root private. Thanks, this

[libvirt] [PATCH 1/1] lxc: only do CLONE_NEWUSER when kernel supports it

I was trying to get the lxc driver to work on ubuntu jaunty. This patch gets me further than I was getting before. Like I say below, it's probably not the right way though. -serge From 2513f8a7e0654e84570fe0ef2204dabe276b9e4e Mon Sep 17 00:00:00 2001 From: root r...@jaunty.(none) Date: Fri, 17

Re: [libvirt] PATCH: Allow LXC to use private /dev/pts instance

Quoting Daniel P. Berrange (berra...@redhat.com): This change seemed to fix that problem with no ill-effects. -if (chroot(oldroot) 0) { -virReportSystemError(NULL, errno, %s, - _(failed to chroot into tmpfs)); -goto err; -} - -if

[libvirt] [PATCH] lxc: fix veth off by 1 error

When not specifying a target for veth device, veth.c:getFreeVethName() is supposed to scan for unused veth devices in /sys/class/net. However, when it finds one, it bumps the index by one before returning it. So, if you have one container running, veth0 is passed into the container, veth1 is

[libvirt] [PATCH] lxc: make the pivot_root more robust.

libvirt/lxc is broken on F11. The pivot_root() call returns -EINVAL. The below is one way we can fix it. I'm also sending another patch which takes the simpler approach of using chroot. However, chroot is trivially escapable (see for instance

[libvirt] [PATCH] lxc: use chroot instead of pivot_root

This is an alternative to the pivot_root patch which I just sent. It has the advantage of being much simpler. It also won't have a problem with the container's / being a read-only mount. It has the disadvantage, of course, of being escapable. From a91bca7f60f27e8fbdb4e3bacf3232a6cbb630d3 Mon