@DustinB said in Migrating logs and history between XOA instances?:

Every action that has taken place on the pool by XO, is what we were wanting to keep. But if you replace XO, you lose the logs as they are retained on the original XO.

If you are using the Audit plug-in, there is a way to move these entries to a new XOA deployments.

I assume that you are referring to other logs, like the ones appearing on a VM's Logs tab, correct?

@olivierlambert said in Update XOA OS via apt update?:

unintended updates

I think Olivier meant "unattended".

The latest XOA release is based on Debian 12. If your XOA is using an earlier version of Debian, then you should deploy a new instance of XOA to switch to the newer Debian version.

@Forza This isn't needed because the XOA VM is already performing these OS updates using unattended-upgrade.

For deployment on ESXi, you need to also do the following --

sudo -s  
cd /usr/local/bin  
curl -O https://gist.githubusercontent.com/julien-f/a6f98de3bd5a775f3f04b2fa14a9a102/raw/xenstore-read
chmod +x xenstore-read

@McHenry You always have to select a template when creating a new VM. By select the template as a first step, you will avoid this type of problem.

Are the SRs listed correctly if you first select a template?

@Vagrantin Have you tried restarting the host's toolstack with xe-toolstack-restart and then try starting the VM again?

@Vagrantin Have you check the XAPI logs for errors related to starting the VM?

@cichy The docs specifically mention that you need to repair the VHD files following the rsync operation.

@olivierlambert said in XOA 5.110 - Import from VMWare shows "vddk:" without ok or checkmark status:

Is it clear in our doc @Danp to make a snapshot on the VM we want to live migrate, and ourselves? (ie it's not done via the V2V automatically?)

I believe so, although I know that @florent stated that they need to be updated.

@MajorP93 said in XOA 5.110 - Import from VMWare shows "vddk:" without ok or checkmark status:

after successful migration by V2V VDDK tool the resulting VM on XCP-ng side has 2 snapshots:
Are they required? Can they be deleted automatically by V2V feature?

IDK if this will be more automated in the future, but you can easily remove these snapshots following the V2V migration.

@planedrop While you are connected to the XOA VM, be sure to verify that the required changes have been performed on /etc/systemd/system/xo-server.service when the VM memory was increased.

Details can be found in this troubleshooting KB article -- https://help.vates.tech/kb/en-us/31/48

Have you checked the logs via journalctl -u xo-server -f -n 50 to see if that yields any further details about these disconnects? How much RAM is allocated to the XOA VM?

@Andrw0830 Did you take a snapshot prior attempting the warm migration?

@Andrw0830 What version of ESXi?

The 1TB disk resides on a different SR, FME_Snap, which appears to be near capacity. This is why you can't take a snapshot or backup these VMs.

What is the type and size of the SR? How much space is free on it?

It sounds like you are running low on diskspace on the SR where these VMs are located. Have you checked the Unhealth VDIs section under Dashboard > Health tab to see if you have a coalesce issue?

@Andrw0830 Run the following command to remove the VDDK directory tree --

rm -rf /usr/local/lib/vddk

It should prompt you to install the library again after doing this.

Hi @Andrw0830

This is a known issue (the spinning circle), which will likely be addressed in an upcoming patch. Have you tried performing a migration now that you are at the main import screen?

Regards,
Dan