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

@andrewreid Yes, I can't wait to share it with everybody.

@flakpyro today the backup code use binary stream in a the vhd format. This format is limited, by design , to 2TB disks
xcp-ng team introduce the qcow2 format to handle bigger disk
By using a independant format, we'll be able to handle both vhd and qcow2 on the backup side without multiplying complexity. We'll also be able to build the adapter to handle the various vmdk sub format (rax, cowd, sesparse and stream optimized) used by v2v and import bigger disks directly

@b-dietrich said in Externalised backup LTO:

Hi everyone,

I would like to know if it's possible to externalised backup on library tape with XOA ?

Is it in the roadmap for 2024 ?

I will let @olivierlambert on the backlog point. It is still planned, but there is a lot of ground work before :

• since tape can't be easily seek , so you'll have to write the backup at once no turning back to update a previously written block/metadata
• you'll have to build a catalog of tape<->backup to know which tape you'll have to use to restore, or rewrite. This is a huge change since XO don't use any database , the backup repositories are self contained : you can mount a backup repository to a new XO, and the backup will be listed . With tapes, you'll have to keep (and backup) the backup catalog. Yep , we'll need to backup the backups and ensure it's recoverable

That being said, the mirror backup feature as been built to pave the way to tape backup

For now the easiest way to do tape backup is to use full backup to a backup repository only used for this, and to mirror it to tapes. At our scale, priorities can also change if there is a big enough sponsor, that is ready to take a part of the financial load of this feature and gives us access to real world hardware and processes.

@CJ yes we have to fix the preview panel

the test with @dumarjo showed that there is still a bug during the import. I am still investigating it and will keep you informed, hopefully today or tomorrow

@ismo-conguairta said in VMware migration tool: we need your feedback!:

I have two different behaviour on two different XO instances. Each XO instance refers to a different pool (different hosts, same xcp-ng version). In both the instances I try to connect to the same Private Virtual Datacenter based on VMware/vSphere at OVH.

In the first one I get the following error message by using the web UI: "invalid parameters" (take a look at this logfile 2023-02-28T19_25_21.933Z - XO.txt )

In the second one, I get the following error message by using the web UI "404 Not Found https://<vsphere-ip>/folder/<vm-name>/<vm-name>.vmx?dsName=<datastore-name>"

By using the xo-cli I get the "404 Not Found" on both the instances.

Regarding the "404 Not Found", I want to point out that at OVH I have a VMware datacenter (with 2 hosts) and in order to access to the storage I need to specify the parameter dcPath=<datacenter-name>

So the right URL should be https://<vsphere-ip>/folder/<vm-name>/<vm-name>.vmx?dcPath=<datacenter-name>&dsName=<datastore-name>

Simply adding (in a static way) the dcPath specification on line :54 of esxi.mjs file makes it work.

I thought it was constant. I will look into the api to get it, and if not possible expose it in the UI

@Seclusion : noted I will look into theis error message, this one is a first for me

@brezlord mac address and uefi should works now

@rochemike patch done this morning

@rochemike great, that will be even easier

can you open a support ticket and open a support tunnel ? I will connect and patch your installation

@acomav you're up to date on your XOA

I pushed a new commit , fixing an async condition on the fix_xva_import_thin branch . Feel free to test on your XO from source.

@techjeff thanks for your effort, I found the problem

can you test this branch : fix_cr_healthcheck ? (git checkout fix_cr_healthcheck from xen-orchestra folder) it will be merged soon

hi @stilllearning @michmoor0725 @dumarjo we merged a fix in master.
For those who use a XOA, open a support tunnel and I will patch the installation

regards

Florent

@florent PR for bucket is here : https://github.com/vatesfr/xen-orchestra/pull/6757 it should be merged today and go live with the release on the end of he week

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(xo-web): relax pattern for bucket #6757

@KPS that is a second bug
I will look into it this afternoon.
edit : confirmed, I'm working on it

@ronivay that's a great information. I can reproduce the comportment with xenserver 7.1 CU 2
Thank you

@parsedave Hi,

We worked on a branch that should fix it : https://github.com/vatesfr/xen-orchestra/pull/7583 It should be merged in master by the end of the week

Thanks for your report

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(vmware-explorer): harden vmx parsing #7583

@Gheppy yes

at least if fixes import \o/

I am creatig card in the backlog to improve the import. Could you extract the ovf file of the windows ova ( rename it to tar and extract it) , and send it to me or post in in the forum ( it should not contains any confidential information )

@gasky @Gheppy

could you try this branch : fix_re_re_ova_export (PR is https://github.com/vatesfr/xen-orchestra/pull/7183/files ) ?

don't forget to do a yarn install before relaunching xo, since we updated a dependency

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(xo-vmdk-to-vhd): improve compatibilty of ova with disk bigger than 8.2GB #7183

@olivierlambert yes, as soon as my branch is working as intended

For now I can generate a valid tar (with pax header) , but virtual box don't like it