@olivierlambert nice ! a new discover... no way to manage by UI in xo5/xo6 AFAIK ?

I am very concerned that the pfSense VM went offline yesterday when the pool master was shutdown even through the pfSense VM was running on the slave. If I can get an understanding of how this happened I can better mitigate it from happening again. I have just reread this to ensure I understand the master/slave relationship: https://xcp-ng.org/forum/topic/6986/pool-master-down-restart-makes-the-whole-pool-invisible-to-xo-till-master-is-online-again/9?_=1764739019505 Can anyone suggest a reason as to why the pfsense VM went offline when the master was down? As the router role is crucial and there are a number of moving parts to ensure it works as a VM I am seriously considering running it as a standalone server.

I hope someone will reply to my post here about how to check status on this but I believe I've resolved the main issue: I disabled and re-enabled the whole task itself yesterday and it ran this morning as scheduled.

@Bastien-Nollet The delta backup job saves to srv04-incremental and srv12-incremental. The incremental mirror job has srv04-incremental as source and srv12-incremental as destination. The VM that showed no data to copy message was a the "Incremental backup every 4 hours - 8 days retention" backup job. Originally I only had one remote, srv04. I created srv04-incremental and renamed srv04 to srv04-full and used the mirror backup feature to copy all delta backups to srv04-incremental (as I did not want to attempt to move the data on the NFS backend side). Then, I set up srv12-incremental and srv12-full and created mirror jobs to copy from srv04-full and srv04-incremental. Once the mirror backups were completed I switched the normal backup jobs to store backups on both backup servers. I can set up a support connection if you want to remotely check this.

@bvitnik Thanks for your reply! Yes, all of the XCP-ng hosts have been restarted since I started monitoring the /var/log directory due to package upgrades. I also restarted the toolstack 2 or 3 times in the time frame so I think the issue was not caused by some sort of stuck process or similar. I did some research in this regard and also noticed that most people that have an environment of my scale do not encounter this issue (I currently have 105 VMs running). So I also suspect that there is something unusual happening in my pool. I thought about circumventing this issue by implementing a remote syslog server (like graylog) that has enough storage and letting all my XCP-ng hosts write to it. I would really prefer to fix the underlying issue though. Does anybody possibly know some common things that could cause this that I could check? That would be really awesome. Thanks and best regards

@henri9813 yes thank you for correcting my message

@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.

@dinhngtu said in XCP-ng Windows PV tools announcements: @probain The canonical way is to check the product_id instead https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-product_id The ProductCode changes every time a new version of XCP-ng Windows PV tools is released, and you can get it from each release's MSI: No problem... If you ever decide to have the .exe-file as a separate item. Not bundled within the zip-file. Then I would be even happier. But until then, thanks for everything!

@fred974 It used to be (and probably still is) that You have to be reasonably near correct time for NTP to accept any changes.

I confirm that this is the current behaviour, as @pilow reported here https://xcp-ng.org/forum/post/99446 We might change it in the future to make it better, but it won't be trivial to change.

@gduperrey said in How to Install XCP-ng Guest Tools on Rocky Linux 10?: but I don't have a release date yet, even for testing Actually it's already available as xcp-ng-pv-tools in the xcp-ng-incoming repository. What Gaël means is that we haven't run CI on it yet, so we haven't moved the package to the testing repository yet, which is when we usually invite users to test. However here I'm able to say that there's no risk in installing it now for testing, with: yum update xcp-ng-pv-tools --enablerepo=xcp-ng-incoming,xcp-ng-ci,xcp-ng-testing,xcp-ng-candidates (the testing repos will only be enabled for the time of the command, not permanently)

Yes, account aren't related

Thanks a lot for this In few months ago I have found your topic to try wazuh, and it is working good. After some error on my home lab, I need to install all again and remember your topic. On my installation, I just need to set /dev/xvda1 (if I just put /dev/xvda, VM not start). My home lab is on ProLiant DL360 Gen9.

October release fixed it

@olivierlambert Just to add another weird case of this situation I tell you my SAML-auth-adventures. I have just migrated a week ago from XOCE to XOA paid support this week and all the process was fine except the auth with the saml plugin. The commit I had in XOCE was [XO 5d92f - Master 3f604]. I compiled it the first week of this november so it wasn't very outdated. We use the MSEntraID SAML authentication and it was working fine in XOCE since at least one year ago. Mi process was like this: First, I installed XOA and imported the configuration from my old XOCE. Everything was fine and all was imported succesfully (backups, users, acls, etc.), including my plugin configurations. Note that I reused the https server certificate/private key and used the same IP and the same DNS (beacuse I turned off my XOCE before starting XOA). Everything was working fine except the saml auth plugin. I had the same "Internal server error" problem. I looked at the xo-server logs and the error was "invalid document signature" so, as Olivier said, we changed the configuration in MSEntraID to set the "Sign SAML response and assertion" on. Once we changed the configuration I thought the plugin would work again, but surprisingly not. If I try again SAML validation i still got the "Internal server error". When i checked again the xo-server logs I saw ahother exception, this time with the error "SAML assertion audience mismatch" and a reference to the issuer configuration of the plugin. The exact error I got from xo-server logs using "journalctl -u xo-server -f -n 50" was: "xoa xo-server[2370]: Error: SAML assertion audience mismatch. Expected: <id-of-MSEntraID-xo-validation> Received: spn:<id-of-MSEntraID-xo-validation>"I didn't understand this, because the configuration was exactly the same as I had in XOCE. In fact, I turned off XOA and turned on again XOCE just to test the plugin. The result was that in XOCE the plugin worked well. After many tries and some time of impostor syndrome we found the solution: I don't know why, but in XOCE compiled at the beginning of november you have to configure the issuer field of the plugin with the <id-of-MSEntraID-xo-validation> (8digit-4digit-4digit-4digit-12digit). Instead, in XOA deployed also this november, you have to set the issuer field to you XOA URL: https://<xo.company.net>/ I hope this will help, because it was a pain in the neck for us this week. BTW: @olivierlambert this "Internal server error" coming from an uncatched exception in the plugin was not very descriptive. Even a generic try-catch block just to show in the web interface the error would help... P.D.: I'm from Spain, so I do my best with my english P.D. 2: Great job with all the Vates virtualization stack! You are the best! Dani

Hi @k11maris, I think the situation you showed in your screenshot where both options are selected but are both greyed out should not happen. We will try to reproduce it on our side and fix it.

Hi! I'm not sure who to ping exactly for this question @pdonias or @Bastien-Nollet maybe?