XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    New Rust Xen guest tools

    Scheduled Pinned Locked Moved Development
    152 Posts 38 Posters 90.4k Views 35 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • yannY Offline
      yann Vates πŸͺ XCP-ng Team @kevdog
      last edited by

      @kevdog great news, looking forward for this PKGBUILD!
      Wouldn't it make sense to build from release packages rather than from Git?

      The CI scripts should give you some guidance. For dependencies you should have a list at https://gitlab.com/xen-project/xen-guest-agent#build-requirements. Not sure why you would want python-setuptools?

      J D 2 Replies Last reply Reply Quote 0
      • J Offline
        john.c @yann
        last edited by john.c

        @yann said in New Rust Xen guest tools:

        @kevdog great news, looking forward for this PKGBUILD!
        Wouldn't it make sense to build from release packages rather than from Git?

        The CI scripts should give you some guidance. For dependencies you should have a list at https://gitlab.com/xen-project/xen-guest-agent#build-requirements. Not sure why you would want python-setuptools?

        The Arch Linux distribution is a rolling release! The release packages appear to be for stable non-rolling release based software distributions.

        So if kevdog were to create the PKGBUILD based on release packages, then how well will they handle the rolling release Arch Linux?

        yannY 1 Reply Last reply Reply Quote 0
        • yannY Offline
          yann Vates πŸͺ XCP-ng Team @john.c
          last edited by

          @john-c a rolling-release distro does not have to follow every commit of each software component, that would be a bit extreme πŸ™‚ They are rather about providing users with latest component releases as they are published.

          1 Reply Last reply Reply Quote 0
          • mhomokyM Offline
            mhomoky @olivierlambert
            last edited by

            @olivierlambert / @Sam According to the Gitlab docs the project URI needs to be in URL encoded format, resulting in a working line as below in my own cloud-init:

                  deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project\%252Fxen-guest-agent/packages/generic/deb-amd64/ release/
            

            I found this through experimentation, but weirdly it seems to be a double-URL encoded string at that point in the URI for Gitlab… go figure.

            I have another escape related question though. I'm not sure if it's your YAML parser or my editor but if I attempt to use the % as found in the beginning of the documentation example, neovim no longer recognises the file as YAML. So this:

            #cloud-config
            hostname: {name}
            fqdn: {name}%.my-domain.com
            

            from line 3 onwards doesn't work correctly, despite being valid YAML 1.2.2.

            Again to get this working, I had to surround the value with single quotes:

            #cloud-config
            hostname: '{name}%'
            fqdn: '{name}%.my-domain.com'
            

            Which library / version of YAML are you targeting?

            Also, is the UUID or mac address of a VM exposed to the cloud-init parser internally (or is there a list somewhere of other variables like {name} that are?).

            Thanks for a great product and I hope this helps someone πŸ™‚

            S 1 Reply Last reply Reply Quote 0
            • olivierlambertO Offline
              olivierlambert Vates πŸͺ Co-Founder CEO
              last edited by

              Hi @mhomoky I think it's unrelated to the topic, that would be better to create a new thread I think.

              1 Reply Last reply Reply Quote 0
              • S Offline
                Sam @mhomoky
                last edited by

                @mhomoky Thanks, worked perfectly fine.

                deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project\%252Fxen-guest-agent/packages/generic/deb-amd64/ release/
                

                No issues in Cloud-config

                Also for hostname, I just used {name}without any %

                The only thing missing is being able to reapply cloud-init configs or easy reconfigure from the Ui. But that's for another topic.

                1 Reply Last reply Reply Quote 0
                • dClauzelD Offline
                  dClauzel @olivierlambert
                  last edited by

                  @olivierlambert I tried it in Debian 12.8/stable with sysvinit as init (and not systemd).

                  The package was installed without problem, but the agent is not started.

                  When run manually via sudo /usr/sbin/xen-guest-agent, the agent is then correctly detected by the dom0.

                  So it means no dependencies on systemd (which is good :), and only an init script in /etc/init.d/ is required for having full support.

                  yannY 1 Reply Last reply Reply Quote 0
                  • yannY Offline
                    yann Vates πŸͺ XCP-ng Team @dClauzel
                    last edited by

                    @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!

                    dClauzelD 1 Reply Last reply Reply Quote 1
                    • dClauzelD Offline
                      dClauzel @yann
                      last edited by

                      @yann Thanks for the fast reply ❀

                      Ok, I am opening a ticket, and providing a simple support script.

                      1 Reply Last reply Reply Quote 1
                      • D Offline
                        David_5.1
                        last edited by David_5.1

                        Hello,

                        I have a setup with routers (running Debian Bookworm) that need more interfaces than the maximum allowed number of vifs so the VM has one vif and VLAN untagging is done inside it.
                        As no IPs were detected by the traditional xen tools, I switched to the new, Rust ones, but they fail to detect IPs too πŸ˜•

                        I think it is caused by the lack of /sys/class/net/enX0.*/device/devtype files, despite a few enX0.* interfaces (and folders) and /sys/class/net/enX0/device/devtype (containing vif, as expected) exist.

                        Should I create an issue directly in the Gitlab project, or comment the partially-related one for SR-IOV support?

                        yannY 1 Reply Last reply Reply Quote 0
                        • yannY Offline
                          yann Vates πŸͺ XCP-ng Team @David_5.1
                          last edited by

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

                          D 1 Reply Last reply Reply Quote 0
                          • D Offline
                            David_5.1 @yann
                            last edited by

                            @yann here you are : https://gitlab.com/xen-project/xen-guest-agent/-/issues/22

                            1 Reply Last reply Reply Quote 2
                            • D Offline
                              Dillweed @yann
                              last edited by

                              @kevdog @yann said in New Rust Xen guest tools:

                              @kevdog great news, looking forward for this PKGBUILD!
                              Wouldn't it make sense to build from release packages rather than from Git?

                              The CI scripts should give you some guidance. For dependencies you should have a list at https://gitlab.com/xen-project/xen-guest-agent#build-requirements. Not sure why you would want python-setuptools?

                              Hey all, I put together PKGBUILD for Arch which pulls the latest git. It seems to be working fine for me. You'll need to install xen package on AUR.
                              https://aur.archlinux.org/packages/xen-guest-agent-git

                              It's my first attempt at submitting something on AUR. I look forward to any feedback.

                              1 Reply Last reply Reply Quote 3
                              • A Online
                                Andrew Top contributor @olivierlambert
                                last edited by

                                @olivierlambert No IP record... Using Debian 11 with Management agent 1.0.0-proto-0.4.0. It's a non-standard interface setup with the IPv4/IPv6 assigned to the bridge interface. The agent does not report any addresses up to XO.

                                1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
                                    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
                                    inet 127.0.0.1/8 scope host lo
                                       valid_lft forever preferred_lft forever
                                    inet6 ::1/128 scope host
                                       valid_lft forever preferred_lft forever
                                2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
                                    link/ether 32:a9:24:28:18:56 brd ff:ff:ff:ff:ff:ff
                                3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
                                    link/ether 52:31:46:59:66:a1 brd ff:ff:ff:ff:ff:ff
                                    inet 192.168.1.33/24 brd 192.168.1.255 scope global br0
                                       valid_lft forever preferred_lft forever
                                    inet6 2000::5031:46ff:fe59:66a1/64 scope global dynamic mngtmpaddr
                                       valid_lft 2591833sec preferred_lft 604633sec
                                    inet6 fe80::5031:46ff:fe59:66a1/64 scope link
                                       valid_lft forever preferred_lft forever
                                
                                1 Reply Last reply Reply Quote 0
                                • olivierlambertO Offline
                                  olivierlambert Vates πŸͺ Co-Founder CEO
                                  last edited by

                                  Likely because br0 isn't parsed. Pinging @yann and @TeddyAstie

                                  yannY 1 Reply Last reply Reply Quote 0
                                  • yannY Offline
                                    yann Vates πŸͺ XCP-ng Team @olivierlambert
                                    last edited by yann

                                    @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

                                    F 1 Reply Last reply Reply Quote 0
                                    • F Offline
                                      flakpyro @yann
                                      last edited by flakpyro

                                      With the release of Debian 13 apt now complains that the repo is not signed. Also Debain has changed to using .sources files for repos.

                                      For example,, the new format would be:

                                      Types: deb
                                      URIs: https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/
                                      Suites: release/
                                      Components: 
                                      Signed-By: https://path/to/release.gpg
                                      Trusted: yes
                                      
                                      

                                      Maybe worth addding a release.gpg to the repo and updating documentation when configuring the repo on newer Debian / Ubuntu releases?

                                      Example of the error when no key is present:

                                      Ign:8 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 release/ InRelease
                                      Hit:9 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 release/ Release
                                      Ign:10 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 release/ Release.gpg
                                      Fetched 176 kB in 1s (154 kB/s)
                                      All packages are up to date.    
                                      Notice: Missing Signed-By in the sources.list(5) entry for 'https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64'
                                      
                                      
                                      1 Reply Last reply Reply Quote 0
                                      • olivierlambertO Offline
                                        olivierlambert Vates πŸͺ Co-Founder CEO
                                        last edited by

                                        @yann can you update the README accordingly?

                                        yannY 1 Reply Last reply Reply Quote 0
                                        • yannY Offline
                                          yann Vates πŸͺ XCP-ng Team @olivierlambert
                                          last edited by

                                          @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.

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post