Update Manager Plugin marked as Incompatible as per compatibility-matrix.xml

This post was originally published on this site

Hello User,

 

Have you upgraded your windows based vCenter to 6.7 and not able to see update manager plugin in the web client ?

 

The chances are high that you may face this issue especially when running vCenter on Windows version.

 

Note : The update manager plugin will not be available for HTML client for windows vCenter 6.7 however you should still be able to access it via the Flash client.

 

The following article helps to get the update manager plugin visible to the flash client in case if it is showing errors as below screenshot”

 

to write kb.JPG

 

To isolate this issue further restart only the web client service and navigate to C:/ProgramData/VMware/vCenterServer/logs/vsphere-client/logs/vsphere_client_virgo.log

Search for term “vcIntegrity” from the bottom to top of the log file

Validate if you are seeing the errors as mentioned below and only proceed further if the errors matches with your environment.

 

[2020-06-26T14:56:44.888-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.vim.extension.VcExtensionManager                  Detected an invalid signature for plugin: com.vmware.vcIntegrity:6.7.0.41977 – com.vmware.vise.extensionfw.signing.PluginSignatureException: No META-INF/MANIFEST.MF entry found in the plugin zip file.

[2020-06-26T14:56:44.889-04:00] [INFO ] plugin-validation1            com.vmware.vise.extensionfw.impl.OsgiUsageValidationService       Started validation of OSGi bad practices.

[2020-06-26T14:56:44.889-04:00] [INFO ] plugin-validation1            com.vmware.vise.extensionfw.impl.OsgiUsageValidationService       Finished validation of OSGi bad practices.

[2020-06-26T14:56:44.891-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.extensionfw.impl.PackageManifestParser            Plugin id mismatch between the registered extension key (com.vmware.vcIntegrity) and the id specified in plugin-package.xml (com.vmware.vumclient). The registration id will be used but you should keep them in sync.

[2020-06-26T14:56:44.892-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.extensionfw.impl.PackageManifestParser            Plugin version mismatch for com.vmware.vcIntegrity between the plugin registration info (6.7.0.41977) and the version specified in plugin-package.xml (6.7.0). The registration version will be used but you should keep them in sync.

[2020-06-26T14:56:44.895-04:00] [WARN ] vc-extensionmanager-pool-93  70000042 100002 200001 com.vmware.vise.extensionfw.ExtensionManager                      Plugin package com.vmware.vcIntegrity:6.7.0.41977 not deployed: it is marked incompatible either in your setup’s compatibility-matrix.xml or internally in this release.

 

Now it is time to review if your compatibility-matrix.xml got modified.

The file is located @ C:/ProgramData/VMware/vCenterServer/cfg/vsphere-client/compatibility-matrix.xml

 

The file should be similar to what is shown below:

 

<Matrix>

  <pluginsCompatibility>

     <!– ###VMWARE_KB_WHITELIST### –>

     <PluginPackage id=”com.vmware.vsphere.(client|ds|ssoadminui|client.modules|client.srupload|client.telemetry)” status=”compatible”/>

     <PluginPackage id=”com.vmware.ds” status=”compatible”/>

     <PluginPackage id=”com.vmware.ssoadminui” status=”compatible”/>

     <PluginPackage id=”com.vmware.license.client” status=”compatible”/>

     <PluginPackage id=”com.vmware.opsmgmt.client” status=”compatible”/>

     <PluginPackage id=”com.vmware.vsan.health” status=”compatible”/>

     <PluginPackage id=”com.vmware.vsphere.client.h5vsan” status=”compatible”/>

     <PluginPackage id=”com.vmware.vcIntegrity.vcIntegrity” status=”compatible”/>

     <PluginPackage id=”com.vmware.vum.client” status=”compatible”/>

     <PluginPackage id=”com.vmware.imagebuilder.imagebuilder” version=”[6.6.0,)” status=”compatible”/>

     <PluginPackage id=”com.vmware.vca.marketing.ngc.ui” status=”compatible”/>

     <PluginPackage id=”com.vmware.vco” version=”[6.5.0,)” status=”compatible”/>

     <PluginPackage id=”com.vmware.vrops.install” status=”compatible”/>

     <PluginPackage id=”com.vmware.fallback.mixed” status=”compatible”/>

     <!– Known compatible plugins –>

     <PluginPackage id=”com.vmware.vrUi” status=”compatible”/>

     <PluginPackage id=”com.nimblestorage.hi” version=”[5.0.0,)” status=”compatible”/>

     <PluginPackage id=”com.dell.plugin.OpenManage_Integration_for_VMware_vCenter_WebClient” version=”[4.2.0,)” status=”compatible”/>

     <!– TODO: Add more plugins here to enable them in the vSphere Client –>

    

     <PluginPackage id=”.*” status=”incompatible”/>

    

  </pluginsCompatibility>

</Matrix>

 

Reason:

In 6.7 the VUM plugin ID is referred as “com.vmware.vcIntegrity” and  “com.vmware.vumclient”

However in the above xml file we see the VUM ID is mentioned as “com.vmware.vcIntegrity.vcIntegrity” and  “com.vmware.vum.client”

This causes the update manager plugin to fail to validate during the startup of web client service.

 

Resolution:

 

The resolution is simple, remove all the unwanted/stale plugin from the vCenter MOB page.

You can access vCenter MOB page and remove the stale plugins following this KB – VMware Knowledge Base

 

kb3.png

Example Screenshot showing list of unwanted plugins on the vCenter server which are not in use

 

Once the plugins are removed, take backup of the existing compatibility-matrix.xml

Now in the original “compatibility-matrix.xml” file, copy past the following and save it

 

<!–

   The ‘id’ value allows for standard java regular expressions. The actual plugin id

   is matched against this regular expression.

 

 

   The ‘version’ values must be a string in any of the following formats. If skipped

   it indicates any version.

 

 

   Version: An exact version, e.g. 6.0.0, 5.5, etc. The format allows for maximum

      of 4 dotted numbers.

 

 

   Interval: (, 6.4], [6.5, 7.0), (7.5, ). Use empty strings to mark infinity values.

 

 

   Range: Several versions and intervals can be mixed in one single string

      producing a set of value, e.g. ( ,6.4), 6.8.3, 6.9.1, [7.5.2.2, ).

 

 

      Each item in the set is separated from the others using comma “,”.

      Each item in the set can be either version or interval.

 

 

   The ‘status’ can be any of the following strings: unknown,

      incompatible, compatible, certified

–>

<Matrix>

  <pluginsCompatibility>

     <!–

        ‘Incompatible’ plugins are not loaded. You can use this to ‘blacklist’

        plugins if needed. To prevent specific plugin package(s) from

        loading, use the template entry below as guidance how to add new records

        with the actual id and version of the plugin you want to prevent from loading.

 

 

        The plugin ids can be taken from the plugin-package.xml file of each plugin.

 

 

        A few well known set of plugins locations (on the vCenter Appliance):

           /usr/lib/vmware-vsphere-client/plugin-packages/

           /etc/vmware/vsphere-client/vc-packages

           /etc/vmware/vsphere-client/cm-service-packages

 

 

        On Windows the following locations can be checked:

           <INSTALL DRIVE>ProgramDatavCenterServerruntimevsphere-clientplugin-packages

           <INSTALL DRIVE>ProgramDatavCenterServercfgvsphere-clientvc-packages

           <INSTALL DRIVE>ProgramDatavCenterServercfgvsphere-clientcm-service-packages

     –>

     <!–

     <PluginPackage id=”com.foo.plugin.id” version=”1.0.0″ status=”incompatible”/>

     <PluginPackage id=”net.bar.plugin.id” version=”(,2.1]” status=”incompatible”/>

     –>

 

 

 

 

 

 

     <!–

        The sample section below shows ‘whitelist’ definition. Compatible plugins

        are loaded. All others are declared as incompatible (due to the id regex),

        thus effectively forbidding them.

 

 

        The approach limits the list of plugins loaded only to a small ‘white’ list.

        This allows for vsphere-client to work in a ‘safe-like’ mode.

 

 

        Below are predefined sets of plugins for your convenience:

        1st-party, core:

          com.vmware.vsphere.client,

          com.vmware.ds,

          com.vmware.ssoadminui,

          com.vmware.vsphere.client.modules,

          com.vmware.license.client,

          com.vmware.opsmgmt.client

 

 

        1st-party extended (in addition to the above):

          com.vmware.loganalyzer,

          com.vmware.vsphere.client.telemetry

 

 

        2nd-party (basically anything that comes already pre-bundled with the

        vCenter Appliance and is not in the above two sets):

            com.vmware.vca.marketing.ngc.ui,

            com.vmware.vco

     –>

     <!–

     <PluginPackage id=”com.vmware.vsphere.(client|ds|ssoadminui|client.modules)” status=”compatible”/>

     <PluginPackage id=”com.vmware.license.client” status=”compatible”/>

     <PluginPackage id=”com.vmware.opsmgmt.client” status=”compatible”/>

 

 

     <PluginPackage id=”.*” status=”incompatible”/>

     –>

  </pluginsCompatibility>

</Matrix>

Now restart vSphere web client service and you should be able to see the update manager listed and no longer marked as incompatible.

If you still see VUM plugin missing, review the virgo logs and start over again.

 

Happy Troubleshooting 

 

Regards,

Jonathan

Vrealize Automation 8.1: Provision Virtual Machine on specific hosts instead of Cluster

This post was originally published on this site

I have a environment where my workload cluster is stretched across 2 physical location. 1st DC is active and 2nd DC is passive. However the management and workload cluster are streched across.

 

4 Hosts are in DC1 and 4 hosts in DC2. Total 8 hosts in streched cluster.

 

With VRA 8.1 i can chose cloud zone with specific cluster (if DRS enabled), not hosts.

 

So if i am provisioning VM using blueprint in vra 8.1 the provisining is happening on clujster level and based on performance it choses any host , sometimes of DC2 also.

 

I want my provisioning to get limited to DC1 hosts only from vRA 8.1

 

I tried a lot but not getting any option on vra 8.1 on how to restrict this provisioning on limited no of hosts.

 

Please guide.

503 Service Unavailable after 6.7.0.44100 upgrade.

This post was originally published on this site

Hi,

 

We are getting 503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x00007fe978004950] _serverNamespace = / action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe) error when opening the vCenter log in page.

 

The Appliance Management is functional and health status is showing all Good.

 

Overall Health Good (Last checked Jul 21, 2020, 04:26:43 PM)

CPU Good

Memory Good

Database Good

Storage Good

Swap Good

 

Seems to be the same issue as posted here 503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x000055ed2fdb3820] _serverNamespace = / action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)

 

