@Kptainflintt said in Cloning Windows 11 with vTPM: No reply to this topic but just seen same thing. And same "workaround" : disabling vTPM at VM creation from template to avoid crashing. I can confirm that XOA want to add a second vTPM, any fix ? Sharing for temporal context: This appears to still be be happening when creating a VM using my custom Windows 11 template (didn't do any cloudbase stuff, just some really basic stuff like updates, then sysprep). Once I click "Open advanced settings" then toggle "Enable vTPM" into the disabled state, my attempt to create the VM succeeds, and the newly cloned VM has a vTPM with a different UUID. This is literally my first attempt at creating and then cloning a windows 11 template, but it seems to be working.

This look great! Something I was missing. But unfortunately I get an authentication error as well. I do not get it running. I am using PowerShell 7.5 and I am using a cert that is singed by my own CA. This CA is included in the Windows cert store for trusted root certificates. With all browser this works fine. Hopefully someone has an idea?

Hi, I don't know if my question can be part of this thread. I apologize in advance... I bought a new system based on "AMD Ryzen 9 9950X" installed on "ASUS PRIME B850-PLUS-CSM". My target is to install two VM: linux based Ubuntu; Windows 11 In a possible future, I would like to install a graphic card for windows 11 CAD applications... I would like to ask if xcp-ng can run this environment... Thank you Claudio

I often wondered what's the general purpose of that option. As I only have 1 - 2 socket servers, I always choose 1 socket with x cores (mostly 2 - 8, not exeeding 1 real CPU). Also for historic reasons: Sockets have been limited, but not cores. Does it generally make any difference on Xen side/backend? VM OS might handle it different due to NUMA optimizations.

@bleader Hi, After a restart of the entire host, port 6640 is now listed when I trigger ss. But, unfortunatly, tunnels are not working, every VM on this host loose connection to other in the same sdn network. Exemple with an ping between two hosts : 2025-10-09T12:22:54.781Z|00026|tunnel(handler1)|WARN|receive tunnel port not found (arp,tun_id=0x1f1,tun_src=192.0.0.1,tun_dst=192.0.0.3,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_erspan_ver=0,gtpu_flags=0,gtpu_msgtype=0,tun_flags=key,in_port=33,vlan_tci=0x0000,dl_src=56:30:10:5c:4d:ad,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.10.10,arp_tpa=192.168.10.20,arp_op=1,arp_sha=56:30:10:5c:4d:ad,arp_tha=00:00:00:00:00:00) 2025-10-09T12:22:54.781Z|00027|ofproto_dpif_upcall(handler1)|INFO|Dropped 61 log messages in last 59 seconds (most recently, 1 seconds ago) due to excessive rate 2025-10-09T12:22:54.781Z|00028|ofproto_dpif_upcall(handler1)|INFO|received packet on unassociated datapath port 33 If I migrate the VM on the third host to another, network came back. This is very strange, because the network I've choose to test it is one of firt of all created, not last one, so it have worked before, and not now. I don't understand why and what to do...

@psafont Sounds good on point #1. On point #2 I agree LLA shouldn't be the primary management IPv6 address on the interface, but you could run into trouble by not having a LLA address assigned at all. All of the IPv6 standards assume a LLA is assigned to an interface running IPv6 for things like NDP or RA to work ergo mysterious things could break as a result of an LLA address not being assigned. Just spitballing here, but if you're concerned that only an LLA would be assigned to an interface then perhaps there could be logic to disable IPv6 for said management interface if no non-LLA address is assigned, or IPv4 could be preferred if only LLA addresses as assigned?

@olivierlambert Here's the new model. We've tried a few combinations and I think with TrueNAS shared storage this will now work well. [image: 1759787234216-f78178c0-3330-4233-8f9b-debc3c61a3e9-image.png]

@lsouai-vates