selinux breaks revisor

[Daniel P. Berrange]

On Thu, Jan 24, 2008 at 06:18:26PM -0600, Douglas McClendon wrote:
> Jesse Keating wrote:
> >On Thu, 24 Jan 2008 23:24:17 +0000
> >"Daniel P. Berrange" <berrange at redhat.com> wrote:
> >
> >>On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote:
> >>>On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
> >>>
> >>>>>Something to consider perhaps is the use of lguest, which is
> >>>>>currently i386 only, but does boot up nearly instantaneously,
> >>>>>and can be scripted, as its console is the launching shell.
> >>>>>
> >>>>>Is there an efficient technique for mounting a disk image so
> >>>>>that changes made to it are discarded?
> >>>>Sure, just create an LVM writable snapshot of your master image,
> >>>>and boot with that instead, and throw away the snapshot when
> >>>>you're done.
> >>>Cool.  So if there was a RPM package which contained a barebones
> >>>Fedora image and some management scripts, I don't imagine it would
> >>>be too difficult to do things like build RPMs inside that with e.g.
> >>>different SELinux policies to the host.  Any supporting RPMS
> >>>required inside the guest could be installed via a script either
> >>>from host media or over the net, then the final RPM (or whatever is
> >>>being created) could be copied back out to the host before
> >>>discarding the guest instance.
> >>>
> >>>It would not be as fast or simple as chroot, but I suspect it would
> >>>work pretty well, especially if the guest dispenses with all
> >>>non-essential startup.
> >>Actually you can do some tricks here too. You can boot the guest using
> >>the real disk image. Once it is up & running in desired state you can
> >>save the VM to disk (cf hibernate).  Launching it just becomes a case
> >>of taking a snapshot of the disk, and restoring the VM state file.
> >>Much much quicker than normal startup - a matter of seconds -
> >>depending on guest RAM  size. As long as you take care to always
> >>restore it against a snapshot of the disk from the same it was saved,
> >>you can repeat this restore process many times over. It is not
> >>entirely straightforward to do these steps in the general case, but
> >>if you want to mandate LVM storage only then it is a tractable problem
> >>
> >>Dan.
> >
> >
> >Yeah, it all sounds pretty exciting, but get back to me when it works
> >on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha...
> >
> 
> *cough* viros *cough* smirfgen *cough* qfakeroot
> 
> No, doesn't work on those archs, by since all the infra is qemu, it may 
> well get there in the foreseeable future.

Plain QEMU is unusably slow for doing any real work - particularly compute
and disk intensive stuff like builds / composes. You need KVM for it to be
viable, which restricts you to i686 / x86_64 currently, and possibly adding
ia64 & ppc64 in the medium-term future. No work on sparc/arm, and no clue
about s390.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|