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

@dinhngtu Thank you so much. If you want me I'll be at the pub.

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

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

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

It's better to have it to get handy options like IP addresses displayed and so 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.

@psafont is it safe to remove it on production pool? whenever the SDN controller is turned on. so, i can do something on new host, before joining into pool to generate this cert?

@olivierlambert Hmm. It may just be easier to do a restore and export. I tried doing a file restore of / but I get a Cannot GET error when trying to download the tgz. I don't see anything in the UI to indicate what the problem is or if it actually created the tgz.

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

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.

@flakpyro i try to find a new version but site and search only found 3.3.0. When try to search again in a proxmon forum found the repo xD

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

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

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

@Razor_648 While I was writing my previous message, I have been reminded that there are also issues with LVHDoISCSI SR and CBT, you should disable CBT on your backup job and on all VDI on the SR. It might help with the issue.

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