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 _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
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-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
Hello Mike, Thank you for suggestion. I would love to incorporate remus in xapi if thats possible. Remus as its inbuilt logic of detecting checkpoint failure and taking decisions accordingly. I think there is remus support for xen 3.4 What do you suggest as my next step ? Regards, Rushikesh On Mon, Sep 26, 2011 at 12:38 PM, Mike McClurg <mike.mcclurg@citrix.com>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-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
On Mon, Sep 26, 2011 at 8:58 AM, R J <torushikeshj@gmail.com> 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@citrix.com>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@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@cs.ubc.ca>wrote:> > > On Mon, Sep 26, 2011 at 8:58 AM, R J <torushikeshj@gmail.com> 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@citrix.com>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@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> >_______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
On Sun, Oct 09, 2011 at 01:16:46AM +0530, R J wrote:> 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. [1]http://nss.cs.ubc.ca/remus/hg/ I hope > this project is not stopped. >There''s also: http://wiki.xen.org/xenwiki/Remus -- Pasi> 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 > <[2]rshriram@cs.ubc.ca> wrote: > > On Mon, Sep 26, 2011 at 8:58 AM, R J <[3]torushikeshj@gmail.com> 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 > <[4]mike.mcclurg@citrix.com> 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 ([5]http://nss.cs.ubc.ca/remus/). Are you > proposing to implement Remus support in xapi? > Mike > > _______________________________________________ > Xen-devel mailing list > [6]Xen-devel@lists.xensource.com > [7]http://lists.xensource.com/xen-devel > > References > > Visible links > 1. http://nss.cs.ubc.ca/remus/hg/ > 2. mailto:rshriram@cs.ubc.ca > 3. mailto:torushikeshj@gmail.com > 4. mailto:mike.mcclurg@citrix.com > 5. http://nss.cs.ubc.ca/remus/ > 6. mailto:Xen-devel@lists.xensource.com > 7. http://lists.xensource.com/xen-devel> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api