That's why XO proxies are great and the go-to solution
Alternatively, you can deploy an XO inside the target network and manage your hosts from there (but you won't have the unique central console with one XO+proxies for the entire infrastructure)
@bryonadams it seems like you are not on the most recent version of Xen Orchestra. Could you update your XO?
"excess property" errors are often wrong parameter errors.
name_description and memory are accepted but the auto_poweron parameter is not allowed because it is misspelled... the API expects autoPoweron.
Hi, thank you for the example! We will take a look. It could be a good idea to have a dedicated documentation/web page with usage examples of 'DevOps' tools
@robyt nice catch
We use compression when selecting block based backup (by default brotli), that brings a 20-50% storage reduction depending on the data
PR is here https://github.com/vatesfr/xen-orchestra/pull/6865 and will be merged before may release
fbeauchamp opened this pull request in vatesfr/xen-orchestra
closed
fix(xo-web): VHD directory tooltip
#6865
It seems that the task failed 5 minutes a go, with the error >> HTTP connection has timed out <<, I restarted the task and now everything is displayed.
Thank you
@Andrew I'm on the same commit. To be clear, it's a warning not an error --
[4/5] Linking dependencies...
warning " > eslint-config-standard@17.0.0" has incorrect peer dependency "eslint-plugin-n@^15.0.0".
warning Workspaces can only be enabled in private projects.
@fred974 Gotcha, yeah this is their built in speed test which IMO isn't that accurate since it uses a very small amount of data to determine speeds, I've seen wild fluctations in it.
There isn't a huge diff: stable is just release-1. "release" is "latest". So for example, our next XO release (5.83) will be in latest while your current latest code will land in stable. So if next week (June the 1st) you decide to get back on stable, you will be in 5.82 (the current latest of today).
@kent
You can ask for a trial so you can do it the time you need
If you use XO from the sources, you will have the feature for free (but without support/updater and such)
At first glance, it does not seem so easy.
First, we will implement this feature in XO Lite (soon). We will then see if there is a trivial way to adapt the changes in XO5
This was ultimately traced to a currupted metadata on the VHD and to a stuck tapdisk process on the host where the VM was running.
Solved thanks to a very persistent member of support. Thanks Jon!
@sluflyer06 the warning on XO is to discourage the mass. But you can really try
you can make a config.toml file in ~/.config/xo-server/config.*.toml , it should be loaded , and won't be changed by an XO update . https://github.com/JsCommunity/app-conf
@HeMaN this may have actually worked...
In etc/network/interfaces
The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
This is an autoconfigured IPv6 interface
iface eth0 inet6 auto
post-up route add default via 10.10.10.1 dev eth0
auto eth1
iface eth1 inet static
address 10.10.5.188
post-up route del default dev eth1
Then I don't see why it would be a XO problem
FYI, we use JSON-RPC over websockets. Hopefully, someone at Teleport community would be able to pinpoint the problem
Hi,
In XO Hub, you already have a Debian 11 which is Cloudinit ready This is more a Cloudinit question BTW, you should ask their community. Frankly, Cloudinit doc isn't great and many things changed a lot
