tests: add xen-guest-agent integration tests by d3athjest3r · Pull Request #434 · xcp-ng/xcp-ng-tests

d3athjest3r · 2026-03-23T15:35:17Z

Description

Install the agent from the CI-published package repositories on a running Linux VM and verify its core Xenstore behaviour: version attributes, OS info, memory counters, feature-balloon flag, and VIF IP publication.
RPM packages are served from GitLab Pages (which supports the repodata/ directory structure that DNF requires) and DEB packages are served from the GitLab Generic Package Registry using a numeric project ID to prevent APT from decoding the %2F in the project path.

Signed-off-by: Julian Vetter julian.vetter@vates.tech

glehmann

I'm not sure we need the complex logic to find and download the last version.
There are not that many releases, so a simple URL should be enough IMO.
I think that would also allow downloading the file directly on the VM

d3athjest3r · 2026-03-24T13:04:26Z

I'm not sure we need the complex logic to find and download the last version. There are not that many releases, so a simple URL should be enough IMO. I think that would also allow downloading the file directly on the VM

Ok. But the URLs are not easy to find or to browse. What would be a "stable" URL to fetch the deb packages and the rpms from? I have, e.g., https://gitlab.com/xen-project/xen-guest-agent/-/releases. But they don't directly contain the RPMs or DEBs, I would have to extract the links to the successful pipeline artifacts, and download from there. Moreover, these paths are not aligned. One is artifacts/browse/RPMS/x86_64/ and one is artifacts/browse/RPMS/x86_64/. Would this be stable across releases? For the deb packages I could download it via https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/release-0.4.0/xen-guest-agent_0.4.0_amd64.deb. But for the RPMs this doesn't work. Any suggestions? @ydirson @dinhngtu @fallen

glehmann · 2026-03-24T13:30:33Z

They are stable as in "they won't go away", but not stable as in "we'll keep the same URL for a new release".

Updating the package URL in a PR instead of doing it automatically during the test would also prevent breaking the build in an unplanned way if the new package introduces a regression.

Other opinions are welcome :)

d3athjest3r · 2026-03-24T13:44:19Z

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686362/artifacts/raw/target/release/xen-guest-agent_0.4.0_amd64.deb

They are stable as in "they won't go away", but not stable as in "we'll keep the same URL for a new release".

Updating the package URL in a PR instead of doing it automatically during the test would also prevent breaking the build in an unplanned way if the new package introduces a regression.

Other opinions are welcome :)

Ping @tperard

tperard · 2026-03-24T15:15:11Z

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm
They are stable as in "they won't go away"

I disagree, URL based on a job_id can disappear from the day to the next, if we change setting on the project to keep only the artefact of the latest pipeline (on a branch) or change the retention to delete old artefacts. We should rely on a branch name or a tag instead.

There's Download job artifacts by reference name which makes it simple enough to download the needed artefact.

That would give us, for the main branch:

And replace main by 0.4.0 in the URL for the latest tag.

But that download all the artefacts as an archive, but there's another API to get one file only, if you know the path, e.g.:

https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/0.4.0/raw/target/release/xen-guest-agent_0.4.0_amd64.deb?search_recent_successful_pipelines=true&job=pkg-deb-amd64

With the full archive, you could just extract it, and install all the *.deb or all the *.rpm without needed to figure out the filename.

I've just notice that the two proposed "stable" URL seems to be from tag 0.4.0. I would rather have a self describing URL, but a looking random url with a description in a comment can work too, at the risk that the comment is getting out-of-sync as soon as we update the url.

d3athjest3r · 2026-03-24T15:21:35Z

https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm
They are stable as in "they won't go away"

I disagree, URL based on a job_id can disappear from the day to the next, if we change setting on the project to keep only the artefact of the latest pipeline (on a branch) or change the retention to delete old artefacts. We should rely on a branch name or a tag instead.

There's Download job artifacts by reference name which makes it simple enough to download the needed artefact.

That would give us, for the main branch:
* https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/main/download?search_recent_successful_pipelines=true&job=pkg-deb-amd64

