On 03/16/2017 08:03 PM, Francesco Romani wrote:
> On 03/16/2017 01:26 PM, Francesco Romani wrote:
>> On 03/16/2017 11:47 AM, Michal Skrivanek wrote:
>>>> On 16 Mar 2017, at 09:45, Francesco Romani <fromani@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.
> Early preview:
> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-compact
>
> still plenty of TODOs, I expect to be reviewable material worst case
> monday morning.
This is how typical XML could look like:
<metadata>
<ovirt-tune:qos />
<ovirt-vm:vm />
<devices>
Why do we need this nesting?
<ovirt-instance:graphics>
What is ovirt-instance?
ovirt-tune and ovirt-vm make sense, I can guess what you mean, I don't have any
idea what is ovirt-instance.
<specParams>
<fileTransferEnable>true</fileTransferEnable>
<copyPasteEnable>true</copyPasteEnable>
<displayIp>192.168.1.51</displayIp>
<keyMap>en-us</keyMap>
<spiceSslCipherSuite>DEFAULT</spiceSslCipherSuite>
<spiceSecureChannels>smain,sinputs,scursor,splayback,srecord,sdisplay,ssmartcard,susbredir</spiceSecureChannels>
<displayNetwork>ovirtmgmt</displayNetwork>
</specParams>
</ovirt-instance:graphics>
<ovirt-instance:disk>
<specParams>
Why do we need this nesting?
<path />
</specParams>
</ovirt-instance:disk>
<ovirt-instance:disk>
<specParams />
<domainID>c578566d-bc61-420c-8f1e-8dfa0a18efd5</domainID>
We are using sd_id, img_id and vol_id now for these in new storage code.
<volumeID>5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</volumeID>
<poolID>5890a292-0390-01d2-01ed-00000000029a</poolID>
<imageID>66441539-f7ac-4946-8a25-75e422f939d4</imageID>
We need more info about disks, like diskType, shared, discard, etc.
Can you show a complete vm xml with metadata?
</ovirt-instance:disk>
</devices>
</metadata>
still working on this
--
Francesco Romani
Red Hat Engineering Virtualization R & D
IRC: fromani
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel