selinux breaks revisor
Daniel P. Berrange
berrange at redhat.com
Fri Jan 25 00:56:37 UTC 2008
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 -=|
More information about the fedora-devel-list
mailing list