Offline
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
@Pilow said in Veeam backup with XCP NG:
@olivierlambert I get you.
Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.
Giving better observability is something we are working actively on , this is tightly coupled with being able to stop a task, and I hope we will be able to show the progress soon
@manilx yes, that's it
we should change the "full backup interval" to "base/complete backup interval", to clarify what is a full . And we will do it.
we are reworking the import code , along the new backup code ( https://xcp-ng.org/forum/topic/10664/our-future-backup-code-test-it ) to unify the differetn disk transformation path
For now:
@andrewreid Yes, I can't wait to share it with everybody.
@AlexD2006 thanks for signaling this, we just merged a fix, that fix it on our labs
can you test it on your side ?
https://github.com/vatesfr/xen-orchestra/pull/9202
@AlexD2006 this looks like the right issue, we will look into it immediately ( yesterday was a public holiday in France)
@Andrew then again, with such a precise report, the fix is easier
the fix should join master soon
found it , there was not one, but 2 bugs
albeit small they were putting the xo backup in a incorrect state
the fix is here, and will be merged as soon as possible and then released as a patch for xoa users
https://github.com/vatesfr/xen-orchestra/pull/8780
really thank you everyone for the information
@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation
@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
