Offline
@stormi Thanks. I'll cross my fingers for a fix, at some time.
I also updated yesterday, on my ODROID H3+. Everything worked as expected.
I noticed that /etc/xensource/usb-policy.conf was send back to stock configuration, so I readded my modification to it. I'm not sure, if that's the expected behavior, after the host update + restart.
Thank you for the latest update 
.
@stormi Updated a single lab with no problems.
I'm not sure if "pure positive" updates are meant for this thread, so I'll just report that, anyways 
.
@stormi Thank you!
Are there any planned work related to hot backups of VM's, where a USB device are attached? It's currently not possible.
In the weekend I ended up moving a single container to a alpine image, so I could continue backing up my primary docker VM. But I was hoping to have rolling backup of the alpine VM, too
Great work.
Let's hope the team will migrate a similar implementation in near future 
I'm trying to make a webhook which only fires, if my backup has been made properly (success, without errors). Is that possible?
backupNg.runJob does fire, but at all actions. Are there a better method hook I can use? I'm not been able to track a more suitable method, yet.
Have I missed a detail, or is that not possible right now?
The backup-reports allows me to device the runId, but I'd like to have a webhook even every-time things go as planned (as I've like to integrate the reporting into the service from healthchecks.io).
Another workaround would be to have the backup job fire a postpone script or similar, allowing me to customize it (if the proper amount of data was available), or have a postpone script for both success and failure for each job.
Healthcheck does support filtering of the payload received, but only for emails, though. And I'd like to get it working with webhooks, if possible.
@stormi Updated a single lab with no problems.
I'm not sure if "pure positive" updates are meant for this thread, so I'll just report that, anyways .
@olivierlambert I clearly didn't spend much time in the updated interface, yesterday evening 
! It was not meant as a "Well, no changes, boring and lazy devs", or anything like that. I really enjoy XO.
I normally update all other things quite often. But I simply didn't think of the fact, that XO was isolated in it's own VM, and living it's own dreams.
@manilx said in XCP-ng 8.3 betas and RCs feedback 
:
Keep it updated and follow Vates' blog to have the news and changes
Thank you. I'll start following that for news. My limited use of XO does mean that I'm not really digging into the deeper levels. This is a great shortcut for that .
I'm excited about the 8.3 production release. With that said, I joined XCP-ng with the 8.3 release, and it has been rock solid. I mean, there has been a few bugs, but nothing impacting the stability.
I also faced problems with controlling power-state of my VMs (reboot) yesterday, but after installing the latest patches to my host (through XO), and rebooted the host, things worked again, as expected.
@stormi said in XCP-ng 8.3 betas and RCs feedback :
Reboot after update
...
Question : What's the "upgrade path" for us starting on 8.3 alpha. Is it just a question about updating the system, and nothing else?
Or, should I plan some kind of operation, so I can "switch" to a stable 8.3 release at some time? Like switching from unstable to a stable branch in Manjaro. Maybe it should make sense to include something about that, in a upcoming final release for 8.3. I bet other people with a r8125 NIC also jumped directly on 8.3 alpha, due to the build-in support for that NIC.
Just a notice for the "newbies" like myself 
:
Remember to update your Xen Orchestra from time to time. I can't really explain why, but I've not thought about that at all. So yesterday I updated from a march 2023 commit, to the most recent one. Not much was changed, but I guess some kind of incompatibilities could be expected, after more than one year without a single update of Xen Orchestra 
.
Great work.
Let's hope the team will migrate a similar implementation in near future
I'm trying to make a webhook which only fires, if my backup has been made properly (success, without errors). Is that possible?
backupNg.runJob does fire, but at all actions. Are there a better method hook I can use? I'm not been able to track a more suitable method, yet.
Have I missed a detail, or is that not possible right now?
The backup-reports allows me to device the runId, but I'd like to have a webhook even every-time things go as planned (as I've like to integrate the reporting into the service from healthchecks.io).
Another workaround would be to have the backup job fire a postpone script or similar, allowing me to customize it (if the proper amount of data was available), or have a postpone script for both success and failure for each job.
Healthcheck does support filtering of the payload received, but only for emails, though. And I'd like to get it working with webhooks, if possible.
@stormi I've hold back my fingers, and didn't press the "reboot button".
But, if I need to, will downgrading edk2 make anything break? I guess my pfSense instance will fail after a reboot (like described), so... Hopefully I don't need to reboot my host in the next weeks 
? Maybe it's a good idea to note, to not push a update like this, so close to Christmas.
Happy Christmas, and Merry New Year 
.
@stormi Thanks. I'll cross my fingers for a fix, at some time.
I also updated yesterday, on my ODROID H3+. Everything worked as expected.
I noticed that /etc/xensource/usb-policy.conf was send back to stock configuration, so I readded my modification to it. I'm not sure, if that's the expected behavior, after the host update + restart.
Thank you for the latest update .
@stormi Fair. Are there any public issue to follow? Maybe I didn't do my search that well? Thank you for the answer.
@stormi Thank you!
Are there any planned work related to hot backups of VM's, where a USB device are attached? It's currently not possible.
In the weekend I ended up moving a single container to a alpine image, so I could continue backing up my primary docker VM. But I was hoping to have rolling backup of the alpine VM, too
@mdavico Saly, I also get a VM_HAS_VUSBS(OpaqueRef:***/removed/**) error message in 8.3, if I have a ongoing passthrough.
I'm not sure if it's the same thing with backups. If it is, that's problematic. One of my instances needs the USB Passthrough, but I need the rolling backup.