Have you tried resetting the VM's power state?
xe vm-reset-powerstate uuid=<UUID_of_the_VM> --force
Have you tried resetting the VM's power state?
xe vm-reset-powerstate uuid=<UUID_of_the_VM> --force
There was a change a while back with the way Node handles timeouts, which affected instances of XOA where both IPv4 and IPv6 were assigned.
Temporarily adding the following entry to /etc/hosts will likely resolve the issue --
185.78.159.93 xen-orchestra.com
Hi Dustin,
Yes... these types of actions are recorded in the Audit log (Settings > Audit) if you have access to this feature and have enabled it.
Dan
Is xo-server
running? Check systemctl status xo-server
You can also check the recent logs with journalctl -u xo-server -f -n 50
@rustylh Great! Are you now able to move beyond the error you posted above?
@rustylh Did you follow the instructions to visit the page and a cept the self-signed certificates?
@olivierlambert Pretty sure the problem originates from this PR.
@wf said in XO Community edition backups dont work as of build 6b263:
How do I roll back to a previous commit?
git checkout <target commit>
Then rebuild with yarn; yarn build
@venkatm Which firmware is the VM using to boot, BIOS or UEFI? Are you ending up in the dracut emergency shell?
@francescomaria-c A few things to check --
Is the pool master fully patched? If the slave is more up-to-date than the master, then it can display behavior such as you describe where it is unable to communicate with the master.
When joining a new host to a pool, this new host should only have the management network configured as it will inherit its network configuration from the pool.
Thanks for letting us know. I've passed the information on to our IT staff. In the interim, you should be able to respond to that ticket by accessing the support portal at https://xen-orchestra.com/#!/member/support
@kmgallo From your description, it sounds like these hosts were in separate pools. Is that correct? Are you able to SSH into the host and check its status from within xsconsole
?
@joneill Switch to the Licenses tab (XOA > Licenses) and then click the red button to activate the license on the appliance.
This message shouldn't appear if the license is properly activated. Since you have an active XOA trial, you should open an official ticket through the support portal and we can take a look at this for you.
Please review our Vmware migration checklist -- https://help.vates.tech/kb/en-us/37/133
Depending on your type of datastore, it is possible that you need to perform a cold migration where the VM is shutdown prior to attempting the V2V process. Also, the creation of a snapshot is a requirement unless you are migrating from a VSAN.
@Jonathon We are interested if you can reproduce using an up-to-date instance of XO.
Your XO VM is about 2 months out-of-date. Please make sure you are fully updated before posting making this type of post.
Let us know if you are able to reproduce using an up-to-date version of XO. You could also use a free trial of XOA to test this.
Hi,
Have you installed the Guest Tools into the VM? Missing guest tools is the most common reason for this issues.
Regards, Dan
P.S. I edited your post to add markdown code around the log so that it is easier to read.
@anik I believe that you have some of the names backwards.
XO Lite is available by default on XCP-ng 8.3. See the documentation for how to access it on XCP-ng 8.2.1.
The newer XO 6 interface is accessible from XOA by using /v6
. It may need to be explicitly enabled to use it on XO from sources.
@coolsport00 Export the VM as an OVA file, then import this on the XCP-ng side.