100% agree, "stacked" tags are great. @lsouai-vates can you pass the word because I think XO 6 team isn't aware of those "stacked" tags in XO 5

@tc-atwork thanks for post, i wasnt able to get xo6 setup as i havent had time to play with it. I look forward to when it released. For now I just keep using xo-lite to open the console window.

@bleader Hi, thnak you for your response. However, What I can see : iptable rule is here : iptables-save | grep 6640 -A xapi-INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 6640 -j ACCEPT Service is started and running : systemctl status openvswitch ● openvswitch.service - Open vSwitch Loaded: loaded (/usr/lib/systemd/system/openvswitch.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/openvswitch.service.d └─local.conf, slice.conf Active: active (running) since mer. 2025-10-01 12:00:35 CEST; 1 day 22h ago Process: 44006 ExecStop=/usr/share/openvswitch/scripts/ovs-ctl stop (code=exited, status=0/SUCCESS) Process: 44042 ExecStart=/usr/share/openvswitch/scripts/ovs-start (code=exited, status=0/SUCCESS) CGroup: /control.slice/openvswitch.service ├─44085 ovsdb-server: monitoring pid 44086 (healthy) ├─44086 ovsdb-server /run/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/var/run/openvswitch/db.sock --private-key=db:Open_vSwitch,SSL,private_key --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --ssl-ciphers=AES256-GCM-SHA38:A... ├─44100 ovs-vswitchd: monitoring pid 44101 (healthy) └─44101 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir --log-file=/var/log/openvswitch/ovs-vswitchd.log --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach --monitor Process ovsdb-server is running : ps -aux | grep ovsdb-server root 44085 0.0 0.0 44128 556 ? S<s oct.01 0:00 ovsdb-server: monitoring pid 44086 (healthy) root 44086 0.2 0.0 52252 12544 ? S< oct.01 6:52 ovsdb-server /run/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/var/run/openvswitch/db.sock --private-key=db:Open_vSwitch,SSL,private_key --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --ssl-ciphers=AES256-GCM-SHA38:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA --ssl-protocols=TLSv1.2 --no-chdir --log-file=/var/log/openvswitch/ovsdb-server.log --pidfile=/var/run/openvswitch/ovsdb-server.pid --detach --monitor But, port 6640 is not listening : tcp LISTEN 0 1 127.0.0.1:5900 0.0.0.0:* users:(("vncterm",pid=1322,fd=3)) tcp LISTEN 0 128 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=1265,fd=8)) tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1158,fd=3)) tcp LISTEN 0 64 0.0.0.0:36183 0.0.0.0:* tcp LISTEN 0 5 0.0.0.0:10809 0.0.0.0:* users:(("xapi-nbd",pid=2864,fd=6)) tcp LISTEN 0 1 127.0.0.1:9500 0.0.0.0:* users:(("vncterm",pid=1322,fd=4)) tcp LISTEN 0 128 127.0.0.1:8125 0.0.0.0:* users:(("netdata",pid=2783309,fd=61)) tcp LISTEN 0 128 0.0.0.0:19999 0.0.0.0:* users:(("netdata",pid=2783309,fd=7)) tcp LISTEN 0 128 0.0.0.0:48863 0.0.0.0:* users:(("rpc.statd",pid=5012,fd=9)) tcp LISTEN 0 64 [::]:44169 [::]:* tcp LISTEN 0 128 [::]:111 [::]:* users:(("rpcbind",pid=1265,fd=11)) tcp LISTEN 0 128 *:80 *:* users:(("xapi",pid=2859,fd=11)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1158,fd=4)) tcp LISTEN 0 128 *:443 *:* users:(("stunnel",pid=3140,fd=9)) tcp LISTEN 0 128 [::]:19999 [::]:* users:(("netdata",pid=2783309,fd=8)) tcp LISTEN 0 128 [::]:57023 [::]:* users:(("rpc.statd",pid=5012,fd=11)) And yes, you're right, on the third node (wich raise this error), there is no "option" line on bridges. I've tried to start/stop ovs, start/stop sdn-controller. No changes

