@stormi
It seems to be good here!

PS: i'm using these 2 scripts to list all interfaces drivers version accross our servers :

$ cat get_network_drivers_info.sh
#!/bin/bash                                                                                                                                                                                                                                                                                                   

format="| %-13.13s | %-20.20s | %-20.20s | %-10.10s | %-7.7s | %-10.10s | %-30.30s | %-s \n"
printf "${format}" "date" "hostname" "OS" "interface" "driver" "version" "firmware" "yum"
printf "${format}" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------"

if [ $# -gt 0 ]; then
    servers=($(echo ${BASH_ARGV[*]}))
else
    servers=($(cat host.json | jq -r '.[] | .address' | egrep -v "^192.168.124.9$"))
fi

for line in ${servers[@]}; do
    scp get_network_drivers_info.sh.tpl ${line}:/tmp/get_network_drivers_info.sh  > /dev/null 2>&1;
    ssh -n ${line} bash /tmp/get_network_drivers_info.sh 2> /dev/null;
    if [ $? -ne 0 ]; then
        echo "${line} fail" >&2
    fi
done

$ cat get_network_drivers_info.sh.tpl
#!/bin/bash                                                                                                                                                                                                                                                                                                   

format="| %-13.13s | %-20.20s | %-20.20s | %-10.10s | %-7.7s | %-10.10s | %-30.30s | %-s \n"
d=$(date '+%Y%m%d-%H%M')
name=$(hostname)
cd  /sys/class/net/
for interface in $(ls -l /sys/class/net/ | awk '/\/pci/ {print $9}'); do
    version=$(ethtool -i ${interface} | awk '/^version:/ {$1=""; print}')
    firmware=$(ethtool -i ${interface} | awk '/^firmware-version:/ {$1=""; print}')
    driver=$(ethtool -i ${interface} | awk '/^driver:/ {$1=""; print}')
    YUM=$(which yum)
    if [ $? -eq 0 ]; then
        packages=$(yum list installed | awk '/ixgbe/ {print $1"@"$2}' | tr '\n' ',')
    else
        packages="NA"
    fi
    os_version=$(lsb_release -d | awk '{$1=""} 1' | sed 's/XenServer/XS/; s/ (xenenterprise)//; s/release //')
    printf "${format}" "${d}" "${name}" "${os_version}" "${interface}" "${driver}" "${version}" "${firmware}" "${packages}"
done

PS: host.json file is generated via : xo-cli --list-objects type=host

@stormi Hello, some week after, I can confirm that the problem is solved here by using intel-ixgbe.x86_64@5.5.2-2.1.xcpng8.1 or intel-ixgbe.x86_64@5.5.2-2.1.xcpng8.2

@stormi I have installed intel-ixgbe 5.5.2-2.1.xcpng8.2 on my server s0267. Let's wait a some days to check if the memleak is solved by this patch.

@stormi

The 2 servers have been reinstalled with an up to date 8.2. They host each 2 VMs that are doing the same thing (~100Mb/s of netdata stream).

The right one has the 5.9.4-1.xcpng8.2, the left one has 5.5.2-2.xcpng8.2.

The patch seem to be OK for me.

@stormi

• server 266 with alt-kernel: still no problem.
  

• server 268 with 4.19.19-6.0.10.1.xcpng8.1: the problem has begun some days ago after some stable days.
  

• server 272 with 4.19.19-6.0.11.1.0.1.patch53disabled.xcpng8.1:
  )

• server 273 with 4.19.19-6.0.11.1.0.1.patch62disabled.xcpng8.1:
  

It seems that 4.19.19-6.0.11.1.0.1.patch62disabled.xcpng8.1 is more stable than 4.19.19-6.0.11.1.0.1.patch53disabled.xcpng8.1. But it is a but early to be sure.

@stormi For the kernel-4.19.19-6.0.10.1.xcpng8.1 test, i'm not sure it solve the problem because I get a small memory increase. We have to wait a bit more

@stormi I have installed the two kernels

272 ~]# yum list installed kernel | grep kernel
kernel.x86_64                   4.19.19-6.0.11.1.0.1.patch53disabled.xcpng8.1

273 ~]# yum list installed kernel | grep kernel
kernel.x86_64                   4.19.19-6.0.11.1.0.1.patch62disabled.xcpng8.1

I have removed the modification in /etc/modprobe.d/dist.conf on server 273.

We have to wait a little bit now

@stormi @r1
Four days later, I get:

• one server (266) with alt-kernel: still no problem
• one server (268) with 4.19.19-6.0.10.1.xcpng8.1: no more problem!
• one server (272) with kmemleak kernel: no memleak detected, but the problem is present
• one server (273) with search extra built-in weak-updates override updates: problem still present

@danp Thank you. I have downgraded one server.

@stormi So i have :

• one server with 4.19.19-6.0.10.1.xcpng8.1
• one server with kmemleak kernel
• one server with search extra built-in weak-updates override updates

@tcorp8310 for information you can use the xe template-export template-uuid= filename= command to export a template into a file.

