[ovirt-devel] [vdsm] Engine XML: metadata and devices from XML

[Nir Soffer]

On Fri, Mar 17, 2017 at 4:58 PM Francesco Romani <fromani at redhat.com> wrote:

> 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170318/6a194605/attachment.html>