Updates announcements and testing



  • Hi everyone.

    As a way to improve the quality of our updates, I will announce it here everytime there is a new update candidate in our updates_testing repository, so that you can test them and give feedback before they are pushed to everyone through the updates repository.

    How to install the update candidate

    Install all the current update candidates

    yum update --enablerepo='xcp-ng-updates_testing'
    

    Install specific update candidates

    yum install --enablerepo='xcp-ng-updates_testing' package1 [package2 ...]
    

    If a package breaks something, you can downgrade to the previous version:

    yum downgrade package1 [package2 ...]
    

    Then run any tests you find appropriate for the installed updates, and report here.

    Most update candidates won't stay for long in the testing stage, so each update is to be tested as soon as possible 🙂

    What to test

    Always: the most important task is to make sure the update introduced no regressions. Test basic functionality related to the updated component, test that your setup is still functional. As a bonus, you can also test more complicated scenarios that involve the component.

    If the update fixes a bug or security issue: try to reproduce before installing the update, then try to ensure the update does what it says it does.

    If the update brings new features, it's good to test them too.

    If you can only test parts of the above, it's still good. Just say so when you report here.

    How to report

    Say what and how you tested, and give the results, either positive or negative. When in doubt about your results, just ask!



  • Update candidate: vhd-tool

    • target: XCP-ng 7.5
    • reasons for the update: fix VHD import that was broken due to the previous fixes on large VDI import
    • packages:
      • vhd-tool-0.20.0-4.3.xcp.el7.centos.x86_64 - Command-line tools for manipulating and streaming .vhd format files
    • description of the changes:
    • install: yum install --enablerepo='xcp-ng-updates_testing' vhd-tool-0.20.0-4.3.xcp.el7.centos.x86_64
    • testing tips: anything that involves importing or exporting VHDs. Examples:
      • restoring delta backups (was broken)
      • creating delta backups (should still work)
      • continous replication (was broken)
    • reboot needed: no


  • @stormi Is it safe to assume that these packages are only intended for the latest version of XCP-ng?



  • @danp yes, the latest stable version of XCP-ng, so 7.5 at the moment.

    I updated my message to add the target version.



  • In a pool environment, does this package need to be installed on the master only, or on all the nodes?



  • @lavamind All nodes in the end. But maybe installing it only on one node to do a test would be OK, provided that's the node where the delta backup restore operation occurs. It will not make the node incompatible with the others. But if the operation involves several nodes, better upgrade them all. Maybe someone else (@olivierlambert ?) can give more information about that.



  • It's better to update on all nodes, because you won't have to remember which one is patched or not. The risk is very low, we aren't expecting any side effect.



  • Hello,
    I tried on small vdi's and my restore and cr problems solved with this update. I start large vdi restore and I will post results when done. Thank you.

    Edit: Iarge vdi restore and cr job (1.3 terrabyte) complete succesfully. Also delta backup jobs still working without error. Thank you again.



  • Thanks for the tests. I have pushed the vhd-tool package to the updates repository now, for everyone.



  • Update candidate: qlogic-netxtreme2 and qlogic-netxtreme2-4.4.0+10-modules

    • target: XCP-ng 7.5 and XCP-ng 7.6
    • reasons for the update: updated driver to fix various issues including kernel oops
    • packages:
      • qlogic-netxtreme2-7.14.49-1.x86_64.rpm
      • qlogic-netxtreme2-4.4.0+10-modules-7.14.49-1.x86_64.rpm
    • description of the changes:
      • an updated driver was needed to fix various regressions in hardware support for NICs using the bnx2x driver, regressions that started with XenServer 7.2.
      • we had a test package available but an official driver disk has been issued upstream, so we'll release this one instead: https://support.citrix.com/article/CTX239113
    • install: yum install --enablerepo='xcp-ng-updates_testing' qlogic-netxtreme2-7.14.49-1.x86_64
    • testing tips: test if you have the required hardware. If you haven't, just test that it installs correctly and nothing unexpected breaks.
    • reboot: not required if you know how to unload (rmmod) and re-load (modprobe) the driver from the command line. Else a reboot will do it for you.


  • Another one

    Update candidate: xen

    • target: XCP-ng 7.5 and XCP-ng 7.6
    • reasons for the update: security update
    • packages:
      • 7.6:
      xen-debuginfo-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-devel-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-dom0-libs-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-dom0-libs-devel-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-dom0-tools-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-hypervisor-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-hypervisor-debuginfo-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-installer-files-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-libs-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-libs-devel-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-ocaml-devel-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-ocaml-libs-4.7.6-6.2.1.xcp.x86_64.rpm
      xen-tools-4.7.6-6.2.1.xcp.x86_64.rpm
      
      • 7.5:
      xen-debuginfo-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-devel-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-dom0-libs-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-dom0-libs-devel-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-dom0-tools-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-hypervisor-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-hypervisor-debuginfo-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-installer-files-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-libs-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-libs-devel-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-ocaml-devel-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-ocaml-libs-4.7.5-5.6.1.xcp.x86_64.rpm
      xen-tools-4.7.5-5.6.1.xcp.x86_64.rpm
      
    • description of the changes:
    • install: yum install --enablerepo='xcp-ng-updates_testing' xen-dom0-libs xen-hypervisor xen-tools xen-dom0-tools xen-libs or if you don't mind installing other update candidates at the same time: yum update --enablerepo='xcp-ng-updates_testing'
    • testing tips: basic functions of the hypervisor
    • reboot: yes


  • Did a test on 5 physical hosts (from 7.5 to 7.6): everything is working correctly.

    We should probably release this in "prod" for Monday



  • Xen security update released for 7.5 and 7.6RC1.

    The qlogic-netxtreme2 package will stay in updates_testing a bit longer to let people test it.



  • I have now pushed the qlogic-netxtreme2 package to updates for 7.5 and 7.6.



  • Note to everyone interested in helping in testing update candidates (which is very important for the confidence we have in our updates), you can subscribe to this topic and make sure your user settings in this forum allow sending notification e-mails to you (it does not by default).

    Update candidate: xcp-emu-manager

    • target: XCP-ng 7.5 and XCP-ng 7.6
    • reasons for the update: fix a VM migration issue that occurs mostly with loaded VMs
    • packages:
      • 7.6: xcp-emu-manager-0.0.6-1.x86_64.rpm
      • 7.5: xcp-emu-manager-0.0.3-1.1.x86_64.rpm
    • description of the changes:
      • Many users reported seemingly random migration failures. Community testing alllowed to find that it was consistently reproducible by forcing high resource usage such as with this command: stress --cpu 1
      • The problem was caused by the fact that xcp-emu-manager, our replacement of the proprietary emu-manager component from Citrix that handles suspend, resume and migrate operations, did not know how to handle progress messages that arrived when not expected anymore, near the end of the migration process. The fix consists in ignoring those messages when the next step of the process has already started.
      • Fixes https://github.com/xcp-ng/xcp/issues/72
    • install: yum install --enablerepo='xcp-ng-updates_testing' xcp-emu-manager
    • testing tips: migrate VMs, especially loaded ones. Or artificially stress linux VMs with the stress command then migrate them.
    • reboot: no reboot required, no toolstack restart.

    For this specific update, please report your results there: https://xcp-ng.org/forum/topic/522/unable-to-migrate-live-vms-after-upgrading-from-xcp-ng-7-4-to-7-5



  • The update for 7.6 has been made available as a regular update, as xcp-emu-manager-0.0.6-2.x86_64.rpm. It should prevent most migration crashes, but can still get stuck when the VM is heavily loaded. Instead of failing directly, it will now try to wait for a low enough activity to resume the process. We're still working on it to bring a better, complete solution.



  • Update candidate: xen

    • target: XCP-ng 7.5 and XCP-ng 7.6
    • reasons for the update: security update
    • packages:
      • 7.6:
      xen-debuginfo-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-devel-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-dom0-libs-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-dom0-libs-devel-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-dom0-tools-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-hypervisor-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-hypervisor-debuginfo-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-installer-files-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-libs-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-libs-devel-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-ocaml-devel-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-ocaml-libs-4.7.6-7.1.1.xcp.x86_64.rpm
      xen-tools-4.7.6-7.1.1.xcp.x86_64.rpm
      
      • 7.5: same packages in version 4.7.5-5.7.1.xcp
    • description of the changes:
    • install: yum install --enablerepo='xcp-ng-updates_testing' xen-dom0-libs xen-hypervisor xen-tools xen-dom0-tools xen-libs or if you don't mind installing other update candidates at the same time: yum update --enablerepo='xcp-ng-updates_testing'
    • testing tips: basic functions of the hypervisor
    • reboot: yes