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@elastichosts.com> wrote:
Richard Davies <richard.davies@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg