Solved

X-Ray 3.1 - VXRail tests with internal VCenter


Badge
All,

I noticed that the X-Ray tests do the power on hardware as one of the first steps. Can the power on steps be bypassed some how within the scenarios? My particular platform that I am using has the embedded VCenter (POC hardware), so X-Ray times out trying to connect to the VCenter when you have the entire cluster powered down. I don't believe I can link these hosts to an external VCenter right now, due to the VSAN and dVS configurations.

I'm kind of stuck with a chicken-and-egg scenario here.
icon

Best answer by BlakeRobertsNBL 2 October 2018, 17:39

I found a workaround that is managing this issue. I'm using custom scenarios now and changed the YAML code from "- cluster.Cleanup: {}" to "- cluster.PowerOffCureVMs: {}" and "- cluster.DeleteCurieVMs: {}" in the teardown phase. This has gotten X-Ray to work properly on the different targets.

View original

7 replies

Userlevel 2
Badge +10
I'm a little confused - if the entire cluster is powered down is anything online before you try and run the scenario? X-Ray will attempt to power on nodes that are part of the cluster that under test to ensure that the test can run, and as part of that it will work with vCenter to ensure they come online. You can power on the cluster ahead of time and ensure that vCenter is available before running the scenario...

The cluster that is in vSphere should be the same cluster that you intend to test and is registered as a target within X-Ray. No extra nodes, no fewer nodes in the vSphere cluster or the X-Ray target configuration.

Is this for a particular platform? Which scenario?
Badge
I have tried to leave the cluster powered on, but X-Ray 3.1 fails the prechecks saying that the cluster is powered on. Would this be something that I would have to edit the YAML file to skip the power on steps?

This is a VXRail platform, so it's particularly obnoxious by design.
Userlevel 2
Badge +10
No scenario should fail with the cluster and vcenter powered on already. X-Ray will only try to power on if something is powered off (like from a previous scenario failure or something), so this is very strange.

Can you share any of the logs or screenshots to help orient me some more?
Badge
Will do when I get to that point. I've customized a scenario that skips the "cluster.CleanUp: {}" YAML entry during setup. If this errors out when it hits it at teardown, I will screenshot and send it in.

Ideally, if I can find where the cluster.CleanUp steps are and remove the power on, that would solve all of those issues.
Userlevel 2
Badge +10
Since the backend of X-Ray is open source (curie) you can take a look what's happening here: https://gitlab.com/nutanix/curie/blob/master/curie/steps/cluster.py#L10

If you add the target without IPMI, you might be able to skip power ops as well, but you won't be able to do any of the node failure/rolling-upgrade scenarios.
Badge
I'll take a look at the cluster python code. My custom scenario bypassed the power-on, so I was able to successfully run the scenario until the teardown phase. Here was the error in the log:


code:
Error log: invalid literal for int() with base 10: 'JfgHNnAiERSJEnf4'

That value is definitely NOT an integer!
Badge
I found a workaround that is managing this issue. I'm using custom scenarios now and changed the YAML code from "- cluster.Cleanup: {}" to "- cluster.PowerOffCureVMs: {}" and "- cluster.DeleteCurieVMs: {}" in the teardown phase. This has gotten X-Ray to work properly on the different targets.

Reply