@florent said: @jr-m4 you can export the heap memory of the nodeJS process by doing kill -SIGUSER2 <xoserverpid> onte that this will increase a lot the memory consumed by the xo process even when its done exporting the memory . This will help us know what xo is doing at the moment Do you have somewhere I can upload the heapsnapshot? (148MB) Ping @poddingue as well, for visibility

@poddingue Okay, we're back here. I was told I have a hung CIFS mount that no longer exists, so a host needs to reboot to clear it, and faulty XOSTOR resources. But I can't reboot the host until I can move VMs off. Is there any indication of how to repair the faulty XOSTOR resources so I can move the VMs and reboot the host? Thanks for taking a look.

Looking at Git, it doesn't seem like it, so I guess that answers my question.

@afk said: Hi everyone, Some of you may already be aware of this but I learned the news this morning. https://www.virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads/ Essentially, Broadcom has decided, without any announcement, to remove all download links (and even some documentation it seems) for VDDK. This impacts all migration tools that use the VDDK for copying data of VM disks. If you have any version of VDDK, please keep it somewhere safe and make backups. I only have a x86-64 linux release from september 2025 that I used for testing V2V. Obviously, I can't share any link here but the release has the following sha256 hash: 79d215198f1b8fd1d240a16b27ac2543c521ae2afdc1876444c2acf8945d74ca VMware-vix-disklib-9.0.0.0.24742305.x86_64.tar.gz Apparently, web archival links are also taken down. @olivierlambert With Broadcom removing public access to VDDK downloads, we now have users who either cannot obtain VDDK at all or whose existing VDDK installations (main + backup) have become corrupted. This creates a real need for a fully open‑source fallback path inside V2V, one that still meets the performance requirements normally associated with VDDK. The open‑source community has already demonstrated that VDDK‑level throughput is achievable without VMware’s proprietary stack. Several projects have shown that: • Parallel NBD can saturate modern storage bandwidth when implemented correctly • Highly multithreaded block pipelines can outperform single‑threaded VDDK transfers • A throwaway Linux Proxy Copy VM can act as an efficient intermediary, reading blocks via NBD and streaming them directly to the destination hypervisor. This approach avoids VDDK entirely, remains fully open source, and provides a reliable fallback for users who can no longer access VMware’s proprietary components. Given the direction Broadcom is taking, having this fallback inside V2V would significantly improve resilience for XCP‑ng users and ensure long‑term independence from VMware licensing changes. The Proxy Copy VM must be treated as an ephemeral orchestration component — automatically excluded from the migration set and destroyed once the transfer completes — ensuring it never interferes with HA, LB, or startup/shutdown sequencing. This architecture also gives Vates a clean, open‑source answer to Broadcom’s decision to pull public VDDK access — ensuring V2V remains fully functional even if VMware continues removing or restricting proprietary components.