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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

At the moment (and as of the latest XenServer release), when migrating a 
VM, it is first ballooned down to static-min before the migration 
happens.  I don't think this is the right behavior; my sense is that 
there's little or no benefit, and a big potential cost. So I'd like to 
open up a discussion on the topic.
I don't know the reason this behavior was decided, so I have go guess. 
Two reasons that come to mind are:
1. To reduce the network cost of migrating (lower memory -> fewer pages 
transferred)
2. To simplify logic of memory

#1 I don't think is actually true.  Migration can only happen when the 
disk is on shared storage across a network.  When the balloon driver 
inflates the balloon, dirty pages will be written to disk; and assuming 
the data was somehow useful, they'll be read back in on the other side 
when the balloon is deflated.  So on the whole, the total number of 
pages over the network won't decrease; they'll just switch from 
migration traffic to disk traffic.
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.
As for the cost: of course ballooning down has a cost, both in terms of 
cpu cycles spent, and dirty pages transferred over the network; and 
there's the cost on the other side of re-filling any pages that were 
swapped out.  Furthermore, if the working set is greater than than 
static min, then ballooning down will cause the VM to thrash for the 
period of time while it's migrating, which is much worse than having a 
slightly longer migration time.
Thoughts?

-George


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api