@stormi Thanks, looking forward.

@olivierlambert There you go hehe

@bloodyskullz If you still see the old ISO SR, the easiest way to migrate is simply by creating a new one and migrate the ISOs through XO to the new one. In regards to deletion of the old SR you need to check if it really is mapped to another drive or if the mapping was not working and it filled / if so, you might not be able to delete it

@bleader said in update via yum or via xoa?: yes you're basically doing an RPU manually. But it is indeed odd that the process is stuck at 0%, it should be fairly fast to do the install patches, no errors in the logs? i've another install all patches and install all. Now i'll use rpm update and see if speed is the same or not

@Danp Yes to both. I've probably restarted the toolstack at least a dozen times, mostly to clear hung tasks. I did notice some weird issues with a secondary SR being disconnected on xcp02, (one of 10 hosts, 9 after I ejected and forgot xcp01), but there's no disks on it. It wasn't being used for anything at all (yet), and it's fine on all the rest. That does lead me to think maybe it was a power bump that rebooted a switch or something though. Maybe it caused some kind of hangup with xcp01 and xcp02, and since xcp01 was the pool master, it cascaded to the other issues I've seen? Could that cause the VM's that were originally running on xcp02 to die and not be able to be recovered easily?

I just tried to install Ubuntu 24.04 to test it out, and I experienced the same problem with it not recognizing the IP address. I was first using the Ubuntu-provided package (xe-guest-utilities=7.20.2-0ubuntu1), which was failing. I then tried the package I had been using with my Ubuntu 22.04 servers that used to be part of the XCP-ng guest-tools.iso (xe-guest-utilities_7.20.0-9_amd64.deb) and had the same results. I mounted my current guest-tools.iso, which now has xe-guest-utilities_7.30.0-11_amd64.deb, and installed it. Now it was retrieving the IP address correctly. I'm not sure why the OP was still having trouble with that version (I'm using UEFI instead of BIOS, but I wouldn't think that would matter). I went ahead and tried out the Rust-based tools mentioned (xen-guest-agent_0.4.0_amd64.deb), and it was properly getting the IP address as well. I'm guessing there's some incompatibility (probably with the 6.x kernel) that was fixed between 7.20 and 7.30 (intentionally or accidentally). Given how much the Linux tools have changed over the years and the fact that they're not used for PV drivers anymore, is there a particular reason to use one over the other (legacy vs Rust)? What features do they really provide now? Is it just CPU/memory/disk/network status?

@ha_tu_su Here are the details, albeit little late than what I had promised. Mondays are...not that great. Below commands were executed on all 3 hosts after installation of xcp-ng. yum update wget https://gist.githubusercontent.com/Wescoeur/7bb568c0e09e796710b0ea966882fcac/raw/052b3dfff9c06b1765e51d8de72c90f2f90f475b/gistfile1.txt -O install && chmod +x install ./install --disks /dev/sdd --thin --force Then XO was installed on one of the hosts and a pool was created which consisted of 3 hosts. Before that NIC renumbering was done on VW1 was changed to match the NIC numbers for other 2 hosts. Then XOSTOR SR was created by executing follwoing on master host: xe sr-create type=linstor name-label=XOSTOR host-uuid=<MASTER_UUID> device-config:group-name=linstor_group/thin_device device-config:redundancy=2 shared=true device-config:provisioning=thin Then on host which is linstor controller below commands were executed. Each of the network has a /30 subnet. linstor node interface create xcp-ng-vh1 strg1 192.168.255.1 linstor node interface create xcp-ng-vh1 strg2 192.168.255.10 linstor node interface create xcp-ng-vh2 strg1 192.168.255.5 linstor node interface create xcp-ng-vh2 strg2 192.168.255.2 linstor node interface create xcp-ng-vw1 strg1 192.168.255.9 linstor node interface create xcp-ng-vw1 strg2 192.168.255.6 linstor node-connection path create xcp-ng-vh1 xcp-ng-vh2 strg_path strg1 strg2 linstor node-connection path create xcp-ng-vh2 xcp-ng-vw1 strg_path strg1 strg2 linstor node-connection path create xcp-ng-vw1 xcp-ng-vh1 strg_path strg1 strg2 After this HA was enabled on the pool by executing below commands on master host: xe pool-ha-enable heartbeat-sr-uuids=<XOSTOR_SR_UUID> xe pool-param-set ha-host-failures-to-tolerate=2 uuid=<POOL_UUID> After this some test VMs were created as mentioned in Original Post. Host failure case works as expected for VH1 and VH2 host. For VW1 when it is switched off, VH1 and VH2 also reboot. Let me know if any other information is required. Thanks.

In any case, you can ignore it.

@Danp Okay, you're a genius, I upgrade this morning after my backup. So that could explain my issue. the mentioned thread is exactly my issue, but I didn't find it when I was searching about my issue. Thanks for all !

No, from the XCP-ng point of view, the VM is still running without any interruption.

@olivierlambert @Marc-pezin Thank you very much for sorting this out!

@nick-lloyd I like your interpretation.

@aghering You could try compiling it yourself on 8.1... I don't have an 8.1 test/build system.

@NerdsOrder66 Ah, good question... My most recent environment included a Windows Server with 100+ RDP users. There wasn't anything special for optimization there aside from giving it a bunch of RAM/CPU resources, but YMMV.

@olivierlambert No, the only thing I get with xl dmesg on the host, for some time back, are random brief reports of individual CPUs running above temperature threshold and then being clocked down, and then resolving. Nothing else.

I suppose you mean OVA, right? Anyway, good news

@olivierlambert said in Very scary host reboot issue: I am very very busy so I don't have time to make a search by myself but maybe someone else around with few minutes could point you to the blog post talking about this edit: found it in few sec luckily: https://xcp-ng.org/blog/2024/01/26/january-2024-security-update/ Thanks. I'll check this out.