@tjkreidl said in Issue with SR and coalesce: @nikade Am wondering still if one of the hosts isn't connected to that SR properly. Re-creating teh SR from scratch would do the trick, but a lot of work shuffling all the VMs to different SR storage. Might be worth it, of course, if it fixes the issue. Yeah maybe, but I think there would be some kind of indication in XO if the SR wasn't properly mounted on one of the hosts. Lets see what happends, its weird indeed that its not shown.

@Davidj-0 You can list VMs without a management agent with the following filter: power_state:running !managementAgentDetected?. XO does not support this for halted VMs but that could be added indeed.

Yes, a more up to date ISO will come at some point (likely for the LTS)

Question for @florent

Hm that's important feedback thanks. We need to check if we can reproduce in here Ping @stormi so we can assign someone to test that

Hi, If you have support, you should create a ticket asking for the feature if you need. We don't have much request for that, but if nobody ask, it will never happen by chance If you don't, you can still open an issue on our XCP-ng repo to ask for it, at least we'll have a trace of the request

@pctechsolution Hum, first time i see this issue. It's probably the same thing as the disk (the appliance don't know how to fetch CPU and Memory data). I don't have time the next few days to search the files, but i'll do that ASAP

@john.manning Happy to hear that. I guess it was my fault - I edited the naming of the snipped pseudo vars: OLDVBDUUID = xe vdi-param-get uuid=VDIUUID param-name=vbd-uuids VDIUSERDEVICE = xe vbd-param-get param-name=userdevice uuid=OLDVBDUUID maybe that way it's clearer for others that might find that helpful

@ph7 Thanks for the help...I think that gets me close. I will tinker with it some more. Thanks again for the answers.

@dinhngtu It's not the software, the problem is back again [image: 1741962581773-d0b27630-6669-4074-9b96-9d80b92fb1d4-image.png]

@olivierlambert I was looking for a way to mark this solved, can't find it. I haven't moved things, but after migrating my big lab to my mini-lab, I'm confident that the warm migration is the way to go. It was fast and seamless as long as you have the right network adapters set up. I had to fool with one of my networks to make a VM function, but that was certainly something I overlooked while setting up the mini-lab. A little testing before moving the VMs should make this go easily if using the old servers is the option for this project.

@ronan-a [...] 64 bytes from 172.27.18.161: icmp_seq=21668 ttl=64 time=0.805 ms 64 bytes from 172.27.18.161: icmp_seq=21669 ttl=64 time=0.737 ms 64 bytes from 172.27.18.161: icmp_seq=21670 ttl=64 time=0.750 ms 64 bytes from 172.27.18.161: icmp_seq=21671 ttl=64 time=0.780 ms 64 bytes from 172.27.18.161: icmp_seq=21672 ttl=64 time=0.774 ms 64 bytes from 172.27.18.161: icmp_seq=21673 ttl=64 time=0.737 ms 64 bytes from 172.27.18.161: icmp_seq=21674 ttl=64 time=0.773 ms 64 bytes from 172.27.18.161: icmp_seq=21675 ttl=64 time=0.835 ms 64 bytes from 172.27.18.161: icmp_seq=21676 ttl=64 time=0.755 ms 1004711/1004716 packets, 0% loss, min/avg/ewma/max = 0.712/1.033/0.775/195.781 ms I am attaching simple ping stats for last 11 days. I don't think we can blame the network

@cairoti, I think the VMs are restarted in their natural name order. I prefix mine with 00, 01, 10, 11, 20, 21, 22 etc., to control the start order.

@Denson Are all hosts properly time synchronized to NTP? Make sure they are all within reasonable limits of each other. Might be a network thing -- are all interfaces configured alike on all hosts? Can the hosts all ping each other?

kernel log and Xen log, check for anything around the time of the issue

@MAnon This is a valid point actually, and without additional work, you couldn't just restore to another hypervisor. However, check this blog post: https://xen-orchestra.com/blog/xen-orchestra-5-100/?utm_campaign=mail_5.100&utm_term=logo&ct=YTo1OntzOjY6InNvdXJjZSI7YToyOntpOjA7czo1OiJlbWFpbCI7aToxO2k6NjU7fXM6NToiZW1haWwiO2k6NjU7czo0OiJzdGF0IjtzOjIyOiI2NzIzODI1NDE4ZjVmMjE5NDI2OTYwIjtzOjQ6ImxlYWQiO3M6NToiODM5ODciO3M6NzoiY2hhbm5lbCI7YToxOntzOjU6ImVtYWlsIjtpOjY1O319 Veeam is likely going to properly support XCP-ng. And for what it's worth, you can use agent based Veeam backups in the VMs and that works fine.

@manilx It is not cheaper, but it draws about half the power when idle. When doing work the power still gets up there, they are 60-90 watt computers, which is still less than the 300 watt capable HP servers at full go. If you really stress your lab a lot, real servers are a win as they will draw less power for more performance, but if yours is like mine and it idles a lot, cutting the power is nice. I'm about 200 watts at idle with the above, and that's two labs worth. I was 400 with the single old lab system. Mounts are cheap book ends, drilled and screwed to that specific shelf, and drilled for short m4 thumbscrews to get into the VESA mount on the t740. If anyone reading this wants to duplicate, and they see HP T755 cheap enough, I recommend these because it has 6 cores / 12 threads over the t740 with 4 cores / 8 threads. Both are DDR4 sodimm and top out at 64GB. Both have a PCI 3.0 x8 (x16 slot) that takes half height cards. And if the BIOS is locked, you can write over them with a programmer and enter the data needed to function (see badcaps forum for my guide).

@irtaza9 You should be able to login with the default credentials after you restart the xo-server service with systemctl restart xo-server.service.