qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] simulating a chroot-like interface with qemu


From: Avi Kivity
Subject: Re: [Qemu-devel] simulating a chroot-like interface with qemu
Date: Tue, 06 Jan 2009 16:05:30 +0200
User-agent: Thunderbird 2.0.0.18 (X11/20081119)

Liraz Siri wrote:
I'd like to run by you guys an idea I've been playing around with.

We've recently cut down in our use of qemu/kvm in our development
toolchain for TurnKey Linux and instead switched to using chroot for
many things, mainly because it is lighter and easier to script which
translates into reduced overhead during development.

On the flip side there are many downsides to using chroot:

* requires root privileges. You can get around this by giving a program
  suid privileges but that's dangerous because...
* root processes inside the chroot can easily break out
* processes inside the chroot share the network stack with processes
  outside the chroot.

  So for example, if mysql is running with the default configuration
  inside a VM and binds to port 3306 that will work even if the host is
  also running mysql listening to 3306. If you're using chroot  there is
  an additional overhead requiring you to reconfigure things.

* similarly, processes inside the chroot share the same abstract unix
  socket namespace, which complicates some usage scenarios...


All of these (and many more) will be fixed by the namespace work that's being merged into Linux bit by bit.

I'm thinking maybe for some uses it would be useful to simulate an
interface that looks and functions like chroot but is magically
implemented with qemu/kvm behind the scenes (e.g., separate kernel,
network stack, etc.).  Sort of a power chroot that offers stronger
isolation/compartmentalization but with a similar unixish interface
(e.g., pipeable, scriptable, etc.)

Perhaps rather than mounting a block device, the guest could access its
root in the host filesystem transparently via a network filesystem of
some kind.

You could easily use nfsroot in the guest together with -kernel and -initrd to load a guest without a block device. With -append and 'init=' you can have the guest start any script you like.


--
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]