Yep, blank name for the virtual machine.
More information:
Call storageresourcemanager.configurestoragedrsforpod blah blah
(didn't write it all down)
I did once get the above ^ permission error and then this message:
The guest os id is not valid. Therefore, editing these vm settings is not recommended.
What was I doing?
Cloned a virtual machine and then tried to make any changes to the settings (I tried changing the port group and adding/removing a vCD iso). Saying OK to commit the changes brings up that permission error.
I looked up the Storage Resource Manager parts in the API docs and there are no associated privileges: Drink Me
Similar calls need System.View priv set (which this user holds).
Here's the way I've currently been able to get rid of the error: I removed the associated datastores from the datastore clusters (moved it to the parent folder) and now I can't recreate the problem. I moved the datastores back under the datastore clusters (without otherwise making changes) and still no error message.
Sounds like a bug with storage DRS to me... I'll wait to see if it shows back up.
Got this again today. No time to do further diag, the sysadmin needed it to work.
ReplyDeleteHere's what I think is going on: SDRS / Datastore Clusters can't work with isos or other non-VM objects that live in datastores. No automatic storage vmotion for isos. So datastores that hold non-VM objects should probably not be put into a datastore cluster.
DeleteStill totally a guess, but that's why they pay me the big bucks, right?
Not a bug, just a stupid error message.
I'm also getting this - full error is:
ReplyDeleteCall "StorageResourceManager.ConfigureStorageDrsForPod" for object "StorageResourceManager" on vCenter Server "" failed.
This is whilst trying to attach a ISO imagine onto a VM. The datastore the ISO image is on is not part of a storage DRS cluster, but the VMs primary store is. If I move the datastore the VM is on out of the cluster, add the ISO to the VM, and move the datastore back, it's ok!
Seems like a bug to me.
Hey hey! Finally listed as a bug and fixed in 5.1u1. About bloody time.
ReplyDeleteHas there been any fix for vCenter 5.0? We are dealing with this now and our users are less then pleased. We tried removing the datastores from sDRS and re-adding them, but the bug remains.
ReplyDelete*If* VMware will fix it in 5.0, it will probably be in the next major patch for vCenter. I don't remember seeing it in the last release notes for 5.0 and we're not using sDRS right now...so I can't verify if we would have the bug still in my prod.
ReplyDeleteSorry, wish I had a better answer for you. :(
I have installed Update 1 and all the latest patches and we are still having this issue. I will open a case with vmware and update if I find anything out. Removing datastore clustering resolves the issue.
ReplyDeleteThanks for the tip Anonymous. That sucks, but thanks for the update.
DeleteSo... I have a case open with support. They indicated that Engineering had closed out this bug with the release of 5.1 Update 1. They are re-opening this again. I will update everyone as I hear more. Now this is strictly related to 5.1 Update 1. I have not tested 5.0 Update 2 to see if it is truly resolved in that release or not. My guess is if it still show up in 5.1, it probably will in 5.0 as well.
ReplyDeleteI have noticed that it is extremnely interittent now. Most of the time it works but on occassion the usgle System --> Read permission error pops up. Nothing new from vMware on this yet. Our logs have been uploaded for review.
ReplyDeleteQuick update. It looks like we have a special use case that is causing the issue. Most of you may not even run into this. We have 4 or 5 VMs that we do not want out client to even see in vCenter. We have them in a nester resource pool (we tried vApp and got the same results) and a separate folder under VMs and Templates. The issue only shows up if you deny access to the Non Admin group to both the resource pool (or vApp) AND the folder under VMs and Templates. If you select deny on either one and Read Only on the other, the issue does not show up. We have passed this info on to vMware and are awaiting a response. If you are not doing anything like this, chances are the issue will be fixed for you with 5.1 Update 1 or 1a.
ReplyDeleteAnother update for everyone. Turns out our issue was with the vCenter thick client. Update 1 for vSphere 5.1 does not automatically update the vCenter client. Once you update to the latest client, the issue is resolved. For 5.1 Update 1, the correct version to use should be 5.1.0.1064113 or later. Sorry for the confusion.
ReplyDeleteYou rock. Thanks for updating us with the solution!
Delete5.0 u3 vSphere Client also looks to have this fix now. Huzzah! https://www.vmware.com/support/vsphere5/doc/vsp_vc50_u3_rel_notes.html
ReplyDelete