Incompatible repository. Provide a repository from vSphere Update Manager Download Service 5.x.y

I tried to configure options: 'Use a shared repository' providing full path to catalog but clicking 'Validate URL' I get error:

It is important to answer question what 'Validate URL' button is checking ? 
Only path to catalog? No.
Path to patch repository with valid patch metadata? Yes.

If the patch catalog e.g. E:\Data\ is empty you will get error 'Invalid repository' because the content of folder is empty, no patch metadata.

According to VMware Documentation 5.1: http://bit.ly/1iPaZsL

"UMDS 5.1 is compatible and can work with Update Manager 5.0, Update Manager 5.0 update releases and Update Manager 5.1." 

According to VMware Documentation 5.5: http://bit.ly/1mqkw4c

"UMDS 5.5 is compatible and can work with Update Manager 5.0, Update Manager 5.1, Update Manager 5.5 and their respective update releases. "

What if my VUM server is in DMZ without internet access and I would like to have automated patch download?

We have 3 options:

1.) My DMZ is 'paranoid' DMZ with 'air gap' to hosts with internet access in this case you have to use portable media like USB drive or DVD/CDROM - it is not automated process :)

2.) My DMZ servers can have http/https access to UMDS server it means that security department is happy to open port 80 or 443 - in such case you can follow e.g. http://bit.ly/1vh66sy

3.) My DMZ servers can communicate via UNC shares with hosts with internet access.It means that your security department is happy to open SMB over TCP port 445 (for Windows 2008). You can follow VMware KB http://kb.vmware.com/kb/1000627 or you can follow procedure below.

I don't have to add that security department always loves option 1 :)

Prerequisites: VMware Update Manager was installed in DMZ Server A, VMware UMDS service was installed on Server B with internet access.

1.) Log in to Server A (with VUM)

2.) Setting up shared folder on VMware Update Manager Server A

 a.) Log in to each VMware Update Manager server that you will be installing that does not have an Internet connection as an Administrator.
b.) Create a shared folder that will have the exported patches from the Update Manager Download Service server at the desired drive location by going to My Computer > <Drive Letter>. For example, E:\.
c.) Right-click the My Computer window and click New > Folder and name it Data.
d.) Right-click the newly create Data folder and click Properties.
e.) Click the Sharing tab, and then click Advanced Sharing.
f.) Click Share this folder.
g.) Change the default share name to Repository.
h.) Click Permissions > Add > Locations and change location to the local computer.
i.) Under Enter the object names to select, type Administrators and then click Check Names.
j.) Click OK to save changes.
k.) Click Administrators.
l.) Click the Allow check box to give Administrators Full Control.
m.) Click OK to save changes.

3.) Log in to Server B (with UMDS)

a.) Map to the network share(s) that were created by navigating to My Computer > Map Network Drive.
b.) Choose a drive letter. For example, U:\.
c.) Click Browse and navigate to the VMware Update Manager server.
d.) Choose the share Repository. Repeat this step for each VMware Update Manager server that does not have an Internet connection and assign it a unique drive letter.
e.) Click Reconnect at logon and then click Finish.

f.) Open CMD
g.) Run: "C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vmware-umds.exe" -G

We see that I setup only downloading host patches for esxi5.1 and esxi5.5 and I disabled downloading Virtual Appliances upgrades.

"C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vmware-umds.exe" -S --disable-host --disable-va

"C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vmware-umds.exe" -S -e embeddedEsx-5.1.0-INTL embeddedEsx-5.5.0-INTL

h.) Change patch store for UMDS:

"C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vmware-umds.exe" -S --patch-store U:\

i.) If we decided using default patch store (and our export store is U:\) we have to export patches:

"C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vmware-umds.exe" -E --export-store U:\

j.) The patch store and export store cannot be configured to the same path.

k.) We start downloading patches to our patch store.

"C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vmware-umds.exe" -D

4.) As soon as metadata is downloaded to patch store on Server B (UMDS)we can validate successfully Shared repository on Server A (VUM)

 
 
 the end.

EMC XtremeIO with VMware View very high CPU usage on ESXi hosts

New vBlock for extreme applications, 4 Cisco B200 M3 blades, 1000 VMs are deployed - CPU on all blades hit the roof. We didn't expect that.

 In XtremIO logs we notice a huge amount of SCSI reservation logs:

