Restart the toolstack on each server.

You should be able to delete the snapshots without causing any harm. A couple of things to keep in mind --

• If the snapshot is associated with an existing backup job, then the next run of that job will result in a full backup instead of a delta

• It may take some time for the snapshots to coalesce following deletion, so this could still affect your backups until they are completely removed

• If you want to delete the backups associated with the old job, then you can from the Backup > Health tab in XO

It is also possible to perform this activity from within XO as described here. There are some prerequisites for performing this action that you should review -- https://docs.xcp-ng.org/installation/requirements/#-pool-requirements

I would setup a Continuous Replication backup job to create a duplicate VM on the new storage repository. When you are ready to perform the cutover, shutdown the original VM, perform one final run of the CR job, and then start the new VM on the new pool.

Interesting read that mentions xcp-ng!

https://www.theregister.com/2022/09/30/citrix_xen/

Yes, it's technically possible, as long as the underlying hardware is compatible. For example, you can't put a server using AMD processors into a pool with Intel processors.

The server being moved into the existing pool will lose its local storage and all VMs stored there, so you will need to migrate those VMs to the main pool before the server is merged. Afterwards, you can move them back if desired.

@JoyceBabu They are now available at https://www.xenserver.com/downloads

@jr-m4 Yes, it seems that all dropdown lists are broken by a recent dependency update. XO team has been notified.

@BrianDLC The error ""EACCES: permission denied" should have pointed you to a permissions error to begin with.

Since we have no knowledge of how that script operates, it often makes more sense to refer you to their repo for help rather than us guessing at the reason for the issue.

@Ascar I suspect that Olivier means to register with the XO instance using this syntax --

xo-cli register [--allowUnauthorized] [--expiresIn <duration>] [--otp <otp>] <XO-Server URL> <username> [<password>]

You can run xo-cli without any parameters to get the full usage text.

@olivierlambert It's even older than that.

https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.v5.md#5540-2020-12-29

https://xen-orchestra.com/blog/xen-orchestra-5-54/

That XOA version was released over 5 years ago. You really should share these kind of details in advance to avoid nonproductive exchanges. I recommend that you revisit the reason that they are "stuck" on this old version.

In current releases of XOA, you can resolve the issue by running a successful backup job that includes the affected VM.

To manually resolve the issue, you need to clear the left over keys in the blocked-operation parameter. For example, this will clear these keys for a VM with UUID be0a9812-fd14-be75-e2fa-40c31ce8875c --

vm_uuid=be0a9812-fd14-be75-e2fa-40c31ce8875c
xe vm-param-remove uuid=$vm_uuid param-name=blocked-operations param-key=migrate_send
xe vm-param-remove uuid=$vm_uuid param-name=blocked-operations param-key=pool_migrate

@Bytevenidos I don't see an endpoint in the REST API for mounting an ISO. However, you should be able to mount the ISO during the VM creation. I will ask around about using the REST API to mount and eject ISOs.

@Bytevenidos Are you up-to-date?

You attach a VDI to a VM by creating a VBD. Take a look at the POST /vbds endpoint.

@allySalami I'm not sure how that could be. You checked the VM's Advanced tab, correct? Are you running XOA or XO from sources? What is your current version / commit?

Check the VM's Advanced tab to see if this option is enabled --

@acebmxer There are older versions of the guest tools still available on Github.

@acebmxer said in Host compatibility:

Maybe if i shutdown the vms and boot backup all will be good?

This is generally correct. If the VMs haven't been migrated or rebooted since the additional host was added to the pool, then you can encounter this situation due to CPU masking.

See the docs for an explanation of Homogeneous vs Heterogeneous Pools.

@Pilow said in Network Management lost, No Nic display Consol:

you can try the command on MASTER host, you should see

master:ip_of_the_master

Slight correction. On the master, you should only have

master

without the colon and IP address.