There's no XO tasks per se, so you can't see it 😉 What matters is you have all the VM migrated in the end, but yes, it's not "visible".

Next major XO UI will have "XO tasks" that will display clearly the queue 🙂

I got the same error again today.

It's a delta job with two remotes.

fe12531c-52e2-4457-bc13-ee36db7f4fb5-image.png

Even though it says the backup failed, it looks like it is available on both remotes:
ca6eabb8-f810-44ac-bce0-7079755bc7de-image.png

srv01 = pool member
srv02 = pool master
srv03, srv04 = backup remotes
XOA runs on srv02

The error seems to imply that it can't resolve the hostname of srv02, but that seems rather odd. I am using static IP only.

Hi,

Please before creating a thread, read carefully this: https://xen-orchestra.com/docs/community.html

Double check you are on the latest commit from master branch.

@gigante said in Pool CPU usage is impossible:

@s-pam I am unsure of the purpose of that, but at least now I know! Thanks! 🙂

Just guessing here, but one reason is probably that single-threaded applications can only utilise one CPU thread, so they cannot go faster than 100%.🙃

@olivierlambert Thanks for the reply. I'll change to the "master" branch. I thought you were on a release schedule because you have a "releases" tab with the releases.

@deoccultist Not much I can add there, it looks like a system error between your XOA and the remote.

What kind of remote are you using? Does this happen often? Have you tried restarting xo-server or the OS?

I can recommend gparted to resize your partions. It's easy and has a GUI.
Important: you can't resize the boot partition without a live ISO.

I don't think console is possible at all (I have no idea in fact, I don't think Docker got an API to allow a remote console display). XO could deal with Docker API, it's not a "physical" access in the container.

@olivierlambert Then keep it in mind for that. 😉

As I ran into the same issue again: Is there no chance of getting a more informative error? "NO_HOSTS_AVAILABLE" is in the first view totally wrong and not helpful for debugging. ISO or at least storage not available would better help finding the problem (in this case an offline/disconnected iso repository).

@olivierlambert

So much for my memory.....

XCP-ng center always exports a snapshot as a template. The menu item is called that and the xva files made always re-import as templates. The equivalent xe function is xe snapshot-export-to-template which does the same thing. The only way to export the snapshot as a VM is to set the is-a-template parameter to false then export with xe vm-export. Once that's been done it looks impossible to set is-a-template back to true. Using either xe vm-param-set or xe snapshot-param-set and trying to set is-a-template back to true gives an error "VM_IS_SNAPSHOT"

I remember one of the backup scripts, NAUBackup/VMBackup if you're familiar with it, doing this and was never quite sure why until now. Looking through its code, it's creating a snapshot, setting is-a-template to false, exporting it as a VM, then deleting the snapshot in order to make an xva file backup while keeping the VM live. I'm not familiar with backups made by XO but I'm guessing you must be doing them in a similar fashion.

Edit: I just did some more testing and discovered that as soon as I set the is-a-template parameter to false on a snapshot made by XCP-ng Center or xe vm-snapshot, it starts showing up in the xsconsole "All VMs" list and in xe vm-list commands just as snapshots created by XO do. In addition, they're showing up both on xe vm-list and xe snapshot-list. Fresh snapshots made with is-a-template still set to true show up in xe snapshot-list but do not show up in xe vm-list or xe template-list. They do show up in the list of templates available in XCP-ng Center when creating a new VM but those with is-a-template set to false do not.

This is starting to smell to me more like a bug in xe or XAPI and possibly XCP-ng center as well but definitely in xe or XAPI. Is there any way to look into what's going on there?

Hi,

The fastest way to get support for your XOA is by creating a ticket at https://support.vates.fr 🙂

The forum is for community support.

@runevn said in Can't boot Windows 10 VM - Boots into UEFI Interactive Shell:

I found the solution. I had to press enter during the boot to boot into the "CD-ROM drive".

Guuuuh. Thank you for coming back and posting this.

We do not encourage to modify the dom0 Console IP is returned by XAPI. So check your management network IP address.

@olivierlambert You are absolutely right: tags are enough. My fault. We will code some cronjobs that find the current SR, set the right tag and that's it. If the cronjob runs before the CR job is running, we should be fine.
If you will implement the other idea: I guess (as you can specify only one backup target atm) an option to choose: 'store all vdis in target SR' or 'store only vdis from source SR in target SR' would be great, but if less work should be done: just store all vdis in the target SR - no matter where the source vdis are laying around 🙂

Anyway: great work! Keep on!

The official Cloudinit documentation for example? https://cloudinit.readthedocs.io/en/latest/

Hi,

We do not distribute XO via docker, so it's a 3rd party script/solution. Please report on the repo providing XO first, as explained in our doc: https://xen-orchestra.com/docs/community.html

@olivierlambert Ahhh, ok. Was focusing on XO; that's pointed me in the right direction. Thanks...and have a great weekend!

@bret_miller said in Upgrade failed: Command failed: npm uninstall -g --silent xen-orchestra:

✖ npm version: 6.14.5
does not satisfies ^4.6

For the sake of someone after me with this problem, based on it apparently looking for npm version 4.6.x, I did this:

sudo npm install -g npm@4.6.1

Then re-ran the xo check which came out clean except for being on and old version.

Then re-ran the upgrade which immediately re-upgraded to npm 6.14.11 and completed the upgrade successfully.

My theory then is that the upgrade to 6.14.x probably happened on a failed XO upgrade leaving the system in a state that I could no longer upgrade. It now appears fixed.