<info>2014-06-11 15:09:59.507783 localhost xtremapp: [8474(9770 nb_truck_0)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:a0:5f, vol=12, opcode=42
<info>2014-06-11 15:09:59.705085 localhost xtremapp: [8474(9771 nb_truck_1)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:b1:7f, vol=12, opcode=42
<info>2014-06-11 15:10:00.314514 localhost xtremapp: [8474(9770 nb_truck_0)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:b1:7f, vol=6, opcode=42
<info>2014-06-11 15:10:00.973382 localhost xtremapp: [8474(9771 nb_truck_1)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:a0:4f, vol=10, opcode=42
<info>2014-06-11 15:10:00.973393 localhost xtremapp: [8474(9774 nb_truck_4)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:a0:4f, vol=10, opcode=40
<info>2014-06-11 15:10:01.088004 localhost xtremapp: [8474(9775 nb_truck_5)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:a0:7f, vol=10, opcode=42
<info>2014-06-11 15:13:53.936724 localhost xtremapp: [8474(9774 nb_truck_4)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:a0:4f, vol=10, opcode=40
<info>2014-06-11 16:24:34.787011 localhost xtremapp: [8474(9770 nb_truck_0)]: I/O operation failure: SCSI2 reservation conflict for 20:00:00:25:b5:02:a0:7f, vol=16, opcode

Checking VAAI settings and we see human-error:

~ # esxcfg-info -o | egrep -B 8 '/HardwareAcceleratedMove|/HardwareAcceleratedLocking'
            \==+Advanced Integer Option :
               |----Option Name.....................................HardwareAcceleratedLocking
               |----Current Value...................................0
               |----Default Value...................................1
               |----Min Value.......................................0
               |----Max Value.......................................1
               |----Hidden..........................................false
               |----Parent........................................../VMFS3/
               |----Path............................................/VMFS3/HardwareAcceleratedLocking
--
            \==+Advanced Integer Option :
               |----Option Name.....................................HardwareAcceleratedMove
               |----Current Value...................................0
               |----Default Value...................................1
               |----Min Value.......................................0
               |----Max Value.......................................1
               |----Hidden..........................................false
               |----Parent........................................../DataMover/
               |----Path............................................/DataMover/HardwareAcceleratedMove

 Enabling VAAI primitives:

 

# esxcli system settings advanced set -o /DataMover/HardwareAcceleratedMove -i 1

# esxcli system settings advanced set -o /VMFS3/HardwareAcceleratedLocking -i 1

 

SCSI reservations disappear from XtremeIO logs. 

 

pCPUs utilisation around 50% during deployment 1000 VMs. After ~2hrs 1000 desktops ready to use. That's really extreme!!!

 

Remember to get extreme performance keep VAAI primitives enabled on vSphere hosts !!!  

the end.

VMware vCenter stopped - MSSQL database is full

1.) On windows machine we see that disk is full.

2.) In vpxd.log or Microsoft event log we can notice:

2014-03-30T09:16:27.494+08:00 [04120 error 'Default' opID=HB-host-87@2013030-52d23067] An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Error: Error[VdbODBCError] (-1) "ODBC error: (42000) - [Microsoft][SQL Server Native Client 10.0][SQL Server]Could not allocate space for object 'dbo.VPX_HOST_VM_CONFIG_OPTION'.'PK_VPX_HOST_VM_CONFIG_OPTION' in database 'vCenter' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup." is returned when executing SQL statement "INSERT INTO VPX_HOST_VM_CONFIG_OPTION WITH (ROWLOCK) (HOST_ID, CONFIG_OPTION_VER, DATA, ARRAY_INDEX, CONFIG_OPTION_DESC, CREATE_SUPPORTED_FLG, DEFAULT_CONFIG_OPTION_FLG) VALUES (?, ?, ?, ?, ?, ?, ?)"
2014-03-30T09:16:15.853+08:00 [04120 error 'Default' opID=HB-host-87@2013030-52d23067] [VdbStatement] SQL execution failed: INSERT INTO VPX_HOST_VM_CONFIG_OPTION WITH (ROWLOCK) (HOST_ID, CONFIG_OPTION_VER, DATA, ARRAY_INDEX, CONFIG_OPTION_DESC, CREATE_SUPPORTED_FLG, DEFAULT_CONFIG_OPTION_FLG) VALUES (?, ?, ?, ?, ?, ?, ?)
2014-03-30T09:16:15.853+08:00 [04120 error 'Default' opID=HB-host-87@2013030-52d23067] [VdbStatement] Diagnostic data from driver is 42000:1:1105:[Microsoft][SQL Server Native Client 10.0][SQL Server]Could not allocate space for object dbo.VPX_HOST_VM_CONFIG_OPTION'.'PK_VPX_HOST_VM_CONFIG_OPTION' in database 'vCenter' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded.

3.) To address this issue we have to follow steps from VMware KB:
http://kb.vmware.com/kb/1025914 

a.) Stop vcenter server
b.) Extend virtual disk which is full for e.g. 1GB in VMware viClient.

4.) Login to Windows machine where MS SQL is installed

5.) Start 'Microsoft SQL Server Management Studio'

