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

[Douglas McClendon]

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