@Ascar I assume TNS1-MIA is running so XO shows it's running on the host xcp1-mia in the pool xcp1-mia whereas TNS2-MIA COBIA is shutdown therefore running on no host at all and so XO only shows it belongs to the pool xcp1-mia

@Byte0 Hi the script is not provided by this repo but directly by the xapi rpm:

[10:47 r620-s2 ~]# rpm -qf /etc/xapi.d/plugins/firewall-port
xapi-core-1.249.36-1.2.xcpng8.2.x86_64

Anyway yes the check method is weird because it answer the opposite of the reality - but... it's by design according to upstream: https://github.com/xapi-project/xen-api/blob/45d934eec88def324799e0c428df14e726eb8566/ocaml/xapi/dbsync_slave.ml#L129-L134

But the open/close method works as expected and then you can see the rules are correctly added to iptables.

@maxxie XO / Settings / Servers is to show a list our your pool's masters so one per pool.

It's expected as only the master is connected to XO and then dispach the API calls to other hosts when relevant.
If the Pool view shows 2 hosts then you're good.

You can also ssh to any of your host and run xe host-list you should see the 2 listed

@McHenry on the host you want to join: check if /etc/stunnel/certs/sdn-controller-ca.pem exists - if not create it: touch /etc/stunnel/certs/sdn-controller-ca.pem and then
xe pool-certificate-uninstall name=sdn-controller-ca.pem then retry the join.

@Byte0 Hi!

/etc/xapi.d/plugins/firewall-port {open|close} port protocol should do the trick. Beware we advised against modifying this config for obvious security consideration.
So know what you're doing

@McHenry not sure what you mean.

You can easily join the host with no VMs to the other one by calling xe pool-join master-address=<ip of other host> master-username=... master-password=...

Then you should have a 2 hosts pool.

What make you think it's not possible?

@McHenry The import should have given you an uuid once finished which si the uuid of the VM.

It should also appears when doing an xe vm-list

@McHenry hi

you need to call xe vm-import filename=/path/to/file.xva

@PimAarts hi!
"path": "2a10:3781:2ad:f5:92e2:baff:fe31:5b80:/mnt/Venus/ISO_Library"

Should be "path": "[2a10:3781:2ad:f5:92e2:baff:fe31:5b80]:/mnt/Venus/ISO_Library" with brackets around the IPv6.

@PimAarts hi!

Thx for the report - I reproduced the issue and am investigating.
Meanwhile clicking on Cancel will give you access to XOLite

@brezlord So I managed to reproduce the issue: basically what's happening is lspci shows a shortened version of the PCI ID and the XAPI expects to parse a complete version of the ID so it fails while parsing. Removing manually the passthrough in the xen command line and re-adding it via XAPI should solve the issue.
Now that the API is available this shouldn't happen anymore as the only supported way of passing through a device is via XAPI.

Regards

@brezlord If it's not to much a bother that would be great yeah.
Comparing the xen-cmdline when doing the passthrough manually on 8.2 VS how it looks on 8.3 and when done via the XAPI.

@brezlord Can you sahre the value you put in the xen-cmdline on 8.2?

I think the XAPI awaits this format: xen-pciback.hide=(pci-id1)(pci-id2)... and will fail the value doesn't match this format.

@jasonnix there's a typo you use pdb instead of pbd

There's a evacuation-batch-size in /etc/xapi.conf thant can be edited to tell how many VMs to migrate at the same time when evacuating an host.

@mmancina Hi you can try to call xe pif-scan host-uuid=<uuid of your host> , the NIC should appear after that.

@olivierlambert Pretty easy since everything is stored in the network other_config field.

@gb-123 AFAIK the host doesn't call XO, if you shut XO off, the private network would continue to work but its state wouldn't change.
It means if you restart an host etc the connection to this host would be lost.

The logs depends on how your installed XO or XOA etc so you might want to go through our doc!

Cheers

@gb-123 The tunnel are numbered by order of creation by XAPI, you can't change them.

I don't XCP-ng 8.3 has an issue since we use it internally and the SDN is working fine on our side.
I think some events are triggering the SDN controller to add the host over and over and during the adding of the host the connection might be perturbated. You should take a look a look at XO's logs to see if you can find something that might trigger the SDN controller.

Does the host added frequently has another weird behavior?

@gb-123 You're right! I'll edit my post.

Thx