service-control –status

Stopped:

pschealth vmcam vmware-certificatemanagement vmware-content-library vmware-imagebuilder vmware-mbcs vmware-netdumper vmware-perfcharts vmware-rbd-watchdog vmware-sca vmware-sps vmware-topologysvc vmware-updatemgr vmware-vapi-endpoint vmware-vcha vmware-vpxd vmware-vpxd-svcs vmware-vsan-health vmware-vsm vsan-dps

Running:

applmgmt lwsmd vmafdd vmcad vmdird vmdnsd vmonapi vmware-analytics vmware-cis-license vmware-cm vmware-eam vmware-pod vmware-postgres-archiver vmware-rhttpproxy vmware-statsmonitor vmware-sts-idmd vmware-stsd vmware-vmon vmware-vpostgres vsphere-client vsphere-ui

Amazon EBS Fast Snapshot Restore for Shared EBS Snapshots

This post was originally published on this site

Snapshots are an integral part of Amazon Elastic Block Store (EBS). Snapshots allow you to create a block-level, point-in-time copy of your volumes for backup, or disaster-recovery purposes. Snapshots are incremental, only data modified since the last snapshots are copied again. You can share snapshots between AWS Regions, or AWS Accounts. Once you have a snapshot, you can create a new Amazon Elastic Block Store (EBS) volume based on a snapshot. The new volume begins as an exact replica of the original volume that was used to create the snapshot.

