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@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.