@gduperrey I thought I had. I was replying to that thread and the forum software prompted me to click to reload. It continued to show the contents of the thread above as I clicked to post my reply, so if it opened a new thread, I count that as a bug in the forum, not user error

@Denson After enabling HA, the host has to be manually rebooted, which I think you're already aware of. OK, well, that leaves pretty much a network issue. Hmm. The statefile created OK on the shared SR within the pool? The "not found" error message doesn't give you much to go on, unfortunately.

@Andrew, @bvitnik and @DustinB In my tests, I did the following. I did this process twice and it worked. To simulate a hardware failure on the master node, I simply turned it off. If the master pool is down or unresponsive due to a hardware failure, follow these steps to restore operations: Use an SSH client to log in to a slave host in the pool. Run the following command on the slave host to promote it as the new pool master: xe pool-emergency-transition-to-master Confirm the change of the pool master and verify the hosts present in it: xe pool-list xe host-list Even if it is down, the old master node will appear in the listing. Remap the pool in XCP-ng or XO using the IP of the new master node. After resolving the hardware issues on the old master node, start it up. When it finishes booting, it will be recognized as a slave node. In testing, I did not need to run any other commands. However, if the node is not recognized, try typing on it after accessing it via SSH: xe pool-recover-slaves I didn't understand why it worked. It seemed like "magic"!

@bvitnik Thank you -- very useful information!

Confirmed, that works. Thanks!

@nim81 said in Support licensing structure update: but there's no way I can possibly justify the levels of increase being asked here. As Olivier has said, your comparing paying for XOA with no support, to XOA and XCP-ng supported in a package deal. I don't know that the Vates team has specifically cancelled the XOA only package, but that is a bit germane to the conversation. Just use XO from Source, or one of the scripts and move on with your day. If your business grows you can always sign up for support again.

got it @michael.manley . thanks . unchecked that , will monitor and let you know . thanks so much

A powershell SDK? Oh, you just made me a rather happy guy.

@ainsean I am using HPE SN1100Q 16Gb 2P FC HBA

@cds5296 Hi, could you list your hardware specs (server model, CPU model) and post a crashdump?

ok, so I was wrong, the vm boot ! But as you can see I now have a strange space collision, any idea ? [image: 1740412441805-7e80b573-1cc9-4430-b90c-de0b47806ec8-image.png] [image: 1740412567632-e3fb582e-3f25-46b8-a712-f388bab49a80-image.png] when I boot in recovery mode, I can get into linux, so I know it almost work.

@olivierlambert @payback007 @flakpyro I tested my Win11 23H2 setup (on XCP 8.3) and had the same type of problem. Everything was updated and working on 23H2 with XenTools 9.4. Then Windows update ran and downloaded 24H2 and just got stuck after a reboot (windows logo and spinning circle). Force reboot made Win11 revert, so that good. I un-installed the XenTools 9.4 (just from the control panel/uninstall) and then ran windows update again. This time it did update with a few automatic reboots. I then re-installed the XenTools 9.4 and everything is working on Win11 24H2 now. I guess there is some problem between XenTools 9.4 and 24H2 update, not a XCP problem. I did not test the ISO 24H2 update, just the automatic windows update.

@olivierlambert OK. I was guessing something like that. Many thanks for your answer. Best regards, BK

@dhiraj26683 Sorry for late reply, I'm interested if you solve this issue? I have similar issue on one node in cluster, the other working well. When memory issue happened last time I moved all VMs on 'healty' node and on problematic node I applied: # free && sync && echo 3 > /proc/sys/vm/drop_caches && free After few seconds I was prompted with login (all the time server was responsive so I think it is not restarted). I know that doesn't solve problem of not releasing cache, but I didn't have to restart server, at least - maybe So if you have something better, please let me know!

@Danp oh yes you are right . . . boot is 500GB and SR is 4TB, though I removed the hardware mirror and am just using the 2 4TB drives so I have a SR of close to 8TB. I think my problem has been that the hardware raid was not working well with XCP, and I also was trying to use some older samsung SSDs (also 500GB) both of which did fail a long test in the system diagnostics. So I have removed both of them from the machine and will see how things work now (after yet another reinstall because I was not having luck getting XCP to see the second 4TB HDD after removing the HW mirror).

@Danp how can u resolve from this?

Late to the game, but this might help someone... I don't recommend this in a production environment, but it would be fine for e.g. a home lab. I built qemu from source on another host (in my case, on a laptop running Ubuntu Mate): ./configure --static make ... and then sftp'd the generated qemu-img executable to the XCP-ng host (I didn't care about any other outputs from the build process, some of which failed anyway likely due to the ancient version of Ubuntu Mate running on my laptop). Building with --static avoided any issues with missing libraries on the XCP-ng host, at least for qemu-img.

Thank you for that @olivierlambert I've tried with the Dell R710 and R730, without any luck - I did a lot more extensive tests with the R710, which led to the frustration of not "trying as hard" with the R730, but perhaps there are some "tricks" that I missed? I tried to enable NV with modprobe and the like (I know that's vague, but its a LOT of nuance to describe for the "what and how"). Since the R710 is fairly ancient, I would typically assume its "less capable" than the R730 for NV with XCP-ng, but then sometimes I run into oddities where the R710 actually outperforms the R730 "without additional configuration" (such as with my other post/comment I'm actively exploring/troubleshooting - https://xcp-ng.org/forum/post/89035 ) - Then there is also the incredibly tedious and annoying mxGPU "slicing" features from the limited GPUs that feature was available for that the major of the internet has reported to NOT work for them in any modern Kernel of Linux, (though a few "edge cases" have been reported sucessfull). So, "maybe" older hardware has better / more mature drivers in some cases? That said, I've retired the R710, so the point is somewhat moot, anyway - but it serves as an interesting use case that I've learned a great deal from "conceptually". (TL;DR - its true what they say about "assuming" ) But, rather than start tinkering again and potentially create another 3+ day project, are there any specific "success stories" with the R730, specifically that you could recommend? or perhaps a specific model / CPU combination where NV has been reported by others as working with XCP-ng? Perhaps specific UEFI/BIOS settings or "kernel hacks" that "tend to have a higher reported success"?

It's very likely in Xen itself since a part of the power management is done there. Another topic to bring during the Xen Winter Meetup @TeddyAstie