From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Vincent, Pradeep" Subject: Re: New feature support - xl or xm ? Date: Mon, 7 Jun 2010 18:35:46 -0700 Message-ID: References: <19460.57088.748052.808033@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1093879067==" Return-path: In-Reply-To: <19460.57088.748052.808033@mariner.uk.xensource.com> Content-Language: en List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson , Stefano Stabellini , "xen-devel@lists.xensource.com" Cc: Dulloor List-Id: xen-devel@lists.xenproject.org --===============1093879067== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C832EC8217AB4pradeepvamazoncom_" --_000_C832EC8217AB4pradeepvamazoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I haven't looked deeply into 'xl' but.. >>From the recent Xen summit, I walked away thinking 'xl' didn't have the cal= lback mechanisms (e.g. Cleanup etc) and this helped it stay stateless while= falling short of full 'xm' replacement. This email thread indicates 'xm/xe= nd' 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 pa= rticularly if the 'xm' to 'xl' migration isn't expected to work. Thoughts ? Thanks, - Pradeep Vincent On 6/1/10 3:20 AM, "Ian Jackson" 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 --_000_C832EC8217AB4pradeepvamazoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Xen-devel] New feature support - xl or xm ? I haven’t looked deeply into ‘xl’ = but..

>>From the recent Xen summit, I walked away thinking ‘xl’ didn= 217;t have the callback mechanisms (e.g. Cleanup etc) and this helped it st= ay stateless while falling short of full ‘xm’ replacement. This= email thread indicates ‘xm/xend’ will be deprecated in due cou= rse 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 pa= rticularly 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

--_000_C832EC8217AB4pradeepvamazoncom_-- --===============1093879067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1093879067==--