@MajorP93 stress of VM migration XD good luck with your V2Vs !

@vmpr hello, to be able to address the problem more clearly can you give me the version of your XO please? and if you are on stable or latest? XO v5.111.0 has been publicly released in latest channel yesterday.

@DustinB with Easyvirt integrated in the stack

The same issue was reported here, but seems its been fixed already. https://github.com/Jarli01/xenorchestra_installer/issues/137 nickali created this issue in Jarli01/xenorchestra_installer closed v6 build error: Scale is not exported by #137

Ah... so I missed the fix by one commit and two hours... I can confirm it resolve it. Thanks!

@hitechhillbilly Hi, For now the import tool does not use the proxy. Not that the full import tool also work from source if you need additional XOA , but we won't be able to connect to them for support

@Danp the issue is "resolved" only because we got the host back online so it released the lock. Yes I did try Start on which is method that produced the "The VDI is not available" error no the offline host was not the pool master Yes the VDI's are on shared iSCSI storage (truenas) And I want to note that OTHER VM's that were not on that failed host were able to restart and on any other node without an issue. I was even able to delete old snapshots without an issue so clearly the storage was online and available. It is deeply concerning that we were unable to get the VMs running again and only coincidental that were were able to re-seat the ram module and get it back online -- once it rejoined the pool the locked VM started without any issues on another host, so something was clearly locking it down even though it was fully stopped and visible.

@thomas-dkmt we might need to make sure XO docs tell how system updates are handled and proxy config

@olivierlambert said in Migrating logs and history between XOA instances?: Hi, VM stats aren't store on XOA but on your pools, and they should be there with the same history as the old one Can you tell exactly what kind of logs are you talking about? Thanks. I had looked on the wrong VM. The stats are indeed retained. Originally I was thinking of audit logs, but I realized they can be exported and imported. So for m point of view it is enough for now. Other logs that are missing is for example backup logs.

@Forza I didn't try, as my default Graylog Input was UDP and worked with the hosts... But guys, that was it. In TCP mode, it's working. Rapidly set up a TCP input, and voila. [image: 1758137911306-42411fc9-af86-4838-a870-ca9ca6307234-image.png]

@KPS Unfortunate, no. I just replicate and avoid moving live VM on the same host, target for replication.

@DustinB Yeah I thought about doing something like this, but then we are getting into overkill costs lol. My main point behind this post was to get info on what other people are doing, I presumed most are just relying on config backups and will restore it at the other site if needed, which is fine. I was just also debating about whether or not I wanted the subnets to match between these 2 sites, since that can create some routing headaches, but should still be doable and would make recovery even faster. @olivierlambert yeah I do use that feature, so that's very helpful! Should make this all doable.

Excellent news!

@Andrw0830 I am using paid version of ESXi / vSphere. The free version of ESXi has so many limitations that I consider it pretty much unusable / only usable for very limited basic tests. It would not suprise me if your issue is due to the license limitations within ESXi.

@Andrew said in XOA suddenly "empty" during rolling update: @halvor Yes, kind of... The pool master must be updated and rebooted first. If you move the master to a different host then you are no longer rebooting the pool master first. XOA is just a very smart client and needs the pool master to provide all of the pool information. Secondary machines will just redirect to the master, so if you try to connect XOA to one as a backup it won't work. You just need to wait for the master to reboot and return to a functioning state and wait for XOA to automatically reconnect. The everything will start happening again. If your master host is destroyed (ie. software corruption, hardware failure) then an existing host can be forced to take over the pool as master, but this is not a good thing to do unless the actual pool master is unrecoverable. Ok, great, thank you for clearing this up!

@planedrop While you are connected to the XOA VM, be sure to verify that the required changes have been performed on /etc/systemd/system/xo-server.service when the VM memory was increased. Details can be found in this troubleshooting KB article -- https://help.vates.tech/kb/en-us/31/48