On Wed, Feb 20, 2008 at 09:49:57PM -0600, Douglas McClendon wrote: > Daniel P. Berrange wrote: > > > >Some other examples of scenarios where you want to build appliance images > >but > >do not have virtualization capabilities directly accessible. > > > > - Machines where the user's primary OS is running under an embedded > > hypervisor. > > QEMU is tolerable for booting an image to verify that it works, but > > building > > the image in QEMU is too slow to be practical. > > > Obviously, since my project uses precisely that (qemu) I'll defend a > bit: Some examples of where 'too slow to be practical' is IMHO an > oversweeping generalization- > > - when a few hours or overnight is not a big deal
Yes it is a big deal because it directly impacts the amount of development and testing I can do in any single day. If it takes 15 minutes to build an image I can get through many many build & test cycles in a day. If it takes overnight then I can only do one build & test. For some people it may not be a big deal to wait overnight, but for many people it it totally impractical to wait this long. > - in the future, when qemu, either via kvm/kqemu or just plain faster > hardware, reduces the install time from hours to minutes, and the > simplicity and security of no-root-privs becomes more valuable than the > time saved using alternate methods (at least for some usage cases). KQEMU is essentially unmaintained & you can't assume access to KVM since it requires hardeware virtualization & even if your hardware has such capabilities there are plenty of scenarios where the end user will not be able to use them. > Naturally these might not be situations you are interested in, but I > think your statement of 'too slow to be practical' was an > oversimplification which you knew I would take the bait and defend ;) You're imagining things - if you choose to use QEMU for your project I've no problem with that - that's your choice to make. It is simply not practical for my day-to-day work to wait for installs inside QEMU emulator to complete. 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-livecd-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-livecd-list
