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

Will have to think more on this. We do have a a domian policy for Windows Updates, that mostly works; it never seems to work as intended. In any case, if a Citrix driver is updated, with the registry setting set, it will reboot x number of times? (3 is suggested I believe) Wish there was a bomb proof method. Just this morning I came to office to find half the building down, because MS decided to push a Citrix update last night, and the DHCP server was down, until I rebooted the VM from the console once more. ;(

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.