[occi-wg] Extraction of requirements
samj at samj.net
Fri May 1 10:12:35 CDT 2009
I thought there were some systems that could hotplug CPUs and in any
case it's not something we need to care about-implementors can handle
runtime updates or return a HTTP error at their discretion.
There are various ways to handle memory [re|de]allocation but again
how it happens under the covers (eg balloon drivers etc) is
(fortunately) not our concern here.
Sam on iPhone
On 5/1/09, Chris Webb <chris.webb at elastichosts.com> wrote:
> Richard Davies <richard.davies at elastichosts.com> writes:
>> > and ulimit (for memory)?
>> Less interesting in this case, since the behaviour of the VM guest
>> system is less linear. What should behaviour be if the operating system
>> inside the VM believes it has 10GB of RAM, but the VM process has a ulimit
>> of 2GB. What (should?) happen when the internal VM operating system
>> allocates 2.1GB (as it believes it can!)?
> In reality it's even worse than that. Something like kvm will just mmap an
> area of address space corresponding to the physical address space it intends
> to simulate. Consequently, if you ulimit the available virtual memory below
> the level specified for the vm, it will fail to start altogether.
> Perhaps one might think of a different mechanism from ulimit -v which
> instead restricts the number of pages you're allowed to dirty, but what
> should it do when a hypervisor process attempts to write to one page too
> many? It's not a case of returning an error from a system call: you actually
> have to refuse a write to memory that's already been malloced/mmaped, so
> about all you could do is kill the process---probably not very friendly
> behaviour to export to users!
> occi-wg mailing list
> occi-wg at ogf.org
More information about the occi-wg