@Razor_648 While I was writing my previous message, I have been reminded that there are also issues with LVHDoISCSI SR and CBT, you should disable CBT on your backup job and on all VDI on the SR. It might help with the issue.
@Danp said in Advanced VM settings Logs:
Hi Dustin,
Yes... these types of actions are recorded in the Audit log (Settings > Audit) if you have access to this feature and have enabled it.
Dan
Perfect, thanks!
@olivierlambert Understood, however, I'm failing to see what part of my posting was irrelevant to the topic at hand. I was merely sharing what I'd experienced as well and providing context.
I thought this was the kind of feedback expected of community members, who want to see this project flourish?
@StephenAOINS
This endpoint is not currently present in our REST API swagger, but we do plan to add it to the list of endpoints.
We are currently finalizing the migration of existing endpoints, the next step will be adding new ones.
We will keep you informed when it is available. Feel free to come back to us if you want to learn more and follow our blog posts.
have a good day
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]
