SimpliVity "forgetting" VSS credentials

[DCollette]

We recently replaced our 7-year old SimpliVity 380 Gen 10 system with a new SimpliVity 325 Gen 11 system and are experiencing a problem with it. We use SimpliVity VSS Application consistent backups on our SQL servers and every couple of weeks, the VSS Application backups start failing on several of our VMs. It's always due to the lack of administrative credentials necessary to perform a VSS backup. I always use the SimpliVity "Save Credentials for VSS" feature to save the VSS administrative credentials but every few weeks the credentials are lost on certain VMs.

When saving the VSS credentials, the dialog window states "HPE SimpliVity saves the credentials securely and only uses them to access VSS". Are these credentials stored with the VM or in the OmniStack or somewhere else? I don't recall having to keep re-entering the VSS credentials with our previous SimpliVity system.

Thanks,

Doug

[Joshua610]

Are these credentials stored with the VM or in the OmniStack or somewhere else?
"OmniStack stores the credentials securely and only uses them to access VSS."

Found within the HPE OmniStack 5.2.0 for vSphere Administration Guide
pg 84

[DCollette]

Thanks for answering the question on where the VSS credentials are stored. We just had another VM with a failed VSS backup because SimpliVity forgot the VSS credentials. This has happened to at least four different VMs, some multiple times. I wonder if it's a bug in OmniStack Ver. 5.1.3.8 which is a newer version that what we running on our previous SimpliVity system.

[Joshua610]

I can dig in that direction as well to see in the meantime if it is happening to just a selct few vms then possibly confirm their settings. I know via the OVC you have this option/command to run: 

svt-vm-backup-params-set --datastore datastore_name --vm vm_name--enable-vss --disable-vss--guestusername guest_username --guestpassword guest_password --override [common-options]

"Sets the backup parameters on a Windows virtual machine to either enable or disable Volume Shadow Copy Service (VSS) - based backups."

 Im heading in the direction to see if any bugs in that direction are being seen/noted. I will follow up in a day or so. 

[DCollette]

Thanks very much, Joshua. I've been setting the VSS credentials for each VM using the "Save credentials for VSS..." selection in the HPE SimpliVity Actions menu. It saves the credentials for several weeks but then the VSS backups start failing due to a lack of stored credential. So I save the credentials again and I'm good for another few weeks. Interestingly, it's not happening on all VMs using VSS, but it has happened on at least 4 so far.

Will the OVC command you sent do the same as the "Save credentials for VSS..." or is it at a higher level, i.e. more effective?

Thanks again,

Doug

[Joshua610]

Being via cli/OVC it may work better then using the GUI. Other then that it is more of a user preference; however, as I have worked with SimpliVity I have found things done via cli/OVC seem to be more "effective". 

I also prefer to work via cli which is my user preference. Give it a shot and let us know if via cli works better for you. 

if I recall correctly during the times of 3.7.x's and earlier some actions were recommended to be done via cli as opposed to GUI. 

[DCollette]

Thanks again, Joshua. I ran the command you sent for all of the VMs that we do VSS backups. The command completed successfully for all of the VMs except one. I've tried running the command multiple times on different OVCs and I always get the same error: ERROR [229]: Error performing guest operation. Interestingly, the VM that fails with the command has been doing VSS backups just fine with the credentials set through the GUI.

Any idea of what ERROR [229} means?

Thanks,

Doug

[Joshua610]

Within SimpliVity that usually means that the OVC failed to communicate with what I believe are the vmWare Tools running on that Vm. Usually caused by incorrect/invalid credentials (fat fingered or spaces) for the Gust OS. 

Consider confirming credentials (I know but always worth the 3rd or 4th check) and then checking the vmWare Tools. For further insight I'd need some logs from both sides to point fingers as you could imagine.