- RSS Channel Showcase 8774891
- RSS Channel Showcase 3204508
- RSS Channel Showcase 5280712
- RSS Channel Showcase 3446128
Articles on this Page
- 06/22/17--12:34: _vRO permissions - h...
- 06/22/17--12:38: _Upgrade Vcenter 5.5...
- 06/22/17--12:34: _Weird Get-TagAssign...
- 06/22/17--12:42: _Re: Horizon 7.1 Una...
- 06/22/17--12:42: _Re: Where can I dow...
- 06/22/17--12:48: _Re: HP DL380 Gen9(p...
- 06/22/17--12:57: _Re: Elasticsearch e...
- 06/22/17--13:09: _Re: Orphaned VM's, ...
- 06/22/17--13:11: _Re: Random logon de...
- 06/22/17--13:12: _Re: Weird Get-TagAs...
- 06/22/17--13:21: _Re: Qlogic HBA 2562...
- 06/22/17--13:30: _Re: Alarm managemen...
- 06/22/17--13:35: _Re: Changing a Virt...
- 06/22/17--13:36: _Re: Changing a Virt...
- 06/22/17--13:50: _Re: Horizon 7 Insta...
- 06/22/17--14:07: _Re: Changing a Virt...
- 06/22/17--14:11: _Re: Where can I dow...
- 06/22/17--14:12: _Re: New VROPS Rest ...
- 06/22/17--14:14: _Re: VROPs monitor I...
- 06/22/17--14:29: _Re: VSAN and shutti...
- 06/22/17--12:34: vRO permissions - hardening RBAC, Security
- 06/22/17--12:38: Upgrade Vcenter 5.5 to 6.5 with View composer as well
- 06/22/17--12:34: Weird Get-TagAssignment bug
- 06/22/17--12:42: Re: Where can I download Workstation 8 to run RH7.2 Enigma
- 06/22/17--12:48: Re: HP DL380 Gen9(p840ar) disks are not visible - ESXi 6.0 U2
- 06/22/17--12:57: Re: Elasticsearch error
- 06/22/17--13:09: Re: Orphaned VM's, getting the folder Size from path, VMX
- 06/22/17--13:11: Re: Random logon delay when using UEM
- 06/22/17--13:12: Re: Weird Get-TagAssignment bug
- 06/22/17--13:21: Re: Qlogic HBA 2562 showing different firmware version
- 06/22/17--13:30: Re: Alarm management with C# in .Net
- 06/22/17--13:35: Re: Changing a Virtual Machine's name
- 06/22/17--13:36: Re: Changing a Virtual Machine's name
- 06/22/17--14:07: Re: Changing a Virtual Machine's name
- 06/22/17--14:11: Re: Where can I download Workstation 8 to run RH7.2 Enigma
- 06/22/17--14:12: Re: New VROPS Rest Notification Plugin
- 06/22/17--14:14: Re: VROPs monitor IOP per vmdk
- 06/22/17--14:29: Re: VSAN and shutting down all hosts in a stack
1. vCenter Server instance is added in vRO using an administrator user account with full privileges (using the "Share a unique session" option while adding vCenter Server instance) on vCenter Server and full permissions in vRO.
2. The "vmuser" has fewer privileges e.g. the default "Virtual machine user (sample)” role on the vCenter Server and View, Inspect, Execute permissions in vRO.
The “vmuser” executes the vCenter Server workflow “Create simple virtual machine”.
The workflow execution completes successfully creating the specified virtual machine. However, the operations are executed in the context of the service account i.e. the administrator user account with full privileges used for adding the vCenter Server in vRO. Note that the “vmuser” has no permission to create a virtual machine and with execute permission in vRO the restricted user created a virtual machine.
Also observed that the Initiator reported in the Recent Tasks vs. More Tasks in vSphere Web Client are different.
What options are available if I want to execute the vRO workflow/operations in the context of the “vmuser” – the user that initiated the vRO Workflow instead of the service account used for adding the vCenter Server in vRO?
Appreciate your thoughts, suggestions, comments on this.
I think of few options:
1. Plug-in for vRO with Custom Workflows
2. Leverage vRO REST API retrieving vRO user, workflow/operation details and check against the vCenter Server privileges for the vRO user for allowing/disallowing the vRO workflow/operation.
Needing to upgrade a Vcenter 5.5 (installed on Windows Server) to 6.5. I would like to just upgrade the Vcenter in place. That part seems easy. This also has VMware View tied to it. Will this break? I have several 5.5 hosts that we are also migrating away from. I 3 new hosts with 6.5 installed, but as you know my current Vcenter will not manage them until the upgrade. Can I upgrade to 6.5 manage current 5.5 and 6.5 hosts, do the migration and then down the old hosts?
I've got two VCSAs at 6.5 build 5705665. When I run the following, I get the error noted below:
$VCTags = Get-TagAssignment -Server vcsa1.blah.local
Name Port User
---- ---- ----
vcsa1.blah.local 443 BLAH\user
vcsa2.blah.local 443 BLAH\user
Get-TagAssignment : 6/22/2017 1:55:51 PM Get-TagAssignment Sequence contains more than one matching element
At line:4 char:12
+ $VCBTags = Get-TagAssignment -Server vcsa1.blah.local
+ CategoryInfo : NotSpecified: (:) [Get-TagAssignment], CisException
+ FullyQualifiedErrorId : VMware.VimAutomation.ViCore.Impl.V1.Service.Tagging.Cis.TaggingServiceCisImpl.GetTagAssignment.Error,VMware.VimAutomation.ViCore.Cmdlets.C
I can disconnect from vcsa2 and run the Get-TagAssignment cmdlet successfully against vcsa1. The error only occurs when simultaneously connected to these two servers. I have one other 6.5 build 5705665 VCSA and any combination with it and the other two doesn't result in the error. I also have some 5.5 vCenters on Windows and can't reproduce the error with any combination of those and 6.5 servers.
I've reproduced from Windows Server 2012 R2 (PowerShell 4.0, PowerCLI 6.5R1) and Windows Server 2016 (PowerShell 5.1, PowerCLI 6.5.1).
Can anyone else reproduce this?
Message was edited by: dbailey12
Awesome! Happy to help and thanks for marking answered.
While you could try and install Workstation 8, perhaps just changing the virtual hardware of your old RH7.2 VM to an older compatibility level helps?
The virtual hardware might just contain parts that are too new for RH7.2 to be recognized. We're talking about an OS from 2001 after all.
Try virtual hardware version 6 or 7.
FWIW, on Workstation 12 you can change the virtual hardware version with the virtual machine shut down (not suspended) via:
- Right click on the VM in the library
- Manage -> Change Hardware compatibility
- You'll get a wizard
- From the drop down select "Workstation 6.5 - 7.x"
- Clone if you want to preserve the original VM, alter if you're OK with changing the VM itself
Quite puzzling that 'esxcli storage core path list' lists the devices, possibly the devices are disconnecting/detaching during boot?
Can you attach the boot log located here /var/log/boot.gz ?
Please check if these paths are active via the Web Client:
Host > Configure > Storage Adapters > Select the vSAN controller > Paths
-o- If you found this comment useful please click the 'Helpful' button and/or select as 'Answer' if you consider it so, please ask follow-up questions if you have any -o-
Has anyone come up with a good solution for this? The KB articles referenced did not help. It seems like a complete waste of time to have to restart servers until you get them up in the correct order. There has to be something that can be scripted differently.
I added some debugging lines in the 2nd part of the script (attached).
What does this show (i don't need all the output, just some representative loops through the 2nd part of the script).
Thanks for the additional info, JohnTwilley.
UEM isn't doing anything special w.r.t. accessing or locking files. It just asks Windows to enumerate files from a folder, read files, write files, etc, without doing anything special.
Do you also get the error when you add the Entity parameter, referring to one or more specific VIObjects?
here's the readme file for the current Firmware for QLE2562 HBA's.
The Firmware Version of your adapter is 7.04.00, latest available is 8.01.02.
Are we saying that the API does not provide the functionality?
Deepak, this is the Fusion forum - one of the hosted products, not ESXi.
You can rename the vmx filename without issues.
You'll just have to reregister the VM in the library again and remember to answer the question "did you copy or move the VM" with "Move" as copy will change the virtual hardware ID's and mess up things in your guest in this case.
As for the .vmdk filenames, leave them as is!
Yes they can be renamed if needed, but you have to use vmware-vdiskmanager to rename them, do NOT rename these in finder as your VM will stop working.
If however you insist on renaming them then:
First commit ALL snapshots.
use vmware-vdiskmanager -n as in:
vmware-vdiskmanager.exe -n sourceName.vmdk destinationName.vmdk
That keeps your vmdk intact, but that's not enough yet.
You will also have to edit your .vmx file by hand and adjust all occurences of the original vmdk name into the new name.
Oh and do take a backup before you do any of the above.
You could do so using the application Vimalin in my sig or by copying the whole bundle while the VM has been shut down. Vimalin OTOH can take a backup of the VM when it is running.
Hope this helps,
We had major issues with this until we upgraded everything to Horizon View 7.0.3 from 7.0.2. Now we don't see the issue except occasionally when we first create an instant clone pool. This is a replication timing issue which causes the serviceprincipalname attribute on the computer object in the AD to not be fully populated. You can actually fix it manually by editing this attribute by hand (or script) but obviously that isn't really a solution. Funny thing though is we have two separate environments with 2 different domains for prod and dev and we only saw the issue in one of the domains.
Thank you Wila. Wading through the ESXi and ESX KB instructions made me glad I'm using Fusion.
I did find Fusion KB 1015695 which used Settings>General to change the name but warned "The virtual machine bundle and files will still bear the virtual machine's original name. These files are referenced by the virtual machine settings and should not be renamed." Is "virtual machine bundle" another name for the .vmwarevm file in the Virtual Machines folder?
I have spend the last 2 hours trying to acchieve what you suggested.
So far the best results was a 8 colour 640x480 screen - but that was stable !!!
I tried all obscure settings that came to my mind - including trying vHW 5, 6 ,8, 10 and 12 with various guestOS parameters.
Unfortunately I messed up the stable config while trying to reconfigure it - the commandline tool Xconfigurator is unusable in 640x480 and without nano I was not even able to enable ssh.
I give up for now - I guess I still have an old Redhat 7.2 VM somewhere that was created in the good old days - maybe that one still works - in case I find it ;-)
Ok thanks for letting me know. I will sort it out this weekend on my lab and test it before I post it again.
No need for logs, I should be able to sort it out on mine
Yes the metric will be per SCSI I'D under VirtualDisk
As a follow up, I heard back from VMWare. All they could tell me was:
"There should be a small resync providing that all the hosts are up before the VMs and that when you shut the environment down, it was healthy. We should expect a small resync but not a full rebuild."
So, once again, this forum was more useful than paid support. :-/ Thanks again Bob and GreatWhiteTec!