enhancement: add instance info as Libvirt metadata by phsm · Pull Request #11061 · apache/cloudstack · GitHub

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 Report

❌ Patch coverage is 1.64474% with 299 lines in your changes missing coverage. Please review.
✅ Project coverage is 17.37%. Comparing base (b0c7719) to head (386890a).
⚠️ Report is 122 commits behind head on main.

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              @@
##               main   #11061      +/-   ##
============================================
- Coverage     17.38%   17.37%   -0.01%     
+ Complexity    15282    15281       -1     
============================================
  Files          5891     5892       +1     
  Lines        526356   526631     +275     
  Branches      64270    64307      +37     
============================================
- Hits          91526    91523       -3     
- Misses       424488   424764     +276     
- Partials      10342    10344       +2

Flag	Coverage Δ
uitests	3.61% <ø> (ø)
unittests	18.42% <1.64%> (-0.02%)	⬇️

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.

@blueorangutan package

@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.

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

@blueorangutan test

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

[SF] Trillian test result (tid-13587)
Environment: kvm-ol8 (x2), Advanced Networking with Mgmt server ol8
Total time taken: 62552 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr11061-t13587-kvm-ol8.zip
Smoke tests completed. 139 look OK, 2 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File
ContextSuite context=TestAccounts>:setup	Error	0.00	test_accounts.py
ContextSuite context=TestAddVmToSubDomain>:setup	Error	0.00	test_accounts.py
test_DeleteDomain	Error	12.74	test_accounts.py
test_forceDeleteDomain	Failure	12.91	test_accounts.py
ContextSuite context=TestRemoveUserFromAccount>:setup	Error	15.14	test_accounts.py
ContextSuite context=TestTemplateHierarchy>:setup	Error	1532.60	test_accounts.py
ContextSuite context=TestDeployVmWithAffinityGroup>:setup	Error	0.00	test_affinity_groups_projects.py

@weizhouapache @DaanHoogland @rohityadavcloud can this be merged?

@weizhouapache @DaanHoogland @rohityadavcloud can this be merged?

It needs 2 approvals and manual test

Just FYI: this code is now used on ~500 hosts across multiple Cloudstack platforms in our production. So it at least doesn't crash :)

Just FYI: this code is now used on ~500 hosts across multiple Cloudstack platforms in our production. So it at least doesn't crash :)

ok @phsm
since this is an enhancement, I change the target branch to main

can you fix the conflicts @phsm ?

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

@blueorangutan package

@DaanHoogland 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.

Just FYI: this code is now used on ~500 hosts across multiple Cloudstack platforms in our production. So it at least doesn't crash :)

ok @phsm since this is an enhancement, I change the target branch to main

can you fix the conflicts @phsm ?

The conflicts have been fixed. Should be alright now.

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

@blueorangutan test

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

[SF] Trillian test result (tid-14118)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 54501 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr11061-t14118-kvm-ol8.zip
Smoke tests completed. 146 look OK, 0 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File

Hi team,

news on it? Will be present on 4.22? @bernardodemarco all is fine? Thanks

@tanganellilore , 4.22 has a release candidate out, so I don’t think so. cc @harikrishna-patnala .

So @DaanHoogland you think that is not feasable have on it?
All stage passed 🙏🏻 @copilot

So @DaanHoogland you think that is not feasable have on it? All stage passed 🙏🏻 @copilot

we can merge it when @harikrishna-patnala call the freeze over we can merge it for 4.22.1. Or if the current RC doesn’t make it for the next one.

@phsm

This feature looks great and provides valuable functionality for monitoring and exporting.

My main concern is related to VM lifecycle management: I remember for KVM there is a function to unmanage a VM from CloudStack. If a VM is unmanaged this way, the newly added metadata configuration must be revoked or reset to its normal state. Has this scenario been taken into consideration.

Hello, sorry for the late reply: had to allocate some time to build the newer Cloudstack 4.22-RC and test the Unmanage behvior.

I wanted to test what actually happens during unmanage.
I compared the VM domain XML before and after the Unmanage: the XMLs are identical.

Which means, even the smbios info says its Cloudstack:

  <sysinfo type='smbios'>
    <system>
      <entry name='manufacturer'>Apache Software Foundation</entry>
      <entry name='product'>CloudStack KVM Hypervisor</entry>
      <entry name='serial'>15d24df0-db8d-44c4-819c-b58897e8efa0</entry>
      <entry name='uuid'>15d24df0-db8d-44c4-819c-b58897e8efa0</entry>
    </system>
  </sysinfo>

