Feature #4358
additional info to VM XML vit the metadata field (kvm)
Status: | Closed | Start date: | 02/26/2016 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Drivers - VM | |||
Target version: | Release 5.0 | |||
Resolution: | fixed | Pull request: |
Description
Hi,
As libvirt and qemu-kvm are in permanent development if someone would like to use cutting edge/latest stable/ there should be a way to change/tweak the VM XML easy. AFAIK the current XML generation is buried in the "core" (compiled c++ code).
Such an example is the polling of disk stats - it is a job that is ran on the hypervisors so they had only the data that is in the VM XML only and (IMO) there is a need for the poll script to know what is the TM_MAD for each disk and call correct script/driver/ to report the needed data(disk sizes, snapshot sizes etc.). for example if a disk is of type "block" it could be anything - lvm,iscsi,storpool etc. The benefits of this approach are simpler and more flexible vmm/poll script extendable for each additional driver.
Here is another example: Recently we played with the VM optimizations that are done by adding an tweaking tool in the vmm/deploy script to tweak the VM XML. It is good as proof of concept, but in real scenario there is a need to have an field to pass additional data how such hooks/scripts to behave depending on the given VM need. Easiest solution could be a custom field in the metadata of the VM XML to carry base64 encoded blob (or more fields?) that the opennebula admin can add to the VM via the VM templates or similar. I agree there are complication with the live addition of the disks, but it looks like a good beginning to have such info for the vmm/deploy. For the attach i think such data is good to be passed as additional argument so the attach script to know how to complete the tasks, again if the tm_mad is known it could offload the XML snipped to be build by external tool for the given driver,if available.
Probably there are other implications that are out of my mind, so this is a rough scratch what i have in mind.
Cheers,
Anton Todorov
Associated revisions
feature #4358: Adds <metadata><vm_xml64> element to the deployment file.
This new element includes de VM template in XML format and base64
encoded
feature #4358: Fixes deployment generation bugs
feature #4358: Do not include the element in base64 as it hits the max
element size limit by libvirt
History
#1 Updated by Ruben S. Montero over 5 years ago
- Status changed from Pending to Closed
- Target version set to Release 5.0
- Resolution set to fixed
Included a new element <metadata><vm_xml64> with the VM XML document encoded in base64