lukaslang's Posts

We have the same problem and it does not seem that the newest bugfix release 8.4.0.2 resolves the issue. This is annoying since this vSphere Replication release is mandatory fpr vSphere ESXi 7 U2
I am not using iSCSI or the above mentioned RDM Disks. Everything is attached over FC. In addition I found out, that VMs beeing backed up residing on an upgraded Host need consolidation after a snap... See more...
I am not using iSCSI or the above mentioned RDM Disks. Everything is attached over FC. In addition I found out, that VMs beeing backed up residing on an upgraded Host need consolidation after a snapshot backup. The manual consolidation finishes without an error, BUT the warning remains and the disks are not consolidated properly. Only way to consolidate the disk is to shut down the VM or vmotion it to a not upgraded 6.7 Host. A newly installed 7.0 U2 Hosts does not have this behavior. It seems that there are some major underlying issues in the upgrade process. At the moment I cannot recommend an Upgrade from 6.7 to 7 U2a (at least for our environment).
In my 10 year vsphere career I never had such issues. Also vcenter has many strange problems. Maybe it is time to invest in quality than feature quantity. Fresh installing the host did resolve the p... See more...
In my 10 year vsphere career I never had such issues. Also vcenter has many strange problems. Maybe it is time to invest in quality than feature quantity. Fresh installing the host did resolve the problem for me also, but it is PITA if you have many hosts.
Which kind of storage are you using? Maybe it is related to 3PAR Volumes?
We have the exact same problem using a HPE customized 7.0 U2 image. Strangely enough, the first Host updated without a problem.
Hi, currently we are planning a major permission change in our vSphere environment. I think everybody who has tried to be more restrictive has quickly realized that the permission structure inside v... See more...
Hi, currently we are planning a major permission change in our vSphere environment. I think everybody who has tried to be more restrictive has quickly realized that the permission structure inside vCenter is a real pita. If you are using Storage Policies, VM Customizations, Tags etc. it gets even crazier. These 3 things require permissions directly on the vCenter object which enables users to see more of the infrastructure without even having "real" permissions on it. Back2Topic: We are trying to hide specific Tags, but from what I've seen, this is currently impossible. You can permit the users to assign only specific tags but you cannot hide them. The hilarious thing is that this documentation is misleading: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-2199584C-B422-4EEF-9340-5449E1FB7DAE.html This sentence does describe my problem, but it does not work: For example, if you grant the Assign vSphere Tag privilege to user Dana on host TPA, that permission does not affect whether Dana can assign tags on host TPA. Dana must have the Assign vSphere Tag privilege at the root level, that is, a global permission, or must have the privilege for the tag object. A user who has no permission on the vCenter level, cannot see any tags even if you assign them permissions directly on the tag. The crazy thing is: if you give the user any permission (e.g. if you want that the user can read vm customizations or Storage Policies) he can read all Tags, but assign only the ones where he has the "Assign or Unassign Tag" permission. Maybe this is a bug in the GUI and using the API it would work. I've tried it with 6.7 U3k and 7.0 U1c, both have the same behavior. Is there anyone out who had more luck doing this or am I overseeing something?
Ok, small update to this: vCenter 7 U1a seems to resolve the issue. Since I went directly to U1a, I cannot tell if U1 would do the same. In vCenter 6.7 U3k the issue remains.
Were you able to sort it out or do you had to recreate the whole category including tags etc.? That would be a real pain in the a.
Hi, we ran into an interesting issue. While renaming a Tag Category we receive the following error: com.vmware.vapi.std.errors.invalid_argument {'messages': [], 'data':} At line:... See more...
Hi, we ran into an interesting issue. While renaming a Tag Category we receive the following error: com.vmware.vapi.std.errors.invalid_argument {'messages': [], 'data':} At line:1 char:24 + Get-TagCategory XXX | Set-TagCategory -Name "XXXXX" +                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo      : NotSpecified: (:) [Set-TagCategory], CisException + FullyQualifiedErrorId : ViCore.Impl.V1.Service.Tagging.Cis.TaggingServiceCisImpl.SetCategory.Error,VMware.VimAutomation.ViCore.Cmdlets.Commands.Tagging.SetTagCategory This Category was originally created on a newly deployed vCSA 6.5 and updated to 6.7 U3. If I create a new Tag Category, assign Tags and Tag Objects with them, there is no problem renaming the category afterwards. The same thing happens in our DEV environment, which was already updated to 7.0. We tried the local Admin User and AD Users. Nothing changed. Has anyone experienced something similar before?
The KB mentioned above was updated. U1b has the fix included
Ich würde dann die VM aus dem Inventory entfernen und neu einlesen (Tags vorher sichern falls vorhanden)
Bitte kontrolliere mal den Wert "memSize" in der vmx. Dieser sollte eigentlich für den zugewiesenen Arbeitsspeicher zuständig sein. svga.vramSize bezieht sich auf den Arbeitsspeicher der virtu... See more...
Bitte kontrolliere mal den Wert "memSize" in der vmx. Dieser sollte eigentlich für den zugewiesenen Arbeitsspeicher zuständig sein. svga.vramSize bezieht sich auf den Arbeitsspeicher der virtuellen GPU und wird in Bytes angegeben (in deinem Fall 8 MB). Sollten die Änderungen an der vmx nicht mehr automatisch funktionieren, wäre darüber nachzudenken die VM aus dem Inventory zu entfernen und neu einzulesen.
Hi, today we discovered a very strange problem in our environment. A Citrix Netscaler Appliance was updated to v12.0 53.22.nc for evaluation purposes. The evaluation vSphere Host (6.5 U1 5969... See more...
Hi, today we discovered a very strange problem in our environment. A Citrix Netscaler Appliance was updated to v12.0 53.22.nc for evaluation purposes. The evaluation vSphere Host (6.5 U1 5969303) had no problem with this configuration. The VM was connected to a vDS. Then we moved the machine in the production environment where the Hosts are connected through HPE Flex10 cards to a VC (FW 4.50) on a VSS. Then the strange thing happened: Doing a vMotion of the machine or disconnecting and reconnecting a NIC of the VM, the Host NIC ports transporting the VM traffic were shutdown and the VirtualConnect threw out a loop detection. This can be reproduced consistently doing the operations mentioned above. Strange enough, the problem seems to be associated to the VSS. Migrating the VM to a dVS, the problem seems to be resolved. We checked also the vSphere versions. It happens too in 6.0 U3 (5224934). Bringing back the Netscaler to version 11.1 Build 50.10.nc resolves the problem on the VSS. Are there any Users that use the constellation of Netscaler, VSS and VirtualConnect and could do a test? The SUS of the VC are Active/Active.
I know, that your 10 Gig Adaper is not listed under this HPE KB, but it could be something to try: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00030080en_us&hprpt_id=HPGL_ALE... See more...
I know, that your 10 Gig Adaper is not listed under this HPE KB, but it could be something to try: https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00030080en_us&hprpt_id=HPGL_ALERTS_1991645&jumpid=em_alert…
On HPE Custom images the affected vibs are the following: scsi-be2iscsi ima-be2iscsi Removing them clears the warning on HPE Servers with 6.0U3. On 6.5 the vibs are the same mentioned in t... See more...
On HPE Custom images the affected vibs are the following: scsi-be2iscsi ima-be2iscsi Removing them clears the warning on HPE Servers with 6.0U3. On 6.5 the vibs are the same mentioned in the Dell document.