@JorisK said: fix/update-transfer-size-calculation I can confirm that XO6 now shows the same transfer sizes as XO5. Lovely

Created issue on their github, cause the wording makes it seem like only latest is supported now, which was not mentioned in their release notes https://github.com/piraeusdatastore/piraeus-operator/issues/1066

I did some further investigation and I think there is something wrong with the ip-settings of the management interface. At the xsconsole I see the following: Management Network Parameters Device bond0 address 172.28.4.11 Netmask 255.255.252.0 Gateway 172.28.4.1 So it's using the bond0 interface. # xe pif-list host-uuid=41a2a448-a5dc-44c6-be44-c07540d75c60 uuid ( RO) : 0761d887-268e-5cf0-401b-a08ad7c419aa device ( RO): bond0 MAC ( RO): 30:3e:a7:1d:b0:90 currently-attached ( RO): true VLAN ( RO): -1 network-uuid ( RO): 28d51793-0226-cf3f-75d3-ed7c5a9d8b33 host-uuid ( RO): 41a2a448-a5dc-44c6-be44-c07540d75c60 This is part of the output of xe bond-list # xe bond-list uuid ( RO) : 79c525c3-22f9-04ce-4a80-21d18ef65ebc master ( RO): 0761d887-268e-5cf0-401b-a08ad7c419aa slaves ( RO): 7ac18886-e0a5-057b-bac0-36b909588dba ; 2f18fc9a-8c1c-dfce-9416-fa8c657c5f63 I already checked that: 7ac18886-e0a5-057b-bac0-36b909588dba --> eth3 2f18fc9a-8c1c-dfce-9416-fa8c657c5f63 --> eth2 And now the confusing part. This is part of the output of the ip a command: 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 30:3e:a7:1d:b0:90 brd ff:ff:ff:ff:ff:ff 3: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 30:3e:a7:1d:b0:91 brd ff:ff:ff:ff:ff:ff 4: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 30:3e:a7:1d:b0:92 brd ff:ff:ff:ff:ff:ff 13: xenbr4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 30:3e:a7:1d:b0:92 brd ff:ff:ff:ff:ff:ff inet 172.28.4.11/22 brd 172.28.7.255 scope global xenbr4 valid_lft forever preferred_lft forever As you can see the xenbr4 has also the management ip-address and has the same mac-address as the eth4 interface. OK check the following commands: [17:21 dacshyp002 ~]# ip addr show xapi1 15: xapi1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 30:3e:a7:1d:b0:90 brd ff:ff:ff:ff:ff:ff inet 172.28.4.11/22 brd 172.28.7.255 scope global xapi1 valid_lft forever preferred_lft forever [17:21 dacshyp002 ~]# ip addr show xenbr4 13: xenbr4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 30:3e:a7:1d:b0:92 brd ff:ff:ff:ff:ff:ff inet 172.28.4.11/22 brd 172.28.7.255 scope global xenbr4 valid_lft forever preferred_lft forever And If I look at the routing table: # ip route default via 172.28.4.1 dev xapi1 172.18.8.0/23 dev xenbr0 proto kernel scope link src 172.18.8.11 172.18.10.0/23 dev xenbr7 proto kernel scope link src 172.18.10.11 172.28.4.0/22 dev xenbr4 proto kernel scope link src 172.28.4.11 172.28.4.0/22 dev xapi1 proto kernel scope link src 172.28.4.11 According to me the node has 2 interfaces xenbr4 / xapi1 with the same ip-address and also 2 different routes for the same ip-range 172.28.4.0/22. And that's why the heartbeat has some issues. Can someone confirm this ? By the way I really don't know how this happened.

@jerry1333 @poddingue First of all, XO and XCP-ng are running very well on all hosts and VMs, and I am using XO-5 without any issues. I have been noticing the same exact issue jerry1333 had, or may still have, with an annoying message that appears just after 30 seconds of connecting to the Xen Orchestra version 6 initial home screen with a Chrome browser (version 153) on my Windows 11 PC. In the past, the error message at the top of the window used to cycle on and off, over and over every 30 seconds. Now, if I don't click on "Retry", the "Unable to connect" message remains indefinitely. Xen Orchestra is up to date: Master, commit fc571 [image: image.jpeg] I consider this to be a mere annoyance, but if I am the only one experiencing this, perhaps someone can give me a suggestion on where to look for a solution. Thank you.

hmm primary, xen02 [13:30 ovbh-pprod-xen02 ~]# drbdsetup status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 node-id:1 role:Primary suspended:no force-io-failures:no write-ordering:flush volume:0 minor:1013 disk:UpToDate backing_dev:/dev/linstor_group/xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1_00000 quorum:yes open:yes size:315195168 read:233813750 written:1173974506 al-writes:758189 bm-writes:361 upper-pending:0 lower-pending:0 al-suspended:no blocked:no ovbh-pprod-xen01 node-id:0 connection:Connected role:Secondary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:1173974894 out-of-sync:0 pending:1 unacked:0 ovbh-pprod-xen05 node-id:2 connection:Connected role:Secondary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:1146927724 out-of-sync:0 pending:1 unacked:0 xen01 [13:31 ovbh-pprod-xen01 ~]# drbdsetup status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 node-id:0 role:Secondary suspended:no force-io-failures:no write-ordering:flush volume:0 minor:1013 disk:UpToDate backing_dev:/dev/linstor_group/xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1_00000 quorum:yes open:no size:315195168 read:1242 written:1181073258 al-writes:819172 bm-writes:349703 upper-pending:0 lower-pending:0 al-suspended:no blocked:no ovbh-pprod-xen02 node-id:1 connection:Connected role:Primary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:1174048714 sent:0 out-of-sync:0 pending:0 unacked:0 ovbh-pprod-xen05 node-id:2 connection:Connected role:Secondary tls:no congested:no ap-in-flight:0 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:0 out-of-sync:111291800 pending:0 unacked:0

I ran into the same problem with DR replicas. Ignoring VMs by tag would solve the problem, but so would excluding the ip address information.