@MajorP93 said:

-disable HA on pool level
-disable load balancer plugin
-upgrade master
-upgrade all other nodes
-restart toolstack on master
-restart toolstack on all other nodes
-live migrate all VMs running on master to other node(s)
-reboot master
-reboot next node (live migrate all VMs running on that particular node away before doing so)
-repeat until all nodes have been rebooted (one node at a time)
-re-enable HA on pool level
-re-enable load balancer plugin

Never had any issues with that. No downtime for none of the VMs.

update time again. and same issue

I followed these steps

-upgrade master
-upgrade all other nodes
-restart toolstack on master
-restart toolstack on all other nodes
-live migrate all VMs running on master to other node(s)
-reboot master

now cant migrate anything else.
live migration : NOT_SUPPORTED_DURING_UPGRADE
warm migration: fails and VM shuts down immediately and needs to be forced back to life
CR backup to another server : NOT_SUPPORTED_DURING_UPGRADE

@nvs Hi there, we had a similar issue with on our 5900x boxes. We have about a twenty of these and they have been generally greats hosts for xcp loads. However, one of them was constantly rebooting. While testing the ram the temp jumped to 90/90. They are running in 1U boxes so I expect heat but this seemed silly. We ramped the fans to max but this did not help.
We then used bios to drop down various cpu boost profiles and gadgets to lower the heat and re-applied paste to cpu..

so far so good.

I know this is old but I had a similar issue. In the end I told dracut NOT to reassemble my raid array which allowed the system to boot perfectly after. I have no idea why it tries to assemble the same array two but on the second seems to be important

@olivierlambert said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:

Because doing an update without rebooting doesn't reload the updated main programs, like XAPI. A host in only updated after a full reboot.

Reply

Hi there
Is it just me or is this a chicken and egg situation.

you upgrade the master... how the pool is in NOT_SUPPORTED_DURING_UPGRADE() stage. You cant move vms off the master so all you can do is close down vms.. reboot.. pray

then move the a non master.. you cant move the vms off here either NOT_SUPPORTED_DURING_UPGRADE(). So you have do the same..

needless to say I hit issues on each reboot which caused 30- 60 min delays in getting vms back up and running.

can you Warm migrate or is this dead also (to scared to test)

@Davidj-0 in my case there CPU activity is minimal. I think something is wrong with the software raid 10 setup. On an identical setup warm migration between to the raid 10 array between hosts is showing horrible iowait similar to the sr to sr transfer on the other host

I think I am seeing a similar issue. Raid1 NVME copy to raid 10 4x2tb HDD on same host

a 300gb transfer is estimated at 7 hours. (11% done in 50 mins)

the vm is live.

according to the stats almost nothing is happening on this server or the 2 storage

Hi there

I am steadily migrating VMs from exsi to xcp-ng.

I am using clonezilla destination to source and it could not be easer or quicker. So far so good.

However, I also migrated bare metal server (ubuntu 18). Initially on reboot the vm just showed a Hard disk found message.. so i switched from bios to uefi and it booted immediately. However, the console text is unreadable.

I have seen a few discussions around this related to the template settings. I have tested ubuntu 18 and 20 template but both have the same effect.

I cant edit any pre-boot options as nothing can be read..

The VM is running just fine.. but one day I am going to need to use that console. ..

Any ideas?

@olivierlambert spoke too soon.. CR works in one direction but not the other
https://images.dx3webs.com/kgSC4E.png

@olivierlambert actually.. just tried CR again... and this time it is working.. will test with a few more vms.

@Gheppy Yes.. putting that in place seemed to fix DR.. but not CR.

@Gheppy weird.. DR is now working for me but CR is still never ending

Hi there

I am testing DR and continuous replication.

It all seems straight forward. Select vm runnning on host1... point the backup to local storage on host2 .. press play

The backups start.. there is 30gb of network activity.. the vm and disk is visible at host 2 but the backup never completes and new backups cant start as they are not finished.

Error: the job (23857c52-0987-4eba-9b90-bd4fbb5d3a7c) is already running

Where do I look to find the reason?

@florent What is the location of the logs?

@florent Yes, esxi is just fine. All running VMs are happy. I have pulled one more off this server after the failed attempt. Have tried about 6 times .. same result.. VM appears.. process completes after a few seconds.. no disk appears

The disc config seems very boring and normal.

https://images.dx3webs.com/Zdiy2T.png

https://images.dx3webs.com/y4vMSZ.png

new issue.. I am trying to pull a vm (powered off) from a server I have already pulled 3 vms from (no problems)

However, this time it takes a few seconds before the command ends.

I can see the vm however, no disk is pulled over at all.

no obvious errors in logs.

@olivierlambert ah I see.. other than that!! it works.. Just like magic!! v cool

@olivierlambert said in VMware migration tool: we need your feedback!:

XO from the sources

XO from github (2 days old)

esxi .. 7.0.0 (Build 16324942)

Total noob here jumping in at the deep end.

I get

 xo-cli vm.importFromEsxi host=xxx.xxx.xxx.xxx user=w...w password='u .... l' sslVerify=false vm=16 network=a1044bf9-4c06-8ae0-060c-e3462dd4524f sr=9b465ed4-e6d2-7a67-b5e0-5edc4915adac stopSource=true thin=true  

✖ Cannot read properties of undefined (reading 'stream')
JsonRpcError: Cannot read properties of undefined (reading 'stream')
    at Peer._callee$ (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/json-rpc-peer/dist/index.js:139:44)
    at tryCatch (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:44:17)
    at Generator.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:125:22)
    at Generator.next (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:69:21)
    at asyncGeneratorStep (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
    at _next (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:9)
    at /opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/asyncToGenerator.js:27:7
    at new Promise (<anonymous>)
    at Peer.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/@babel/runtime/helpers/asyncToGenerator.js:19:12)
    at Peer.exec (/opt/xo/xo-builds/xen-orchestra-202302081722/node_modules/json-rpc-peer/dist/index.js:182:20)