Have you rebooted after installing the updates?

Hi @kagbasi-ngc, The "VM Lacks Feature" message typically means the VM is missing a functional agent required for migration, so it's likely not related to the load balancer. To keep things clear and easier to follow, I suggest opening a separate thread for unrelated issues. It helps us stay focused and makes it easier to assist everyone effectively. Regarding XO reconnecting: this behavior can occur if previous host connection details are still present in the configuration. Since Xen Orchestra doesn’t perform any kind of autodiscovery, this usually points to a misconfiguration—most often when multiple hosts from the same pool are added manually under Settings > Servers. Lastly, about the related topic you mentioned—yes, the certificate is likely the root cause of that particular issue.

any ideas?

Hi, In that case, it's better to use mirror backup, with a different schedule

I probably would have just bought a cheap mini PC and used Virtual Box for this, which is something I did do in the past for an old XP machine when the hardware started to fail. Grabbed a disk to vhd of it before the final failure and loaded it into Vbox. Might be able to do this in nested virtualization in XCP-ng.

@olivierlambert Thank you Olivier

No, it's fine, as long the issue contains all the relevant details it's fine

Hello @ronan-a Just to be sure, you want logs of the node which want to join or the master ? Bonne journée

It's better to have it to get handy options like IP addresses displayed and so on.

Hello @ronan-a I will reproduce the case, i will re-destroy one hypervisor and retrigger the case. Thank you @ronan-a et @olivierlambert If you need me to tests some special case don't hesit, we have a pool dedicated for this

Thank you so much for that hint. Yes, after restarting some xoa service this now works. So cool. You are great. Thank you.

The initial reason we've chosen to create an "all-in-one" ISO image was to simplify further configuration of an automated installation with PXE / Answerfile. We tried driver disks before, though in our special case of mellanox-mlnxen-alt and hardware without any other NICs, I believe it always ends up requiring manual intervention. I haven't found a way to load the driver disk in the installer that is not connected to the network. I think, even though my approach requires a bit more effort, it can still prove useful in some cases.

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

@dnikola The AQC113 10G card (from your vendor) also support 2.5G with the driver loaded.

@bogikornel As discussed in the thread, pygrub doesn't work. (It might be fixable, because copying kernel and initrd to dom-0 and directly setting PV-kernel, PV-ramdisk and PV-args works, which is basically what pygrub is supposed to do. But I stopped investigating as pvhgrub is a much better option which acually works.) You have 3 options copy kernel and initrd do dom-0 and configure xe vm-param-set uuid=... domain-type=pvh xe vm-param-set uuid=... PV-kernel=/dom-0/path/to/kernel xe vm-param-set uuid=... PV-ramdisk=/dom-0/path/to/initrd xe vm-param-set uuid=... PV-args="root=... ro console=hvc0 ..." xe vm-param-clear uuid=... param-name=PV-bootloader Not a very practical option, just PoC. use pvh-ovmf, but this requires UEFI-enabled VM (ie. GPT disk layout with EFI partition and some EFI bootloader or kernel directly in EFI with proper config (or as UKI) use pvhgrub. You need a recent grub2 to build the image for i386-xen_pvh target. Or just get the blob - this one is from Alpine package curl https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/grub-xenhost-2.12-r8.apk | tar -xzf - --strip-components=3 usr/lib/grub-xen/grub-i386-xen_pvh.bin Save it to dom-0 (e.g. to /var/lib/xcp/guest/grub-i386-xen_pvh.bin) and configure the VM xe vm-param-set uuid=... domain-type=pvh xe vm-param-set uuid=... PV-kernel=/var/lib/xcp/guest/grub-i386-xen_pvh.bin xe vm-param-clear uuid=... param-name=PV-ramdisk xe vm-param-clear uuid=... param-name=PV-args xe vm-param-clear uuid=... param-name=PV-bootloader If the VM has valid grub2 config, it should work. Of course, you need a linux kernel with CONFIG_XEN_PVH enabled.

So you have to dig in the SMlog to check what's going on

@stormi Thanks! @olivierlambert @TeddyAstie I am unable to test further since I don't have a 'passable'/'assignable usb controller which can be passed through. Have ordered one and would keep you guys posted once I get it and test it. Though I can confirm that the bug (dunno if it is the driver / xcp-ng) persists.

I did it that way so as to get the old Citrix driver first, and then let it update and watch it reboot. That was my logic anyway. @dinhngtu said in Migrating from XCP-ng Windows guest tools to Citrix: @bberndt Okay, I managed to reproduce your situation. I think it's because the "driver via Windows Update" option was enabled after installing the XS drivers, which caused the drivers to lock onto the non-C000 device and prevent updates from coming in. Normally, XenClean should be able to fix the situation. But if you want to fix things manually, or if things still don't work (C000 is still not active), here's a procedure that should fix the problem: Take a snapshot/backup/etc. Keep a note of static IP addresses (if you have any; there's a chance those will be lost). You can also use our script here: https://github.com/xcp-ng/win-pv-drivers/blob/xcp-ng-9.1/XenDriverUtils/Copy-XenVifSettings.ps1 Reboot in safe mode and disable the non-C000 device. Reboot back to normal mode; it'll ask you to reboot a few more times. The C000 device should now be active and you should be able to get driver updates again. (Optional) You can now enable and manually update the non-C000 device (Browse my computer - Let me pick).