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

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

Hi George,

> 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

Yeah, I think it was a mix of these.

> #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.

I think we hoped that less useful data would be discarded... but I take your 
point that, if the data is useful, then it doesn't save anything :)

> 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.

Cheers,
Dave

> 
> 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

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