FT for XCP

FT for XCP

[R J]

[-- Attachment #1.1: Type: text/plain, Size: 1257 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1360 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: FT for XCP

[Mike McClurg]

[-- Attachment #1.1: Type: text/plain, Size: 1485 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: FT for XCP

[R J]

[-- Attachment #1.1: Type: text/plain, Size: 1890 bytes --]

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-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>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
>

[-- Attachment #1.2: Type: text/html, Size: 2824 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 3033 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4856 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

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

[R J]

[-- Attachment #1.1: Type: text/plain, Size: 3719 bytes --]

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-p4f71khQOEj3fQ9qLvQP4Q@public.gmane.org>wrote:

>
>
> On Mon, Sep 26, 2011 at 8:58 AM, R J <torushikeshj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>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-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
>> http://lists.xensource.com/xen-devel
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 5979 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

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

[Pasi Kärkkäinen]

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-p4f71khQOEj3fQ9qLvQP4Q@public.gmane.org> wrote:
> 
>      On Mon, Sep 26, 2011 at 8:58 AM, R J <[3]torushikeshj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> 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-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
>        [7]http://lists.xensource.com/xen-devel
> 
> References
> 
>    Visible links
>    1. http://nss.cs.ubc.ca/remus/hg/
>    2. mailto:rshriram-p4f71khQOEj3fQ9qLvQP4Q@public.gmane.org
>    3. mailto:torushikeshj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>    4. mailto:mike.mcclurg-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org
>    5. http://nss.cs.ubc.ca/remus/
>    6. mailto:Xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
>    7. http://lists.xensource.com/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
> http://lists.xensource.com/xen-devel