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(a)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 -=|