| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
Re: [Xen-API] [RFC] Ballooning and live migration
Dave Scott wrote:
As for #2, I think that the following is simple enough:
* If free memory on migration target host >= VM memory target, just
transfer as is.
* If free memory on migration taget host < VM memory target, balloon
down to free memory.
I think I agree that if the memory is completely free on the target then it's
sensible to just transfer as-is.
If the memory isn't free on the target then we might have a choice about which
VMs to balloon: the VMs running on the target or the VM-to-be-migrated or both.
Do you have an opinion as to which is better? In the case of VM.start we figure
out what our target would be after the VM has started and host memory is
rebalanced, assuming no other VMs appear -- we could do a similar thing in
migrate perhaps.
Obviously that's a policy thing. I chose the principles above because
they were simple. :-)
Since we don't have any measurement of VM memory pressure at the moment,
I suppose a logical thing to do would be to treat a migration on the
target host similar to how we would treat VM creation, wrt chosing new
memory targets for running VMs, and the new VM. It's basically the same
problem, of deciding how much memory the new (to this host) VM should
have, and taking it from other VMs. The target can be chosen by the new
host, passed to the old host, and if new_target < current_target, the VM
can be ballooned down before migrating.
But I don't have an idea how complex that would be to implement. :-)
-George
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
|
|
| |
|
Home