Team - Security

Private

Posts

  • RE: Upgrade 8.2.1 -> 8.3 failed (manually fixed)

    When you say retry, did you completely restart the installation process, or did you just go back to the installer screen and retry the step that does the backup?

    If you retried the step, you should still have all the logs of the installer on the updated host in /var/log/installer/ in that case, I would suggest checking the dmesg-log, that sounds like a disk error to me.

    Having removed the file would not impact the newly upgraded host in anyway, it just means you lack that file in the backup, so that could have an impact in case you were to restore, which I hope you won't need.

    Other than that, I would encourage you to check your disk health as this could be a sign of hardware error.

  • RE: ECONNREFUSED when creating SDN network

    @Kptainflintt

    You're facing 2 different issues:

    1. it seems the SDN Controller plugin cannot reach OVSDB
    2. the SDN Controller plugin does not cleanup when there is an issue

    For 2. there is a work item to fix this on the XO team side. Just to clarify, what happens is that your request reached the XAPI, a network was created on the pool, then the SDN plugin tries to actually establish the tunnel, but fails as it cannot reach OVSDB, at that point you get the error, but the network have been created on your pool(s).

    You can check to confirm that the tunnel is not established using ovs-vsctl show, when the network is established, you should see something that looks like:

        Bridge xapi6
            Controller "pssl:"
            fail_mode: standalone
            Port vif1.3
                Interface vif1.3
            Port xapi6
                Interface xapi6
                    type: internal
            Port xapi6_port1
                Interface xapi6_iface1
                    type: gre
                    options: {key="11", remote_ip="192.168.1.220"}
    

    Of course it could be vxlan instead of gre, but the remote_ip part is the important point. Here I believe you won't see that. And you'll have to manually remove these networks from your pool(s).

    Regarding 1. and the connexion refused error, that probably means the 6640 port was not opened in the firewall. This should have been done automatically by XAPI.

    You can check if that's the case:

    # iptables-save  | grep 6640
    -A xapi-INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 6640 -j ACCEPT
    

    If you don't have that rule you can search your /var/log/xensource.log* for openvswitch-config-update and see if there are any errors there.

  • RE: Epyc VM to VM networking slow

    @Forza By default XOA VM has 2 vcpus, how many vcpus do your ubuntu have? Althrough iperf isn't running multithreaded in your test, there is one queue on the kernel side of the VM per vcpu to process packets.

  • RE: Patch for CVE-2025-27466, CVE-2025-58142, CVE-2025-58143

    It likely depends how they check:

    • if they use xl info they cannot know if it is the latest
    • if this is an automated SBOM scan, there is no database containing our version to assess it was patched

    At least that's the only ways I have in mind right now 🙂

    Could be interesting if you can get the info on how it is checked and where they expect to find the information.

  • RE: Patch for CVE-2025-27466, CVE-2025-58142, CVE-2025-58143

    Hello, the blog post you linked is our announcement that these have been fixed on our side. As you don't have any updates in XOA or yum commands, it means that you're on the latest version already.

    The reported version of xen through xl info il the base version, the .3 is our own patch or build iteration, therefore not reflected in that command.

    If you want to be sure, the best way is to compare the yum info xen-hypervisor version to the one present in the blog post.

Member List