@marcoi on xo side we use to show the ip of the ipmi and the sensor. We don't write anything nor use it for poweroff

@snk33 migration were successful, we need to clarify the doc and/or the tool , the VM need to have at least one snapshot for warm migration

@wmazren said in VDI not showing in XO 5 from Source.:

       is-a-snapshot ( RO): false
         snapshot-of ( RO): d31f2db0-be21-4794-b858-1bea357869c8

this disk is now recognized as a snapshot by xo
is it a disk from a restored VM ?

@Pilow the run logs ( in backups ) are marked as success ?

@nikade no, it should either succeed or remove the unfinished parts. Are you migrated toward a qcow2 remote ?

could you download one of the vmdk file ( it should be small ) of a VM with at least a snapshot on VSAN ?

@snk33 I don't see the snapshot
could you extract the .vmx and . vmsd file of the VM ?

@snk33 said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?:

35803

nice I am connected
Could you launch a warm migration ? I will check the logs

@snk33 the vddk migration path is now far more than a Poc , and it gaves very good result but we are missing some key part to improve things on VSAN , since it's not too easy to setup and we are not a vmware shop

we would gladly work together if we an ensure warm migration can be made reliable even from VSAN.

How can we proceed ? If you have a xoa, would it be ok to allow us to use a tunnel so we can start a VM migration ad find the root cause ?

@Pilow error reporting is a feature in itself . Thanks

@Pilow would it be possible to test from source, or with latest ( note that v6 will be default on latest ) ? it would be useful to have the real error message instead of the itnermediate value

@Pilow This is most likely related to different version of your xapi . You can only do full replication from one older to a newer version

(and there are some recent commit this week to give a better error)

@Pilow I will take a look in deep later, but the key/delta and disk usage is set during backup, even if they are merged during LTR retention

@henri9813 yes thank you for correcting my message

you can uncheck the "Merge backups synchronously" in the advanced view of the backup job to have it run inside the backup job, thus making it visible

(we are reworking the internal design for better observability, but there is a lot of job before)

@dnordmann the tunnel is closed. By the way the patch will be release tomorrow on latest, by the end of december on stable

thank you all for your patience and your help identifying the root cause of this bug

@Forza

Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects

better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this

In any case, both are on our backlog

@dnordmann said in V2V - Stops at 99%:

@florent

Ticket#7747444
and I just opened another ticket for the other client that is having the same issue. Ticket#7748053.
Support tunnels should be open for both clients.
Thanks!

I deployed the patch on the new client, if it's ok I will do the second one after

@dnordmann if I remember well you have opened a ticket on your xoa , can provide us the ticket number and we can patch your xoa ?

if you are using xo from source, you need to change branch and then restart xo-server

@MajorP93 that's nice to hear taht it, at least solved the issue
are you using a xoa ? or a compiled fro source ?
what is the user that run the xo service ?

@dnordmann @tsukraw
thank you for your patience, we found something while working with the xcp storage team, and there is an issue with the last block size

Can you confirm that the failing VM has at least one disk with a disk with a size not aligned with 2MB ?

Could you test this PR on the failing import ? https://github.com/vatesfr/xen-orchestra/pull/9233

regards

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(nbd-client): nbddisk must emit full size block #9233