From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shriram Rajagopalan Subject: Re: libxl - API call to return sxpr of a domain? Date: Tue, 7 Jun 2011 11:30:50 -0400 Message-ID: References: <1307437379.775.513.camel@zakaz.uk.xensource.com> Reply-To: rshriram@cs.ubc.ca Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1862055972==" Return-path: In-Reply-To: <1307437379.775.513.camel@zakaz.uk.xensource.com> 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 Campbell Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --===============1862055972== Content-Type: multipart/alternative; boundary=485b3970cadefea09004a520e99b --485b3970cadefea09004a520e99b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 7, 2011 at 5:02 AM, Ian Campbell wrote: > On Tue, 2011-06-07 at 04:30 +0100, Shriram Rajagopalan wrote: > > I am looking into adding Remus support for libxl. The easiest way is > > to obtain the domain's sxpr, so that the rest of Remus python code > > stays as is. > > > > Is there an api call in libxl to return a domain's sxpr ? a grep on > > the libxl code > > base returned nothing. Or am I missing something pretty obvious? > > xl has some code to do this but libxl doesn't. An sxpr representation of > a domain is rather a xend specific concept which is the only reason xl > has it. > There are some plans to allow libxl to generate json for any of the IDL > defined datastructures, mostly as a convenient pretty-printer but being > machine parsable is a handy side-effect. Currently this would just be > for individual datastructures though. > > Where/how does remus use sxp? tools/python/xen/remus/vm.py:domtosxpr() > seems to consume a xend datastructure and make a Remus sxp out of it -- > can an xl equivalent not be written using the python bindings? (NB > bindings may be incomplete, we can fix up as you discover stuff). Are > all usages of sxp in Remus of that particular sxp format or are there > others? > > The only reason remus uses sxpr is because xend conveys info in that form. Basically, it only needs the vif device name (vif1.0, etc), the disk device name and the access format (tap/drbd) for proper operation. save.py:MigrationSocket - establish connection with remote machine's xend daemon vm.VM(domid): get sxpr (dominfo) from xend via xml rpc call. save.py:Saver - image.makeheader(dominfo) - serialize the sxpr and send to remote machine. everything else in vm.py is to parse the sxpr to extract the vif and disk info. self.disks = getdisks(self.dom) self.vifs = getvifs(self.dom) Are sxp's baked into the Remus wire-protocol? Remus wire-protocol is whatever protocol xend requires. The reason for bypassing the usual xend live migration code path is because of the callbacks, the checkpoint interval based suspend/resume, etc. Now that I know that xl/libxl doesnt use sxpr in its wire-protocol (dunce! :( ), the plan would have to be different. (a) Follow the same implementation style like that with xend (bypass xl's live migration mechanism) - involves some code duplication probably for communicating with remote machine, in xl's wire protocol. The advantage is most of remus' python code (save.py, device.py, qdisc.py, code to install/parse IFB devices, tc rules, etc) stays as is. (b) integrate the remus control flow into xl/libxl stack - I dont know how much work that would be yet. > Personally I think moving > away from using SXPs internally towards using actual data structures > would be a good idea... > > > BTW, is tools/python/xen/remus part of xend or part of Remus? Or does it > straddle the boundary? > > part of Remus stack. > Ian. > > shriram --485b3970cadefea09004a520e99b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7, 2011 at 5:02 AM, Ian Campbell <Ian.Campbell@= citrix.com> wrote:
On Tue, 2011-06-07 at 04:30 +0100, Shrira= m Rajagopalan wrote:
> I am looking into adding Remus support for libxl. The easiest way is > to obtain the domain's sxpr, so that the rest of Remus python code=
> stays as is.
>
> Is there an api call in libxl to return a domain's sxpr ? a grep o= n
> the libxl code
> base returned nothing. Or am I missing something pretty obvious?

xl has some code to do this but libxl doesn't. An sxpr repr= esentation of
a domain is rather a xend specific concept which is the only reason xl
has it.
There are some plans to allow libxl to generate json for any of the IDL
defined datastructures, mostly as a convenient pretty-printer but being
machine parsable is a handy side-effect. Currently this would just be
for individual datastructures though.

Where/how does remus use sxp? tools/python/xen/remus/vm.py:domtosxpr()
seems to consume a xend datastructure and make a Remus sxp out of it --
can an xl equivalent not be written using the python bindings? (NB
bindings may be incomplete, we can fix up as you discover stuff). Are
all usages of sxp in Remus of that particular sxp format or are there
others?


The only reason remus uses sxpr is because xend c= onveys info in that form.
Basically, it only needs the vif device name (= vif1.0, etc), the disk device name and
the access format (tap/drbd) for proper operation.

=A0save.py:Migra= tionSocket - establish connection with remote machine's xend daemon
= =A0vm.VM(domid): get sxpr (dominfo) from xend via xml rpc call.
=A0save.= py:Saver - image.makeheader(dominfo) - serialize the sxpr and send to remot= e machine.

everything else in vm.py is to parse the sxpr to extract the vif and di= sk info.
=A0self.disks =3D getdisks(self.dom)
=A0self.vifs =3D getvif= s(self.dom)

Are sxp's baked into the Remus wire-protocol?
Remus w= ire-protocol is whatever protocol xend requires.

The reason for bypassing the usual xend live migration code path is because= of the
callbacks, the checkpoint interval based suspend/resume, etc. Now that I kn= ow that
xl/libxl doesnt use sxpr in its wire-protocol (dunce! :( ), the = plan would have to be different.

(a) Follow the same implementation = style like that with xend (bypass xl's live
migration mechanism) - involves some code duplication probably for communic= ating with
remote machine, in xl's wire protocol. The advantage is m= ost of remus' python code (save.py,
=A0device.py, qdisc.py, code to = install/parse IFB devices, tc rules, etc) stays as is.

(b) integrate the remus control flow into xl/libxl stack - I dont know = how much work that would be
yet.
Personally I think moving
away from using SXPs internally towards using actual data structures
would be a good idea...

=A0
BTW, is tools/python/xen/remus part of xend or part of Remus? Or does it straddle the boundary?

part of Remus stack. <= br>
Ian.

shriram
--485b3970cadefea09004a520e99b-- --===============1862055972== 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 --===============1862055972==--