@olivierlambert

That did it

Tested with both the LSI and Paravirtual - both succeeded

Thanks

@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

@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