6.) Choose vcenter database and expand Tables

7.) Find dbo.VPX.PARAMETER

 8.) Right click on dbo.VPX.PARAMETER and choose from context menu 'Edit Top 200 Rows'

9.) Find event.maxAge, event.maxAgeEnabled parameters and change values to 30 and true.

10.)Find task.maxAge, task.maxAgeEnabled parameters and change values to 30 and true,

11.)Expand vcenter DB go to Programmability -> Stored Procedures

 12.)Expand Stored Procedures right click on dbo.cleanup_events_tasks_proc

13.)From context menu choose Exacute Stored Procedure...

14.) Click OK

15.) Depending on database size the task can run long period of time

16.) Go to vCenter -> Administration -> vCenter Server Settings...

17.) Parameters event.maxAge, event.maxAgeEnabled, task.maxAge, task.maxAgeEnabled are set in Database Retention Policy in vCenter settings.

Executing this procedure you delete older tasks and events in some environments with compliance requirements e.g. PCI DSS you should take backup to keep full history of events.

end

Cannot configure a local host OS identity source in VMware vSphere 5.1 Single Sign-On [SSO]

I get quite regular requests that someone cannot configure local host OS identity source in VMware SSO.

First of all we have to answer question why we encounter this issue?

In VMware vCenter 5.1/5.5 Single Sign-On (SSO) we basically have three modes:

* Basic
* Primary / High Availability Cluster (HA)
* Multisite 

Please see VMware KB 2035817 http://kb.vmware.com/kb/2035817


In Primary / High Availablity and Multisite Single Sign-On modes, there is no local operating system identity source.

Please see VMware Documentation: http://bit.ly/TuFNDH

1.) Check what SSO mode was installed.

a.) Press WIN + R and type regedit 

 
b.) Go to HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Infrastructure\SSOServer and check value fot SetupType

 c.) Because real men don't click you can run in command prompt 



> REG QUERY "HKLM\SOFTWARE\VMware, Inc.\VMware Infrastructure\SSOServer" | findstr /i SetupType

In this case SSO was installed in Basic standalone mode therefore I can use local OS identity source. If you see value Primary / HA or Multisite you cannot use local OS identity source

2.) What in situation I have e.g. SSO in Primary mode and do not want to use Active Directory or openLDAP as identity source (seems quite unusual in enterprise but it is still the case).

a.) If your requirements is local OS identity source to demote Primary or Multisite to Basic mode you need re-install vcenter stack.

b.) As workaround solution you can consider to add users to System-Domain and assign appropriate permissions and roles to vCenter objects.

The End.

VMware VMtools 'IP address' and 'DNS Name' information missing in vcenter Summary TAB

In Summary TAB in viClient connected to vCenter or directly to esxi host, choosing VM with installed VMtools we can see IP address and DNS Name. 

For Microsoft Windows machines guestinfo.dll is responsible for passing this information to ESXi host and vCenter.

For Linux e.g. RHEL we have similar to  Microsoft .dll dynamically linked shared object library file libguestInfo.so is passing info to ESXi host and vCenter.

Based on VMware KB article http://kb.vmware.com/kb/1013371 we can set vmx parameter to disable/enable this information in Summary TAB.

If we set the isolation.tools.setinfo.disable parameter to FALSE we enabling to pass information about IP and DNS to ESXi host and vCenter.

If we set the isolation.tools.setinfo.disable parameter to TRUE we disabling to pass information about IP and DNS to ESXi host and vCenter.

In paranoid security environments you can remove guestInfo.dll on Windows machines by running this batch .bat script:

Rem Delete GuestInfo.dll

net stop vmtools

del "C:\Program Files\VMware\VMware Tools\plugins\vmsvc\"guestinfo.dll

echo > "C:\Program Files\VMware\VMware Tools\plugins\vmsvc\"guestinfo.dll.removed

net start vmtools

Removing libguestInfo.so on linux system doesn't change this behavior (I need to do more deep research for that) you have to use vmx parameter.

By default this parameter is not added during VM creation and information from GuestOS is passed to ESXi and vCenter.