Thus, I am unsure whether the metadata should or should not stay in the unmanaged instance. So far the Unmanage functionality looks like "completely forget the VM and leave it be in the libvirt".

@phsm
This feature looks great and provides valuable functionality for monitoring and exporting.
My main concern is related to VM lifecycle management: I remember for KVM there is a function to unmanage a VM from CloudStack. If a VM is unmanaged this way, the newly added metadata configuration must be revoked or reset to its normal state. Has this scenario been taken into consideration.

Hello, sorry for the late reply: had to allocate some time to build the newer Cloudstack 4.22-RC and test the Unmanage behvior.

I wanted to test what actually happens during unmanage. I compared the VM domain XML before and after the Unmanage: the XMLs are identical.

Which means, even the smbios info says its Cloudstack:
  <sysinfo type='smbios'>
    <system>
      <entry name='manufacturer'>Apache Software Foundation</entry>
      <entry name='product'>CloudStack KVM Hypervisor</entry>
      <entry name='serial'>15d24df0-db8d-44c4-819c-b58897e8efa0</entry>
      <entry name='uuid'>15d24df0-db8d-44c4-819c-b58897e8efa0</entry>
    </system>
  </sysinfo>
Thus, I am unsure whether the metadata should or should not stay in the unmanaged instance. So far the Unmanage functionality looks like "completely forget the VM and leave it be in the libvirt".

yes, so do you want to give it the extra attention to remove the metadata @phsm ?

It was not clear if the CS maintainers wanted me to actually clean the <metadata> after the VM instance is unmanaged.
Judging by your reply, I understand it is necessary? Then I will work on it.

I think it is better not to touch the <sysinfo type='smbios'> part of the XML tree (this part is not something that this PR adds), as this part is actually visible from the inside of the VM.

Thus, I am unsure whether the metadata should or should not stay in the unmanaged instance. So far the Unmanage functionality looks like "completely forget the VM and leave it be in the libvirt".

yes, so do you want to give it the extra attention to remove the metadata @phsm ?

@DaanHoogland @phsm
I think it is ok to keep the libvirt metadata when unmanage the VM.

Thus, I am unsure whether the metadata should or should not stay in the unmanaged instance. So far the Unmanage functionality looks like "completely forget the VM and leave it be in the libvirt".

yes, so do you want to give it the extra attention to remove the metadata @phsm ?

@DaanHoogland @phsm I think it is ok to keep the libvirt metadata when unmanage the VM.

ok, in this cas we are ready to merge?

Thus, I am unsure whether the metadata should or should not stay in the unmanaged instance. So far the Unmanage functionality looks like "completely forget the VM and leave it be in the libvirt".

yes, so do you want to give it the extra attention to remove the metadata @phsm ?

@DaanHoogland @phsm I think it is ok to keep the libvirt metadata when unmanage the VM.

@weizhouapache

I guess this feature is designed to export VM metadata from Apache CloudStack to a monitoring system. However, we must address a data integrity concern: when a VM is unmanaged in CloudStack, its CloudStack-specific metadata becomes obsolete. To ensure the monitoring environment receives accurate data, this feature should automatically revoke exported metadata for unmanaged VMs.
Retaining metadata for an unmanaged VM will result in inaccurate data within monitoring systems.

@pavanaravapalli

Depends how the "Unmanage" VM action is interpreted by CS authors, and what the users expect it to do:

It is either

Leave VM be as it was, so the user can do their own choices what to do with its DomainXML, or
Leave VM be as it was, but clean up everything Cloudstack-related that is not crucial for the VM to work.

In your example the user can account for this, and clean up the metadata (and may be something else) by some post-unmanage scripts. Or maybe the user doesn't mind having the information of the VM past in its metadata.

Leave VM be as it was, so the user can do their own choices what to do with its DomainXML, or

@phsm
In case of Option 1 :
While persisting metadata for unmanaged VMs is a feasible approach for one or two instances. If multiple VMs become unmanaged, users are forced into a repetitive and manual cleanup proces.

If we adopt this approach, we must at a minimum document this behavior clearly in the release notes to set user expectations.

My personal opinion is that the Cloudstack shall not meddle with domainXML during unmanaging.

However, I will respect any decision from the maintainers. If the decision is to not edit the domainXML when unmanaging, then the PR is ready to merge. If the decision is to edit domainXML, then I can work on it.

If the decision is to not edit the domainXML when unmanaging, then the PR is ready to merge. If the decision is to edit domainXML, then I can work on it.

