New feature support - xl or xm ?

New feature support - xl or xm ?

[Dulloor]

If we are to add new guest configuration parameters, is it enough to
make it work with xl ?
Sorry, if I missed any past mails regarding this, but (in general)
should people think xl or xm or both ?

-dulloor

Re: New feature support - xl or xm ?

[Stefano Stabellini]

On Fri, 28 May 2010, Dulloor wrote:
> If we are to add new guest configuration parameters, is it enough to
> make it work with xl ?
> Sorry, if I missed any past mails regarding this, but (in general)
> should people think xl or xm or both ?

xl is strongly recommended at this point.

Re: New feature support - xl or xm ?

[Ian Jackson]

Stefano Stabellini writes ("Re: [Xen-devel] New feature support - xl or xm ?"):
> On Fri, 28 May 2010, Dulloor wrote:
> > If we are to add new guest configuration parameters, is it enough to
> > make it work with xl ?
> > Sorry, if I missed any past mails regarding this, but (in general)
> > should people think xl or xm or both ?
> 
> xl is strongly recommended at this point.

Indeed.  I think at this point it's probably OK to submit features for
libxl only and not add them to xm/xend too.

Ian.

Re: New feature support - xl or xm ?

[Vincent, Pradeep]

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

I haven't looked deeply into 'xl' but..

>From the recent Xen summit, I walked away thinking 'xl' didn't have the callback mechanisms (e.g. Cleanup etc) and this helped it stay stateless while falling short of full 'xm' replacement. This email thread indicates 'xm/xend' will be deprecated in due course of time. Did I miss anything here ?

Is migration of VMs from 'xm' managed hosts to 'xl' managed hosts expected to work ?

I think moving away from commonly used xend/xm could be a bit of a thorn particularly if the 'xm' to 'xl' migration isn't expected to work.

Thoughts ?

Thanks,

- Pradeep Vincent

On 6/1/10 3:20 AM, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

Stefano Stabellini writes ("Re: [Xen-devel] New feature support - xl or xm ?"):
> On Fri, 28 May 2010, Dulloor wrote:
> > If we are to add new guest configuration parameters, is it enough to
> > make it work with xl ?
> > Sorry, if I missed any past mails regarding this, but (in general)
> > should people think xl or xm or both ?
>
> xl is strongly recommended at this point.

Indeed.  I think at this point it's probably OK to submit features for
libxl only and not add them to xm/xend too.

Ian.

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


