libxl config datastructures

libxl config datastructures

[Tamas Lengyel]

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

Dear libxl developers,
currently there is no way to automatically parse a config file into
the libxl_domain_config datastructure and therefore using any libxl_*
function that requires that datastructure as an input is unusable. The only
implementation that creates that structure is in xl_cmdimpl.c in the
private function parse_config_data. As I see, it relies on the XLU_Config
structure to create the libxl_domain_config structure. It is
very impractical to replicate that code for third party tools just to be
able to use for example libxl_domain_restore.

My requests is either:

   - Create a publicly accessible function in libxl.h that parses a
   file/char* to libxl_domain_config structure (essentially making
   parse_config_data public).
   - Or just use XLU_Config everywhere. I'm not entirely sure why there is
   a need to have two separate formats and the whole translation in-between.

Thanks,
Tamas

[-- Attachment #1.2: Type: text/html, Size: 1011 bytes --]

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

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

Re: libxl config datastructures

[Tamas Lengyel]

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

Dear libxl developers,
currently there is no way to automatically parse a config file into
the libxl_domain_config datastructure and therefore using any libxl_*
function that requires that datastructure as an input is unusable. The only
implementation that creates that structure is in xl_cmdimpl.c in the
private function parse_config_data. As I see, it relies on the XLU_Config
structure to create the libxl_domain_config structure. It is
very impractical to replicate that code for third party tools just to be
able to use for example libxl_domain_restore.

My requests is either:

   - Create a publicly accessible function in libxl.h that parses a
   file/char* to libxl_domain_config structure (essentially making
   parse_config_data public).
   - Or just use XLU_Config everywhere. I'm not entirely sure why there is
   a need to have two separate formats and the whole translation in-between.

Thanks,
Tamas

[-- Attachment #1.2: Type: text/html, Size: 1701 bytes --]

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

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

Re: libxl config datastructures

[Ian Campbell]

On Wed, 2012-08-01 at 04:16 +0100, Tamas Lengyel wrote:
> Dear libxl developers,
> currently there is no way to automatically parse a config file into
> the libxl_domain_config datastructure and therefore using any libxl_*
> function that requires that datastructure as an input is unusable. The
> only implementation that creates that structure is in xl_cmdimpl.c in
> the private function parse_config_data. As I see, it relies on the
> XLU_Config structure to create the libxl_domain_config structure. It
> is very impractical to replicate that code for third party tools just
> to be able to use for example libxl_domain_restore. 

There is a deliberate split in functionality here, which is part of the
design of libxl.

libxl is a library which can be used to implement a toolstack. It is not
in and of itself a toolstack. I often say that it implements the common
"bottom third" of a toolstack.

xl is an actual toolstack which uses libxl and aims for, among other
things, xm compatibility which implies the ability to parse xm style
configuration files (and a similar command line syntax, etc).

The parsing of xl/xm style configuration files is specific to the
toolstack and therefore belongs in xl.

It is incorrect to say that "libxl_* function that requires that
datastructure as an input is unusable", it is obviously entirely
possible to fill in this data structure without reference to an xm/xl
style configuration file. If you are writing your own toolstack then it
is expected that you will have your own configuration format and will
parse that instead, there is certainly no general requirement that all
toolstack use xm/xl style configuration files.

For example The libxl backend for libvirt takes libvirt configuration
and uses that to drive libxl in order to implement the required
functionality and we expect that in the future the xapi toolstack will
similarly use settings in its database to drive libxl.

Now in actual fact the actual parser is in the libxlu (utils) library.
This is because although the configuration file format is particular to
xm/xl we acknowledge that some of the functionality of xl, such the
ability to parse simple key=value configuration files or xl disk
configuration specifications, might be useful to other toolstacks.

> My requests is either:

It would be useful if you would explain what you are actually trying to
achieve here. Are you writing your own toolstack which strives for xm
compatibility? Or are you perhaps trying to add functionality to libxl
which actual belongs in xl?

If you explain what you are doing then we can try and figure out how
best to move forward.

>       * Create a publicly accessible function in libxl.h that parses a
>         file/char* to libxl_domain_config structure (essentially
>         making parse_config_data public).
>       * Or just use XLU_Config everywhere. I'm not entirely sure why
>         there is a need to have two separate formats and the whole
>         translation in-between.

I don't think either of these would be correct and in keeping with the
design decisions which we have made for libxl/xl.

Ian.

Re: libxl config datastructures

[Tamas Lengyel]

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

Hi Ian,
thanks for the quick reply.

>  Are you writing your own toolstack which strives for xm compatibility?

In essence, yes. My goal is to checkpoint a running VM and be able to
restore the VM with a slightly modified configuration (which is currently
XM style). The config modification I can do easily with XLU_Config, but
turning that into libxl_domain_config would require, as you said, to write
my own translator.

> The parsing of xl/xm style configuration files is specific to the toolstack
and therefore belongs in xl.

While I understand the design decision now for keeping config formats
general, since the code is already written for xl, might as well let other
developers access it through libxlu when it's convenient for them. It would
make (at least my) life easier.

Thanks,
Tamas

[-- Attachment #1.2: Type: text/html, Size: 1666 bytes --]

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

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

Re: libxl config datastructures

[Ian Campbell]

On Wed, 2012-08-01 at 11:06 +0100, Tamas Lengyel wrote:
> Hi Ian,
> thanks for the quick reply. 
> 
> 
> >  Are you writing your own toolstack which strives for
> xm compatibility?
> 
> 
> In essence, yes. My goal is to checkpoint a running VM and be able to
> restore the VM with a slightly modified configuration (which is
> currently XM style). The config modification I can do easily with
> XLU_Config, but turning that into libxl_domain_config would require,
> as you said, to write my own translator.

Why not add this functionality to xl directly if it is useful?

Actually "xl restore" and "xl migrate" already support passing in an
updated configuration file to use on the other end, IIRC.

Ian.

Re: libxl config datastructures

[Ian Jackson]

Tamas Lengyel writes ("Re: [Xen-devel] libxl config datastructures"):
> Hi Ian,
> > The parsing of xl/xm style configuration files is specific to the toolstack
> and therefore belongs in xl.
> 
> While I understand the design decision now for keeping config formats general,
> since the code is already written for xl, might as well let other developers
> access it through libxlu when it's convenient for them. It would make (at least
> my) life easier.

I don't understand why you aren't happy to use just the config parser
supplied in libxlu.  It's there specifically for the use of people who
want to do things based on the xl config file format (or subsets of
it).

Ian.

Re: libxl config datastructures

[tamas.k.lengyel]

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

Hi Ian,

> I don't understand why you aren't happy to use just the config parser supplied in libxlu. 

I'm OK with the config parser in Xlu, my problem is the conversion between XLU_Config and the datastructure the libxl domain creation functions are expecting. Right now the only way would be to duplicate the code in xl to do the transition, which I don't want to do, or by calling xl itself instead of using libxl, which I found very ugly and hack-ish.

Further problems with XLU_Config is the fact that the datastructure is transparent. It would be fine, if there were more accessor functions written for it, such that it could be saved again as a file or dumped in a char *. Also would be required the ability to change elements of a XLU_ConfigList.

Currently, the only way I was able to do this is by unmasking XLU_Config and XLU_ConfigList, and interacting with the elements directly. That way I can change the config, export it back to a file, then by forking and calling xl itself (!) I can create the VM with the modified config. It works, its a hack, I don't like it.

I would be happy to send you patches that would enable me to do the XLU_Config modifications I need to do without needing to unmask it.

As for libxl, without the datastructure conversion I won't be able 
to use it and have to do the ugly fork and xl call instead..

Tamas
 

[-- Attachment #1.2: Type: text/html, Size: 1730 bytes --]

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

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

Re: libxl config datastructures

[Ian Jackson]

tamas.k.lengyel@gmail.com writes ("Re: [Xen-devel] libxl config datastructures"):
> I'm OK with the config parser in Xlu, my problem is the conversion between XLU_Config and the datastructure the libxl domain creation functions are expecting. Right now the only way would be to duplicate the code in xl to do the transition, which I don't want to do, or by calling xl itself instead of using libxl, which I found very ugly and hack-ish.

Yes.

> Further problems with XLU_Config is the fact that the datastructure is transparent. It would be fine, if there were more accessor functions written for it, such that it could be saved again as a file or dumped in a char *. Also would be required the ability to change elements of a XLU_ConfigList.

I have just gone and looked at the code and you mean
  parse_config_data
in xl_cmdimpl.c.

I think this should be in libxlu.  Sadly this is too late for Xen 4.2.

If you would like to send patches to move the code from
parse_config_data into libxlu, we'll consider them for 4.3.

Thanks,
Ian.