Personnally I think we can merge and work on an optional clearing the metadata later. I do not think a VM is no longer created by ACS once it is unmanaged so removing that would even be a bit lying ;) no biggy anyway but that’s up to you @pavanaravapalli … merging

If the decision is to not edit the domainXML when unmanaging, then the PR is ready to merge. If the decision is to edit domainXML, then I can work on it.

Personnally I think we can merge and work on an optional clearing the metadata later. I do not think a VM is no longer created by ACS once it is unmanaged so removing that would even be a bit lying ;) no biggy anyway but that’s up to you @pavanaravapalli … merging

@DaanHoogland
Agreed. I just wanted to call out this edge case for the release notes to set user expectations if PR merges as is :)

I just wanted to call out this edge case for the release notes to set user expectations if PR merges as is :)

would you create a PR for the next version of the release notes, @pavanaravapalli ?

I just wanted to call out this edge case for the release notes to set user expectations if PR merges as is :)

would you create a PR for the next version of the release notes, @pavanaravapalli ?

Thanks! I'd be happy to create the PR. To ensure I get it right, would you be open to pairing on it? I'm ready to work with your guidance since this is my first time with ACS release notes.

I just wanted to call out this edge case for the release notes to set user expectations if PR merges as is :)

would you create a PR for the next version of the release notes, @pavanaravapalli ?

Thanks! I'd be happy to create the PR. To ensure I get it right, would you be open to pairing on it? I'm ready to work with your guidance since this is my first time with ACS release notes.

open a new PR here: https://github.com/apache/cloudstack-documentation/compare
alternatively you can edit here : https://github.com/apache/cloudstack-documentation/blob/main/source/releasenotes/about.rst but be sure to edit the version you mean to. default is main (which suits this PR as it was also merged on main. On saving you are asked to create a PR.

I will review as will some others I presume #famouslastwords

I just wanted to call out this edge case for the release notes to set user expectations if PR merges as is :)

would you create a PR for the next version of the release notes, @pavanaravapalli ?

Thanks! I'd be happy to create the PR. To ensure I get it right, would you be open to pairing on it? I'm ready to work with your guidance since this is my first time with ACS release notes.

open a new PR here: https://github.com/apache/cloudstack-documentation/compare alternatively you can edit here : https://github.com/apache/cloudstack-documentation/blob/main/source/releasenotes/about.rst but be sure to edit the version you mean to. default is main (which suits this PR as it was also merged on main. On saving you are asked to create a PR.

I will review as will some others I presume #famouslastwords

@DaanHoogland
Hey! 🎉 I’ve opened a PR 👉 apache/cloudstack-documentation#595 — give it a look when you get a chance! 👀

