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@xxxxxxxxxx> 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 -=| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
