Re: Distro kernel and 'virtualization server' vs. 'server that sometimes runs virtual instances' rant (was: Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops))

[Luke S Crawford <lsc@xxxxxxxxx>]

Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> writes:

> Picture this (and assume tools exist to help you measure
> and manage it):  Each user is billed only for the resources
> they use, including RAM.  RAM "optimization" can be controlled
> by the user via a menu (or slider bar for more granularity);
> at one extreme, RAM (and more specifically page cache) is
> aggressively reduced... but only if another VM is demanding
> it.  On the other extreme, fixed maximum RAM is fully owned
> by the user, and it sits idle if not in use.  The user
> can choose dynamically whether to pay more for fast responsiveness,
> or to pay less and surrender RAM if needed elsewhere, with
> some probability for slower responsiveness.

That sounds excelent for situations where I can quickly and cheaply
move a guest from one piece of physical hardware to another.

> Does that sound more attractive to an IAAS provider?

This is useful in some cases.  Still not in mine;  see, I can't afford
shared storage, so giving me free ram that may only be free for a 
few minutes is of limited utility.   Yeah, I can use it as shared disk
cache for extra heavy disk users, but it's still a more complex model
for the customer to understand, and I can't bring up more guests on that
host.   I could give it to other people on the same host, but 
I think that might be of limited utility, as I don't know how many
customers will be willing to pay for extra capacity if that extra
capacity is only sometimes available.  

But then, I am experimenting with low-cost homebrew OpenSolaris NAS setups,
so if that works out, and I get a working live migration system together,
then this could be useful.  Not as useful as, say, some mechanisim for live 
or nearly live migration with local storage, but still useful.  

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel