Empty Performance Graphs

[borzel]

Performance Graphs shown:
unbranded XCP-ng Console <-> XenServer 7.2

Performance Graphs not shown:
unbrandet XCP-ng Console <-> XCP-ng 7.4.0
brandet XCP-ng Console <-> XCP-ng 7.4.0

@olivierlambert @johnelse Maybe there was a change/hack related to Performance Data in XCP-ng 7.4.0?

[cocoon]

Just as a note, I modified the official XenCenter to be able to connect to XCP-NG 7.4.1 (I already installed manually the rpm) and I see performance Graphs with it.

[olivierlambert]

So it's likely to be a modified XenCenter issue than XCP-ng. We don't see any perfs issues fetching with XO.

[cocoon]

Yes there seem to be some differences still.
Interesting: The One Day Zoom and One Week Zoom shows data for me.

And if you double click into a graph or want to create a new one there is no DataSource in the list.

[borzel]

Maybe my build environment is not optimal... will try today with the updated instructions here from @cocoon

[cocoon]

I see some Json exceptions if I double click a graph where it should display the DataSources:

Exception thrown: 'Newtonsoft.Json.JsonReaderException' in Newtonsoft.Json.dll
Error parsing -Infinity value. Path 'result[25].min', line 1, position 5259.

[cocoon]

OK so the official Xen Center 7.4.0 must be based on a much older code base, maybe around september 2017, I think we are way ahead with an unstable code base where alot of json stuff was added.

Maybe we should do some tests with an older code base + the same for the dotnet-packages like this:
https://github.com/xenserver/xenadmin/commits/release/falcon/UPD-146
https://github.com/borzel/dotnet-packages/tree/release/falcon/lcm

[cocoon]

Is working in the mentioned release.
I did not rebrand it, just some quick hacks:
-added XCP-NG to FriendlyNames
-hard coded server_min = 18; into this line (because min + max = 99 and current is 18):
https://github.com/xenserver/xenadmin/blob/release/falcon/UPD-146/XenAdmin/MainWindow.cs#L892

            // When releasing a new version of the server, we should set xencenter_min and xencenter_max on the server
            // as follows:
            //
            // xencenter_min should be the lowest version of XenCenter we want the new server to work with. In the
            // (common) case that we want to force the user to upgrade XenCenter when they upgrade the server,
            // xencenter_min should equal the current version of XenCenter.  // if (server_min > current_version)
            //
            // xencenter_max should always equal the current version of XenCenter. This ensures that even if they are
            // not required to upgrade, we at least warn them.  // else if (server_max > current_version)

            int server_min = master.XenCenterMin;
            int server_max = master.XenCenterMax;

            server_min = 18;

            if (server_min > 0 && server_max > 0)

[borzel]

cool ... i thought the same thing today in the morning...

[borzel]

I tried to decode the Citrix Release Codenames

[borzel]

Resolved with #15