On Fri, 2011-09-30 at 13:22 +0100, Jonathan Ludlam wrote:
> Ah, that's a shame. I was hoping this was a bugfix to the ocaml
> xenstored and that the C version already did this. Unfortunately the
> patch here went in to XenServer a couple of years ago, and Thomas, who
> made the change, has since left. I'll dig into this and see why we
> depend upon it.
Seems to be CA-30927 which was "internal shutdown doesn't work anymore
after VM.checkpoint":
The bugs comes from the fact that xal always assume that
suspended domains are or will be soon dead.
However, for VM.checkpoint that assumptions is false, as the VM
is suspended, snapshoted, and then resumed, without destroying
the domain.
Thomas said in that ticket:
I fixed this issue by:
* teach to xal how to handle dead domains for suspended
reasons which become suddenly alive
* when resuming a domain, use the xenstore introduce call
* modify xenstore to generates a @introduceDomain event
even if the introduced domain does not exists
I believe nobody care to see too many @introduceDomain event, so
that will not change anything. My fix modifies the code path
taken by VM.suspend, but that should be safe because xapi
destroys properly the domain after suspending it.
(I think he meant _does_ exist in the third bullet). In his commit
message he said:
Teach xal what to do with dead domains which become alive again.
Needed to modify xenstored as well in order to trigger a
@introduceDomain event even if the introduce call tries to
introduce an already existing domain. That will kick-up xal in
case when resuming the domain.
I think possibly the right fix would have been to have xal kick-up
itself. That said spurious @introduceDomain watches are pretty harmless
(as he suggests) since they have no context, the recipient has to go and
check it's idea of the world vs the real state to know what happened an
the answer "nothing" is not a big deal...
Ian.
>
> Jon
>
> On 30 Sep 2011, at 08:49, Ian Campbell wrote:
>
> > On Thu, 2011-09-29 at 22:17 +0100, Jon Ludlam wrote:
> >> Have xenstored trigger an @introduceDomain event even if the
> >> introduce call tries to introduce an already existing domain.
> >
> > The C daemon doesn't appear to behave this way. It would be nice to
> > explain why this change is necessary.
> >
> >> Signed-off-by: Thomas Gazagnaire <thomas@xxxxxxxxxxxx>
> >> Acked-by: Jon Ludlam <jonathan.ludlam@xxxxxxxxxxxxx>
> >>
> >> diff -r 734cb0807357 -r b6022a18ebb0 tools/ocaml/xenstored/process.ml
> >> --- a/tools/ocaml/xenstored/process.ml
> >> +++ b/tools/ocaml/xenstored/process.ml
> >> @@ -168,9 +168,10 @@
> >> | _ -> raise Invalid_Cmd_Args;
> >> in
> >> let dom =
> >> - if Domains.exist domains domid then
> >> + if Domains.exist domains domid then begin
> >> + Connections.fire_spec_watches cons "@introduceDomain";
> >> Domains.find domains domid
> >> - else try
> >> + end else try
> >> let ndom = Xc.with_intf (fun xc ->
> >> Domains.create xc domains domid mfn port) in
> >> Connections.add_domain cons ndom;
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> >
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home