[occi-wg] Extraction of requirements

[Sam Johnston]

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
>> operating
>> 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!
>
> Cheers,
>
> Chris.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>