Month: January 2016

vCloud Director 8: UI, then and what now?

/ johannstander / Leave a comment

Just more than a month ago we were given very exciting news from the vCloud team regarding further limited enhancements to the UI of vCD-SP for 2016.

//platform.twitter.com/widgets.js How things can change within a month:

http://www.networkworld.com/article/3026996/hybrid-cloud/despite-layoffs-vmware-has-a-big-bet-on-this-one-cloud-innovation.html

https://www.thelayoff.com/vmware

 Lets hope that none of these recent activities has any impact on the vCD-SP UI announcements but only time will tell…

vCenter Server – Host Profiles error "the option uservars.suppressShellWarning"

/ johannstander / Leave a comment

Receive the error “the option uservars.suppressShellWarning”

This is due to a previous selection to suppress warnings for instance for enable SSH on your ESXi host.

Solution:

To fix this you can either change the host profile to enable this suppression

Advanced Configuration Settings -> Advanced Options -> Advanced configuration option
Click the green plus “+” sign symbol to create a new option.
Select advanced option “configured a fixed option”
The name of the option “UserVars.SuppressShellWarning”
Set the value to “1”

If you don’t want to suppress the warnings anymore you can disable it through the advanced settings of the ESXi host using vSphere web client:

Select ESXi host -> Manage tab -> Settings
Select Advanced System settings
easiest way is to search in filter for “suppress”
This will list the UserVars.SuppressShellWarning.
Change the settings to 0.

ESXi reset system configurations

/ johannstander / 1 Comment

As some point in time you would want to re-use an ESXi host but do not want to go through the hassle of a complete reinstall and rather have quick solution.

I find the “reset system configuration” in DCUI very useful for this task.
There is also a way to perform this task via SSH:

#  /sbin/firmwareConfig.sh –reset   (this will automatically reboot your host)
# /sbin/firmwareConfig.sh –reset-only (this will not reboot host and needs to be done manually)

Fusion 8.1 – NAT port forwarding not working

/ johannstander / Leave a comment

If you are Fusion 8.1 user on Mac then this might apply.

NAT port forwarding seems to be having some issues on latest 8.1!

To fix this perform the following steps:

  •     Download the NAT network component from https://www.vmware.com/go/dl_vmnet-natd (MD5: e347f5c8d86640af5102852c897e31cc)
  •     Replace /Applications/VMware\ Fusion.app/Contents/Library/vmnet-natd with the file downloaded in step 1.
  •     Restart the NAT network with the following commands:
    • sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –stop
    • sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –start
How to setup port forwarding:
  • Set static IP for your virtual machine
  • Get VM mac address under network adapter for VM settings
  • Modify dhcp.conf
    • sudo nano /Library/Preferences/VMware\ Fusion/vmnet8/dhcpd.conf
    • Now, after where it says End of “DO NOT MODIFY SECTION” enter the following lines:
      • host Windows8x64 {
        • hardware ethernet 00:0C:29:B6:22:3E;
        • fixed-address  192.168.167.80;
      • }
      • Windows8x64 — Replace it use your virtual machine name
      • hardware ethernet address — use your VMWare Fusion’s virtual MAC address.
      • Important: Allocate an IP address that is outside the range defined inside the DO NOT MODIFY SECTION section.
      • Restart Fusion

  • Change NAT config
    • sudo vi /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf
    • replace values in [incomingtcp] with your requirements:
    •     [incomingtcp]
    •     # Use these with care — anyone can enter into your VM through these…
    •     # The format and example are as follows:
    •     # = :
    •     #8080 = 172.16.3.128:80
  • Restart network service for Fusion:
    • sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –stop
    • sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –start

vSphere 5.5 – Solution for VASA setup errors with VNX

/ johannstander / Leave a comment

Over weekend I wanted to review some of the features and functionalities that VASA and VSI provides inside vCenter server for a VNX array(5300).  VASA configuration should be straight forward but ran into some strange issues which took some extensive troubleshooting:

Troubleshooting:

VMware compatibility guide for EMC VASA provider specifies that VASA support is part of VNX Block OE 05.32; no additional software is required.  Our VNX 5300 has FLARE 5.32 which should allow for straight connectivity to the VNX…
http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vasa&productid=20232

On vCenter server web client select your vCenter server in inventory list on left.  Select Manage tab in right pane -> Storage provider sub-tab. Click the green button.

URL for direct VNX block:
https:///vasa/services/vasaService
URL for direct VNX file:
https://:5989/vasa/services/vasaService
URL for SMI-S:
https://5989/vasa/services/vasaService

When trying to connect directly to VNX block I received the following error message:

In vCSA i reviewed the following error messages in sps.log under \var\logs\vmware\vpx\sps\
“Received fatal alert: unknown_ca”

The most common issue that seems to be related to the VASA configuration is a expired certificate for the storage monitoring server.
This can be verified with the following commands on vCSA:
# cd /etc/vmware-vpx/ssl/
# keytool -keystore sms.keystore -storepass testpassword -list -v
Check the valid from and until in the output provided.
This was NOT my issue.

To further test this I installed a windows 2012 server with SMI-S. Same connectivity errors appeared.
So what is going on here!

Some further troubleshooting was in order:
– I regenerated the storage management certificates and restarted the vCenter server appliance
– I restarted the array’s management server.
– I added the vCenter server certificate to trusted certificates on VNX
– Verified the user created on VNX has VM administrator role.
– For user authentication if you create a local user on VNX, then be sure to add local\username for authentication in service provider.
– Verify that there is an array connected to SMI-S.  this can be verified by running the command “symcfg list” or logging in with testsmiprovider.exe and executing “dv” command.

Still no luck.
Looking further at the sps.log file I figured the problem had to be with the vCenter server that is sending the certificate to the array.

Solution:

I sticked with SMI-S since it provides more customization in administration console.
https://:5989/ECOMConfig/
    Username and password the same   (admin / #1Password)
Under security select “SSL Certification Management.
Here we want to select option 3 and import CA certificate from file…

So which certificate do we import?  well that would be the sms.keystore cert, but we need the cert as PEM data.  Do this perform the following commands on vCSA:

# cd /etc/vmware-vpx/ssl/
# keytool -importkeystore -srckeystore sms.keystore -destkeystore /tmp/sms.pkcs -srcstoretype JKS -deststoretype PKCS12
# cd /tmp
# openssl pkcs12 -in sms.pkcs -out sms.pem

Now open the sms.pem in and editor and copy the information from —Begin Certificate— to —End Certificate—
Paste into the textbox to submit the CA to SMI-S.

Now in vCenter service provider, setup connection to SMI-S again.

Link:
https://www.emc.com/collateral/software/white-papers/h10630-vmware-vasa-symmetrix-wp.pdf