[ovirt-devel] [vdsm] Engine XML: metadata and devices from XML
Francesco Romani
fromani at redhat.com
Wed Mar 22 15:52:35 UTC 2017
On 03/18/2017 01:14 PM, Nir Soffer wrote:
>
>
> On Fri, Mar 17, 2017 at 4:58 PM Francesco Romani <fromani at redhat.com
> <mailto: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 <mailto: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?
We use libvirt metadata for elements; so each direct child of metadata
is a separate metadata grop:
ovirt-tune:qos is one
ovirt-vm:vm is one
and so forth. I don't want to mess up with the existing elements. So we
could be backward compatible at XML level (read: 4.1 XML works without
changes to 4.2)
>
>
> <ovirt-instance:graphics>
>
>
> What is ovirt-instance?
Gone, merged with ovirt-vm
ovirt-vm will hold both per-vm metadata and per-device metadata.
>
>
> <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?
*Here* we had this nesting because the example took vm.conf and brutally
translated to XML. Is a worst case scenario.
Why is it relevant? There it was initial discussion about how to deal
with complex device; to minimize changes, we could
marshal the existing vm.conf into the device metadata, then unmarshal on
Vdsm side and just use it to rebuild the devices
with the very same code we have today (yes, this means
sneaking/embedding vm.conf into the XML)
Should we go that way, it could look like the above.
Let's talk in general now. There are three main use cases requiring nesting:
1. per-vm metadta. Attach key/value pairs. We need one level of nesting
to avoid to mess up with other data. So it could look like
<metadata>
<ovirt-vm:vm>
<foo>1</foo>
<bar>2</bar>
</ovirt-vm:vm>
</metadata>
this is simple and nice and I think is not bothering anyone (hopefully :))
2. per-device metadata: it has to fit into vm section, and we could
possibly have more than one device with metadata, so the simplest format
is something like
<metadata>
<ovirt-vm:vm>
<foo>1</foo>
<bar>2</bar>
<devices>
<device>
<fast>true</fast>
<cheap>false</cheap>
</device>
</devices>
</ovirt-vm:vm>
</metadata>
This is the minimal nesting level we need. We could gather the
per-device metadata in a dict and feed device with it, like with a new
"meta" argument to device constructor, much like "custom" and "specParams"
Would that look good?
3. QoS. we need to support the current layout for obvious backward
compatibility questions. We could postpone this and use existing code
for some more time, but ultimately this should handled by metadata
module, just because it is supposed to be
the process-wide metadata gateway.
>
>
> <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.
Noted
>
>
>
> <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?
Will post as soon as possible.
--
Francesco Romani
Red Hat Engineering Virtualization R & D
IRC: fromani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170322/b80797f6/attachment-0001.html>
More information about the Devel
mailing list