@jr-m4 Hi there... A warm VMware V2V migration should indeed start up by itself, so I'm not sure what you are experiencing is normal. This is documented, as you've probably seen, at: https://xcp-ng.org/blog/2022/10/19/migrate-from-vmware-to-xcp-ng/ That said, in addition, if you want your imported VMs to start up automatically every time your XCP-ng server or pool boots up, you have to enable the Auto Power On / Auto Start configuration. For this to work, it must be enabled at both the Pool level and the individual VM level. Method using Xen Orchestra (Recommended): Go to the VM tab, select your imported VM, and navigate to the Advanced view. Toggle the Auto power on switch to ON. (XO will handle configuring both the host pool and the VM flags for you). Or alternatively, via the bash shell: --> Get your Pool UUID xe pool-list --> Set the auto_poweron parameter to true xe pool-param-set uuid=<POOL_UUID> other-config:auto_poweron=true Enable Autostart on the Imported VM: --> Get your VM UUID xe vm-list name-label="Your_Imported_VM" --> Set the VM param to true xe vm-param-set uuid=<VM_UUID> other-config:auto_poweron=true

@KB973 Hello, thanks for the details. Regarding migration we are aware of issues in the lock system to resume a VM after migration. Often a lock is locked by SR.scan. We can't easily patch in V1. Also do you have the same issues using a default MTU (1500)?

@FritzGerald Thank you for taking the time to write up the install procedure. I was able to follow it on my end and it seems to be working. What commands do you use to set the three services to start up automatically at boot up? Right now if I reboot and run upsc apc@localhost it throws an error until I manually do: upsdrvctl start systemctl start nut-server.service systemctl start nut-monitor.service

I wasn't even aware about this being a Windows limitation by itself

@carloum70 Sorry, that option was deprecated. You may need to be more specific in the reset, something like the following with is just an example: xe-reset-networking -m IP_of_Master --device=eth0 --mode=static --ip=192.168.1.50 --netmask=255.255.255.0 --gateway=192.168.1.1 --dns=192.168.1.254 Check the options and see which ones you actually need in your case. Worst case, you could possibly dissolve the bond, redo the PMI and then re-create the bond. WHy eth4 shows up is hard to guess. I have seen before that on some hosts in a pool that the NIC order was not the same, even though the hardware and OS versions were identical. In that case, you have to shut down the NICs and use interface-rename to reassign specific NIC names to the corresponding MAC addresses.

Wonderful !

@fohdeesha Hi all, I apologize that it's taken a while to get all the issues sorted, fixed and properly verified. I have pushed the corrected version up to my GitHub, and everything seems to be working much better (thanks to the efforts of everyone here)! A big shout out to all of you, as this is exactly how open source is supposed to work! Let me know if there are any other issues that arrise - and Happy Day to one and All!

