Difference between revisions of "HowToPopulateLibosinfoDB"

From Libvirt Wiki
Jump to: navigation, search
(Example of usage)
Line 2: Line 2:
  
 
=== Example of usage ===
 
=== Example of usage ===
First of all we need to get a picture what are the basic data types used in the [http://fedorahosted.org/libosinfo libosinfo] and how are they used. Liboisnfo aim is to have APIs to manage info about various operating system, hypervisors ('platform' in libosinfo terminology) and devices they or their combination support. For example:
+
First of all we need to get a picture what are the basic data types used in the [http://fedorahosted.org/libosinfo libosinfo] and how are they used. Liboisnfo aim is to have APIs to manage info about various operating systems, hypervisors ('platform' in libosinfo terminology) and devices they or their combination support. For example:
 
<code>
 
<code>
 
  #!/usr/bin/python
 
  #!/usr/bin/python
Line 11: Line 11:
 
</code>
 
</code>
  
We create a loader and let it process the default paths. This includes <code>/usr/share/libosinfo</code>, <code>/etc/libosinfo/db</code> and <code>~/.config/libosinfo/db</code>. Moreover, various paths can be supplied via <code>OSINFO_DATA_DIR</code> environment variable. In this process, the XML files (the acutal database) are read in and parsed. Each object in the DB has its own ID. For some reason, libosinfo coders have decided to use (nonexistent) URIs for that: <code>http://qemu.org/qemu-kvm-0.11.0</code> or <code>http://fedoraproject.org/fedora-10</code>. These are referred to as long IDs. If you want, you can use short IDs (<code>kvm-0.11.0</code> and <code>fedora10</code> in this case) but you have to be sure they are unique and doesn't address more than one long ID.
+
We create a loader and let it process the default paths. This includes <code>/usr/share/libosinfo</code>, <code>/etc/libosinfo/db</code> and <code>~/.config/libosinfo/db</code>. Moreover, various paths can be supplied via <code>OSINFO_DATA_DIR</code> environment variable. In this process, the XML files (the acutal database) are read in and parsed. Each object in the DB has its own ID. For some reason, libosinfo coders have decided to use (nonexistent) URIs for that: <code>http://qemu.org/qemu-kvm-0.11.0</code> or <code>http://fedoraproject.org/fedora-10</code>. These are referred to as long IDs. If you want, you can use short IDs (<code>kvm-0.11.0</code> and <code>fedora10</code> in this case) but you have to be sure they are unique and don't address more than one long ID.
  
 
<code>
 
<code>

Revision as of 17:21, 5 September 2012

How to populate Libosinfo DataBase

Example of usage

First of all we need to get a picture what are the basic data types used in the libosinfo and how are they used. Liboisnfo aim is to have APIs to manage info about various operating systems, hypervisors ('platform' in libosinfo terminology) and devices they or their combination support. For example:

#!/usr/bin/python
from gi.repository import Libosinfo as osinfo;
loader = osinfo.Loader()
loader.process_default_path()
db = loader.get_db()

We create a loader and let it process the default paths. This includes /usr/share/libosinfo, /etc/libosinfo/db and ~/.config/libosinfo/db. Moreover, various paths can be supplied via OSINFO_DATA_DIR environment variable. In this process, the XML files (the acutal database) are read in and parsed. Each object in the DB has its own ID. For some reason, libosinfo coders have decided to use (nonexistent) URIs for that: http://qemu.org/qemu-kvm-0.11.0 or http://fedoraproject.org/fedora-10. These are referred to as long IDs. If you want, you can use short IDs (kvm-0.11.0 and fedora10 in this case) but you have to be sure they are unique and don't address more than one long ID.

os = db.get_os("http://fedoraproject.org/fedora-11")
hv = db.get_platform("http://qemu.org/qemu-kvm-0.11.0")

So now we've actually searched the DB for specific OS and platform. Simple so far, isn't it?

dep = db.find_deployment(os, hv)
fltr = osinfo.Filter()
fltr.add_constraint("class", "network")
link = dep.get_preferred_device_link(osinfo.DeviceLinkFilter(target_filter = fltr))
dev = link.get_target()
print "Device: '" + dev.get_name() + "' Driver: '" + link.get_driver() + "'"

The next thing we need to do once we've obtained OS and platform from the DB is find so called deployments. This actually combines the two and tells what devices are supported (okay, the OS and Platform can contain list of supported devices as well, but don't overtake). This is the part which needs populating the most. Once we have the deployment, we create a filter - in this case we want device with 'network' class = NIC and ask what is the preferred device. We obtain a link which contains interesting data.

Example of DB

<libosinfo version="0.0.1">

<device id="http://pci-ids.ucw.cz/read/PC/1002/4382">
  <class>audio</class>
  <bus-type>pci</bus-type>
  <vendor>0x1002</vendor>
  <product>0x4382</product>
  <name>SB600 AC97 Audio</name>
</device>

<device id="http://pci-ids.ucw.cz/read/PC/1274/5000">
  <class>audio</class>
  <bus-type>pci</bus-type>
  <vendor>0x1274</vendor>
  <product>0x5000</product>
  <name>ES1370</name>
  <name>es1370</name>
</device>

<device id="http://pci-ids.ucw.cz/read/PC/a727/0013">
  <class>network</class>
  <bus-type>pci</bus-type>
  <vendor>0xa727</vendor>
  <product>0x0013</product>
  <name>3CRPAG175 Wireless PC Card</name>
</device>

<os id="http://fedoraproject.org/fedora-10">
  <short-id>fedora10</short-id>
  <name>Fedora 10</name>
  <vendor>Fedora Project</vendor>

  <devices>
    <device id="http://pci-ids.ucw.cz/read/PC/1274/5000">
      <driver>ac97</driver>
    </device>
  </devices>

  <resources arch="all">
    <minimum>
      <n-cpus>1</n-cpus>
      <ram>402653184</ram>
    </minimum>

    <recommended>
      <cpu>400000000</cpu>
      <ram>536870912</ram>
      <storage>9663676416</storage>
    </recommended>
  </resources>
</os>

<platform id="http://qemu.org/qemu-kvm-0.11.0">
  <upgrades id="http://qemu.org/qemu-kvm-0.10.0" />
  <short-id>kvm-0.11.0</short-id>
  <name>KVM 0.11.0</name>
  <version>0.11.0</version>
  <devices>
    <device id="http://pci-ids.ucw.cz/read/PC/1002/4382" />
    <device id="http://pci-ids.ucw.cz/read/PC/1274/5000" />
    <device id="http://pci-ids.ucw.cz/read/PC/a727/0013" />
  </devices>
</platform>

<deployment id="http://fedoraproject.org/fedora-10?kvm-0.11.0">
  <platform id="http://qemu.org/qemu-kvm-0.11.0" />
  <os id="http://fedoraproject.org/fedora-10" />

  <devices>
    <device id="http://pci-ids.ucw.cz/read/PC/1002/4382">
      <driver>ac97</driver>
    </device>
    <device id="http://pci-ids.ucw.cz/read/PC/a727/0013">
      <driver>3com</driver>
    </device>
  </devices>
</deployment>
</libosinfo>

Okay, this is rather long, but I think it's selfexplanatory. The RNG schema is here.

BTW, running the above example against this DB will throw this output:

Device: '3CRPAG175 Wireless PC Card' Driver: '3com'

Description of classes

As you may already know, <os/> addresses OS class, <platform/> addresses Platform and so on. The most crucial part is the deployment becasue that's what actually make libosinfo usable for purposes like virt-install: "Hey, I want to run OS X on hypervisor Y. What model of NIC should I use? What is the recommended amount of RAM?"