@olivierlambert You got it, I'll do that. Thank you.

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

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

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

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

That's the reason, then. The update will update files on the disk, not on what's running in memory, so after updates you must reboot to actually use those updates

Hmm I'm not sure it's even possible due to the nature of isolation provided by Xen Let me ask @Team-Hypervisor-Kernel

See that as a positive experience: you have learned many things

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.

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!

Hello. @JamfoFL said in Xen Orchestra from Sources unreachable after applying XCPng Patch updates: This is very odd. When I check to see if the Orchestra status is running, everything looks OK: [image: 1752072112055-5c529c8c-8f2b-4c79-806c-daa2b8398847-image.png] This doesn't look ok. The process behind this service has actually exited. Suggest you start/restart this service and check if XO is reachable. If it's not, dive into the logs and look for clues why the process is exiting. You may want to also try manually running /etc/init.d/orchestra and see if that produces any helpful output. But when I try to run the command you sent over, I get an error message stating "Unit xo-server.service" could not be found". However, when I check in the very same folder from which I am running the command, I can see xo-server.service right there. Not taking away from the points others have made about .service files needing to be in the correct location, but in your case, worrying about the xo-server.service file is probably a dead end. It appears whoever installed XO created the systemd service as orchestra. You needn't try and "fix" the fact you don't have an xo-server.service. .joel

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

any ideas?