@stormi

I just realized your icon is from Keen4. I use to play that game when I was much younger.

Thanks again for all your help!

@adzmedia

One thing to try is the boot mode when creating the VM. The template for Windows defaults to UEFI as the boot mode.

I believe if you use BIOS Boot it will allow you to load the ISO.

Hope that helps!!!

@techjeff

Thanks TechJeff!

Yes I have 5 different instances of Xen Orchestra sleeping across my pool. I updated my Primary & Secondary to the latest Xen Orchestra and that's when they stopped working.

Jobs that Xen Orchestra was coordinating for me included booting, backups, and shutdown's.
They all started failing on the new version:

XO-Server 5.83.0 / XO-Web 5.89.0 / Ubuntu 20

The older version running on Ubuntu 18 is XO-Server 5.78.2 / XO-Web 5.80.0 is back to being Primary and works flawlessly so far.

So I'll follow your advice and live on the old version until the issue is resolved.

This is still great software, sometimes it takes these issues to fully appreciate how useful & reliable this application is.

Big Thanks to you super smart people who keep these things working for us!!!

I recently needed to rebuild my instance of Xen Orchestra as part of an upgrade.

For some reason when using the Job that triggers host.start it returns with an invalid parameter error.

Any idea on what I could try to resolve this issue?

Error Details:

host.start
{
  "id": [
    "efa4ef5e...."
  ]
}
{
  "code": 10,
  "data": {
    "errors": [
      {
        "code": null,
        "reason": "type",
        "message": "must be string, but is array",
        "property": "@.id"
      }
    ]
  },
  "message": "invalid parameters",
  "name": "XoError",
  "stack": "XoError: invalid parameters
    at Module.invalidParameters (/opt/xo/xo-builds/xen-orchestra-202111080620/packages/xo-common/src/api-errors.js:21:32)
    at Object.call (file:///opt/xo/xo-builds/xen-orchestra-202111080620/packages/xo-server/src/xo-mixins/api.mjs:73:18)
    at Api.callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202111080620/packages/xo-server/src/xo-mixins/api.mjs:300:19)"
}

@PC_123
For anyone who has this issue in the future.

The command stormi provided did fix the problem on a running machine. Unfortunately it did not persist following a reboot.

The command: iptables -F

Seems to be a better long term solution.

Thanks again to @stormi for isolating the issue.

@stormi

I just realized your icon is from Keen4. I use to play that game when I was much younger.

Thanks again for all your help!

@stormi

That fixed it, thank you. Any idea why the firewall rule wasn't initially created?

[10:59 xcp-ng3 ~]# /usr/libexec/netdata/xcpng-iptables-restore.sh
Applying firewall rules for netdata from /etc/sysconfig/iptables_netdata

@stormi

I'm glad you were able to spot a difference. My untrained eye still doesn't see the difference.

@stormi

[10:28 xcp-ng3 ~]# rpm -qa | grep netdata
netdata-1.19.0-3.xcpng8.1.x86_64
netdata-ui-1.19.0-3.xcpng8.1.x86_64

[10:29 xcp-ng2 ~]# rpm -qa | grep netdata
netdata-1.19.0-3.xcpng8.1.x86_64
netdata-ui-1.19.0-3.xcpng8.1.x86_64

@stormi
Not working host:

[10:07 xcp-ng3 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
xapi_nbd_input_chain  tcp  --  anywhere             anywhere             tcp dpt:nbd
ACCEPT     gre  --  anywhere             anywhere
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
xapi_nbd_output_chain  tcp  --  anywhere             anywhere             tcp spt:nbd

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere             icmp any
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     udp  --  anywhere             anywhere             ctstate NEW udp dpt:ha-cluster
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:21064
ACCEPT     udp  --  anywhere             anywhere             multiport dports hpoms-dps-lstn,netsupport
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain xapi_nbd_input_chain (1 references)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain xapi_nbd_output_chain (1 references)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Working Host:

[10:28 xcp-ng2 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
xapi_nbd_input_chain  tcp  --  anywhere             anywhere             tcp dpt:nbd
ACCEPT     gre  --  anywhere             anywhere
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
xapi_nbd_output_chain  tcp  --  anywhere             anywhere             tcp spt:nbd

Chain NETDATA (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:dnp-sec

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere             icmp any
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     udp  --  anywhere             anywhere             ctstate NEW udp dpt:ha-cluster
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:21064
ACCEPT     udp  --  anywhere             anywhere             multiport dports hpoms-dps-lstn,netsupport
NETDATA    all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain xapi_nbd_input_chain (1 references)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain xapi_nbd_output_chain (1 references)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

@PC_123

I ran identical code on two machines. One worked and the other didn't. The machine that didn't work is not the master of the pool. Could that be the reason? Do I need to setup the centralized reporting that was mentioned at the beginning of this thread?