removed the failed server connection. Restarted xo-server service. Added new host again. Seems fine now. In hind sight, I could have very well recycled a DHCP ip here as well, if that is a known issue...

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

I thought I did that. Oh I see whats happening. My cold moves are freaking out. The first time, I restarted the toolstack for the server I was working on the # of tasks dropped by 50% or so. as soon as I tried my cold move of a VM again, im up to 50-60 tasks again. Going from Xen 7.1 to XCP 7.6. and a Xeon 2630 V3 to a 2620 V0. Which I know is a bad idea, hence the cold move.

Same message than the other thread: https://xen-orchestra.com/docs/community.html Read this carefully.

Updated to Master build, a66ae, xo-server 5.92.0, xo-web 5.96.0. Consoles seem to work fine again. thanks all!

That's correct

@bberndt the sdn controller communicate with the hosts on port 6640, opening it on the host should be enough. I don't know what's happening. !this TLS error should have been solved by the override-certs option set to on.

As you can see, the first alpha was not released in September Another XCP-ng pre-release will be done with vTPM, since there's more progress on upstream side (Citrix). When is hard to tell since it's not our call for this component

@deoccultist Sadly, none of this seemed to make any difference.

@olivierlambert We are using rrd2csv to get host cpu stats into SQL to provide nice Grafana page sorted by pool. It would be nice to dial even further down to the vm's that are running high cpu or have memory burden.

I concentrated here, after upgrading my second server: Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /root/xen-orchestra/node_modules/argon2/lib/binding/napi-v3/argon2.node) I've found circumstantial evidence that this depends on libraries found in newer gcc than is in the Cent OS 7 repo at this time. strings /usr/lib64/libstdc++.so.6 | grep CXXABI CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 CXXABI_TM_1 so argon2.node requires something newer than centos7 can provide?! and upgrading gcc does the trick? I may have to try when I have more time. https://stackoverflow.com/questions/63374392/node-module-argon2-usr-lib-x86-64-linux-gnu-libstdc-so-6-version-cxxabi-1 Indeed here is Centos 8. $ strings /usr/lib64/libstdc++.so.6 | grep CXXABI CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 CXXABI_1.3.8 CXXABI_1.3.9 CXXABI_1.3.10 CXXABI_1.3.11 CXXABI_TM_1 CXXABI_FLOAT128 and yes, I understand that XO doesn't target CentOS, but its our 'standard' right now.

https://xen-orchestra.com/docs/community.html Always pull the latest commit and rebuild before opening a thread

Right now there's no way to know what's happening inside a VM disk. So we can't know when a VM disk is full or not.

@bberndt said in Create job to migrate several VMs: Tring to create a job, to schedule the migration of several VMs to another host. At the bottom, there are a couple things I don't know. There are two check boxes here for each of these: mapVdisSrs mapVifsNetworks They don't seem to do anything. What are these? Also, what goes in the box Migration Network. The name storage1, or network1 don't work. thanks. Ah! the UUID of the storage Migration network on the destination is what I need, apparently.