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

Re: [Xen-devel] Re: [Xen-API] FT for XCP



Thanks Shriram,

I thought of using the native VM migrate code but in that case I may end up with corruption either in NW, DIsk or Mem.
The remus page is not updated. http://nss.cs.ubc.ca/remus/hg/ I hope this project is not stopped.

I'm still learning xen-3.4.2/tools path so hopefully I'll get some direction which can save from corruption.

Regards,
R J



On Wed, Sep 28, 2011 at 9:38 PM, Shriram Rajagopalan <rshriram@xxxxxxxxx> wrote:


On Mon, Sep 26, 2011 at 8:58 AM, R J <torushikeshj@xxxxxxxxx> wrote:
Hello Mike,

Thank you for suggestion. I would love to incorporate remus in xapi if thats possible.

Great. That would be certainly welcome. [I am not a fan of ocaml ;)]

Remus as its inbuilt logic of detecting checkpoint failure and taking decisions accordingly.

I think there is remus support for xen 3.4


What matters is the toolstack.
a. I am not sure if the xe toolstack uses libxenguest (tools/libxc) and
 if it does, then it should have the basic remus support already.

b. I am also not sure if it is recent enough to include all the remus bug
fixes that went in over the last 6 months.

What do you suggest as my next step ?


Most of the remus code is python based and completely self contained. It just needs
the domU's info (disk paths & vifs) as an s-_expression_. There is only one api call to
Xend- to obtain the domU's s-_expression_.

1. A quick and dirty way would be to change this single api call to xapi equivalent
and obtain the s-_expression_, then you should have Remus running.

2. Another approach would be to re-write the toolstack code in ocaml - which might
be easy. But make sure that ocaml can make netlink api calls.

shriram
Regards,
Rushikesh




On Mon, Sep 26, 2011 at 12:38 PM, Mike McClurg <mike.mcclurg@xxxxxxxxxx> wrote:
On 09/25/2011 09:11 PM, R J wrote:
Hello List,

I have a proposal and wont mind to implement my self but need a helping hand to start on.
I want to implement the aggressive FT feature in XCP. The best way I could imagine is the use of feature *Live Migration*

Steps
1. Enable the FT of a particular VM using xe commands and adding as a param to that VM e.g. xe vm-param-set FT=true uuid=XYZ
2. If the FT = true detected by xenstore then xapi will initiate a live migrate of that VM to any of available host.
3. A parallel "network ping"/"xapi heartbit" from/to that host could be initialized for each FT VM.
4. Live migrate will run forever until its disabled by FT = false or one of the host is down. e.g. the process will loop at 99.99% migration state
5. If there is a packet drop of x packets the VM Migrate procedure will mark the VM Migration as Complete and will switch the devices forcefully.
-- this could result in some data loss but I dont have any alternative to this.
-- The specific x packets can be set by XCP but we cant rely for default XCP Errors
6. If there is a successful migration due to host down then we will again start from step2

Above steps I have assumed to my knowledge, we can discuss the problems in it.

Apologies if I'm being too naive.

Regards,
Rushikesh

This sounds like Remus (http://nss.cs.ubc.ca/remus/). Are you proposing to implement Remus support in xapi?

Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel



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

 


Rackspace

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