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 <[email protected]>wrote: > > > On Mon, Sep 26, 2011 at 8:58 AM, R J <[email protected]> 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 >> <[email protected]>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 >> [email protected] >> http://lists.xensource.com/xen-devel >> >> >
_______________________________________________ xen-api mailing list [email protected] http://lists.xensource.com/mailman/listinfo/xen-api
