[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] capabilities of xen migration


  • To: xen-api@xxxxxxxxxxxxx
  • From: George Shuklin <george.shuklin@xxxxxxxxx>
  • Date: Wed, 21 Mar 2012 05:43:36 +0400
  • Delivery-date: Wed, 21 Mar 2012 01:43:43 +0000
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xen.org>

On 20.03.2012 23:35, Brendan Morrison wrote:
Hello all, I have recently finished a project researching solutions to perform virtual machine migration across ip subnets whileÂmaintainingÂtcp/ip connections. I am currently looking into continuing this work at a masters level and/ or using it for the google summer of code under either organization debian, or Gentoo. Anyways the current virtualization tecknology used is KVM and it is a limiting factor in our design. As such I am trying to look into other free open sourceÂtechnologiesÂI can use for virtualization.Â

Basically I amÂwonderingÂthe current capabilities of XEN mainly for live migration purposes and more specifically if there is any capability that wouldÂallowÂme to migrate a VM while it is running and upon completion of migration be left with 2 instances of the VM running?Â

I understand that the two machines will obviously not be synchronized .. unless thats possible too? But I am woundering what current built in capabilities are as I would much rather focus on the networking side of the problem and limit the hacking to the currentÂmigrationÂtechnologies toÂimproveÂthe design as this networking is more to where my expertise reside.Â
Thanks in advanceÂ
brendanÂ


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

I see no specific problem with this. Any migration at the end is just 'create new domain', 'copy', 'destroy old domain'. You can modify xapi sources or xen sources not to wait death of original domain, but just change it uuid to 'technical' to avoid confusion. The main problem is that migration is usually solution to free node for maintenance, so 'leftover' domain will die...

I thought about way to do that type of migration, and the simplest way I found (without modifying toolstack or deep changing in guest domain) is just use a /32 networks (IPv4). In that case all packets will be routed via gateway (outside designated network). During migration route will be just replaced with new route table in guest domain and router(s).

If you do that, all traffic (except few dropped packets, which is not problem for TCP) will be routed to new designation and accepted by guest.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.