This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] [RFC] Ballooning and live migration

To: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] [RFC] Ballooning and live migration
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 16 Jun 2010 12:23:05 +0100
Cc: Jonathan Knowles <Jonathan.Knowles@xxxxxxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Jun 2010 04:21:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <81A73678E76EA642801C8F2E4823AD21807FFE6988@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <4C0E29CF.10407@xxxxxxxxxxxxx> <81A73678E76EA642801C8F2E4823AD21807FFE6988@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20100411)
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. :-)


xen-api mailing list

<Prev in Thread] Current Thread [Next in Thread>