When you restore volumes from snapshots, they are available for use almost instantaneously. In the background, EBS lazy loads the data from the snapshot as the operating systems accesses the blocks, this reduces the I/O performance of the volume until it is fully initialized. Some I/O demanding workloads however need the volume to operate at full capacity as soon as it is available. This is why we introduced Fast Snapshot Restore (FSR). Once enabled, FSR allows to create volumes that deliver their maximum performance and do not need to be initialized.

Many AWS customers are sharing their snapshots with other AWS Accounts, and there are many reasons to do this. You might want to centrally prepare and manage golden AMIs, with your applications, monitoring, or management tools pre-backed. In the context of Disaster Recovery (DR), your company policies might require to store all backups in one dedicated account. Until today, only the AWS Account owning the snapshot could enable FSR.

Today, you can enable Fast Snasphot Restore (FSR) on snapshots shared with you.

To enable FSR on a shared snapshot, I first create a snapshot on the source AWS Account. Once the snapshot is created, I share it with another account of mine. To do so, I click Actions, and Modify Permissions. I enter the destination AWS Account Number, click Add Permission and Save.

EBS Share Snapshots

I connect the destination account and navigate to EC2 console. When the snapshot is not visible, I check if the Private Snapshots option is selected.

EBS Private SnapshotsI select the snapshot I want to be available for FSR and select Actions, then Manage Fast Snapshot Restore.

EBS Enable fast snapshot restoreI select the Availability Zones where I want to be able to fast restore my snapshot and click Save.

Enable EBS Fast Snapshot Restore

After the settings are saved, I receive a confirmation:

FSR Restore Confirmation

The snapshot stays in enabling mode for a couple of minutes and then becomes enabled. Once done, you can create Amazon Elastic Block Store (EBS) volumes from it. The volumes are fully initialized.

You can also do all this from the API or the AWS Command Line Interface (CLI).

aws ec2 enable-fast-snapshot-restores            
         --source-snapshot-ids snap-0b00000000d9 
         --availability-zones us-west-1a         
         --region us-west-1

