[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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))
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |