enhancement: add instance info as Libvirt metadata

[phsm]

Description

This PR adds <metadata> section to the domain XML of the virtual machine.

It is useful when the additional instance info is needed from within the compute host,
for example to use it with a monitoring exporter that would label the virtual machine with the additional information.

The method that generates the metadata object is defined in the HypervisorGuruBase class as protected, so it can be used in all its children classes. Currently I've only used it in the KVMGuru because I do not have any other hypervisor kind to test this on.

Additionally, some dead code that looks to be half-finished, was removed, namely
LibvirtVMDef.java: public class MetadataDef and the references to it. Kindly check this part, perhaps I accidentally remove something that was obscurely used by something.

Fixes: #6695

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

The metadata has the following format:

  <metadata>
    <cloudstack:instance xmlns:cloudstack="http://cloudstack.apache.org/instance">
      <cloudstack:zone uuid="e2b3416d-d21a-4907-8865-a3caeeae6a82">ZoneName</cloudstack:zone>
      <cloudstack:pod uuid="962722db-62eb-4ad4-8485-254d87c3050c">PodName</cloudstack:pod>
      <cloudstack:cluster uuid="aff7c9e2-aba8-4e8e-bcec-425d1c5e08ee">clusterName</cloudstack:cluster>
      <cloudstack:name>testname</cloudstack:name>
      <cloudstack:internal_name>i-64-320-VM</cloudstack:internal_name>
      <cloudstack:display_name>testdisplayname</cloudstack:display_name>
      <cloudstack:uuid>365622ff-5902-4c7b-beda-1790f99162f9</cloudstack:uuid>
      <cloudstack:service_offering>
        <cloudstack:name>serviceOfferingName</cloudstack:name>
        <cloudstack:cpu>2</cloudstack:cpu>
        <cloudstack:memory>4096</cloudstack:memory>
        <cloudstack:host_tags>
          <cloudstack:tag>hosttag1</cloudstack:tag>
          <cloudstack:tag>hosttag2</cloudstack:tag>
        </cloudstack:host_tags>
      </cloudstack:service_offering>
      <cloudstack:created_at>2025-06-19T13:13:43</cloudstack:created_at>
      <cloudstack:started_at>2025-06-19T13:17:08</cloudstack:started_at>
      <cloudstack:owner>
        <cloudstack:domain uuid="06fe1128-8252-11ef-8f6c-00163e3b404b">ROOT</cloudstack:domain>
        <cloudstack:account uuid="04c2e6cd-eb39-4619-9dbb-670fe27f2807">PrjAcct-test-1</cloudstack:account>
        <cloudstack:project uuid="0c437d02-7429-47b4-b5a4-19fb4bb452ff">test</cloudstack:project>
      </cloudstack:owner>
      <cloudstack:resource_tags>
        <cloudstack:resource_tag key="restag2">resvalue2</cloudstack:resource_tag>
        <cloudstack:resource_tag key="restag1">resvalue1</cloudstack:resource_tag>
      </cloudstack:resource_tags>
    </cloudstack:instance>
  </metadata>

How Has This Been Tested?

I specifically put an emphasis on compatibility with the previous versions, so having a mgmt server with this feature/agent without this feature and vice versa will not crash the VM startup.
These are the tests that I preformed:

Both the Mgmt servers and the Nodes contain this patch:

• Start a VM on a random host: works
• Start a VM on a specific host: works
• Start a VM with and without resource tags: works, the resource_tags becomes an empty array <cloudstack:resource_tags/>
• Start a VM with and without service offering host tags: works, the host_tags becomes an empty array <cloudstack:host_tags/>
• VM does not belong to a project: works, the project becomes empty <cloudstack:project uuid=""/>
• VM belongs to a project: works, the project info is shown.
• Livemigrate a VM with metadata between the hosts having this patch: works

Mgmt server contains the patch, the node does not contain the patch:

• Start a VM: works, the metadata section is absent
• Migrate a VM from a non-patched host to a patched host: works, the metadata is abesnt on the destination domain XML (because it is only formed during the VM start)
• Migrate a VM from a patched host to a non-patched host: works, the metadata is present on the destination domain XML

Mgmt server does not contain the patch, the host contains the patch:

• Start a VM: works, the metadata section is absent because createMetadataDef() returns null, and createVMFromSpec() does not try to append add this component to the LibvirtVMDef object.
• Migrate a VM from a patched host to a non-patched host, and then migrate back: works

How did you try to break this feature and the system with this change?

I specifically checked for the empty values in my tests: service offering without tags, no resource tags, no project etc as those look to be the most dangerous parts.
Plus, the code checks for null value everywhere, and uses "unknown" default value when null is occurred.

[codecov]

Codecov Report

Attention: Patch coverage is 1.64474% with 299 lines in your changes missing coverage. Please review.

Project coverage is 16.14%. Comparing base (8f2735a) to head (6f67d73).
Report is 1 commits behind head on 4.20.

Files with missing lines	Patch %	Lines
...om/cloud/hypervisor/kvm/resource/LibvirtVMDef.java	0.00%	116 Missing ⚠️
...m/cloud/agent/api/to/VirtualMachineMetadataTO.java	0.00%	91 Missing ⚠️
.../java/com/cloud/hypervisor/HypervisorGuruBase.java	0.00%	83 Missing ⚠️
.../java/com/cloud/agent/api/to/VirtualMachineTO.java	16.66%	5 Missing ⚠️
...ervisor/kvm/resource/LibvirtComputingResource.java	57.14%	1 Missing and 2 partials ⚠️
...er/src/main/java/com/cloud/hypervisor/KVMGuru.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               4.20   #11061      +/-   ##
============================================
- Coverage     16.15%   16.14%   -0.01%     
- Complexity    13273    13276       +3     
============================================
  Files          5657     5658       +1     
  Lines        497898   498173     +275     
  Branches      60374    60411      +37     
============================================
+ Hits          80435    80447      +12     
- Misses       408505   408762     +257     
- Partials       8958     8964       +6     

Flag	Coverage Δ
uitests	4.00% <ø> (ø)
unittests	16.99% <1.64%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[harikrishna-patnala]

@blueorangutan package

[blueorangutan]

@harikrishna-patnala a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13855

[DaanHoogland]

@blueorangutan test

[blueorangutan]

@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests