@Danp My apologies for not being more specific. I’m encountering an issue with XOA deployment on a home lab environment.
Environment Details:
Installation source: USB
Hardware: 16GB RAM, 1TB NVMe HDD
Initial install: Completes successfully
Dashboard: Displays expected status
Steps Taken:
Installed XCP-NG from USB — installation and setup completed without errors.
Verified dashboard — all components appeared healthy.
Deployed XOA to the existing HDD — process executed as expected.
Observed Behavior:
After deployment, XOA appears healthy overall, but the final item labeled “NEW” does not appear in the interface.
Expected Behavior: The “NEW” item should be visible after deployment.
Mark
Just a quick update. I tried changing the time to see if somehow doing it at midnight was causing the issue. I also tried changing the destination for the health check to restore to in case it was some issue with the HDD. Neither were successful.
@Pilow that probably would have been a good idea hey!
[image: xoa_homeassistant-tile-example.png?raw=true]
That's the example tile from dashboard-card-example.yaml.
But it's Home Assistant. You make it look however you want right?
Having the entities available to use is most of the challenge.
@bvitnik Thank you for the great response. I have had great success with Terraform - great work.
I'm not touching ocaml myself. And yes, Citrix... they are still above VMware/Broadcom on my list. But SMH.
I keep promoting XCP-ng hoping some large companies take advantage of it. It's much more valuable to me than nautobot, for example.
In case someone ran into the same problem here is how I solved it.
I had a feeling this was http mounts issue. I checked and looks like during update process the .xo-server.toml got deleted. I copied the sample one from the /opt/xen-orchestra/packages/xo-server/sample.config.toml , edited the http.mount and bob's your uncle.
I have a feeling this has something to do with the format of that file change. When I originally built from source the file has a slightly different syntax and it was called .xo-server.yaml. At least according tot he directions I used to build. In any case its all back to normal now.
Thanks you everyone for your help.
Thanks, this way we'll have a way to understand what's wrong with this OVA, if it's something really specific or a VMWare way to make something we didn't expected
that's relatively easy to explain, only the naming is doubled:
the backup-hdd are local disks raid1 in xcp-ng and there brought to xcp-ng as a local "vmbackup" volume, called vmbackup
on xcp-ng-volume a disk is created with the name "backup_raid1_1tb" and connected as 2nd disk (xvdb) to XO
[image: 1559158139829-ab68fa1c-49a8-4d15-afcf-ecdc8bcd9d04-grafik-resized.png]
to make the disk available for backup-usage the disk xvdb is mounted via "remote" as a local
now usage for backup-ng is possible, but the usage is not xo_disks
I've replied on github. For sure the VMs should not boot. Of course the source vm has autopower on parameter becouse it's needed.
The problem is big: DR copy of Second Active Directory server is up.... for sure I can expect AD problems in a while...
[image: 1558999805954-724808f6-fc82-4487-9f87-4d0291fc3e92-image.png]
Autopower on is set up:
[image: 1558999897310-e4b71a2e-17cd-4e5f-a863-77f693249847-image.png]
Hi,
Before reporting on issues when you use XO from the sources, you must always fetch the latest code available on GitHub. Because it's likely some issues are fixed since then. Please upgrade, and come back if the problem persists
