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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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 toolstackand 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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.
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.