@tony @julien-f All the jobs are running on different days and times, so most of the times they do not overlap one another and still get failed.
i must just add that all the jobs are tag related, maybe there is a problem with Jobs that are defined with tags search.

Novamente obrigado por se dispor a ajudar.

Eu fiz o teste de recriar a VM com o mesmo disco, e finalmente consegui visualizar o problema.
A má notícia é que é um erro de "kernel panic", provavelmente o sistema de arquivos corrompeu de alguma forma. As próximas horas não serão nada prazerosas.

Hi Pechkin000,

Try this :

npm install url-loader

yarn install v1.22.11
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info fsevents@2.3.2: The platform "linux" is incompatible with this module.
info "fsevents@2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.13: The platform "linux" is incompatible with this module.
info "fsevents@1.2.13" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 22.66s.

@olivierlambert ah ok ok, sorry..😅

@julien-f

Apologies, I'm not sure how to do that, but it seems easier to run the server as root instead of these workarounds.

Just change HTTP in the Settings/server to connect to your pools with http://<IP> that's it 🙂

Using this command to install from the old guest tools ISO worked fine

./install.sh -d rhel -m 8

the file version is xe-guest-utilities-latest-7.16.0-2.el8.x86_64, the distro logo is not showing though.

Just a quick FYI, XOA means "Xen Orchestra virtual Appliance" and it's only available via https://xen-orchestra.com or auto deploy. That's the only one with pro support 🙂

I think it's already planned in XO 6 (you might find the issue on GH)

Perfect! Enjoy XCP-ng! 🙂

Thin will have an active disk only the size used. So instead of using 100GiB, you are using 10GiB, and with a snap, only 10GiB and few KiB.

This looks like it was a problem with the VDI's on a network shared storage.
Unpausing the VM's would "start" them but they never actually boot - no console would appear.

In the end, migrating all other VM off the host and then rebooting the host cleared whatever was causing these VMs to be stuck and we were able to delete them

We're currently trialing a new storage provider, so this is definitely something we'll be looking into more with their support.

Okay so it's indeed a certificate issue on your side. Double check your certs. Sometimes, you need to have a cert file with the intermediate authority.

@jmccoy555 I updated both the XO deployments to current code just now. Both were the same BTW before.

one still asks for the SR on every migration. One does not.

[info] Updating xen-orchestra from '4bed8eb86' to '175be4482'

I would REALLY like to figure this out. Annoying.

Thanks

Tim

yes, I have no problem with commit before.
For now I'm on commit 65e62018e6aeabf64cf9def01ad043dfbdff5c18 and all is ok,

@pdonias

So I've dug into the issue and written a few workarounds which will tide me over until a fix comes out - appreciate your work on this.

I've added a few features in, too. The plugin now:

Allows the choice of whether IPv4, IPv6 or Both types of IPs are synchronised Allows you to enter in tags which will deem a VM to be "ignored" if they have one of these tags Allows you to enter in text which if the name label contains it, it will also be ignored (we have a use case where we have several VMs which are decommissioned but are kept in XCP for various reasons as well as our backup process which maintains a series of VMs with the prefix XCP-BACKUP, which we don't want kept in Netbox) Allows you to configure the ID of the configured VRF in Netbox (if needed) that the particular IP ranges relate to Synchronises the platform that the VM is running Brings across all the tags and puts them into Netbox (this is for our monitoring solution, OpenNMS, which uses Netbox to generate its requisitions and categories to automate the provisioning process)

I will submit these changes back into the Git repo tomorrow when I'm back in the office and you can have a look and see what you want to use. 🙂

@_danielgurgel if you mean basic backup, it's XVA export for both. The only different is in a back case, you are writing the file in a remote instead of sending it to your browser.

@beshleman So, after yum --enablerepo=base install python-requests on each of my hosts, secureboot-certs install default default default latest works perfectly. (Cool that it installs certs to each host in the pool with one invocation from any pool host.) Interesting that it doesn't install the three files to /var/lib/uefistored until you secure boot a vm on each host. I went looking for them and was initially confused because they were only written to the pool db. Serves me right for looking under the hood! 🕵 Looks like XCP-ng secure boot is ready for prime time. Great job!