We downed our pool master (no VMs) for testing and the router VM (pfSense) lost internet connectivity.
When we restarted the master the router VM still has no internet connectivity.
All VMs,including the router are online in XO.
[image: 1764639416252-8e09b11c-d718-42fb-9aea-2a8ebd9f48b2-image.png]
From the pfSense console I can ping VMs on the LAN however there is internet connectivity.
Everything looks fine so I am at a loss as to what the issue is.
[image: 1764639562329-50f4713b-1f37-49ee-ac1c-453f9a0364ef-image.png]
@MajorP93
200gb free space was enough in my production system to cause this. The only thing I didn't try was filling it up until I found the point where it started working.
@cichy said in DevOps Megathread: what you need and how we can help!:
Prioritization of VM startup AND shutdown sequencing! PLEASE - in the GUI (XO). So - without code - I can finally shutdown my servers accessing DB's prior to shutting down the DB server vm's themselves thereby saving myself from table corruption.
@cichy In the past it was recommended to do this with an vApp and script. However this means editing the script or configuration file (if one’s created for the script). Which doesn’t make it as easy as the method, used by VMware ESXi for configuring the order and enabling the capacity.
Xen Orchestra and/or XCP-ng could really do with an UI (and API) based method of setting up and managing the VM boot and shutdown order.
That's normal. If you boot the replicated VMs, then blocks will be changed. It mean no further delta replication will work on this VM. Force boot it if you lost the original VM and you don't care about delta toward the copy anymore. If you just want to test the VM without doing a new full (breaking the delta chain), boot with a copy. I think I explained that in this video: https://www.youtube.com/watch?v=FfUqIwT8KzI
That's a display glitch.
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]