* main: (1223 commits) Standardize and auto add license headers for SQL files with pre-commit (apache#12071) pre-commit use colored text in the CI for `pass / fail / skipped` (apache#11977) ui(locales): remove duplicates and fix typos (apache#11872) pre-commit: auto add table of contents with `doctoc` (apache#11679) chore: rename workflow `linter.yml` to `pre-commit.yml` (apache#11647) engine-schema: upgrade path for 4.23.0 (apache#12048) Fixes:apache#7837: Add isolationMethods and vlan to TrafficTypeResponse (apache#8151) Svgs (apache#12051) Update GUI Kubernetes logo (apache#11895) Keeping consistency with other error messages. (apache#11649) enhancement: add instance info as Libvirt metadata (apache#11061) Add empty Provider value in Network/VPC Offering form (apache#11982) merge fix Updating pom.xml version numbers for release 4.23.0.0-SNAPSHOT Updating pom.xml version numbers for release 4.22.1.0-SNAPSHOT UI: fix typo Upload SSL certificate (apache#11869) api/test: fix storage pool update with only id (apache#11897) Updating pom.xml version numbers for release 4.22.0.0 Handle null mountTimeout in RestoreBackupCommand (apache#11944) Fix the config 'powerflex.connect.on.demand' description (apache#11926) ...

boring-cyborg Bot added component:api component:kvm labels Jun 19, 2025

bernardodemarco self-requested a review June 19, 2025 18:49

DaanHoogland reviewed Jun 24, 2025

View reviewed changes

Comment thread api/src/main/java/com/cloud/agent/api/to/VirtualMachineMetadataTO.java Resolved

phsm force-pushed the 4.20-libvirt-metadata branch from 6f67d73 to 3acf518 Compare June 24, 2025 07:18

weizhouapache added this to the 4.22.0 milestone Aug 22, 2025

weizhouapache changed the base branch from 4.20 to main August 22, 2025 10:25

github-actions Bot added the status:has-conflicts label Aug 22, 2025

phsm force-pushed the 4.20-libvirt-metadata branch from 3acf518 to 834c2bd Compare August 26, 2025 11:57

github-actions Bot removed the status:has-conflicts label Aug 26, 2025

DaanHoogland added the status:needs-testing label Aug 28, 2025

DaanHoogland merged commit 8c86f24 into apache:main Nov 7, 2025

github-project-automation Bot moved this from In Progress to Done in Apache CloudStack 4.22.0 Nov 7, 2025

sureshanaparti modified the milestones: 4.22.0, 4.22.1 Nov 10, 2025

sureshanaparti removed this from Apache CloudStack 4.22.0 Nov 10, 2025

pavanaravapalli mentioned this pull request Nov 10, 2025

Document KVM VM metadata handling in unmanage process apache/cloudstack-documentation#595

Merged

pavanaravapalli mentioned this pull request Nov 24, 2025

[KVM] CloudStack infrastructure metadata is preserved in libvirt XML after unmanaged VM operation (introduced in PR #11061) #12126

Open

dhslove pushed a commit to ablecloud-team/ablestack-cloud that referenced this pull request Dec 11, 2025

enhancement: add instance info as Libvirt metadata (apache#11061 )

8b2da1d

rajujith added this to Apache CloudStack 4.22.1 Jan 5, 2026

sureshanaparti moved this to Done in Apache CloudStack 4.22.1 Jan 7, 2026

owsferraro pushed a commit to owsferraro/cloudstack that referenced this pull request Mar 25, 2026

enhancement: add instance info as Libvirt metadata (apache#11061 )

684d2e3

enhancement: add instance info as Libvirt metadata by phsm · Pull Request #11061 · apache/cloudstack · GitHub

Repository navigation

enhancement: add instance info as Libvirt metadata - #11061

enhancement: add instance info as Libvirt metadata#11061DaanHoogland merged 1 commit intoapache:mainapache/cloudstack:mainfrom phsm:4.20-libvirt-metadataphsm/cloudstack:4.20-libvirt-metadataCopy head branch name to clipboard

Conversation

phsm commented Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

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

Uh oh!

codecov Bot commented Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

harikrishna-patnala commented Jun 20, 2025

Uh oh!

blueorangutan commented Jun 20, 2025

Uh oh!

blueorangutan commented Jun 20, 2025

Uh oh!

DaanHoogland commented Jun 23, 2025

Uh oh!

blueorangutan commented Jun 23, 2025

Uh oh!

blueorangutan commented Jun 24, 2025

Uh oh!

Uh oh!

dalax01 commented Aug 22, 2025

Uh oh!

weizhouapache commented Aug 22, 2025

Uh oh!

phsm commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

weizhouapache commented Aug 22, 2025

Uh oh!

github-actions Bot commented Aug 22, 2025

Uh oh!

DaanHoogland commented Aug 26, 2025

Uh oh!

blueorangutan commented Aug 26, 2025

Uh oh!

phsm commented Aug 26, 2025

Uh oh!

blueorangutan commented Aug 26, 2025

Uh oh!

weizhouapache commented Aug 26, 2025

Uh oh!

blueorangutan commented Aug 26, 2025

Uh oh!

blueorangutan commented Aug 27, 2025

Uh oh!

DaanHoogland commented Oct 29, 2025

Uh oh!

tanganellilore commented Oct 29, 2025

Uh oh!

DaanHoogland commented Oct 30, 2025

Uh oh!

phsm commented Nov 5, 2025

Uh oh!

DaanHoogland commented Nov 6, 2025

Uh oh!

phsm commented Nov 7, 2025

Uh oh!

weizhouapache commented Nov 7, 2025

Uh oh!

DaanHoogland commented Nov 7, 2025

Uh oh!

pavanaravapalli commented Nov 7, 2025

Uh oh!

phsm commented Nov 7, 2025

Uh oh!

pavanaravapalli commented Nov 7, 2025

Uh oh!

enhancement: add instance info as Libvirt metadata#11061
DaanHoogland merged 1 commit into
apache:mainfrom
phsm:4.20-libvirt-metadata

phsm commented Jun 19, 2025 •
edited
Loading

codecov Bot commented Jun 19, 2025 •
edited
Loading

phsm commented Aug 22, 2025 •
edited
Loading