[libvirt] [PREPOST] XL parser

Jim Fehlig jfehlig at suse.com
Wed Aug 27 18:58:04 UTC 2014


Kiarie Kahurani wrote:
> Kiarie Kahurani (1):
>   src/xenconfig: XL parser
>
>  po/POTFILES.in                                |   1 +
>  src/Makefile.am                               |   3 +-
>  src/libvirt_xenconfig.syms                    |   5 +
>  src/libxl/libxl_driver.c                      |  44 ++-
>  src/xenconfig/xen_common.c                    | 140 ++++----
>  src/xenconfig/xen_common.h                    |  24 +-
>  src/xenconfig/xen_xl.c                        | 461 ++++++++++++++++++++++++++
>  src/xenconfig/xen_xl.h                        |  29 ++
>  tests/Makefile.am                             |   9 +-
>  tests/testutilsxen.c                          |  50 +++
>  tests/testutilsxen.h                          |   9 +-
>  tests/xlconfigdata/test-fullvirt-new-disk.cfg |  27 ++
>  tests/xlconfigdata/test-fullvirt-new-disk.xml |  46 +++
>  tests/xlconfigtest.c                          | 222 +++++++++++++
>  14 files changed, 981 insertions(+), 89 deletions(-)
>  create mode 100644 src/xenconfig/xen_xl.c
>  create mode 100644 src/xenconfig/xen_xl.h
>  create mode 100644 tests/xlconfigdata/test-fullvirt-new-disk.cfg
>  create mode 100644 tests/xlconfigdata/test-fullvirt-new-disk.xml
>  create mode 100644 tests/xlconfigtest.c
>
>
> After *toooo* long the xen-xl parser has arrived with support for 
> xl disk format and spice graphics(with admittedly very kludgy code)
>
> quick overview 
>
> 1)coverts xl disk config such as 
>
>      disk = ["/dev/sda,raw,hda,rw,"]
>
>     into xml config 
>
>       <disk type='block' device='disk'>
>         <driver name='phy'/>
>         <source dev='/dev/sda/'>
>         <target dev= 'hda' bus='ide'/>
>      </disk>
>
>     and vice-versa
>
>     You notice that in the xl disk config there is no driver type but
>     it appears on the xml;

Driver would be specified by the 'backendtype' keyword, e.g.

backendtype=phy
backendtype=tap
backendtype=qdisk

In the old, deprecated positional syntax, driver is part of the <format>

[<format>:][<target>],<vdev>[:<devtype>],<access>

E.g. "phy:/dev/bla/bla,hda,w" would be driverName = phy.

>  I use the format to intelligently guess the 
>     driver but this does not look very good again you notice I do not
>     support disk backend config which is because there is no member of
>     _virDomainDiskDef which I could relate to the backend
>   

If format is not specified, then you should emit it from the xml too.  E.g.

disk = ["vdev=hda, access=rw, target=/dev/HostVG/XenGuest2,
backendtype=phy"]

should be converted to

<disk type='block' device='disk'>
  <driver name='phy'/>
  <source dev='/dev/HostVG/XenGuest2'/>
  <target dev= 'hda' bus='ide'/>
</disk>

With no 'format', we shouldn't be guessing the 'type' attribute of
<driver>.

> 2)converts spice graphics config 
>     
>     spice = 1
>     spicehost = "127.0.0.1"
>     spiceport = 500
>     spicetls_port = 590 
>     spicedisable_ticketing = 1 #with this set you require a passwd
>     spicepasswd = "thebeast"
>     spiceagent_mouse = 1
>
> to 
>     <graphics type='spice' port='500' tlsPort='590' autoport='no' listen='127.0.0.1'>
>       <listen type='address' address='127.0.0.1'/>
>         <mouse mode='server'/>
>
>     and vice-versa
>
>     You notice that the passwd is not in the xml, am still trying to figure out why
>   

Passwords are scrubbed from the xml unless VIR_DOMAIN_XML_SECURE flag is
provided.

>     Again you will notice the current tests are a bit dependent on xen code(when 
>     initializing the xmlOpt) which would *better* be done away with but that would
>     require some code in src/libxl/
>
>     Into the bargain, am not *sure* how exactly to initialize _virCapsPtr which is 
>     reqiured for xml formatting because I *assume* that tests should be able to run
>     even with drivers not loaded.
>
>     Am also not *sure* that how to map disks to device type, the existing code(xm) 
>     code maps all the disks using another driver other than 'phy' to 'block'.Am not
>     sure this is correct.
>   

I think it is the other way around.  If the driver is phy, then type is
set to VIR_STORAGE_TYPE_BLOCK, otherwise type is set to
VIR_STORAGE_TYPE_FILE.

Regards,
Jim




More information about the libvir-list mailing list