after update to 7.2, findAllForType not working with filter

[FreddyFredFred]

I just updated from 6.0.4 to 7.2 (targeting a venter 6.0 server). I also updated the vro plugin with the version found in the documents section here.

Basically when I run the code below it returns no results whereas before it found items. If I remove the xpath stuff it find a bunch of stuff.

var vDSList = Server.findAllForType("VC:DistributedVirtualPortgroup","xpath:name[starts-with(.,'"+networkToFindVds+"')]");

My hack wrong around (short of reverting) is to just pull null for the second parameter and then use a for loop to try and find what I need.

Is this a known issue?

[iiliev]

Just to clarify - when you said 'also updated the vro plugin' did you actually mean you updated the vCenter plug-in from build available at Technical preview of vRO vCenter plug-in for vSphere 6.5  ?

We actually have two vCenter plug-ins; one bundled with vRO up to (and including) version 7.2, and a new one that will be bundled with the upcoming vRO 7.3. The new one is also provided as a Technical Preview build in the link above.

As the new plug-in is a complete re-implementation, it is possible that the xpath support is not fully implemented yet. I'll double check with the developers working on the new plug-in tomorrow.

[FreddyFredFred]

Yes. the linked plugin is the one i updated to. I downloaded the .dar file from the appliance before updating so in theory I can just put it back if need be? (I'm preparing for a vCenter 6.5 update and I know getting the vco to show properly seems to need this version although I currently don't have the icon in vcenter 6 at the moment and don't know exactly why)

I also noticed that the vro seems to evaluate null differently. I currently have a check to see if somethig is >= "0" or <0 and it failed because null passed the >=0 check whereas befroe it would fail. Minor workaround required but just something different i noticed.

[FreddyFredFred]

And another change I noticed which is now broken is the following:

var foundVMs = VcPlugin.allSdkConnections[theIndex].searchIndex.findAllByUuid(null, vmUuid, true);

if (foundVMs==null)

    throw("no matching vm found for requested UUID");

else

{

    System.log("Found VM: "+foundVMs[0].name);

    return foundVMs[0];

}

before I was able to ctach my error and chek for the text (or pass it along in an email) but not it generates an error saying :

InternalError: (vmodl.fault.SystemError) {

   faultCause = null,

   faultMessage = null,

   reason = Missing non-optional return value

} (Dynamic Script Module name : getVmFromUuid#12)

Maybe I will need to rework my code?? ( now that I have a bit more experience with vRO compared to when I first did this stuff, it all looks horrible)

[iiliev]

Thanks, we'll look into this issue that generates system error.

BTW, both the old and the new vCenter plug-ins support vCenter 6.5. If you want to solve the compatibility issues in Web Client UI, you need to update a different plug-in - the one that is hosted inside the Web Client, which is not a vRO plug-in (dar/vmoapp file) but a WebClient plug-in. This plug-in is available at Technical Preview of Orchestrator plug-in for vSphere Web Client

[FreddyFredFred]

Since the web client plugin needs a change on the vcenter side of things, is the "hands off" fix of updating to 7.3 when it comes out and waiting for a 6.5U1 (for example)? Would I need to reregister the venter component perhaps?

Speaking of vcenter, I noticed the updated 7.2 is using legacy mode for authentication. I assume I can unregister and register against the PSC on my 6.0 vcenter ? (My psc is an external windows one at the moment)

[iiliev]

The system error thrown by SearchIndex.findAllByUuid() seems to be an issue with the new vCenter plug-in. I opened a bug to track it.

For the legacy vs PSC authentication - yes, you can unregister and then register against the PSC.

[FreddyFredFred]

Thanks for the update. The findAllByUuid bug isn't a show stopper for me at the moment so I can live with it.

For the problem with xpath and it not working with findAllForType, still looking into that one?

[iiliev]

For the issue with xpath, I contacted a colleague who works on the new vCenter plug-in, and he'll take a look.

[FreddyFredFred]

I'm considering reverting the vcenter plugin to the one I saved before I updated to avoid these issues I'm having (and some workflow elements feel slower than when I was on 6.0.4 but I don't know if it's the vcenter plugin or the 7.2 that caused slowness)

I think (???) the new vcenter plugin makes changes to workflows so can I reinstall the old plugin and will it overwrite any workflows with older version or am I stuck with the new plugin? (I still have my snapshot/db backup from before the vRO  upgrade a few days ago if I need to roll back to that and then redo the upgrade without the new vcenter plugin assuming it won't completely screw up vcenter because of hooks that have changed and I don't have a vcenter snapshot)

[FreddyFredFred]

Small update....

I ended up rolling back and updating again but left the default vcenter plugin that comes with vRO 7.2.

The xpath filter works with findAllForType()

For the other error with the exception about no return value, that is working properly too.

I also don't have constant freezing of the orchestrator client (maybe half the time I selected a workflow token and clicked the variables tab the program would freeze up)

As you correctly suggested the problem seems to be with the new plugin.

I still have one problem though:

Appliance is still in demo mode . When I try to change to vcenter mode for licensing, I get the following:

"Error! The specified license mode cannot be configured. Before licensing through vSphere, the Orchestrator should be registered to a configured vCenter Server instance."

However when I run the workflow "List the vCenter Orchestrator extensions on vCenter Server" I do see it as registered.

Reboot of vcenter required?? Unregister/register against the PSC instead of legacy mode?

[iiliev]

Using vSphere license provider requires vSphere authentication mode to be configured. SSO (legacy) authentication mode won't work.

So your options are:

If you want to keep SSO (legacy) authentication mode, you need to select Manual License provider and manually enter vCenter 6 serial key

If you configure vSphere authentication mode, you'll be able to choose between Manual License and vSphere License providers

[islavov]

Hi,

About the problems with the new plugin you mentioned:

- The code with findAllByUuid  is fine - just when the result array is empty the plugin is throwing an exception - this is already fixed and now we are returning null; you can find a build with the fix on the technical preview page - Technical preview of vRO vCenter plug-in for vSphere 6.5

- The usage of:

var vDSList = Server.findAllForType("VC:DistributedVirtualPortgroup","xpath:name[starts-with(.,'"+networkToFindVds+"')]");

fails because the new plugin because of the collection retrieve operator used "[]". The new plugin changes a little xpath handling. This is already fixed, it will work with this expression, and the fix is once again in the build mentioned above.

I am sorry to hear you have reverted to the the old plugin - the new plugin is completely new implementation of the plugin and we are targeting resolving of known execution and performance problems with the old plugin.

If you decide to install the new plugin again, we will be glad to help you with other issues you may encounter.

I have a question about 'freezes' you have encountered -  are these freezes of the whole smart client, or are these delays on visualizing of specific row in the  "Variables" value?

How long are these delays, and how often do you encounter them?

[FreddyFredFred]

Hi islavov,

Thanks for fixing those two issues. Now that you've fixed them I don't mind potentially trying again in the future but I'd like to have a stable setup first as a baseline. I had a few other issues which were also part of why I rolled back though and one new issue which just happened:

- The CPU started to go out of control. From the attached image, you an see it was steadily increasing until I rolled back on Saturday. On the realtime graph before I rolled back the CPU was spiking to 50% every few minutes.

I've been on 7.2 with the default vcenter plugin that comes with it for 3 days now and it's been ok except as I started to write this reply. You can see the spike at the far right side of the graph. Maybe you or Illian can tell me what log I can check to see what's causing the issue? If I login to the appliance via SSH and run top, I see java is using 90%+ cpu. It just happened suddenly and I don't know what may have triggered it.

- In my workflow I have a step that disables DRS on the VM I'm deploying. With that newest plugin it seems to get stuck on that step for about 1 minute whereas it normally takes only a second or two. I can include the code if you tell me how to get it formatted properly in a post so it's actually readable

- I was not able to see the vRO icon in the vcenter web client (6.0U2). Not sure if this was related to the cpu slowly going out of control (ie. whatever issue was causing the icon not to appear was also responsible for the cpu going out of control)

[FreddyFredFred]

I forgot to answer the freezing UI question, sorry.

The freeze seems to be of the entire client. I try clicking on something else but it doesn't respond. After about a minute I just kill the process (I'm running WIndows 7). Maybe if I waited longer it would recover but I have no patience

It seemed like it was roughly 50% of the time I would get the problem. I don't know the steps to reproduce it but it was easy enough to happen just by clicking around. Most of the time the error would occur when I clicked on the variables tab. Sometimes I would see "loading data..." instead of the values and sometimes I might see some data.