* https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/main/download?search_recent_successful_pipelines=true&job=pkg-rpm-x86_64
And replace main by 0.4.0 in the URL for the latest tag.

But that download all the artefacts as an archive, but there's another API to get one file only, if you know the path, e.g.:
* https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/jobs/artifacts/0.4.0/raw/target/release/xen-guest-agent_0.4.0_amd64.deb?search_recent_successful_pipelines=true&job=pkg-deb-amd64
With the full archive, you could just extract it, and install all the *.deb or all the *.rpm without needed to figure out the filename.

I've just notice that the two proposed "stable" URL seems to be from tag 0.4.0. I would rather have a self describing URL, but a looking random url with a description in a comment can work too, at the risk that the comment is getting out-of-sync as soon as we update the url.

Ah nice that's ok. I already have code that extracts the rpms and debs from the archive. With your URL just the {deb,rpm} needs to be set for each archive. This would also always test the latest successful build. I think this is great. This way we make sure we don't have any regressions.

glehmann · 2026-03-24T16:59:41Z

Note that the URLs I proposed are just the ones from the release page, which have been there for 2 years, so let's say "kind of stable" :)
I also prefer the URLs proposed by @tperard.

Any opinion on:

the last version vs a specific version
downloading directly on the VM vs downloading on the runner then copying on the VM?

@xcp-ng/os-platform-release

dinhngtu · 2026-04-02T09:55:46Z

+        running_vm.reboot(verify=True)
+        running_vm.ssh(['systemctl', 'is-active', 'xen-guest-agent'])
+
+    def test_xenstore_data(self, running_vm):


The tests in here should be split into several separate test functions, which is free to do since agent_install has class scope anyway.