[-- Attachment #1.2: Type: text/html, Size: 2094 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: New feature support - xl or xm ?

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Tue, 8 Jun 2010, Vincent, Pradeep wrote:
> I haven’t looked deeply into ‘xl’ but..
> 
> >From the recent Xen summit, I walked away thinking ‘xl’ didn’t have the callback mechanisms (e.g. Cleanup etc) and this
> helped it stay stateless while falling short of full ‘xm’ replacement. This email thread indicates ‘xm/xend’ will be
> deprecated in due course of time. Did I miss anything here ?
> 

We intend to port xend to libxl at some point to smooth the migration
path, however xl is going to be where most of the development and
testing is going on, so it is worth considering a switch to xl in any
case.
xl does have the callback mechanisms for cleanup, they are implemented
in a per-VM daemon that is started when you create the domain.
However you can still create a VM without starting the related daemon
(no callbacks or cleanups in that case).


> Is migration of VMs from ‘xm’ managed hosts to ‘xl’ managed hosts expected to work ?
> 
> I think moving away from commonly used xend/xm could be a bit of a thorn particularly if the ‘xm’ to ‘xl’ migration isn’t
> expected to work.
> 
> Thoughts ?
>

There are only two things that xl doesn't have compared to xend: the
concept of managed domains (domains that are installed on your system
and may be offline) and an XML-RPC interface.
If you don't need these two things than switching shouldn't be
difficult.
I think that migrating VMs from 'xm hosts' to 'xl hosts' would
work even at the moment, if you use xl on both source and destination
hosts and specify the configuration file you used to create the domain
at the source. In any case it could be made to work without too many
efforts, given that your are not speaking about fully managed domains.

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

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

Re: New feature support - xl or xm ?

[Vincent, Pradeep]

Thanks Stefano.

>>I think that migrating VMs from 'xm hosts' to 'xl hosts' would
> work even at the moment, if you use xl on both source and destination
> hosts 


I am not sure what you meant here ­ Are you suggesting retrofit of Oxl¹ to
hosts using older hypervisor.

Can migration functionality (including live migration) in Oxl¹ be designed
for backward compatibility with Oxm¹. I am sure this will go a long way in
helping existing users convert over to Oxl¹.

- Pradeep Vincent



On 6/8/10 2:17 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Tue, 8 Jun 2010, Vincent, Pradeep wrote:
>> I haven¹t looked deeply into Oxl¹ but..
>> 
>>> From the recent Xen summit, I walked away thinking Oxl¹ didn¹t have the
>>> callback mechanisms (e.g. Cleanup etc) and this
>> helped it stay stateless while falling short of full Oxm¹ replacement. This
>> email thread indicates Oxm/xend¹ will be
>> deprecated in due course of time. Did I miss anything here ?
>> 
> 
> We intend to port xend to libxl at some point to smooth the migration
> path, however xl is going to be where most of the development and
> testing is going on, so it is worth considering a switch to xl in any
> case.
> xl does have the callback mechanisms for cleanup, they are implemented
> in a per-VM daemon that is started when you create the domain.
> However you can still create a VM without starting the related daemon
> (no callbacks or cleanups in that case).
> 
> 
>> Is migration of VMs from Oxm¹ managed hosts to Oxl¹ managed hosts expected to
>> work ?
>> 
>> I think moving away from commonly used xend/xm could be a bit of a thorn
>> particularly if the Oxm¹ to Oxl¹ migration isn¹t
>> expected to work.
>> 
>> Thoughts ?
>> 
> 
> There are only two things that xl doesn't have compared to xend: the
> concept of managed domains (domains that are installed on your system
> and may be offline) and an XML-RPC interface.
> If you don't need these two things than switching shouldn't be
> difficult.
> I think that migrating VMs from 'xm hosts' to 'xl hosts' would
> work even at the moment, if you use xl on both source and destination
> hosts and specify the configuration file you used to create the domain
> at the source. In any case it could be made to work without too many
> efforts, given that your are not speaking about fully managed domains.
> 

Re: New feature support - xl or xm ?

[Vincent, Pradeep]

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


Also, was there a compelling reason to move away from the 'xm' interface. Obviously 'xm' is both an API and an implementation and I certainly see the reasons to move away from libxenguest/xend/xm implementation in favor of libxl. But was there a reason to opt for a new 'xl' API as opposed change the implementation behind the established 'xm' API.

Did the 'xm' interface (excluding the implementation) fall short of serving the needs ?

Thanks,

- Pradeep Vincent

On 6/8/10 3:49 PM, "Vincent, Pradeep" <pradeepv@amazon.com> wrote:



Thanks Stefano.

>>I think that migrating VMs from 'xm hosts' to 'xl hosts' would
> work even at the moment, if you use xl on both source and destination
> hosts


I am not sure what you meant here - Are you suggesting retrofit of Oxl' to
hosts using older hypervisor.

Can migration functionality (including live migration) in Oxl' be designed
for backward compatibility with Oxm'. I am sure this will go a long way in
helping existing users convert over to Oxl'.

- Pradeep Vincent



On 6/8/10 2:17 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Tue, 8 Jun 2010, Vincent, Pradeep wrote:
>> I haven't looked deeply into Oxl' but..
>>
>>> From the recent Xen summit, I walked away thinking Oxl' didn't have the
>>> callback mechanisms (e.g. Cleanup etc) and this
>> helped it stay stateless while falling short of full Oxm' replacement. This
>> email thread indicates Oxm/xend' will be
>> deprecated in due course of time. Did I miss anything here ?
>>
>
> We intend to port xend to libxl at some point to smooth the migration
> path, however xl is going to be where most of the development and
> testing is going on, so it is worth considering a switch to xl in any
> case.
> xl does have the callback mechanisms for cleanup, they are implemented
> in a per-VM daemon that is started when you create the domain.
> However you can still create a VM without starting the related daemon
> (no callbacks or cleanups in that case).
>
>
>> Is migration of VMs from Oxm' managed hosts to Oxl' managed hosts expected to
>> work ?
>>
>> I think moving away from commonly used xend/xm could be a bit of a thorn
>> particularly if the Oxm' to Oxl' migration isn't
>> expected to work.
>>
>> Thoughts ?
>>
>
> There are only two things that xl doesn't have compared to xend: the
> concept of managed domains (domains that are installed on your system
> and may be offline) and an XML-RPC interface.
> If you don't need these two things than switching shouldn't be
> difficult.
> I think that migrating VMs from 'xm hosts' to 'xl hosts' would
> work even at the moment, if you use xl on both source and destination
> hosts and specify the configuration file you used to create the domain
> at the source. In any case it could be made to work without too many
> efforts, given that your are not speaking about fully managed domains.
>


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


[-- Attachment #1.2: Type: text/html, Size: 4240 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: New feature support - xl or xm ?

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Tue, 8 Jun 2010, Vincent, Pradeep wrote:
> 
> Thanks Stefano.
> 
> >>I think that migrating VMs from 'xm hosts' to 'xl hosts' would
> > work even at the moment, if you use xl on both source and destination
> > hosts 
> 
> 
> I am not sure what you meant here ­ Are you suggesting retrofit of Oxl¹ to
> hosts using older hypervisor.
> 
> Can migration functionality (including live migration) in Oxl¹ be designed
> for backward compatibility with Oxm¹. I am sure this will go a long way in
> helping existing users convert over to Oxl¹.
> 

When xen 4.1 is released and you update your xen host to 4.1, you can
still use xend to perform VM migrations to the new up-to-date host.
>From that point on you'll have a system with both xend and xl working
correctly, so if you want to migrate your VMs to another 4.1 (or 4.2 or
5.0, etc.) host without xend you just need to shutdown xend
(leaving the VMs running) and use xl to perform the migration.

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

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

Re: New feature support - xl or xm ?

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Wed, 9 Jun 2010, Vincent, Pradeep wrote:
> 
> Also, was there a compelling reason to move away from the ‘xm’ interface. Obviously ‘xm’ is both an API and an
> implementation and I certainly see the reasons to move away from libxenguest/xend/xm implementation in favor of libxl. But
> was there a reason to opt for a new ‘xl’ API as opposed change the implementation behind the established ‘xm’ API.
> 
> Did the ‘xm’ interface (excluding the implementation) fall short of serving the needs ?
> 

We like the 'xm' CLI, in fact we are trying our best to provide a
compatible command line interface with 'xl'.
Ideally you'll be able to symlink xl to xm and everything will still
work. If you find any problem with command line incompatibilities please
let us know, and we'll fix them.

On the other hand if you are speaking about the XML-RPC interface
provided by xend, that is a totally different matter.

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

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

Re: New feature support - xl or xm ?

[Vincent, Pradeep]

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

Thanks Stefano. That helps.


On 6/9/10 8:09 AM, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com> wrote:

On Wed, 9 Jun 2010, Vincent, Pradeep wrote:
>
> Also, was there a compelling reason to move away from the 'xm' interface. Obviously 'xm' is both an API and an
> implementation and I certainly see the reasons to move away from libxenguest/xend/xm implementation in favor of libxl. But
> was there a reason to opt for a new 'xl' API as opposed change the implementation behind the established 'xm' API.
>
> Did the 'xm' interface (excluding the implementation) fall short of serving the needs ?
>

We like the 'xm' CLI, in fact we are trying our best to provide a
compatible command line interface with 'xl'.
Ideally you'll be able to symlink xl to xm and everything will still
work. If you find any problem with command line incompatibilities please
let us know, and we'll fix them.

On the other hand if you are speaking about the XML-RPC interface
provided by xend, that is a totally different matter.


[-- Attachment #1.2: Type: text/html, Size: 1600 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: New feature support - xl or xm ?

[AP Xen]

> We like the 'xm' CLI, in fact we are trying our best to provide a
> compatible command line interface with 'xl'.
> Ideally you'll be able to symlink xl to xm and everything will still
> work. If you find any problem with command line incompatibilities
> please let us know, and we'll fix them.
> 
> On the other hand if you are speaking about the XML-RPC interface
> provided by xend, that is a totally different matter.

So with xl, xend doesn't need to be running as it uses the libxl API which
bypasses libxenguest/xend?

Thanks,
AP

Re: New feature support - xl or xm ?

[Keir Fraser]

On 10/06/2010 21:02, "AP Xen" <apxeng@gmail.com> wrote:

>> We like the 'xm' CLI, in fact we are trying our best to provide a
>> compatible command line interface with 'xl'.
>> Ideally you'll be able to symlink xl to xm and everything will still
>> work. If you find any problem with command line incompatibilities
>> please let us know, and we'll fix them.
>> 
>> On the other hand if you are speaking about the XML-RPC interface
>> provided by xend, that is a totally different matter.
> 
> So with xl, xend doesn't need to be running as it uses the libxl API which
> bypasses libxenguest/xend?

All correct, except libxl does use libxenctrl and libxenguest. But it does
not use xend and so does not need it to be running.

 -- Keir