* FT for XCP
@ 2011-09-25 20:11 R J
[not found] ` <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: R J @ 2011-09-25 20:11 UTC (permalink / raw)
To: xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FT for XCP
[not found] ` <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-09-26 7:08 ` Mike McClurg
[not found] ` <4E8024E5.9020406-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Mike McClurg @ 2011-09-26 7:08 UTC (permalink / raw)
To: R J
Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FT for XCP
[not found] ` <4E8024E5.9020406-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
@ 2011-09-26 15:58 ` R J
2011-09-28 16:08 ` Re: [Xen-API] " Shriram Rajagopalan
0 siblings, 1 reply; 6+ messages in thread
From: R J @ 2011-09-26 15:58 UTC (permalink / raw)
To: Mike McClurg
Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Re: [Xen-API] FT for XCP
2011-09-26 15:58 ` R J
@ 2011-09-28 16:08 ` Shriram Rajagopalan
[not found] ` <CAP8mzPOOkZ2iUzKkMCC7T+TExPL6osoANQnw1tUREeE=Jx-_BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Shriram Rajagopalan @ 2011-09-28 16:08 UTC (permalink / raw)
To: R J; +Cc: Mike McClurg, xen-devel, xen-users, xen-api
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] Re: FT for XCP
[not found] ` <CAP8mzPOOkZ2iUzKkMCC7T+TExPL6osoANQnw1tUREeE=Jx-_BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-10-08 19:46 ` R J
[not found] ` <CAO14VsM2GRyCaNU6No06dxyRjSkUmmOjBqm4LMieKXkQmBxtTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: R J @ 2011-10-08 19:46 UTC (permalink / raw)
To: rshriram-p4f71khQOEj3fQ9qLvQP4Q
Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xen-devel] Re: FT for XCP
[not found] ` <CAO14VsM2GRyCaNU6No06dxyRjSkUmmOjBqm4LMieKXkQmBxtTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-10-09 15:10 ` Pasi Kärkkäinen
0 siblings, 0 replies; 6+ messages in thread
From: Pasi Kärkkäinen @ 2011-10-09 15:10 UTC (permalink / raw)
To: R J
Cc: rshriram-p4f71khQOEj3fQ9qLvQP4Q,
xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-users-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR,
xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-10-09 15:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-25 20:11 FT for XCP R J
[not found] ` <CAO14VsP9by7CYgSiVN-hY0rJpDk0MYjuJ+FD5Tp3i8w+BcNYHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-09-26 7:08 ` Mike McClurg
[not found] ` <4E8024E5.9020406-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2011-09-26 15:58 ` R J
2011-09-28 16:08 ` Re: [Xen-API] " Shriram Rajagopalan
[not found] ` <CAP8mzPOOkZ2iUzKkMCC7T+TExPL6osoANQnw1tUREeE=Jx-_BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-10-08 19:46 ` [Xen-devel] " R J
[not found] ` <CAO14VsM2GRyCaNU6No06dxyRjSkUmmOjBqm4LMieKXkQmBxtTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-10-09 15:10 ` Pasi Kärkkäinen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.