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.
Basically smirfgen is my version of mkinitrd/mayflower, but in addition to generating initramfss that boot livecds, it generates ones which do nothing but set up sandbox so that qfakeroot can boot them up via qemu attached to one disk image used for input, one used for output (gets detarred), and one for scratch space, and one to optionally connect to a real disk device or image. There is also an option to automatically make that last one get a devicemapper snapshot layer of protection (same thing as the lvm described, but at a lower more generic layer).
And qemu gets used in nographic with console going to tty which goes to stdout (redirected internally).
The result is that it takes about a couple minutes to convert an arbitrary tarball to an ext3 filesystem image. (longer for bigger input)
Currently it pulls in a copy of the host's selinux policy to use, though it is pretty trivial to make that an option to disable, or pull in an arbitrary selinux policy.
Still very alpha, but maybe interesting to consider
-dmc