Alright I finally got it to work.
I think the trick was to put "Ethernet 2" in quotations. I also perfected the YAML spacing and bracketed the two nameserver addresses.
Thanks for the help gentlemen. Final working network config:
#network:
version: 2
ethernets:
"Ethernet 2":
dhcp4: false
addresses:
- 192.168.1.30/24
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.5, 8.8.8.8]
@Kptainflintt Hey! XO team dev is doing a fix on it: https://github.com/vatesfr/xen-orchestra/pull/8979
FYI @pdonias
pdonias opened this pull request in vatesfr/xen-orchestra
open
fix(xo-server/resource-sets): only edit limits if `limits` is passed
#8979
@manilx I have proposed to the IaC team of Vates, a MCP Server for Vates VMS. Which can be used by GitHub Copilot or similar, if used when doing IaC etc.
@Danp Thanks for pointing me in the right direction. I was following an older howto where --global was not specified. That was my first problem - now fixed!
Second problem was that I had installed into the root directory of Centos7 so the paths for creating the links were different. Once I had found the correct paths and created the links all was good.
Thanks again.
Frank.
@fx991 the SR scans can and have been helpful in detecting storage issues for me. Sometimes when my ISO library goes offline but XCP-ng has not detected the failure and still shows it as connected I usually notice it from the long running SR scans that get stuck.
The "Connection to VM console..." task is when you have a console window open to a VM or Host...hence the reason why you can't cancel/end it...if you want to get rid of it then close all open console windows
I already opened one: https://github.com/vatesfr/xen-orchestra/issues/4882.
pdonias created this issue in vatesfr/xen-orchestra
closed
[VM] Network: show IP addresses in front of their VIFs
#4882
I can already confirm that I could trigger 2 Jobs manually in XO and it run successfully.
Thanks!
The scheduled ones I will see tomorrow and report if it would fail, but it is not expected.
It could, I don't know what XCP-ng Center can do in details. But again, this is NOT a problem.
I said it 3 times, why do you think it's still related to your coalesce problems?
It's the default parameter of your template. XCP-ng Center is probably forcing fixed memory, XO is just doing template recommendation.
You can change values at creation in "Advanced" section.
@Danp As soon as I read that, I thought "I think I've been down this road before." Sure enough. I gave it 2G of RAM and it wouldn't build. I gave it 4G of RAM and I watched using systat and that final step went to about 52% of RAM usage. It has completed. I routinely run Xen Orchestra on a 1G VM because it's rarely used and it runs fine that way. But building it clearly takes a lot more RAM. I'll update my internal notes. It might be worth it to update the building from source docs to mention having enough RAM.
Thanks for hitting the nail on the head with that advice!
XOA got its own numbering, unrelated to xo-server or xo-web: it'a all a matter of a coherent "whole", including dependencies etc. Thing we can't provide when built on sources.
Please test and report You can switch to latest too, doesn't matter.
@luiscamaral Let me reply to myself. If you update xoa it will show user and password as in bellow description:
Template for Alpine Linux 3.10, with 'root' username and 'xohub' password, DHCP enabled
@karlisi said in Interrupted CR task - what now?:
Automatically deleting incomplete VMs can be dangerous
This is an example - don't take it too strictly. I'm talking about exaclty the above problem. I was not aware of it. No information about the problem and this is the exactly the real problem.
