@still_at_work
I'm a noob (or lower) with XenOrchestra, so take any suggestions with copious amounts of salt

I think you would need to set up three separate schedules

• Monthly would take a backup on the first day of the month, with a retention of 12
• Weekly would take a backup every Sunday with a retention of 4
• Daily would take a backup Monday through Saturday with a retention of 6 - here is where I'd probably use delta backups

The downside to this is that it doesn't force the monthly backups to a weekend. You'll occasionally get a monthly full & weekly full happening on the same day.

It would be nice if it could use a single backup with multiple retention schedules like our current backup systems

@Andrew Awesome, thanks

I'm testing XCP-ng/XOA as a potential replacement for VMware Vcenter, and have an issue

I set up a continuous replication backup job for two servers (smart mode tag matching) with a different SR as a target. In Backup, I see the successful jobs completing every 6 hours as scheduled, but don't see anything under the Restore tab.

Are continuous replication backups handled differently?

@olivierlambert

That did it

Tested with both the LSI and Paravirtual - both succeeded

Thanks

I'm testing XCP-ng/XOA as a possible replacement for vmware, and have run into an issue with the online migration.

Because of a prior issue, I have created an NFS datastore and successfully migrated a few Windows machines. Any machine that I'm trying to migrate, I first vmotion to the NFS datastore. We're running VSphere 7.0u3, with hosts running ESXi 7.0u3 as well

Now I'm testing with a few RHEL machines. They are on VM hardware version 11 and running RHEL 7 or 8.

After migration, the VMs disks don't show up and it boots into emergency mode. There are no sda, sdb, etc items in the /dev directory

The source was using a vmware Paravirtual driver, which I thought was the problem, but the issue continues even after switching it to an LSI Logic SAS controller

The import task succeeds and the disks are there and connected to the VM, the OS just doesn't seem to be able to see it.

Any suggestions, or am I stuck with exporting to OVF, converting the OVF to OVA, and importing on the Xen side?

I am trying to configure proxies on our two locations. I installed the proxy on both sites which appears to have worked properly. The 'Test Proxy' also passes

When I add servers with the proxy info (URL copied from the other XOA/Proxy), those servers show up with an error UND_ERR_HEADERS_TIMEOUT, Headers Timeout Error

The servers & pool from the 2nd site never show up in the Home/Servers or Home/Pools page

Am I misunderstanding how the proxy servers are to be used?

@Danp Got this from a ticket for a similar issue

Migrating from VMFS5 (whatever the underlying storage is) : can do warm and cold migration
Migrating from VMFS6 (whatever the underlying storage is) : can do cold migration
Migrating from NFS datastore : can do warm and cold migration
Migrating from VSAN: will need to download the disk completly and then push it to XCP

The version of the esxi is not relevant as long as its 5+, but ESXI6.5 and following are using VMFS6 by default

Ended up creating an NFS datastore, as it had similar issues even though the datastore was VMFS5

I confirmed that I can ping the host from the XOA console
I also confirmed that I can SSH to the host

I changed to 'latest' channel, and ran the upgrade

It is now running version 5.94.2 build 20240401

I tried running the import from vmware again, with the same result

The error shows

esxi.listVms
{
  "host": "10.110.100.32",
  "user": "root",
  "password": "* obfuscated *",
  "sslVerify": false
}
{
  "message": "Cannot read properties of undefined (reading 'name')",
  "name": "TypeError",
  "stack": "TypeError: Cannot read properties of undefined (reading 'name')
    at file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs:292:29
    at Array.map (<anonymous>)
    at Esxi.getAllVmMetadata (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs:265:8)
    at runNextTicks (node:internal/process/task_queues:60:5)
    at processImmediate (node:internal/timers:447:9)
    at process.callbackTrampoline (node:internal/async_hooks:128:17)
    at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:366:20)"
}

@Danp I got that message when trying to connect to the ESXi host

It never gets to the point where I can select the VM, so it's not likely to be a power or snapshot issue

Currently testing Xen Orchestra & XCP-ng to determine if it would be a suitable replacement for vmware in our environment.

I have tried to import a VM from vcenter, but get the error above.

Our ESXi hosts are running 7.0.3

I haven't found if ESXi 7 is supported with this tool or not

Any suggestions?

If this won't work, what are my other options for migrating VMs? I do have FC storage configured so I could present that to Xen if that would speed things up.

Thanks

@olivierlambert The tasks completed overnight, and I had 2 XOA systems running this morning, with two more powered off. I cleaned them up, and it seems to be working now.

FYI, this is in a hosted datacenter, and our throughput is reliably above 500g up/down. During non-busy hours, like Friday afternoons, it runs upward of 2000g. There's a bottleneck or something throttling it, but not on our side (NY, USA)

@olivierlambert That connected and is coming down at about 50KB/s

I've installed XCP-Ng 8.2.1 on two of our Cisco Blades, and put them into a pool (via CLI)

Launching the Xen Orchestra install with the 'Quick Deploy' on the XCP-NG server home page gets to the 'Deploying XOA' with spinner, and goes no further

I tried installing using the CLI bash -c "$(curl -s http://xoa.io/deploy)" and it goes through collecting the network settings & passwords and hangs at 'Importing XOA VM...'

I tried installing at https://vates.tech/deploy/, and it hangs at 20%

I can use the lite.xen-orchestra.com to connect to the primary host and see that there are now four XOA VMs that show powered off

In the tasks at the bottom of lite.xen-orchestra.com, I can see four VM.import tasks with different started durations that count up as expected. Their 'Estimated End' times are quite interesting. The shortest end is counts down from 52:51 to 52:36, then goes back to 52:52 and counts down again

Has anyone seen this before?

Any suggestions on how to get XOA installed?