@olivierlambert I have the same problem, it is even not 2s.
Firefox 106.0.5 on macOS.

PS: it never worked well for me (ie it is not related to the latest XO versions).

@olivierlambert said in REST API:

For the last point, I invite you stay tuned being read carefully each XO release blog post. It's available in XO 5.72 since last June, see https://xen-orchestra.com/blog/xen-orchestra-5-72/#-rest-api-token-generation

I forgot it or miss it
Thank you!

@olivierlambert said in REST API:

However, there's a big gap with POST actions (doing "actions" in short). Since almost all operations are async, like disk or VM creation, REST needs to be tuned for that. I would say it's the "hard" part in REST vs a connected API like xo-cli with websockets and its persistent connection. We will probably use a "queue" system you can request to get the status of the task and the answer. Eg the UUID of the freshly created VM. All in all, it's more complex and can't be done quickly like adding "GET" actions

I hope you will find something that it is not too complicated to implement in your side!

@olivierlambert said in REST API:

Finally, the permissions IMHO are even more complex, we need to discuss that with @julien-f

Yes permissions are always a big thing.

@olivierlambert
For now, we are using the REST API to integrate information about VM into our ERP. We are tracking changes over time and are providing an up to date inventory to our customers.

Next step for us, would be able to create VM directly through the REST API (and not via xo-cli, or xe).
But on the security side, we will need to be able to restrict API users to some objects as the system must not be able to view/modify some objects (mostly do not be able to get/set info for some pools). Even further, we could imagine that each customer has 2 API KEY (one read, the other read/write) that will be restricted to the customer pool or customer VM.

To help people to use the REST API, it would be nice if xo-web can generate the API KEY.

Regards,

Hello,

We start using the REST API.
As I did not see evolution on it since some months, I would like to know what is the status and what are the plan of this API?

Today the most problematic part I have is the lack of rights in the API : the user must be an admin and have read/write access (even if for now the write access is quite limited as it is only "VDI Import"), and so have access to all ressources.

We are only using Collections for now to get VM list, and VM info (ram, disk, cpu), and so far so good

Regards,

PS: i'm using these 2 scripts to list all interfaces drivers version accross our servers :

$ cat get_network_drivers_info.sh
#!/bin/bash                                                                                                                                                                                                                                                                                                   

format="| %-13.13s | %-20.20s | %-20.20s | %-10.10s | %-7.7s | %-10.10s | %-30.30s | %-s \n"
printf "${format}" "date" "hostname" "OS" "interface" "driver" "version" "firmware" "yum"
printf "${format}" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------" "----------------------------"

if [ $# -gt 0 ]; then
    servers=($(echo ${BASH_ARGV[*]}))
else
    servers=($(cat host.json | jq -r '.[] | .address' | egrep -v "^192.168.124.9$"))
fi

for line in ${servers[@]}; do
    scp get_network_drivers_info.sh.tpl ${line}:/tmp/get_network_drivers_info.sh  > /dev/null 2>&1;
    ssh -n ${line} bash /tmp/get_network_drivers_info.sh 2> /dev/null;
    if [ $? -ne 0 ]; then
        echo "${line} fail" >&2
    fi
done

$ cat get_network_drivers_info.sh.tpl
#!/bin/bash                                                                                                                                                                                                                                                                                                   

format="| %-13.13s | %-20.20s | %-20.20s | %-10.10s | %-7.7s | %-10.10s | %-30.30s | %-s \n"
d=$(date '+%Y%m%d-%H%M')
name=$(hostname)
cd  /sys/class/net/
for interface in $(ls -l /sys/class/net/ | awk '/\/pci/ {print $9}'); do
    version=$(ethtool -i ${interface} | awk '/^version:/ {$1=""; print}')
    firmware=$(ethtool -i ${interface} | awk '/^firmware-version:/ {$1=""; print}')
    driver=$(ethtool -i ${interface} | awk '/^driver:/ {$1=""; print}')
    YUM=$(which yum)
    if [ $? -eq 0 ]; then
        packages=$(yum list installed | awk '/ixgbe/ {print $1"@"$2}' | tr '\n' ',')
    else
        packages="NA"
    fi
    os_version=$(lsb_release -d | awk '{$1=""} 1' | sed 's/XenServer/XS/; s/ (xenenterprise)//; s/release //')
    printf "${format}" "${d}" "${name}" "${os_version}" "${interface}" "${driver}" "${version}" "${firmware}" "${packages}"
done

PS: host.json file is generated via : xo-cli --list-objects type=host

@stormi Hello, some week after, I can confirm that the problem is solved here by using intel-ixgbe.x86_64@5.5.2-2.1.xcpng8.1 or intel-ixgbe.x86_64@5.5.2-2.1.xcpng8.2

@stormi oh I did not know that as I never use it: I only know that it exists

PS: we are not using the netdata config from "Advanced telemetry": we are installing our own netdata config.

@jcastang we are using a netdata/prometheus/grafana stack.

@olivierlambert you can change the retention method and keep much more data on netdata. There is also (since netdata 1.18 i think) a dbengine that allows you to store data on disk.