{
    "Successful": [
        {
            "SnapshotId": "snap-0b00000000d9",
            "AvailabilityZone": "us-west-1a",
            "State": "enabling",
            "StateTransitionReason": "Client.UserInitiated",
            "OwnerId": "00123456789",
            "EnablingTime": "2020-06-26T16:40:19.720000+00:00"
        }
    ],
    "Unsuccessful": []
}

At any moment I can check what are the volumes I restored from a FSR.

aws ec2 describe-volumes --filters Name=fast-restored,Values=true

{
    "Volumes": [
        {
            "Attachments": [],
            "AvailabilityZone": "us-west-1a",
            "CreateTime": "2020-01-26T00:34:11.093Z",
            "Encrypted": true,
            "KmsKeyId": "arn:aws:kms:us-west-2:123456789012:key/8c5b2c63-0000-0000-0000-5513e232e843",
            "Size": 20,
            "SnapshotId": "snap-0b00000000d9",
            "State": "available",
            "VolumeId": "vol-0d000000000000b0",
            "Iops": 100,
            "VolumeType": "gp2",
            "FastRestored": true
        }
    ]
}

The AWS Account where you enable Fast Snapshot Restore is charged an hourly price. The owner of the snapshot is not charged for enabling FSR in another AWS Account. When the owner of your shared snapshot deletes the snapshot or stops sharing the snapshot with you, the FSR for your shared snapshot is automatically disabled and FSR billing for the snapshot is terminated.

You can enable Fast Snapshot Restore in all commercial AWS Regions today.

As usual, let us know your feedback by posting messages on the AWS Forum, or leave a comment on this post.

— seb

vLCM – HPe HSM – Fetching of online depot URL failed

This post was originally published on this site

Hello Team VMware,

 

today, I want to try the new vLCM in combination with HPe iLO Amplifier to firmware patching my ESXi hosts.

I successfully installed the HPe iLO Amplifier appliance and let it communicate with the vCenter.

I also uploaded the 3 latest HPe SPP firmware into the appliance but I can´t use it in the vCenter.

 

When I press “Add” for the Online Software Depot I get the following error:

Fetching of online depot URL failed. Depot URL not found in the SPP details.

 

Is somebody aware about that or got the HPe iLO Amplifier with VUM to fly?

 

Fetching Error.JPG

vCenter 7: 16386335
ESXi 7: 16324942
Amplifier: 1.70

 

I really appreciate your help in advance.

 

Greetings

KKvss

VMWare Tools installed but shared folders in Ubuntu refusing to work

This post was originally published on this site

Having got this initial error when trying to use Shared folders running VM on Fusion 11.5.5 with Ubuntu 20.04

 

“Shared folders will not be available in the virtual machine until VMware Tools is installed and running.”

 

some other helpful threads here allowed me to install (and reinstall) VMWare Tools.

 

But despite successful installation I am still getting the same error.

 

Has anyone had this and successfully resolved?

 

Thank you,

NSX-T 3.0 – tunnel down and PING not reachable to Tier 0

This post was originally published on this site

hi,

we are building a single ESXi host based NSX-T 3.0 deployment.

we have two issues :

1. tunnel between the Host TEP and Edge transport node TEP is down.

2. As shown in the below topology diagram, from the Application server running in the segment1, we can ping the 10.204.253.18 IP, but unable to ping the external Tier-0 interface IP 10.204.253.191.

Please help.

 

Screenshots:

upgrade 6.7u3 to 7.0 cert issues

This post was originally published on this site

attempting to upgrade my lab from 6.7u3.latest to 7.0.latest

new VCSA VM deploys ok, but during pre-check get the following error:

 

Error

A vCenter Single Sign-On endpoint certificate validation error has occurred.

 

 

Resolution

Ensure that the endpoint service registrations in vmdir match their corrsponding machine SSL certificates in VECS. For more information, see Knowledge Base article KB 2121701.

 

 

 

 

 

I have already gone through the KB to no avail.  I have also gone through and reset all certs (cert manager option 8).

 

Anyone have any guidance or suggestions?

Thanks,

-GB

 

 

 

 

Console 20.05 launcher issue

This post was originally published on this site

Hello,

 

Since i have upgraded my Onpremise Console version 19.03 to 20.05, i meet  strange issue with all my launcher profiles.

When i publish it, folders and applications icons disappeared on all devices,  and also on Console Launcher Profile.

 

It looks like this issue,  corrected on version 20.06

RUGG-7813: Adding a new app to the Launcher profile causes other app placeholder icons to disappear.

VMware Workspace ONE UEM™ Powered by AirWatch 2006 Release Notes

 

Has anyone noticed this problem ?

 

ps: I am still using Android legacy profile.

 

regards,

PL

Iron Castle Systems