Are you trying to move them all at once?

@doogie06 Thank you too! I also have XO setup for self-signed TLS access. I knew about the xo-cli task deletion command, but always had to disable TLS in my /root/.config/xo-server/config.toml file and then restart xo-server.service to delete the orphaned tasks. The allowUnauthorized parameter was just what I needed. That's why this community is really wonderful. Thanks again.

disable \ enable works.

@Danp
Thanks for the feedback
So i understood correctly so wait and see

Regards

Because the current storage stack doesn't support live resize, which is obvious after your tests.

@Andrew awesome, thank you for your explanation. After reading a bit more about MTU (see this) I get it now. I looked up MTU in OPNsense for the VLAN interfaces and was surprised that it automatically uses 1496 MTU, which explains why it works and means I don't have to adjust my host's MTU settings, which I really didn't want to do.

Now, as far as I understand, keeping it this way could introduce some split packets and therefore potentially limiting throughput. To fix this, I would need to increase the MTU to 1504 or larger. However, after some more reading (thanks for the keyword "baby giants"), it seems that today, MTU is just a "guideline" for LAN. I will keep the host MTU at 1500 for now.

@jimmymiller you mean disk size is locked on? You can't change it.

I think only way it's try to automate VM creation with things like packer https://xcp-ng.org/blog/2024/02/22/using-packer-with-xcp-ng/

@Andrew thanks

@olivierlambert Sure!

By way of example, when a new XCP-ng host is setup, all interfaces are created with an MTU of 1500 (even 10G interfaces).

If I create a bond interface on top of two of the 10G interfaces, the default MTU is set to 1500.

If I then create a VLAN interface on top of the bond interface, and set the MTU to 9000, XO happily lets me do so, but jumbo packets over it don't work because the MTU on the underlying interfaces is still 1500 (e.g. ping -s 1700 via the new interface fails).

If I destroy and re-create the underlying interface (bond0) with an MTU of 9000, then re-create the VLAN interface on top with an MTU of 9000, then things work much better (ping -s 1700 via the new interface succeeds).

Does this help?

Thanks

It is test not prod.
Next week, I'll probably tear it down & re-install with 8.2

@Chr57 Good job, always nice to have everything sorted out before going live 🙂

Your issue was unrelated to tools but a Xen upgrade from 4.13 to 4.17 without rebooting it (ie the libs were on Xen 4.17 while the hypervisor still running in memory was 4.13). A reboot solved that.

No problem, and it's not your fault, it's far from being intuitive. It will be a lot easier in XO 6.

Also, enjoy discovering the cool little things hidden in this view 😉 (like trying XO in Chinese 😄 )

Yes, it should work if the migration doesn't fail 🙂 It's hard to know exactly why it failed in your case, but it's unrelated on being XO VM.

@john-c
Wow. What a "welcome" to a first post here. Thank you for all the information and you taking the time to write them. I'll write a better answer when I get a bit more time. Just wanted to say thank you. 🙂

the nfs share was having network connection difficulties, this was the cause. thanks for your suggestions.

I think this would be awesome, if it's not too much work, would love to see it.

that log appear again, without any actions from my side.

bab449b6-55cb-4e9f-b0af-ce8e9bb19d22-изображение.png

@CJ It may be easier to ensure reliability and prevent other possible issues from happening. I'm not an expert when it comes to the underlying code, but I would take an orphaned VDI over say some form of corruption or something like that.

I'm guessing a little if I'm being honest, but cancelling it mid transfer might break some things, could leave a partial VDI that is locked for example, etc...