[occi-wg] Extraction of requirements

[Richard Davies]

> A question - if VMs are just processes (yes KVM ;-)) then can't I get
> close to the 1st two rules noted using cpulimit* (for CPU)

I agree that with cpulimit or similar you can change processor quota for a
VM's processes. I originally wrote:

> > - Set number of CPUs to 2 but allow to grow to 4 if demand exceeds
> > minimum capacity
> 
> Even harder to implement. I can't think of a common server OS which supports
> changing the number of CPU cores at runtime without a reboot.
> 
> However, changing the priority of the virtual machine versus others on the
> same virtualization host is practical whilst it is running, without any
> modification or reboot of the contained OS.

And that's basically my point - the number of virtual CPU cores visible to
the guest operating system (my first point) is something you can't change at
runtime. The amount of processor priority/physical cores/cpulimit assigned
to those virtual CPUs is something which you can.

So, if a VM boots with 2 virtual cores, then you can control priority and
timeslicing to allocate it 1/2, 1 or 2 physical cores, but will never be
able to allocate above 2 physical cores without rebooting the VM's operating
system with a higher number of virtual cores.


> 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!)?

Cheers,

Richard.