Re: [Fedora-livecd-list] PATCH: Disk (appliance) creator tool

[Douglas McClendon <dmc fedora filteredperception org>]

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