On Sat, Oct 22, 2011 at 06:30:00AM -0500, Clint Billedeaux wrote:
> On Fri, Oct 21, 2011 at 7:54 PM, Ron Johnson <ron.l.johnson@cox.net> wrote:
>
>>>> What distro do you like? Use that.
>>>>
>>>> Thanks Joey, all this effort to host a linux user group, and you fall
>>>> back
>>>>
>>> on..."what do you like?"
>>>
>>> See, I figure the Linux community probably has some interesting flavors
>>> out
>>> there that I could use as just the tiniest little boot OS so that I can
>>> assign more RAM to the virtual machine.
>>>
>>>
>> Except that's manifestly *NOT* what you asked in your 13:58 email.
>>
>> Thus, "we" don't appreciated surprise and anger when "we" answer the
>> question you actually asked instead of the question that you needed.
>>
>>
> First, I'm neither surprised nor angry. I'm merely realizing the poor
> communication on my part and attempting to emphasize how poorly I framed my
> request by altering it. My apologies. Second, answer no more questions
> from me. You have made it clear that I'm an ass and one who should do his
> own homework.
Clint,
James has it right. It depends on what you want to do. Recently, I
took a survey of VMS hosts out there, and some were using qemu on KVM
to provide images to PAYING customers. It may be an options for you.
To answer what distro, that might depends on what distro provides the
environment that makes KVM most stable; this is likely your best route
to the answer.
I am sure there are many "tiny" distros out there that will support
KVM, but stability is likely more important than strictly the amount
of memory made available. Also note, it's not just about memory.
Think about this; if you have a 4 core machine, you shouldn't run more
than 3 images if you expect to have "good performance"; further more,
the host OS treats each image as a very resource remanding program. If
more than one of the images is doing heavy I/O or heavy networking,
forget about it. Furthermore, even if you have allocated enough physical
memory to map more than 1:1 to VM memory, you don't have unfettered
access to this memory on the VMs because you are actually contributing
to a great amount of memory contention on the host OS.
Imagine 3 I/O, memory, and networking intensive things happening on
each VM; the host OS has to manage what is sees to be 3 extremely
resource intensive processes. Memory contention can be somewhat
alleviated by pinning the VM process to a particular core, but that's
just taking advantage of the locality of data. It doesn't address
memory paging issues brought in by heavy memory use of multiple
processes; it also doesn't address the bottle necks at the networking
or I/O level.
So, if you *really* want to properly isolate each VM image, you can't
even use a host OS because it just gets in the way. You need something
like Xen or hypervisor that serves as a very basic layer without
trying to do it's own memory or process management (like an OS would);
this still doesn't address the physical limitations imposed by the
network or the I/O.
I have used Virtual Box to develop locally and to play, but have done
so only locally. I love it; but then again, I don't have to create a
VM farm.
My employer makes extensive use of VMs for development and testing
purposes, and although they throw the best host machines and most
advanced ways of properly managing the VMs for maximal performance,
they still have issues from time to time.
A long time ago, I worked for a group that offered a managed Citrix
environment for Windows; we mostly used Linux and Solaris, but for
Windows it was about all we needed.
Anyway, my point is that it's not about just memory. No Linux out
there will provide any VM environment with the sort of efficient
underlying hardware managemnet because, frankly, the Linux kernel
sucks at this.
Brett
PS: don't let people make you feel like an ass; create a filter and
pretend like the world is free of old curmudgeons. You won't lose out
on any actual technical answers, I can tell you that.
>
> Thanks.
> Clint
>
>
>
>> --
>> Supporting World Peace Through Nuclear Pacification
>>
>> ___________________
>> Nolug mailing list
>> nolug@nolug.org
>>
-- B. Estrade <estrabd@gmail.com> ___________________ Nolug mailing list nolug@nolug.orgReceived on 10/23/11
This archive was generated by hypermail 2.2.0 : 10/23/11 EDT