What is the Windows version? Can you reproduce with a fresh install of the same OS?

Yes, there's no problem to have in total more vCPUs used than cores.

It's just that you can't have one VM using more vCPUs than cores on the machine. There's nothing to do, Xen handles this for you.

There's not enough memory for the ballooning driver to grow, and this cause a domain crash.

Going to the bottom of this is not simple I'm afraid.

@olivierlambert
i see.., i was seeing them as one install.
I have completed actions, thanks

I don't know how it behaves in this case. I think it might stay with the same feature as before removing the older hosts from the pool. You can check the CPU features before and after with:

xe pool-param-get uuid=<POOL UUID> param-name=cpu_info

Example output:

features_hvm_host: 1fcbfbff-f7ba2223-2d93fbff-00000403-00000001-00000281-00000000-00000000-00001000-9c000400-00000000-00000000-00000000-00000000-00000000; features_hvm: 1fcbfbff-f7ba2223-2d93fbff-00000403-00000001-00000281-00000000-00000000-00001000-9c000400-00000000-00000000-00000000-00000000-00000000; features_pv_host: 1fc9cbf5-f6b82203-2991cbf5-00000003-00000001-00000201-00000000-00000000-00001000-8c000400-00000000-00000000-00000000-00000000-00000000; features_pv: 1fc9cbf5-f6b82203-2991cbf5-00000003-00000001-00000201-00000000-00000000-00001000-8c000400-00000000-00000000-00000000-00000000-00000000; socket_count: 4; cpu_count: 80; vendor: GenuineIntel

Okay thanks for the feedback.

@pierre-briec I'm happy it's solved, and happy i was right 😉

In Xen Orchestra, you can change the priority in VM/advanced tab (hard drive vs DVD vs network boot)

Capture d’écran de 2021-11-21 00-01-43.png

Yes, very likely.

@indyj The problem appears to be in the 5.15 kernel as well but the workaround seems to fix the issue.

Hmm I have no idea but I think it might be because of more recent of Xen not supporting the OS itself 🤔

Could you set up netconsole with your guest. This is a kernel feature that allows you to send the console to a netcat/nc client over the network. You add the configuraton to the kernel command line.

https://www.kernel.org/doc/html/latest/networking/netconsole.html

@danp said in This server is a different version to the master:

5.601

You are rigth, the problem was there. I didn´t found any package related to the schema version, but are rigth, so I've look into this. Here a problem like mine, and the key to resolv it. As my host0 was not updated, it was working with schema version 5.601. just a xe-tools-restart was enough to update the schema version to 5.602 and now they match.

Thanks!

@olivierlambert Perfect, thanks again for your time!

@noship Hello. The secure boot feature is currently available as pre-release code. My personal experience is that it works well for my use case. Some others are reporting boot issues after installing the updates so it continues to evolve and is not yet released for production. Search the forum for UEFI and you will find the relevant threads for obtaining and installing secure boot support. Here's one: https://xcp-ng.org/docs/guides.html#guest-uefi-secure-boot

@alexanderk @olivierlambert Sorry to have not responded sooner to your question. It has been a very long, slow slog so far and I haven't been able to devote as much time as I'd like to working on this. Here's what I've done so far: Based on Andrew Cooper's recommendation, I installed a fully patched Windows Server 2008 R2 VM to Xen. (Hyper-V was initially released with Server 2008 so this is almost as far back as you can go.) Using the current unmodified Xen source code, the VM will permit Hyper-V to be enabled in the Windows Server 2008 R2 guest, but--as with newer versions of Windows--once you perform the finishing reboot, Hyper-V is not actually active. Adding the two recommended source-code patches, recompiling and performing the same test causes the VM to hang following the enablement of Hyper-V. I know that I need to set up a serial console for the VM in order to view any logging that might provide a clue as to what's failing during the boot, but I haven't worked that out just yet.

I've also spent some considerable time reading through the Xen Dev email posts on the history of the development of nested virtualization in Xen. One very significant learning from that reading is that nested virtualization on Xen was initially developed by an AMD developer. Development of the NV feature-set for Intel came later after the AMD-focused design die had been cast. As far as I can tell given that I'm running Server 2008 R2, this never worked on Intel. (Maybe it did on an older Intel processor, but I am currently working with SkyLake i7-6700s so have no way to test older hardware.) Unfortunately, I also don't have appropriate AMD hardware on which to perform the same test to see whether or not it might work on AMD.

On the Microsoft Hyper-V side, it seems as though the opposite evolution happened. Nested virtualization was developed on Intel first, then (very recently) AMD. This makes me suspect that it doesn't work on AMD either. In other words, I don't know that nested virtualization of Windows on Xen ever worked such that Hyper-V was actually active in the guest. I would be delighted to have somebody prove me wrong.

Hmm is it a big gap? I would have expect more 🤔

Anyway, @fohdeesha will give us some leads 🙂

Bad idea. Losing network temporarily doesn't mean your app crashed.

I think first you really need to think about what you need.