Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
On Sat, Feb 01, 2020 at 11:56:19AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 31 January 2020 16:08
> > To: Andrew Cooper
> > Cc: Durrant, Paul ; Ian Jackson
> > ; Anthony Perard ; xen-
> > de...@lists.xenproject.org; Wei Liu
> > Subject: Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on
> > save/restore or migrate
> >
> > On Thu, Jan 30, 2020 at 06:20:08PM +, Andrew Cooper wrote:
> > > On 30/01/2020 17:42, Durrant, Paul wrote:
> > > >> -Original Message-
> > > >> From: Ian Jackson
> > > >> Sent: 30 January 2020 17:29
> > > >> To: Durrant, Paul
> > > >> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony
> > Perard
> > > >>
> > > >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> > > >> save/restore or migrate
> > > >>
> > > >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved
> > on
> > > >> save/restore or migrate"):
> > > >>> This patch adds a '-D' command line option to save and migrate to
> > allow
> > > >>> the domain id to be incorporated into the saved domain configuration
> > and
> > > >>> hence be preserved.
> > > >> Thanks.
> > > >>
> > > >> In response to v3 6/6 I wrote:
> > > >>
> > > >> I wonder if this should be done more in libxl. Should this be a
> > > >> domain property ? Wei, Anthony ?
> > > >>
> > > >> This question remains unanswered. I'm sorry that neither Wei nor
> > > >> Anthony had a chance to answer yet...
> > > >>
> > > >> Paul, do you have a reason for doing it this way ? My inclination is
> > > >> that think doing it at the libxl layer would make more sense. Do you
> > > >> think that would be possible ?
> > > >>
> > > > I'm not sure how it would work at the libxl level as the domid is
> > > > part of create_info and that it transferred by xl on migration. IIUC
> > > > we'd need a new libxl save record to transfer it at that level, and
> > > > then I'm not sure whether we'd hit an ordering problem as we'd have
> > > > to dig that save record out before we could actually create the
> > > > domain.
> > >
> > > There is definitely an ordering problem.
> > >
> > > I agree that it should logically be part of the libxl level of the
> > > stream, but none of that is even parsed until after the domain has been
> > > created on the destination side.
> > >
> > > I have no idea how easy/difficult it would be to rearrange libxl to
> > > start parsing the migration stream before creating the domain. I think
> > > there will be a lot of code relying on the domid already being valid.
> >
> > This.
> >
> > The other way I can think of is to specify something (domid policy??) in
> > create_info and apply it during domain creation. But that reeks like a
> > layering violation to me.
> >
>
> That's basically what this series does, but I don't see it as a
> layering violation. It has always been the case that xl is in control
> of the domain creation and then passes the migration stream into
> libxl. Passing in a 'domid policy' (specific value, 'random', or
> 'allocated by Xen') as part of create_info, and not messing with the
> libxl migration data, seems like the right approach to me... which is
> why I've done it that way.
Going through the code more carefully I think your implementation should
be fine.
Wei.
>
> Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
> -Original Message-
> From: Wei Liu
> Sent: 31 January 2020 16:08
> To: Andrew Cooper
> Cc: Durrant, Paul ; Ian Jackson
> ; Anthony Perard ; xen-
> de...@lists.xenproject.org; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate
>
> On Thu, Jan 30, 2020 at 06:20:08PM +, Andrew Cooper wrote:
> > On 30/01/2020 17:42, Durrant, Paul wrote:
> > >> -Original Message-
> > >> From: Ian Jackson
> > >> Sent: 30 January 2020 17:29
> > >> To: Durrant, Paul
> > >> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony
> Perard
> > >>
> > >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> > >> save/restore or migrate
> > >>
> > >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved
> on
> > >> save/restore or migrate"):
> > >>> This patch adds a '-D' command line option to save and migrate to
> allow
> > >>> the domain id to be incorporated into the saved domain configuration
> and
> > >>> hence be preserved.
> > >> Thanks.
> > >>
> > >> In response to v3 6/6 I wrote:
> > >>
> > >> I wonder if this should be done more in libxl. Should this be a
> > >> domain property ? Wei, Anthony ?
> > >>
> > >> This question remains unanswered. I'm sorry that neither Wei nor
> > >> Anthony had a chance to answer yet...
> > >>
> > >> Paul, do you have a reason for doing it this way ? My inclination is
> > >> that think doing it at the libxl layer would make more sense. Do you
> > >> think that would be possible ?
> > >>
> > > I'm not sure how it would work at the libxl level as the domid is
> > > part of create_info and that it transferred by xl on migration. IIUC
> > > we'd need a new libxl save record to transfer it at that level, and
> > > then I'm not sure whether we'd hit an ordering problem as we'd have
> > > to dig that save record out before we could actually create the
> > > domain.
> >
> > There is definitely an ordering problem.
> >
> > I agree that it should logically be part of the libxl level of the
> > stream, but none of that is even parsed until after the domain has been
> > created on the destination side.
> >
> > I have no idea how easy/difficult it would be to rearrange libxl to
> > start parsing the migration stream before creating the domain. I think
> > there will be a lot of code relying on the domid already being valid.
>
> This.
>
> The other way I can think of is to specify something (domid policy??) in
> create_info and apply it during domain creation. But that reeks like a
> layering violation to me.
>
That's basically what this series does, but I don't see it as a layering
violation. It has always been the case that xl is in control of the domain
creation and then passes the migration stream into libxl. Passing in a 'domid
policy' (specific value, 'random', or 'allocated by Xen') as part of
create_info, and not messing with the libxl migration data, seems like the
right approach to me... which is why I've done it that way.
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
On Thu, Jan 30, 2020 at 06:20:08PM +, Andrew Cooper wrote:
> On 30/01/2020 17:42, Durrant, Paul wrote:
> >> -Original Message-
> >> From: Ian Jackson
> >> Sent: 30 January 2020 17:29
> >> To: Durrant, Paul
> >> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> >>
> >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> >> save/restore or migrate
> >>
> >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
> >> save/restore or migrate"):
> >>> This patch adds a '-D' command line option to save and migrate to allow
> >>> the domain id to be incorporated into the saved domain configuration and
> >>> hence be preserved.
> >> Thanks.
> >>
> >> In response to v3 6/6 I wrote:
> >>
> >> I wonder if this should be done more in libxl. Should this be a
> >> domain property ? Wei, Anthony ?
> >>
> >> This question remains unanswered. I'm sorry that neither Wei nor
> >> Anthony had a chance to answer yet...
> >>
> >> Paul, do you have a reason for doing it this way ? My inclination is
> >> that think doing it at the libxl layer would make more sense. Do you
> >> think that would be possible ?
> >>
> > I'm not sure how it would work at the libxl level as the domid is
> > part of create_info and that it transferred by xl on migration. IIUC
> > we'd need a new libxl save record to transfer it at that level, and
> > then I'm not sure whether we'd hit an ordering problem as we'd have
> > to dig that save record out before we could actually create the
> > domain.
>
> There is definitely an ordering problem.
>
> I agree that it should logically be part of the libxl level of the
> stream, but none of that is even parsed until after the domain has been
> created on the destination side.
>
> I have no idea how easy/difficult it would be to rearrange libxl to
> start parsing the migration stream before creating the domain. I think
> there will be a lot of code relying on the domid already being valid.
This.
The other way I can think of is to specify something (domid policy??) in
create_info and apply it during domain creation. But that reeks like a
layering violation to me.
Wei.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
On 30/01/2020 17:42, Durrant, Paul wrote:
>> -Original Message-
>> From: Ian Jackson
>> Sent: 30 January 2020 17:29
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>>
>> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
>> save/restore or migrate
>>
>> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
>> save/restore or migrate"):
>>> This patch adds a '-D' command line option to save and migrate to allow
>>> the domain id to be incorporated into the saved domain configuration and
>>> hence be preserved.
>> Thanks.
>>
>> In response to v3 6/6 I wrote:
>>
>> I wonder if this should be done more in libxl. Should this be a
>> domain property ? Wei, Anthony ?
>>
>> This question remains unanswered. I'm sorry that neither Wei nor
>> Anthony had a chance to answer yet...
>>
>> Paul, do you have a reason for doing it this way ? My inclination is
>> that think doing it at the libxl layer would make more sense. Do you
>> think that would be possible ?
>>
> I'm not sure how it would work at the libxl level as the domid is part of
> create_info and that it transferred by xl on migration. IIUC we'd need a new
> libxl save record to transfer it at that level, and then I'm not sure whether
> we'd hit an ordering problem as we'd have to dig that save record out before
> we could actually create the domain.
There is definitely an ordering problem.
I agree that it should logically be part of the libxl level of the
stream, but none of that is even parsed until after the domain has been
created on the destination side.
I have no idea how easy/difficult it would be to rearrange libxl to
start parsing the migration stream before creating the domain. I think
there will be a lot of code relying on the domid already being valid.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
> -Original Message-
> From: Ian Jackson
> Sent: 30 January 2020 17:29
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>
> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate
>
> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate"):
> > This patch adds a '-D' command line option to save and migrate to allow
> > the domain id to be incorporated into the saved domain configuration and
> > hence be preserved.
>
> Thanks.
>
> In response to v3 6/6 I wrote:
>
> I wonder if this should be done more in libxl. Should this be a
> domain property ? Wei, Anthony ?
>
> This question remains unanswered. I'm sorry that neither Wei nor
> Anthony had a chance to answer yet...
>
> Paul, do you have a reason for doing it this way ? My inclination is
> that think doing it at the libxl layer would make more sense. Do you
> think that would be possible ?
>
I'm not sure how it would work at the libxl level as the domid is part of
create_info and that it transferred by xl on migration. IIUC we'd need a new
libxl save record to transfer it at that level, and then I'm not sure whether
we'd hit an ordering problem as we'd have to dig that save record out before we
could actually create the domain.
Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate
Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved on
save/restore or migrate"):
> This patch adds a '-D' command line option to save and migrate to allow
> the domain id to be incorporated into the saved domain configuration and
> hence be preserved.
Thanks.
In response to v3 6/6 I wrote:
I wonder if this should be done more in libxl. Should this be a
domain property ? Wei, Anthony ?
This question remains unanswered. I'm sorry that neither Wei nor
Anthony had a chance to answer yet...
Paul, do you have a reason for doing it this way ? My inclination is
that think doing it at the libxl layer would make more sense. Do you
think that would be possible ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
