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