XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. yann
    Offline
    • Profile
    • Following 0
    • Followers 0
    • Topics 0
    • Posts 79
    • Groups 4

    yann

    @yann

    Vates 🪐 XCP-ng Team
    59
    Reputation
    37
    Profile views
    79
    Posts
    0
    Followers
    0
    Following
    Joined
    Last Online

    yann Unfollow Follow
    OS Platform & Release Team Vates 🪐 XCP-ng Team Admin

    Best posts made by yann

    • RE: New Rust Xen guest tools

      @Andrew that's planned 😉

      posted in Development
      yannY
      yann
    • RE: New Rust Xen guest tools

      People with FreeBSD 13.2 or later as a guest are also now able to use Netlink to get their IP address changes reported instantly (rather than having to wait for as much as 1 minute).

      This is however not yet part of our CI jobs, as we rely on cross-rs, which for now only provides FreeBSD 12 cross-build support. Your choices to try it:

      • build it yourself
      • manually-prebuilt binary

      Don't forget to kldload netlink first, the Netlink support is not active by default!

      posted in Development
      yannY
      yann
    • RE: Xen Orchestra netbox sync error

      @sb2014 this address reporting looks buggy, can you please share some guest information (OS type and version, guest agent version reported by XO)?

      posted in Advanced features
      yannY
      yann
    • RE: After installing updates: 0 bytes free, Control domain memory = 0B

      @Dataslak can you please request a commandline from GRUB (hit c on the boot menu), and issue the following commands:

      echo $root
      search --label --set root root-eqjpzg
      echo $root
      
      posted in XCP-ng
      yannY
      yann
    • RE: Guest running kernel 6.8 hangs after a while

      Raised this on IRC, resulting in:

      I'll see what I can do, we may still have some time to include this before the release

      I guess that's pretty much all we can do on our side (and that's nice from them 😉 ).

      posted in XCP-ng
      yannY
      yann
    • RE: Guest running kernel 6.8 hangs after a while

      Catching up with the subject...

      The good news first: the patch is already in the 6.8 stable branch (as c8b7b2f158d9d4fb89cd2f68244af154f7549bb4), and part of v6.8.5.

      The Ubuntu situation is:

      • master kernel branch OTOH has been at v6.8.4 for 12 days, with only minor packaging adjustments since then
      • latest tag on master is 6.8.0-25 (only used for lowlatency kernel as of today), based on v6.8.1
      • they also have a 6.8.0-26 and changelog entries for -27 on master-next (all about s390)
      • standard kernel at 6.8.0-22, based on v6.8.1 too

      I'm not familiar with their internal processes, but I suspect they're probably in a validation cycle for upcoming upcoming version right now, and any such fix would have to wait for next one.

      The tracker ticket for 6.8.0-27 seems to imply -27 packaging is "in progress". Still digging...

      posted in XCP-ng
      yannY
      yann
    • RE: XCP-ng 8.3 betas and RCs feedback 🚀

      @Tristis-Oris and with a 3-host pool I can reproduce you issue on 2nd attempt: new master loses its xapi process

      When the master is changed, the xapi service is stopped and then restarted but something seems to get wrong this time.

      Among issues I realize that my former-master shows this at the time of the failing switch:

      Oct 14 15:20:50 xcpng83-bzkcpvhy xsh: [ warn||0 ||xsh] TLS verification is disabled on this host: /var/xapi/verify-certificates is absent
      

      (while both other hosts do have that file)

      daemon.log on new-master shows systemd desperately trying to restart xapi:

      Oct 14 15:20:59 xcp-ng-hqerhcgv xapi-init[1244028]: Stopping xapi: [  OK  ]
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Unit xapi.service entered failed state.
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: xapi.service failed.
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: xapi.service holdoff time over, scheduling restart.
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Cannot add dependency job for unit lvm2-activation.service, ignoring: Unit is masked.
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Cannot add dependency job for unit lvm2-activation-early.service, ignoring: Unit is masked.
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Starting XenAPI server (XAPI)...
      Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Started XenAPI server (XAPI).
      Oct 14 15:20:59 xcp-ng-hqerhcgv xapi-init[1244047]: Starting xapi:
      Oct 14 15:21:00 xcp-ng-hqerhcgv systemd[1]: xapi.service: main process exited, code=exited, status=2/INVALIDARGUMENT
      Oct 14 15:21:00 xcp-ng-hqerhcgv xapi-init[1244078]: Stopping xapi: [  OK  ]
      

      and xensource.log is very similar to yours. Congrats, that's a nice bug 🙂

      posted in News
      yannY
      yann
    • RE: XCP-ng 8.3 betas and RCs feedback 🚀

      @Tristis-Oris Oh OK. Had a try to run it several times myself (though on a 2-host pool), and I was able to see the operation performed twice, though apparently the second op did finish.
      Running from the shell, if launch a second xe pool-designate-new-master while the first has not returned yet, it gets a DESIGNATE_NEW_MASTER_IN_PROGRESS error, but once it has returned there seem to be a window to do strange things.

      posted in News
      yannY
      yann
    • RE: Access historical CPU and memory metrics - Xen Orchestra v5

      @puneet336 you need to make your connection to your pool master (not your XOA guest), that's where the XAPI endpoint is.

      If you did not deploy TLS certificates on your pool, XenAPI.Session(URL) will complain that the SSL certificate is self-signed (which you can workaround by adding ignore_ssl=True as you did above, but don't keep this in production).

      You will also find a few guidelines to write a robust XenAPI client at https://xapi-project.github.io/xen-api/usage.html

      posted in REST API
      yannY
      yann
    • RE: Access historical CPU and memory metrics - Xen Orchestra v5

      @puneet336 @olivierlambert the lib is still working, but I'm usually use it with a local connection, running scripts inside dom0, with this code:

      def get_xapi_session():
          session = XenAPI.xapi_local()
          try:
              session.xenapi.login_with_password('root', '', '', 'xcp-ng-tests session')
          except Exception as e:
              raise Exception('Cannot get XAPI session: {{}}'.format(e))
          return session
      

      Will check what happens with a remote session.

      posted in REST API
      yannY
      yann

    Latest posts made by yann

    • RE: New Rust Xen guest tools

      @john.c OK, that will be useful when the repo is signed, but for now I don't see what adverse effect it can have. Do I miss something?

      Also we try to avoid breaking support for older OS versions, so we'll likely continue to advertise the old format for older versions of Debian.

      posted in Development
      yannY
      yann
    • RE: New Rust Xen guest tools

      @flakpyro the old format is still supported, and actually the [trusted=yes] in the old-style configuration shown in the release notes does work in my quick test with our own Debian 13 hub template.

      posted in Development
      yannY
      yann
    • RE: New Rust Xen guest tools

      @olivierlambert updating the README will be quick enough... but if the sig is indeed mandatory we need to setup something for this first... and autosigning from a CI rather requires doing that on a trusted runner rather than on gitlab-provided ones, so that requires some provisioning and IT work first.

      posted in Development
      yannY
      yann
    • RE: New Rust Xen guest tools

      @olivierlambert yes, and that's a known issue. The protocol used to communicate with XAPI only allows to report info for VIFs (and SR/IOV, with support coming with in a PR). We can likely implement something by querying the status of bridge devices and listening to their changes like we do for the VIFs, and report those for the VIFs that are part of bridges - but it's a bit more than just "parsing br0" 😉 .

      Opened https://gitlab.com/xen-project/xen-guest-agent/-/issues/24

      posted in Development
      yannY
      yann
    • RE: New Rust Xen guest tools

      @David_5.1 a new issue would be better. Thanks fo your feedback!

      posted in Development
      yannY
      yann
    • RE: Memory reporting incorrect values

      @fred974 there is an undeclared conflict between the xe-guest-utilities in the ISO and xenstore-utils, you can install the former after removing the latter (but yes, it is a problem, the Go implementation of xenstore tools should not be in this package).

      posted in Compute
      yannY
      yann
    • RE: New Rust Xen guest tools

      @dClauzel since Debian has switched away from sysvinit we did not take the time to provide an init.d script, but if there is a need, we can include one. Feel free to open an issue (or, even better, a merge request 😉) on the project in Gitlab!

      Thanks for your feedback!

      posted in Development
      yannY
      yann
    • RE: Memory reporting incorrect values

      @fred974 v6.80.6 is definitely very old, and did report MemFree, we ship v7.30 with XCP-ng 8.2. You will likely want to update it, from the "XCP-ng tools" SR.

      posted in Compute
      yannY
      yann
    • RE: Memory reporting incorrect values

      @fred974 right, it is reporting MemFree here.

      What does xenstore ls attr/PVAddons show for this VM? And which kernel version is it using?

      Old xe-guest-utilities before v7.30 indeed reported MemFree, which XenServer then improved in v8.4 to still report something for kernels older than 3.14 which did not have MemAvailable yet, but Ubuntu 22.04 ships a decently-recent kernel, so I suspect it would be rather due to an old xe-guest-utilities.

      posted in Compute
      yannY
      yann
    • RE: Memory reporting incorrect values

      @fred974 the tools should be reporting the value from MemAvailable, so buffer/cache should not be considered as in-use. What do you see (reported by the agent) in xenstore ?

      From within the guest:

      # xenstore ls data
      meminfo_free = "324060"
      meminfo_total = "973736"
      os_distro = "Debian"
      os_name = "Debian 11"
      os_uname = "5.10.0-21-amd64"
      updated = "1"
      

      The meminfo_free should match what you see in /proc/meminfo.

      posted in Compute
      yannY
      yann