@acebmxer Hello, thanks for sharing this here! 
Me and my team have been waiting for this release!
I signed up for the Veeam newsletter hoping I would get notified once Veeam 13.1 (an XCP-ng plugin) gets released but they seem to be a bit slow.
So I found out about this release due to your post.
Will start testing!
Hello,
the issue is back on my end.
Pool and metadata backup failed on all remotes due to "body timeout error".
Attached please find full backup log:
https://paste.vates.tech/?f781d8cb757e56b1#8MN4cyjHhkWKzhhvvggckf8mqjT9gxDY6t4vkSVQcWUY
I can confirm what @christopher-petzel said. Before commit 63f8d got pushed this issue did not occur.
I am currently running commit 1d82c (feat: release 6.6.2).
Best regards
Installed these patches on a pool of 4 hosts, can confirm everything looking good!
@rzr Thanks! How long does it take for these patches go be available?
[17:00 xcpng01 ~]# yum update
Geladene Plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
* xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
* xcp-ng-updates: mirrors.xcp-ng.org
No packages marked for update
//EDIT: Nevermind. After running yum clean metadata they are being picked up.
@Jonathon I think @mathieu-l asked it you rebooted after installing drbd 9.2.18 from test repository. Your message sounds like you rebooted after installing 9.2.16 but not after applying the 9.2.18 update from test repository.
@jonathon are you using your LINSTOR/DRBD stack in the form of licensed XOSTOR? Your issue looks a case for pro support. Did you consider opening a case with pro support?
@rzr Since the targeted test window is over by now, I wonder: what are your plans regarding this set of patches? Will it be released soon?
Hi,
AFAIK this is not possible. Live migration does only work within the same pool. So you can not live migrate VMs to another pool / host that is not part of the pool.
But we do that all the time? - i.e. Two non-pool hosts, live migrate between them (these happen to have the same CPU / family etc.)
Okay I assumed that you use shared storage.
From the XenServer 8.4 "Migrate VMs" docs:
"Storage can only be shared between hosts in the same pool. As a result, VMs can only be migrated to hosts in the same pool."
So for classic live migrations that do not transfer the virtual disk you have to be on the same pool.
What you are describing must be a storage live migration then (XenMotion). That should work across pools, yes. I stand corrected because I did not factor in this variant in my initial answer.
//EDIT: also there is no such thing as non-pool hosts. Even a single host setup has it's own pool.
Hi,
AFAIK this is not possible. Live migration does only work within the same pool. So you can not live migrate VMs to another pool / host that is not part of the pool.
Regarding mixing and matching different CPUs within the same pool: do note that you can not mix AMD/Intel together. Different CPU models of the same brand within a pool will work though. And it behaves just like you said: XCP-ng hosts will agree on the least common denominator regarding CPU features and use that across the pool in order to ensure that (live) migrations will work.
@ph7 As a suggestion: it would improve readibility if you paste your logs on Vates official pastebin tool: https://paste.vates.tech/ and share the links here instead of posting the logs in multiple messages.
Due to the fact that this is the second XO release in a row that broke backups I do wonder: are all backup job types being tested via automated unit tests? Are those tests being run multiple times in order to catch issues that do not occur during every single test run? There must be a reason for QA not catching these kind of issues…
Actually after latest XO update I also started to see "body timeout error". Interestingly on my metadata backup job.
@the_jest According to my own tests not rebooting after patching XCP-ng hosts can cause several issues. Thats why Xen Orchestra GUI notes to reboot after updating. Documentation has further explanation for this and explains whole update procedure.
Hello!
Just an idea but maybe the PCI link speed you are seeing is related to some sort of energy saving feature?
Background: I have a Nvidia GPU in my PC and when there is no load the PCIe speed is lowered from PCIe 4.0 to 1.1 due to energy saving feature.
So yeah, I think @teddyastie 's idea is a good approach here. Try how your setup behaves during a workload.
@marcoi I found out what to enter for "vendor" by running "dmidecode -s system-product-name" on one of my XCP-ng hosts:
[15:45 xcpng01 ~]# dmidecode -s system-product-name
Super Server
//EDIT: in your case it looks like you should enter "To Be Filled By O.E.M." for vendor. Not "To Be Filled By O.E.M. (To Be Filled By O.E.M.)"
For my fellow Supermicro enjoyers: I was able to get the plugin to show some information.
Even if there are some parts missing it is better than nothing in my opinion.
Go to settings --> plugins --> ipmi-sensors --> "+" --> Add --> Fill information and add the vendor string as well as the Sensor Reg Ex.
Hope this helps.
Best regards
@All-Ki Thanks for your work on that plugin!
This is the ipmitool sdr list output on one of my Supermicro based XCP-ng hosts, how can I derive the correct plugin settings (regex) from that?
[13:36 xcpng01 ~]# ipmitool sdr list
CPU Temp | 59 degrees C | ok
System Temp | 30 degrees C | ok
Peripheral Temp | 29 degrees C | ok
M2NVMeSSD Temp1 | no reading | ns
VRMCpu Temp | 31 degrees C | ok
VRMSoc Temp | 43 degrees C | ok
VRMABCD Temp | 34 degrees C | ok
VRMEFGH Temp | 36 degrees C | ok
DIMMA1 Temp | 36 degrees C | ok
DIMMB1 Temp | 35 degrees C | ok
DIMMC1 Temp | 34 degrees C | ok
DIMMD1 Temp | 33 degrees C | ok
DIMME1 Temp | 38 degrees C | ok
DIMMF1 Temp | 37 degrees C | ok
DIMMG1 Temp | 36 degrees C | ok
DIMMH1 Temp | 34 degrees C | ok
FAN1 | no reading | ns
FAN2 | 4200 RPM | ok
FAN3 | no reading | ns
FAN4 | no reading | ns
FAN5 | no reading | ns
FANA | 3600 RPM | ok
FANB | 3600 RPM | ok
12V | 12,05 Volts | ok
5VCC | 5,02 Volts | ok
3.3VCC | 3,33 Volts | ok
VBAT | 0x04 | ok
VDDCR | 1,11 Volts | ok
VMEMABCD | 1,23 Volts | ok
VMEMEFGH | 1,22 Volts | ok
VDD_5_DUAL | 5,16 Volts | ok
VDD_33_DUAL | 3,28 Volts | ok
SOCRUN | 0,87 Volts | ok
SOCDUAL | 0,89 Volts | ok
Chassis Intru | 0x00 | ok
PS1 Status | 0x01 | ok
PS2 Status | 0x01 | ok
Thanks and best regards
@rzr Installed those security update candidates in my XCP-ng test environment.
So far no issues whatsoever. Basic operations all work. VMs running etc.