On 03/16/2017 11:47 AM, Michal Skrivanek wrote: >> On 16 Mar 2017, at 09:45, Francesco Romani <from...@redhat.com> wrote: >> >> We talked about sending storage device purely on metadata, letting Vdsm >> rebuild them and getting the XML like today. >> >> In the other direction, Vdsm will pass through the XML (perhaps only >> parts of it, e.g. the devices subtree) like before. >> >> This way we can minimize the changes we are uncertain of, and more >> importantly, we can minimize the risky changes. >> >> >> The following is a realistic example of how the XML could look like if >> we send all but the storage devices. It is built using my pyxmlpickle >> module (see [3] below). > That’s quite verbose. How much work would it need to actually minimize it and > turn it into something more simple. > Most such stuff should go away and I believe it would be beneficial to make > it difficult to use to discourage using metadata as a generic junkyard
It is verbose because it is generic - indeed perhaps too generic. I can try something else based on a concept from Martin Polednik. Will follow up soon. Bests, > >> >> <domain type='kvm' id='10'> >> <name>a0</name> >> <uuid>ccd945c8-8069-4f31-8471-bbb58e9dd6ea</uuid> >> <metadata xmlns:ovirt-tune="http://ovirt.org/vm/tune/1.0"; >> xmlns:ovirt-vm="http://ovirt.org/vm/1.0"; >> xmlns:ovirt-instance="http://ovirt.org/vm/instance/1.0";> >> <ovirt-tune:qos/> >> <ovirt-vm:vm/> >> <ovirt-instance:instance> >> <ovirt-instance:value type="dict"> >> <ovirt-instance:item key="devices" type="list"> >> <ovirt-instance:item index="0" type="dict"> >> <ovirt-instance:item key="index" >> type="str">2</ovirt-instance:item> >> <ovirt-instance:item key="iface" >> type="str">ide</ovirt-instance:item> >> <ovirt-instance:item key="specParams" type="dict"> >> <ovirt-instance:item key="path" type="str"/> >> </ovirt-instance:item> >> <ovirt-instance:item key="readonly" >> type="str">true</ovirt-instance:item> >> <ovirt-instance:item key="deviceId" >> type="str">e59c985c-46c2-4489-b355-a6f374125eb9</ovirt-instance:item> >> <ovirt-instance:item key="address" type="dict"> >> <ovirt-instance:item key="bus" >> type="str">1</ovirt-instance:item> >> <ovirt-instance:item key="controller" >> type="str">0</ovirt-instance:item> >> <ovirt-instance:item key="type" >> type="str">drive</ovirt-instance:item> >> <ovirt-instance:item key="target" >> type="str">0</ovirt-instance:item> >> <ovirt-instance:item key="unit" >> type="str">0</ovirt-instance:item> >> </ovirt-instance:item> >> <ovirt-instance:item key="device" >> type="str">cdrom</ovirt-instance:item> >> <ovirt-instance:item key="shared" >> type="str">false</ovirt-instance:item> >> <ovirt-instance:item key="path" type="str"/> >> <ovirt-instance:item key="type" >> type="str">disk</ovirt-instance:item> >> </ovirt-instance:item> >> <ovirt-instance:item index="1" type="dict"> >> <ovirt-instance:item key="poolID" >> type="str">5890a292-0390-01d2-01ed-00000000029a</ovirt-instance:item> >> <ovirt-instance:item key="volumeInfo" type="dict"> >> <ovirt-instance:item key="domainID" >> type="str">c578566d-bc61-420c-8f1e-8dfa0a18efd5</ovirt-instance:item> >> <ovirt-instance:item key="volType" >> type="str">path</ovirt-instance:item> >> <ovirt-instance:item key="leaseOffset" >> type="int">0</ovirt-instance:item> >> <ovirt-instance:item key="path" >> type="str">/rhev/data-center/mnt/192.168.1.20:_srv_virtstore_nfs_rel40x_data/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >> <ovirt-instance:item key="volumeID" >> type="str">5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >> <ovirt-instance:item key="leasePath" >> type="str">/rhev/data-center/mnt/192.168.1.20:_srv_virtstore_nfs_rel40x_data/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc.lease</ovirt-instance:item> >> <ovirt-instance:item key="imageID" >> type="str">66441539-f7ac-4946-8a25-75e422f939d4</ovirt-instance:item> >> </ovirt-instance:item> >> <ovirt-instance:item key="index" >> type="int">0</ovirt-instance:item> >> <ovirt-instance:item key="iface" >> type="str">virtio</ovirt-instance:item> >> <ovirt-instance:item key="apparentsize" >> type="str">8589934592</ovirt-instance:item> >> <ovirt-instance:item key="imageID" >> type="str">66441539-f7ac-4946-8a25-75e422f939d4</ovirt-instance:item> >> <ovirt-instance:item key="readonly" >> type="str">false</ovirt-instance:item> >> <ovirt-instance:item key="shared" >> type="str">false</ovirt-instance:item> >> <ovirt-instance:item key="truesize" >> type="str">0</ovirt-instance:item> >> <ovirt-instance:item key="type" >> type="str">disk</ovirt-instance:item> >> <ovirt-instance:item key="domainID" >> type="str">c578566d-bc61-420c-8f1e-8dfa0a18efd5</ovirt-instance:item> >> <ovirt-instance:item key="reqsize" >> type="str">0</ovirt-instance:item> >> <ovirt-instance:item key="format" >> type="str">raw</ovirt-instance:item> >> <ovirt-instance:item key="deviceId" >> type="str">66441539-f7ac-4946-8a25-75e422f939d4</ovirt-instance:item> >> <ovirt-instance:item key="address" type="dict"> >> <ovirt-instance:item key="function" >> type="str">0x0</ovirt-instance:item> >> <ovirt-instance:item key="bus" >> type="str">0x00</ovirt-instance:item> >> <ovirt-instance:item key="domain" >> type="str">0x0000</ovirt-instance:item> >> <ovirt-instance:item key="type" >> type="str">pci</ovirt-instance:item> >> <ovirt-instance:item key="slot" >> type="str">0x05</ovirt-instance:item> >> </ovirt-instance:item> >> <ovirt-instance:item key="device" >> type="str">disk</ovirt-instance:item> >> <ovirt-instance:item key="path" >> type="str">/rhev/data-center/5890a292-0390-01d2-01ed-00000000029a/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >> <ovirt-instance:item key="propagateErrors" >> type="str">off</ovirt-instance:item> >> <ovirt-instance:item key="optional" >> type="str">false</ovirt-instance:item> >> <ovirt-instance:item key="bootOrder" >> type="str">1</ovirt-instance:item> >> <ovirt-instance:item key="volumeID" >> type="str">5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >> <ovirt-instance:item key="specParams" type="dict"/> >> <ovirt-instance:item key="volumeChain" type="list"> >> <ovirt-instance:item index="0" type="dict"> >> <ovirt-instance:item key="domainID" >> type="str">c578566d-bc61-420c-8f1e-8dfa0a18efd5</ovirt-instance:item> >> <ovirt-instance:item key="volType" >> type="str">path</ovirt-instance:item> >> <ovirt-instance:item key="leaseOffset" >> type="int">0</ovirt-instance:item> >> <ovirt-instance:item key="path" >> type="str">/rhev/data-center/mnt/192.168.1.20:_srv_virtstore_nfs_rel40x_data/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >> <ovirt-instance:item key="volumeID" >> type="str">5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >> <ovirt-instance:item key="leasePath" >> type="str">/rhev/data-center/mnt/192.168.1.20:_srv_virtstore_nfs_rel40x_data/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc.lease</ovirt-instance:item> >> <ovirt-instance:item key="imageID" >> type="str">66441539-f7ac-4946-8a25-75e422f939d4</ovirt-instance:item> >> </ovirt-instance:item> >> </ovirt-instance:item> >> </ovirt-instance:item> >> </ovirt-instance:item> >> </ovirt-instance:value> >> </ovirt-instance:instance> >> </metadata> >> <maxMemory slots='16' unit='KiB'>4294967296</maxMemory> >> <memory unit='KiB'>4194304</memory> >> <currentMemory unit='KiB'>4194304</currentMemory> >> <vcpu placement='static' current='2'>16</vcpu> >> <cputune> >> <shares>1020</shares> >> </cputune> >> <resource> >> <partition>/machine</partition> >> </resource> >> <sysinfo type='smbios'> >> <system> >> <entry name='manufacturer'>oVirt</entry> >> <entry name='product'>oVirt Node</entry> >> <entry name='version'>7-3.1611.el7.centos</entry> >> <entry name='serial'>ccd79775-c888-4789-975a-fde1143dffc9</entry> >> <entry name='uuid'>ccd945c8-8069-4f31-8471-bbb58e9dd6ea</entry> >> </system> >> </sysinfo> >> <os> >> <type arch='x86_64' machine='pc-i440fx-rhel7.2.0'>hvm</type> >> <bios useserial='yes'/> >> <smbios mode='sysinfo'/> >> </os> >> <features> >> <acpi/> >> </features> >> <cpu mode='custom' match='exact'> >> <model fallback='allow'>Haswell-noTSX</model> >> <topology sockets='16' cores='1' threads='1'/> >> <numa> >> <cell id='0' cpus='0-1' memory='4194304' unit='KiB'/> >> </numa> >> </cpu> >> <clock offset='variable' adjustment='0' basis='utc'> >> <timer name='rtc' tickpolicy='catchup'/> >> <timer name='pit' tickpolicy='delay'/> >> <timer name='hpet' present='no'/> >> </clock> >> <on_poweroff>destroy</on_poweroff> >> <on_reboot>restart</on_reboot> >> <on_crash>destroy</on_crash> >> <devices> >> <emulator>/usr/libexec/qemu-kvm</emulator> >> <controller type='virtio-serial' index='0' ports='16'> >> <alias name='virtio-serial0'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' >> function='0x0'/> >> </controller> >> <controller type='usb' index='0'> >> <alias name='usb'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' >> function='0x2'/> >> </controller> >> <controller type='pci' index='0' model='pci-root'> >> <alias name='pci.0'/> >> </controller> >> <controller type='ide' index='0'> >> <alias name='ide'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' >> function='0x1'/> >> </controller> >> <interface type='bridge'> >> <mac address='00:1a:4a:16:01:51'/> >> <source bridge='ovirtmgmt'/> >> <target dev='vnet0'/> >> <model type='virtio'/> >> <filterref filter='vdsm-no-mac-spoofing'/> >> <link state='up'/> >> <alias name='net0'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' >> function='0x0'/> >> </interface> >> <serial type='unix'> >> <source mode='bind' >> path='/var/run/ovirt-vmconsole-console/ccd945c8-8069-4f31-8471-bbb58e9dd6ea.sock'/> >> <target port='0'/> >> <alias name='serial0'/> >> </serial> >> <console type='unix'> >> <source mode='bind' >> path='/var/run/ovirt-vmconsole-console/ccd945c8-8069-4f31-8471-bbb58e9dd6ea.sock'/> >> <target type='serial' port='0'/> >> <alias name='serial0'/> >> </console> >> <channel type='unix'> >> <source mode='bind' >> path='/var/lib/libvirt/qemu/channels/ccd945c8-8069-4f31-8471-bbb58e9dd6ea.com.redhat.rhevm.vdsm'/> >> <target type='virtio' name='com.redhat.rhevm.vdsm' >> state='disconnected'/> >> <alias name='channel0'/> >> <address type='virtio-serial' controller='0' bus='0' port='1'/> >> </channel> >> <channel type='unix'> >> <source mode='bind' >> path='/var/lib/libvirt/qemu/channels/ccd945c8-8069-4f31-8471-bbb58e9dd6ea.org.qemu.guest_agent.0'/> >> <target type='virtio' name='org.qemu.guest_agent.0' >> state='disconnected'/> >> <alias name='channel1'/> >> <address type='virtio-serial' controller='0' bus='0' port='2'/> >> </channel> >> <channel type='spicevmc'> >> <target type='virtio' name='com.redhat.spice.0' state='disconnected'/> >> <alias name='channel2'/> >> <address type='virtio-serial' controller='0' bus='0' port='3'/> >> </channel> >> <input type='mouse' bus='ps2'> >> <alias name='input0'/> >> </input> >> <input type='keyboard' bus='ps2'> >> <alias name='input1'/> >> </input> >> <graphics type='vnc' port='5900' autoport='yes' >> listen='192.168.1.53' keymap='en-us' passwdValidTo='1970-01-01T00:00:01'> >> <listen type='network' address='192.168.1.53' >> network='vdsm-ovirtmgmt'/> >> </graphics> >> <graphics type='spice' tlsPort='5901' autoport='yes' >> listen='192.168.1.53' keymap='en-us' defaultMode='secure' >> passwdValidTo='1970-01-01T00:00:01'> >> <listen type='network' address='192.168.1.53' >> network='vdsm-ovirtmgmt'/> >> <channel name='main' mode='secure'/> >> <channel name='display' mode='secure'/> >> <channel name='inputs' mode='secure'/> >> <channel name='cursor' mode='secure'/> >> <channel name='playback' mode='secure'/> >> <channel name='record' mode='secure'/> >> <channel name='smartcard' mode='secure'/> >> <channel name='usbredir' mode='secure'/> >> </graphics> >> <sound model='ich6'> >> <alias name='sound0'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' >> function='0x0'/> >> </sound> >> <video> >> <model type='qxl' ram='65536' vram='8192' vgamem='16384' heads='1' >> primary='yes'/> >> <alias name='video0'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' >> function='0x0'/> >> </video> >> <memballoon model='virtio'> >> <alias name='balloon0'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' >> function='0x0'/> >> </memballoon> >> </devices> >> <seclabel type='dynamic' model='selinux' relabel='yes'> >> <label>system_u:system_r:svirt_t:s0:c207,c629</label> >> <imagelabel>system_u:object_r:svirt_image_t:s0:c207,c629</imagelabel> >> </seclabel> >> <seclabel type='dynamic' model='dac' relabel='yes'> >> <label>+107:+107</label> >> <imagelabel>+107:+107</imagelabel> >> </seclabel> >> </domain> >> >> >> On 03/15/2017 01:28 PM, Francesco Romani wrote: >>> Hi everyone, >>> >>> This is both a report of the current state of my Vdsm patches for Engine >>> XML support, and a proposal to how move forward and solve >>> the current open issues. >>> >>> TL;DR: >>> 1. we can and IMO should reuse the current JSON schema to describe the >>> structure (layout) and the types of the metadata section. >>> 2. we don't need a priori validation of stuff in the metadata section. >>> We will just raise in the creation flow if data is missing, or wrong, >>> according to our schema. >>> 2. we will add *few* items to the metadata section, only thing we can't >>> express clearly-or at all in the libvirt XML. Redundancy and verbosiness >>> will be thus kept at bay >>> 3. I believe [3] is the best tool to do (de)serialize data to the >>> metadata section. Existing tools fits poorly in our very specific use case >>> >>> Examples below >>> >>> +++ >>> >>> Long(er) discussion: >>> >>> >>> I have working code[1][2] to encode any custom, picklable, python >>> object in the metadata section. >>> >>> We should decide which module will do the actual python<=>XML >>> transformation. >>> Please note that this actually also influences how the data in the >>> medata section look like, so the two things are a bit coupled. >>> >>> I'm eager to reinvent another wheel, but after >>> initial evaluation I honestly think that my pyxmlpickle[3] is the best >>> tool for the job over the current alternatives: plistlib[4] and >>> xmltodict[5]. >>> >>> I added the initial rationale here: >>> https://gerrit.ovirt.org/#/c/73790/4//COMMIT_MSG >>> >>> I have completed the initial draft of patches to make it possible to >>> initialize devices from their XML representation [6]. This is the bare >>> minimum we need to support the Engine XML, and we *need* this anyway to >>> unlock the cleanup we planned and I outlined in my google doc. >>> >>> So we are progressing, but I'd like to speed up things. Those [6] >>> patches are not yet complete, many flows are not covered or tested; but >>> they are good enough to demonstrate that there *are* pieces of >>> information wen need to properly initialize the devices, but we can't >>> easily extract from the XML. >>> >>> First examples that come to my mind are the storage.Drive UUIDs; there >>> could also be some ambiguity I'm investigating right now for >>> displayIp/displayNetwork in Graphics devices. In [6] there are various >>> TODO to mark more of those cases. Most likely, few more cases will pop >>> out as I cover all the flows we support. >>> >>> Long story short: it is hard to correctly rebuild the device conf from >>> the XML. This is why in [6] I added the 'meta' argument to from_xml_tree >>> classmethod in [7]. >>> >>> 'meta' is supposed to be the device metadata: extra data related to a >>> device which doesn't (yet) fit in the libvirt XML representation. >>> For example, we can store 'displayIp' and 'displayNetwork' here and be >>> done with that: using both per-device metadata and the XML >>> representation of one graphic device, we will have everything we need to >>> properly build one graphics.Graphics device. >>> This example may (hopefully) be bogus, but I'm keeping it because it is >>> one case easy to follow. >>> >>> The device metadata is going to be stored in the vm metadata for the >>> short/mid term future. Even if the per-device metadata idea/RFE is >>> accepted (no answer yet, but we are working on it), we will not have in >>> 7.4, and unlikely in 7.5. >>> >>> As it stands today, I believe there are two open questions: >>> >>> 1. do we need a schema for the metadata section? >>> 2. how do we bind the metadata to the devices? How do we know which >>> metadata belongs to which metadata, if we don't have aliases nor >>> addresses to match? (e.g. very first time the VM is created!) >>> >>> My current stance is the following >>> 1. In general, one schema gives us two benefits: 1.a. we document how >>> the layout of the data should be, including types; 1.b. we can validate >>> the data we receive. >>> So yes, we need a schema, but we don't need a *new* schema. I think we >>> are in good enough shape with the current Vdsm schema: we can just >>> translate the python object layout to a XML layout. >>> >>> One example is probably more explicative. Some actual data may look >>> like, using my pyxmlpickle module: >>> >>> <domain type='kvm' id='5'> >>> <name>a0</name> >>> <uuid>ccd945c8-8069-4f31-8471-bbb58e9dd6ea</uuid> >>> <metadata xmlns:ovirt-tune="http://ovirt.org/vm/tune/1.0"; >>> xmlns:ovirt-vm="http://ovirt.org/vm/1.0"; >>> xmlns:ovirt-instance="http://ovirt.org/vm/instance/1.0";> >>> <ovirt-tune:qos/> >>> <ovirt-vm:vm/> >>> <ovirt-instance:instance> >>> <ovirt-instance:value type="dict"> >>> <ovirt-instance:item key="devices" type="list"> >>> <ovirt-instance:item index="0" type="dict"> >>> <ovirt-instance:item key="device" >>> type="str">vnc</ovirt-instance:item> >>> <ovirt-instance:item key="specParams" type="dict"> >>> <ovirt-instance:item key="displayNetwork" >>> type="str">ovirtmgmt</ovirt-instance:item> >>> <ovirt-instance:item key="displayIp" >>> type="str">192.168.1.53</ovirt-instance:item> >>> </ovirt-instance:item> >>> <ovirt-instance:item key="type" >>> type="str">graphics</ovirt-instance:item> >>> </ovirt-instance:item> >>> <ovirt-instance:item index="1" type="dict"> >>> <ovirt-instance:item key="device" >>> type="str">spice</ovirt-instance:item> >>> <ovirt-instance:item key="specParams" type="dict"> >>> <ovirt-instance:item key="displayNetwork" >>> type="str">ovirtmgmt</ovirt-instance:item> >>> <ovirt-instance:item key="displayIp" >>> type="str">192.168.1.53</ovirt-instance:item> >>> </ovirt-instance:item> >>> <ovirt-instance:item key="type" >>> type="str">graphics</ovirt-instance:item> >>> </ovirt-instance:item> >>> <ovirt-instance:item index="2" type="dict"> >>> <ovirt-instance:item key="poolID" >>> type="str">5890a292-0390-01d2-01ed-00000000029a</ovirt-instance:item> >>> <ovirt-instance:item key="imageID" >>> type="str">66441539-f7ac-4946-8a25-75e422f939d4</ovirt-instance:item> >>> <ovirt-instance:item key="domainID" >>> type="str">c578566d-bc61-420c-8f1e-8dfa0a18efd5</ovirt-instance:item> >>> <ovirt-instance:item key="device" >>> type="str">disk</ovirt-instance:item> >>> <ovirt-instance:item key="path" >>> type="str">/rhev/data-center/5890a292-0390-01d2-01ed-00000000029a/c578566d-bc61-420c-8f1e-8dfa0a18efd5/images/66441539-f7ac-4946-8a25-75e422f939d4/5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >>> <ovirt-instance:item key="volumeID" >>> type="str">5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</ovirt-instance:item> >>> </ovirt-instance:item> >>> </ovirt-instance:item> >>> </ovirt-instance:value> >>> </ovirt-instance:instance> >>> </metadata> >>> <!-- omitted for brevity --> >>> </domain> >>> >>> >>> Please note that yes, this is still verbose, but we don't want to add >>> much data here, for most of information the most reliable source will >>> be the domain XML. We will add here only the extra info we can't really >>> fetch from that. >>> >>> 2. I don't think we need explicit validation: we could just raise along >>> the way in the creation flow if we don't find some extra metadata we >>> need. This will also solve the issue that if we reuse the current schema >>> and we omit most of data, we will lack quite a lot of elements >>> marked mandatory. >>> >>> Once we reached agreement, I will update my >>> https://docs.google.com/document/d/1eD8KSLwwyo2Sk64MytbmE0wBxxMlpIyEI1GRcHDkp7Y/edit#heading=h.hqdqzmmm9i77 >>> accordingly. >>> >>> Final note: while device take the lion's share, we will likely need help >>> from the metadata section also to store VM extra info, but all the above >>> discussion also applies here. >>> >>> +++ >>> >>> [1] >>> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata3 >>> - uses xmltodict >>> [2] >>> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-pyxmlpickle >>> ported the 'virt-metadata3' topic to pyxmlpickle >>> [3] https://github.com/fromanirh/pyxmlpickle >>> [4] https://docs.python.org/2/library/plistlib.html >>> [5] https://github.com/martinblech/xmltodict >>> [6] >>> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vm-devs-xml >>> [7] https://gerrit.ovirt.org/#/c/72880/15/lib/vdsm/virt/vmdevices/core.py >>> >> -- >> Francesco Romani >> Red Hat Engineering Virtualization R & D >> IRC: fromani >> >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> >> -- Francesco Romani Red Hat Engineering Virtualization R & D IRC: fromani _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