IMO another thing that should be tested is reporting of feature-balloon (cf. https://xcp-ng.org/forum/topic/11955/memory-ballooning-dmc-broken-since-xcp-ng-8.3-january-2026-patches/13?_=1775123800568)

Ok. Addressed. I have split all tests into individual functions.

I have added a test to see what the balloning feature reports.

dinhngtu · 2026-04-02T10:02:02Z

+    for slot in range(10):  # NUM_IFACE_IPS = 10 in xen-guest-agent
+        res = host.ssh_with_result(
+            ['xenstore-read', f'{xs_prefix}/attr/vif/{vif_id}/{proto}/{slot}']
+        )


I know that this is hardcoded in the guest agent, but we shouldn't make the same assumption in the tests.

Yes, I dynamically enumerate now the number of interfaces.

d3athjest3r · 2026-05-11T07:53:19Z

Ping @dinhngtu. I have addressed your comments on the tests.

glehmann · 2026-05-22T17:16:55Z

+        url_download(artifact_urls['rpm'], zip_path)
+        rpm_path = _extract_from_zip(zip_path, '.rpm', tmpdir)
+
+        url_download(artifact_urls['deb'], zip_path)


Move the download to the VM, we don't need the package locally

Yes, addressed. I now use some small snippet of python to download and extract the rpms/debs directly inside the VM.

Are we sure the requested VMs have python3 installed?

I'm not sure. At least for APT based VMs testing this, I now directly add the repository as a source for apt:

vm.ssh(f"echo 'deb [trusted=yes] {deb_repo} main/' " f"> /etc/apt/sources.list.d/xen-guest-agent.list") vm.ssh('apt-get update') vm.ssh('apt-get install -y xen-guest-agent')

Which makes the whole thing more transparent, and doesn't need any specific tools or features in the VM. For the RPM this is unfortunately not possible as of now. But I will have a look at the xen-guest-tools, if I can add this feature. We would need something with createrepo .... Not sure how much effort this is though.

I have send a pull request on the xen-guest-agent to deploy RPMs + repomd.xml, so we can use the folder directly as an RPM repository: https://gitlab.com/xen-project/xen-guest-agent/-/merge_requests/101

Install the agent from the CI-published package repositories on a running Linux VM and verify its core Xenstore behaviour: version attributes, OS info, memory counters, feature-balloon flag, and VIF IP publication. RPM packages are served from GitLab Pages (which supports the repodata/ directory structure that DNF requires) and DEB packages are served from the GitLab Generic Package Registry using a numeric project ID to prevent APT from decoding the %2F in the project path. Signed-off-by: Julian Vetter <julian.vetter@vates.tech>

stormi · 2026-06-08T11:18:19Z

@xcp-ng/os-platform-release Looks like this PR is ready to be merged. Are we waiting on something?

glehmann · 2026-06-08T11:44:47Z

I don't think so.
@d3athjest3r The PR has its required two approvals, you can merge whenever you're ready!

On modern systems that uses dnf, there is a compatibility yum wrapper, some refactoring can be considered to support more package managers. Observed issue was: tests/guest_tools/unix/test_xen_guest_agent.py::TestXenGuestAgent::test_agent_running_after_reboot[...] lib.commands.SSHCommandFailed: SSH command (dnf install -y xen-guest-agent) failed with return code 127: bash: dnf: command not found Related-to: #434 Signed-off-by: Philippe Coval <philippe.coval@vates.tech>

rzr · 2026-06-11T12:33:20Z

+            rpm_repo = xen_guest_agent_urls['rpm_repo']
+            vm.ssh(f"echo -e '[xen-guest-agent]\\nbaseurl={rpm_repo}main/\\ngpgcheck=0'"
+                   f" > /etc/yum.repos.d/xen-guest-agent.repo")
+            vm.ssh('dnf install -y xen-guest-agent')


Please consider this fixup change:

#582

rzr · 2026-06-16T13:49:39Z

This change is bringing some regressions on some hosts, more testing will be needed to be supported by our CI.

d3athjest3r · 2026-06-16T13:52:12Z

This change is bringing some regressions on some hosts, more testing will be needed to be supported by our CI.

Even with your fix to "detect" which package manager to use? Can you point me to the CI runs that failed?

d3athjest3r requested review from a team as code owners March 23, 2026 15:35

glehmann reviewed Mar 23, 2026

View reviewed changes

Comment thread tests/guest_tools/unix/test_xen_guest_agent.py Outdated

Comment thread tests/guest_tools/unix/test_xen_guest_agent.py Outdated

Comment thread tests/guest_tools/unix/test_xen_guest_agent.py Outdated

d3athjest3r force-pushed the test_rust_guest_agent branch 2 times, most recently from 86662db to 807c506 Compare March 24, 2026 15:49

dinhngtu reviewed Apr 2, 2026

View reviewed changes

d3athjest3r force-pushed the test_rust_guest_agent branch 5 times, most recently from b571a89 to 833a9d9 Compare April 30, 2026 06:45

dinhngtu approved these changes May 11, 2026

View reviewed changes

d3athjest3r force-pushed the test_rust_guest_agent branch from 833a9d9 to f2b4552 Compare May 22, 2026 13:13

glehmann requested changes May 22, 2026

View reviewed changes

d3athjest3r force-pushed the test_rust_guest_agent branch 7 times, most recently from 75b8016 to 3d8c3da Compare May 28, 2026 14:55

d3athjest3r force-pushed the test_rust_guest_agent branch from 3d8c3da to f44a732 Compare May 29, 2026 09:30

glehmann approved these changes May 29, 2026

View reviewed changes

d3athjest3r merged commit f7467dd into master Jun 8, 2026
10 checks passed

d3athjest3r deleted the test_rust_guest_agent branch June 8, 2026 12:05

rzr reviewed Jun 11, 2026

View reviewed changes

Uh oh!

Conversation

d3athjest3r commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

glehmann left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

d3athjest3r commented Mar 24, 2026

Uh oh!

glehmann commented Mar 24, 2026

Uh oh!

d3athjest3r commented Mar 24, 2026

Uh oh!

tperard commented Mar 24, 2026

Uh oh!

d3athjest3r commented Mar 24, 2026

Uh oh!

glehmann commented Mar 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d3athjest3r commented May 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stormi commented Jun 8, 2026

Uh oh!

glehmann commented Jun 8, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rzr commented Jun 16, 2026

Uh oh!

d3athjest3r commented Jun 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

d3athjest3r commented Mar 23, 2026 •

edited

Loading