Wonder if these are just issues that will be fixed and not come back by manually cleaning it up. Held off at first cause I did not want to manually clean up, and then have it happen again. Will post in a bit when it finishes and will monitor this one for a few. [18:45 ovbh-pprod-xen02 ~]# drbdadm status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics 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:296465702 written:1319196709 al-writes:790653 bm-writes:361 upper-pending:1 lower-pending:1 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:1319197101 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:8 rs-in-flight:0 volume:0 replication:Established peer-disk:UpToDate resync-suspended:no received:0 sent:1292149931 out-of-sync:0 pending:1 unacked:0 [18:45 ovbh-pprod-xen02 ~]# drbdadm invalidate-remote xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 [18:45 ovbh-pprod-xen02 ~]# drbdadm status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics 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:300587646 written:1319298558 al-writes:790664 bm-writes:15389 upper-pending:0 lower-pending:1 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:SyncSource peer-disk:Inconsistent done:0.69 resync-suspended:no received:0 sent:1321387882 out-of-sync:313023380 pending:0 unacked:1 dbdt1:35.66 eta:8573 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:SyncSource peer-disk:Inconsistent done:0.65 resync-suspended:no received:0 sent:1294222956 out-of-sync:313141144 pending:0 unacked:0 dbdt1:30.42 eta:10052 jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 r l | grep xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen01 │ DRBD,STORAGE │ Unused │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen02 │ DRBD,STORAGE │ InUse │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen05 │ DRBD,STORAGE │ Unused │ Ok │ UpToDate │ Yes │ jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 r l | grep xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen01 │ DRBD,STORAGE │ Unused │ Ok │ SyncTarget(0.04%) │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen02 │ DRBD,STORAGE │ InUse │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen05 │ DRBD,STORAGE │ Unused │ Ok │ Inconsistent │ Yes │ jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 r l | grep xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen01 │ DRBD,STORAGE │ Unused │ Ok │ SyncTarget(0.64%) │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen02 │ DRBD,STORAGE │ InUse │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen05 │ DRBD,STORAGE │ Unused │ Ok │ SyncTarget(0.61%) │ Yes │ jonathon@jonathon-framework:~$ linstor --controllers=10.2.0.10,10.2.0.11,10.2.0.12,10.2.0.13,10.2.0.14 r l | grep xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen01 │ DRBD,STORAGE │ Unused │ Ok │ SyncTarget(1.00%) │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen02 │ DRBD,STORAGE │ InUse │ Ok │ UpToDate │ Yes │ │ xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 │ ovbh-pprod-xen05 │ DRBD,STORAGE │ Unused │ Ok │ SyncTarget(0.96%) │ Yes │

Got a response Yes, sorry, this was not properly pointed out in the release message. This comes from using https://github.com/piraeusdatastore/linstor-csi/releases/tag/v1.13.0 So you can still use the new operator, but you have to downgrade the LINSTOR CSI version until you upgrade the cluster. So doing that for now with the following helm values --- operator: resources: requests: cpu: 250m memory: 500Mi limits: memory: 1Gi installCRDs: true imageConfigOverride: - base: quay.io/piraeusdatastore components: linstor-satellite: image: piraeus-server tag: v1.33.1 linstor-csi: image: piraeus-csi tag: v1.12.0 tls: certManagerIssuerRef: name: pp-step-issuer kind: StepClusterIssuer group: certmanager.step.sm

@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.

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.

@samuelolavo Hello, Could the fact that this is a local LVM SR on a non-master host be relevant to how make_chain_rw is being handled? Yes, it's indeed what's happening. The check for the SRMaster (for a shared SR it's the master but for a local it's supposed to be done on the host directly) is failing and always saying False. I'll fix this. Thank you for the help

@JamesG, Yea i ended up having to go with a bare metal ubuntu install + docker containers for everything and have been off to the races, I would still like a hypervisor but unfortunately had to move on. The software stack on these intel's gpus is still maturing but i'm running some pretty impressive models on them and for the money it has been a good investment, hopefully these will gain some popularity and get better support all around. GPU hosting definitely deserves some attention from xcpng. I would buy some licenses for some production use cases but things like this and nested virtualization (completely unrelated but also something i ran into this past week) needs attention.

Just recieved another update from veeam... Regarding the general earlier errors: Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated] Our QA team did hear back from Vates support, who says its tied to a recent bug they've found with blktap calls: https://github.com/xapi-project/blktap/pull/444 Our QA engineer hasn't heard back yet on ETA when it will be pushed out in a general release yet though

@poddingue Thank you!!!

@poddingue This was fixed a number of weeks ago via a ticket. I believe @florent may know the exact fix.

You already spotted this over on 12468, so this is just to close the loop here. That one's fixed: Pierre Brunet put the fix on a branch, @Andrew and @abudef both tested it, and it's merged now. Since you're running from source on master, you should be able to pull past that merge rather than wait for a release. One thing to keep in mind, though: the same error string showed up in 11875 for a completely different cause, so if it comes back after you update, it's probably not this bug again. I'd let 12468 be the thread to follow since that's where the people who fixed it are.