Daniel P. Berrange wrote:
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
^^^^
I thought I went far enough out of my way to subclass my points so that
you wouldn't think I was suggesting that they applied to your day to day
work.
Some people are in such a hurry that when they drive, they tailgate
people that are already going a few miles over the speedlimit. When
that happens to me, I slow way down :)
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.
Sure, but this is all one reason why I have always found qemu to be so
awesome. It has a solid fallback functionality and performance, even
when you don't have hardware assist, or root perms to throw in a kernel
driver.
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.
Sorry Dan, but YOU are imagining things. Precisely, you are imagining
that anything I said implied in any way that my style solution would be
a benefit to you over your style solutions.
What exactly was I imagining? I mean, I imagine all kinds of things,
but it sounded kind of derogatory the way you said it, like I was
imagining false technical arguments to be true.
-dmc
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
