Unfortunately the Rust-based agent is effectively not progressing. Last commit was months ago, and the 0.4.0-release was over 2 years ago, Issues aren't tagged for many months. Simple and easy MR's are left hanging in limbo.
I'm hoping they will show this project some more love and attention soon. Since I really like the idea of an open source Rust-based agent. As it is clear other things are taking precedent over it.
Thanks again for your input and recomendations! I'll verify that this is solved by having the LUN expanded to 8GB instead. Afterwards I'll mark your answer as the solution!
Thank you for your reply.
The reasoning here is that we are experimenting quite heavily at this moment.
And the thinking here is to have three LUNs each for their intended purpose.
LUNs
1 for VHD-based VDIs
1 for qcow2 based VDIs
The ones above will be used and modified quite a bit
1 for the Heartbeat. Being left alone to be as standard out-of-the-box as possible.
All of the LUNs reside on the same storage systems (Dell PowerStore at the moment). So my resoning here is that they're all on the same storage cluster, and therefore will be affected similarily regardless. Exotic corner-cases may of course show up.
But I will absolutely take your recommendations into account! And when we've stopped messing with the storage for the VMs. I will have the Heartbeat there on that as well!
Update:
We just expanded the SR to 2GB. And I'm still getting the same error.
Write permissions were verified by creating a vdi on the SR. And that was successfull with no problem.
Next step in our lab testing was going to be to enable HA. For this we chose to go with a 500MB Fibre Channel LUN.
However, when I try to enable HA I will find an error in the logs saying SR_SOURCE_SPACE_INSUFFICIENT. (Full log down below).
So my question then becomes. Are the docs out of date, or could this possibly be something else under the hood?
Note: I'm currently waiting on the storage guy to expand the SR to 1GB.
XO CE: 5811d
Node: 24
Pool: Fully updated with latest patches as of may 26, 2026
pool.enableHa
{
"pool": "37e7a3b9-8c45-c7f2-7d09-249a935dd33d",
"heartbeatSrs": [
"3efef95a-4594-5a36-a182-f2b039d51ffa"
],
"configuration": {}
}
{
"code": "SR_SOURCE_SPACE_INSUFFICIENT",
"params": [
"OpaqueRef:601b3d23-c211-b853-0a9a-2c12e16a6567"
],
"call": {
"duration": 21,
"method": "pool.enable_ha",
"params": [
"* session id *",
[
"OpaqueRef:601b3d23-c211-b853-0a9a-2c12e16a6567"
],
{}
]
},
"message": "SR_SOURCE_SPACE_INSUFFICIENT(OpaqueRef:601b3d23-c211-b853-0a9a-2c12e16a6567)",
"name": "XapiError",
"stack": "XapiError: SR_SOURCE_SPACE_INSUFFICIENT(OpaqueRef:601b3d23-c211-b853-0a9a-2c12e16a6567)
at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
at file:///opt/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:38:21
at runNextTicks (node:internal/process/task_queues:65:5)
at processImmediate (node:internal/timers:472:9)"
}
Update: Changed title to better describe problem
I have done some more testing.
Windows Server 2022 is also affected. 9.1.145-77
I also tried the latest WindowsPV drivers from Vates, on Windows Server 2025. 9.1.200-0. And the "problem" still persists.
It is a very low impact and low importance "problem". Since it is afaik purely costmetical.
ping @poddingue for visibility as I believe I've found the trigger for IPv6 expanding... Live Migrations
Ah sorry I read it too quickly. This panel is only there in some occasions, but I see the point of only displaying it when we click on a relevant element. Feedback for you @julienxovates
While on the topic of the tree-view panel.
Have you noticed that the indentation changes if there is a chevron indicating that there are VMs on a host? Making it so that the hosts no longer are alinged vertically
@jr-m4 do you know you can collapse the side bar? Use the hamburger icon just after "Xen Orchestra" title to do so.
Yes, but it is the rightmost pane that I'm not agreeing with.
The left most "tree-view"-sidebar is quite usefull. And has imho good potential.
I really miss the description column XO5 has in the default/home view. I understand space is limited for the tree view, but maybe it could appear when a host is selected in the tree view?
In XO6, you will see it if you click on the eye at the end of the row, then on the right panel.
Is this OK ?
Personally I don't really find the rightmost pane/section all that usefull. It's to narrow to have any clear information. And it also leads to the other panels being smaller than they (imho) need to be able to show their base information as well.
This is especially noticable when using windows sizes narrower than 1080p.
The rightmost pane I hope will get either removed, and redone in UI v7. Because right now XO5 is far more informational than that is.
Sorry for jumping on with my two cents.
Thanks for your input.
Yes I'm aware that basically everything on the VM is incorporated into the snapshot. Including settings and metadata. This is acctually why I was surprised that the creation date wasn't preserved as part of that metadata. And as you say, if one uses that metric to track VM history. Then it can, and will, throw you off.
I'll gladly submit this as a feature request. But my gut feeling is that it is more akin to a bug than missing feature per se.
Thanks!
I do not have Citrix ones. This VM was pretty much freshly installed to test Windows2025 on as pure Vates-maintained stack as possible.
Update: Please note my post above. Tha this seems to be triggered by live-migrating the vm
I believe I have a reproducible method to make it expand.
The trick aparently is Live migrating the VM.
Pre live migration:
Post live migration:
I have now tried updating to the latest version included in the xcp-ng guest-tools.iso. Followed by a reboot.
At the moment, the zeroes are collapsed. But I won't count my chickens before they've hatched. So I will reply back if they expand out again (as seen before).
Thanks!
@jr-m4 Could you check if your VMs are using XenServer or XCP-ng tools?
They are using the vates provided xcp-ng guest tools.
After applying latest updates and commits, to both xcp and XO. The zeroes were still non-collapsed.
However. Rebooting the VM resulted in the zeroes now collapse properly as expected.
I had previously rebooted the VM, so I don't believe that was the solution. But I did not check inbetween pulling latest source, and updating XCP. So I'm unsure which update solved it.
But this then has been resolved.
Update: Not solved! Now on fully updated XCP & XO, and the VM being rebooted as per post-details above.
Well, I'm not seeing the same behavior here,
fe80::4496:9d87:690d:ccc7is collapsed, unlike in your screenshot
I'm now back with better information from the original pool.
xe vm-list uuid=0513005e-3626-1867-306d-9d5415cd6516 params=networks
networks (MRO) : 0/ip: 192.168.97.60; 0/ipv4/0: 192.168.97.60; 0/ipv6/0: fe80:0000:0000:0000:a57c:c544:3b03:8910
I will apply latest updates to see if this has any bearing on the matter.
I have noticed that on at least Windows Server 2025, using the vates maintaned XCP-ng Windows Gust Tools (v9.1.146.0). XO (same in both 5 & 6) doesn't seem to collapse the IPv6 zeroes as expected. Leading to l00000ng addresses visually.
I've searched for forum posts and can't see anything related to this.
The date format on our new XCP-ng interface only seems to show US dates (MM/DD/YY), which is pretty confusing for us here in Australia!
I can't see anything in the settings to change this, is there something I'm missing?
I'm guessing it's pretty confusing for most non-US people, including Swedes.