@Danp Aww. see that box. Let me look into this problem a bit more. Learning some new things here.

There's no issue to restore everything from scratch, as long as your backup repo (BR/remote) is available.

For example, fresh XCP-ng install, deploy XO, connect to the BR and it will find all your previous backups. Then restore, that's it!

@julien-f Thanks for explanation. Thank you

@rjt Note to self about creating and managing appliances at xe cli.
xe help --all | egrep -i '(appliance)' # find xe appliance related commands.

appliance-assert-can-be-recovered, appliance-create, appliance-destroy, appliance-list, appliance-param-clear, appliance-param-get, appliance-param-list, appliance-param-set, appliance-recover, appliance-shutdown, appliance-start,

@olivierlambert

Well damn -- you're right.

Well VM now up and running. Just have to figure out how networking works in this new copied VM. Thanks for help.

@lawrencesystems still doesn't answer the question as to HOW to change the VLAN.

Hello everyone,

XCP-NG 8.2.1 here. Recently, I encountered issues with SR network connectivity (10Gb iSCSI), which caused a few virtual machines (VMs) to stop and subsequently fail to start, displaying the well-known error message: FAILED_TO_START_EMULATOR. While restarting the toolstack or the host are proven solutions, I would like to suggest two additional approaches:

If you have at least two hosts in the same pool, attempt to start the VM on another host. Create a snapshot of the VM and immediately revert to it. Then try to start the VM again. This should resolve the issue.

@kevdog Not at all, it made us aware that our vendor config was no longer relevant 🙂

Thank your for your report!

I think this is normal behavior when you have the Load Balancer plugin loaded. If you don't intend to use it, then unload it. 😉

The message was relatively clear (for a XAPI error 😛 😞

This operation cannot be performed because the specified VDI could not be found on the storage substrate
sr: 28a8b360-7b1b-58ca-81b6-f907c164ec38 (XCP-ng Tools)
vdi: b1a7a49a-f17c-42ac-af73-4429eb57b07a (Old version of guest-tools.iso)

This means the VM can't boot with this current CD because it's not there anymore. I suppose you updated your host without ejecting all CDs before. So the old tools CD was removed for the new one, and your VM kept it. So when you tried to boot, it couldn't because it couldn't find the old ISO.

Use FreeBSD instead of FreeNAS Avoid JPE

You have a problem on your XCP-ng, this is not related to a XO issue. It's stuck doing a snapshot, which is really a basic operation that shouldn't fail at all.

Double check your SMlog on the host.