<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 17, 2017 at 4:58 PM Francesco Romani <<a href="mailto:fromani@redhat.com">fromani@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/16/2017 08:03 PM, Francesco Romani wrote:<br class="gmail_msg">
> On 03/16/2017 01:26 PM, Francesco Romani wrote:<br class="gmail_msg">
>> On 03/16/2017 11:47 AM, Michal Skrivanek wrote:<br class="gmail_msg">
>>>> On 16 Mar 2017, at 09:45, Francesco Romani <<a href="mailto:fromani@redhat.com" class="gmail_msg" target="_blank">fromani@redhat.com</a>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> We talked about sending storage device purely on metadata, letting Vdsm<br class="gmail_msg">
>>>> rebuild them and getting the XML like today.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> In the other direction, Vdsm will pass through the XML (perhaps only<br class="gmail_msg">
>>>> parts of it, e.g. the devices subtree) like before.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> This way we can minimize the changes we are uncertain of, and more<br class="gmail_msg">
>>>> importantly, we can minimize the risky changes.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> The following is a realistic example of how the XML could look like if<br class="gmail_msg">
>>>> we send all but the storage devices. It is built using my pyxmlpickle<br class="gmail_msg">
>>>> module (see [3] below).<br class="gmail_msg">
>>> That’s quite verbose. How much work would it need to actually minimize it and turn it into something more simple.<br class="gmail_msg">
>>> 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<br class="gmail_msg">
>> It is verbose because it is generic - indeed perhaps too generic.<br class="gmail_msg">
>> I can try something else based on a concept from Martin Polednik. Will<br class="gmail_msg">
>> follow up soon.<br class="gmail_msg">
> Early preview:<br class="gmail_msg">
> <a href="https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-compact" rel="noreferrer" class="gmail_msg" target="_blank">https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-compact</a><br class="gmail_msg">
><br class="gmail_msg">
> still plenty of TODOs, I expect to be reviewable material worst case<br class="gmail_msg">
> monday morning.<br class="gmail_msg">
<br class="gmail_msg">
This is how typical XML could look like:<br class="gmail_msg">
<br class="gmail_msg">
<metadata><br class="gmail_msg">
<ovirt-tune:qos /><br class="gmail_msg">
<ovirt-vm:vm /><br class="gmail_msg">
<devices><br class="gmail_msg"></blockquote><div><br></div><div>Why do we need this nesting?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<ovirt-instance:graphics><br class="gmail_msg"></blockquote><div><br></div><div>What is ovirt-instance?</div><div><br></div><div>ovirt-tune and ovirt-vm make sense, I can guess what you mean, I don't have any</div><div>idea what is ovirt-instance.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<specParams><br class="gmail_msg">
<fileTransferEnable>true</fileTransferEnable><br class="gmail_msg">
<copyPasteEnable>true</copyPasteEnable><br class="gmail_msg">
<displayIp>192.168.1.51</displayIp><br class="gmail_msg">
<keyMap>en-us</keyMap><br class="gmail_msg">
<spiceSslCipherSuite>DEFAULT</spiceSslCipherSuite><br class="gmail_msg">
<br class="gmail_msg">
<spiceSecureChannels>smain,sinputs,scursor,splayback,srecord,sdisplay,ssmartcard,susbredir</spiceSecureChannels><br class="gmail_msg">
<displayNetwork>ovirtmgmt</displayNetwork><br class="gmail_msg">
</specParams><br class="gmail_msg">
</ovirt-instance:graphics><br class="gmail_msg">
<ovirt-instance:disk><br class="gmail_msg">
<specParams><br class="gmail_msg"></blockquote><div><br></div><div>Why do we need this nesting?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<path /><br class="gmail_msg">
</specParams><br class="gmail_msg">
</ovirt-instance:disk><br class="gmail_msg">
<ovirt-instance:disk><br class="gmail_msg">
<specParams /><br class="gmail_msg">
<domainID>c578566d-bc61-420c-8f1e-8dfa0a18efd5</domainID><br class="gmail_msg"></blockquote><div><br></div><div>We are using sd_id, img_id and vol_id now for these in new storage code.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<volumeID>5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</volumeID><br class="gmail_msg">
<poolID>5890a292-0390-01d2-01ed-00000000029a</poolID><br class="gmail_msg">
<imageID>66441539-f7ac-4946-8a25-75e422f939d4</imageID><br class="gmail_msg"></blockquote><div><br></div><div>We need more info about disks, like diskType, shared, discard, etc.</div><div><br></div><div>Can you show a complete vm xml with metadata?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</ovirt-instance:disk><br class="gmail_msg">
</devices><br class="gmail_msg">
</metadata><br class="gmail_msg">
<br class="gmail_msg">
still working on this<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Francesco Romani<br class="gmail_msg">
Red Hat Engineering Virtualization R & D<br class="gmail_msg">
IRC: fromani<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Devel mailing list<br class="gmail_msg">
<a href="mailto:Devel@ovirt.org" class="gmail_msg" target="_blank">Devel@ovirt.org</a><br class="gmail_msg">
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a></blockquote></div></div>