On Thu, 2009-05-28 at 18:23 -0400, Luke S Crawford wrote:
> Tim Post <echo@xxxxxxxxxxxx> writes:
>
> > What, exactly is cowboy hackery? A dom-0 that might be a little slower
> > if you boot it without Xen?
>
> No, I mean like Debian's 2.6.27 Dom0. As far as I can tell,
> they imported the SUSE Xen patch once, and have not pulled any of SUSE's
> bugfixes since. By all reports, it works fine, and is excellent as a
> desktop OS. However, it's not something I want on the server where
> reboots cost me money.
One of the biggest problems is having to go out of tree to get a usable
dom-0, then you deploy it .. then you find interesting bugs a week
later. I think everyone right now is just crossing their fingers.
> But why make the default something that will crash the server?
That's really something for the various distros to address too.
> > I don't have this problem. I export PV guest vitals over xenbus and set
> > up watches on them. As for overcommitment, the first step is knowing how
> > much memory each domain's kernel has actually promised to running
> > processes. That much is already in the tree.
>
> That only solves half of the problem and gets you back to where
> you are with FreeBSD jails/unionfs (well, also my users run their own
> kernels and have full control over userland.) Even with that problem
> solved, you still have the problem of disk cache, which is essential for
> acceptable performance.
Right now, what we're doing is not quite overcommitment, its more like
accounting. By placing the output of sysinfo() and more (bits
of /proc/meminfo) on Xenbus, its easy to get a bird's eye view of what
domains are under or over utilizing their given RAM. If a domain has
1GB, yet its kernel is consistently committing only 384MB (actual size),
there's a good chance that the guest would do just as well with 512MB,
depending on its buffer use. The reverse is also true. Its looking at
the whole VM big picture, including buffers, swap, etc.
Its not an automatic process, but it does allow an administrator to
better organize domains and allocate resources. In the case where you've
sold someone 1GB its not applicable .. but in an office / enterprise
setting it does make things easier.
> This is why I'm so uneasy above overcommit. Ram is not like CPU, which
> you can take away at a moments notice and give back as if (almost) nothing
> happened. (or perhaps new CPUs are just so much more powerful than I
> need that I don't notice the degridation.)
I'm the same way, I look forward to seeing the balloon driver advance,
however I'd never flip a switch to 'auto'.
> hm. Well, it is bad that I am coming across as disgruntled.
Frustrated is probably a better word.
> But
> I do think it is bad that the tools that come with xen seem to be focused
> on Xen as a desktop OS at the expense of xen as a dedicated
> virtualization server. I don't think Xen makes a particularly good
> desktop virtualization platform, and this setup unnecessarily
> raises the barrier to using Xen as a dedicated virtualization server.
The tools are the minimum needed to control and manage domains, plus an
API for those who don't want to get intimiate with the lower level
libraries.
I know they're basic, but they also present good examples and a great
opportunity to make tools that suit your exact need.
I don't quite understand why you feel they are better suited to desktop
virtualization (taking the API into consideration for multi server
setups)?
Cheers,
--Tim
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home