Resolved. Patched the rest of the hosts. Restarted all the toolstacks for good measure. I can move the master role now, and deploy new VMs.

@cbaguzman for information, I made some changes on vhd-cli so in the future we'll get a more explanatory error message when a command failed because we passed an incorrect argument: https://github.com/vatesfr/xen-orchestra/pull/9386 b-Nollet opened this pull request in vatesfr/xen-orchestra closed feat(vhd-cli): prevent using invalid options #9386

@dinhngtu That's great, thank you. I think I'll wait a bit before switching tools. Everything's working perfectly at the moment. If you need me to test anything, just let me know. I'd be happy to test it when I have time.

@dinhngtu I think it just have been a bad migration or the Win 11 Template did other things to the windows 10 os. Since new test vm did not show the time issues, and a fresh migration of the vim with correct template selected did not have the issues either. I dont know but maybe there is a way to put detect the correct VM template or make note. I didnt think using the win 11 template would have caused issues since using the "wrong" template on vm creation does not have the same effect.

@florent Yes.

@drwhite85 I suggest watching some youtube videos about xcp-ng. I guest Lawrence Systems - https://www.youtube.com/watch?v=2wMmSm_ZeZ4 He has other videos that go into more depth

@samuelolavo Yes, I do use NUT, but I don’t want to install any additional packet on XCP-ng. The way I found leverage the SSH authorized keys restrictions, and so you only need to change one file. Thanks for the link anyway

Indeed, it's hosted in Lyon, so an issue could happen in many places in the middle ^^

@ronan-a Thanks

@olivierlambert Client is a proxmox shop and whilst tolerating services running in XCP-ng / XO world they require that if everything fails they have the ability to pick up the pieces in-house. Proxmox has easy import of .ova but very manual process for .xva hence....

@Pilow the rrd ( the stats ) use the same code path as the backup . I am not sure if it's a feature or a bug, but at least it's a good canary the data volume of stats can be quite huge and have an impact on management. So it's a little justifiable to use the same network for backup and stats, at least until we can separate things more clealy . At least it helps a lot to check if the network is really reachable (sometimes because of third party filtering or ip configuration error , other to the xoa missing some network), and the downside is not to dangerous.

We could probably make the doc even more precise. Adding @thomas-dkmt in the loop for that.

I managed to do the migration by splitting over the two storages the remove system has. This made it work and I managed to move that one VM. However I still have a second one It's thick provisioned (LVM - never can remember the terms thin/thick). Offline isn't an option unfortunately since I need the services running, can't take if off for 15 hours. But since two of the services are docker containers, both having a separate disk of 500GB, I can make it work by setting up a two new systems and moving everything from the container there. Which would reduce the size by 1TB and make thing easier to manage. Was hoping I could finally upgrade the main xcp-ng last weekend.

@florent increasing the timeout value was the solution. Thank you.

@mpiton thanks for sharing docs, the crucial part was openssl rand -hex 32 my password was too simple and that's why i got :"Query authentication does not match server setting" error after setting 32 characters password i got my metrics, in both http://localhost:9004/metrics and http://<xo-ip>/openmetrics/metrics

Thank you! So in this case, if better option for me to join the hosts to existing pool and then shutdown VMs and start it on host with older CPUs. Thank you again!

@TeddyAstie Sure thing: xl_dmesg.txt Dom0_dmesg.txt DomU_dmesg.txt

@dave.opc that's it keep us updated on this

@florent said in vmware vm migration: @acebmxer yes after the first migration, XO knwo that the migration is incomplete and that you may want to finish it later. But if you start this VM direvtly , it will write some data, thus it won't be in sync anymore with the Vmware snapshot. Then XO won't be able to resume You can start a copy of the VM ( XO will handle it for you ) and delete the copy when you're done My advice is to migrate this VM to the right SR and then do the resume. But keep in mind that the V2V tool is intended to target only one SR, so migrate all they disk to the same SR, and select the right one when resuming the V2V. You can change the network after My previous migration was successful with no issues. Previously test vm was fresh install so no vmtools installed. But I did shut the vm down myself prior to starting the migration. VM boots no issues no prompts. This time I decided to follow the steps listed in the documentation as i have been following the changes and updates for the v2v migration. Following the steps as mention XO presented me with that prompt which was not mention in the documentation. As i was typing the post to gather my information it was then i noticed i did not select the proper destination SR and the appropriate nic/vlan for networking. So I noted that in the post. With the assumption i could correct that on the final migration. With that said the I guess the documentation should state - Start vm to test if boots, etc.. When prompted choose "Start a copy". When done shutdown vm and remove.