Skip navigation
2019

amin masoudifard's Blog

July 2019 Previous month Next month

  It’s an usual problem when the server administrators want to configure more hard disks on their servers without any service interruptions or data loss through wrong array configuration. The issue will be complicated if your server is a hypervisor. If you make a little mistake during disk configuration, it can  lead to loss of entire VMs and consequently their data. So if any HP customized ESXi version are deployed as your host (or another customized setup file for other vendors), you can leverage your array configuration without any interrupt or downtime. Because there is no more need to reboot the host and configure server’s arrays by Popular F8 RAID Menu or HP Smart Start on boot environment. So based on ESXi versions you should execute one of these commands:

  1. For versions before 6.0:  /opt/hp/hpssacli/bin/hpssacli
  2. For versions after ESXi 6.5:  /opt/smartstorageadmin/ssacli/bin/ssacli

Whereas I encountered this situation in ESXi version 6.0 U3, next CLI are based on this version of ESXi HP-Customized:

 

1

Device Scanning

hpssacli rescan

2

Physical Disk Status

hpssacli ctrl slot=0 pd all show status

3

Logical Disk Status

hpssacli ctrl slot=0 pd all show status

4

Turn on/off Blink PD LED

hpssacli ctrl slot=0 ld 3 modify led=on/off

5

Create New RAID x

hpssacli ctrl slot=0 create type=ld drives=2I:1:5,2I:1:6,2I:1:7,2I:1:8 raid=0/1/5

6

Add PD to LV

hpssacli ctrl slot=0 ld 2 add drives=2I:1:5,2I:1:6

7

Add Spare to all array

hpssacli ctrl slot=0 array all add spares=2I:1:9

8

Check Configuration

hpssacli ctrl all show config

 

I hope you enjoy it, but attention: Before any change to your disk array, check all disks slots, numbers and so on, then execute your new raid setup commands.

 

 

Source of Content inside my personal blog: Undercity of Virtualization: Add new disks to the datastore while the host is run

 

 

Whenever you want to use Linked-Clone desktop pools on your environment, you need totally to View Composer service working correctly. but maybe after sometimes you will be faced with such as this warning: "Unable to connect to View Composer".

Regardless of well-known networking connectivity errors (port blocking, routing problem & etc) this error indicates that there is one of following conditions happened:

1. If you defined ODBC DSN with SQL server credentials, please check the "Enforce password policy" and "Enforce password expiration" check boxes on your login account settings. There is a simple way to check it: Re-run your DSN configuration wizard, provide the old setting and press "Test Data Sources..." button, then you can understand what was happened and if your credential is expired, you will know it.

2. If you provide Active Directory Credential instead of local SQL account, please check Group Policy is assigned to your AD account's OU. Maybe there is some restriction setting in "Password Policy" section.

3. For some reasons, maybe there is a problem on Composer server certificate validation, Especially whenever you have re-installed your composer component and want to choose your old certificate (Self-Signed or Valid-Generated). Then you must check your selected certificate for composer server:

Finally after all troubleshooting you can check your service correct operation by running netstat command and confirming connection on port 18433 is established.

It's recommended that as a network admin, you should consider that monitoring of "ESXi hardware usage and network transmit" as one of your virtual infrastructure management phases. Regardless of using monitoring tools or not, SNMP Traffic that is generated from your host, maybe face with an error. After reviewing your "community string" (SNMP v1/v2) or "credential" (SNMP v3) and checking network connection, if still there is a problem, you can execute an useful command for SNMP traffic inspection.

After logging to ESXi Host directly (DCUI) or by SSH connection (e.g Putty) , run this command to resolve the problem:

tcpdump-uw -vvv -i vmk0 -T snmp udp and port 162

 

Therefore you will see each SNMP UDP packets that are transferred on port 162. Also note this repeated "-vvv" syntax, which means you want to see more information of your command's result. Literally you can put only "-v" or "-vv" on your command.

 

Source of content inside my personal blog: Undercity of Virtualization: Analyze SNMP Traffic inside the ESXi

1. first of all, try SSH to your VCSA and stablish your session with root credentials or something like that privilege:)

2. Then after enable shell by this "shell.set --enabled True" and granting shell access, you can find-out vPostgres configuration and credential on these below files (by vi & less):

    /etc/vmware-vpx/embedded_db.cfg

    /etc/vmware-vpx/vcdb.properties

3. Now you can successfully connect to your DB by username: vc and gained password from mentioned files.

4.Consider some situations:

Maybe you cannot access to your database remotely , so edit file /storage/db/vpostgres/pg_hba.conf on VCSA and add following line to file. Be careful to do on right place to work correctly, exactly where IPv4 or IPv6 are mentioned.

    host    all             all            IPAddr/SubMsk       md5

Then edit /storage/db/vpostgres/postgresql.conf and add this line to made database for listening on all IP addresses: listen_addresses = '*'

And at the end of all, execute one of these commands to restart vpostgres service on VCSA and commit the changes have been done:

    /etc/init.d/vmware-vpostgres restart   or  service vmware-vpostgres restart

Also you can verify established connections on PostgreSQL port (TCP 5432) by running piping greps on netstat like this:

    netstat -anp | grep LISTEN | grep tcp | grep 5432

But if your server don't listen on port 5432, Try this:

    /usr/lib/applmgmt/networking/bin/firewall-reload

So you can verify your listening services by doing: iptables -L | grep postgres

 

Source of Content inside my personal blog: Undercity of Virtualization: Connect and Manage VCSA Database (PostgreSQL)

1. Built-in firewall rules:

As one of the first steps for ESXi  hardening you can start from limitation of permitted connections "To / From" the host and restricting unused transmits or blocking suspected traffics. So you may need to revision firewall rules and control what is permitted and what is not? or are their usage permanent or temporary for a specific time duration? Check your list again and for example if you always want to have permanently SSH access to your hosts, limit allowed IP addresses to only your management system IP address.

2. Using SNMP version 3:

Because of security nature of SNMP protocol on version3 in comparison with older versions 1 & 2 (based on support of encryption, authentication & hashing algorithms) it's strongly recommended to use SNMPv3. Old versions are using only a community string for SNMP communication that is clear-text data and certainly is a security breach. So for monitoring ESXi hosts, it's better to configure only SNMPv3 settings by "esxcli system snmp set --v3targets ... (I will explain how to do it in another post)

3. VIB Verification:

VIB or vSphere Installation Bundle is a package file (like a ZIP) contains of some installation files related to the ESXi. As the Kyle said there are 3 main parts of VIBs: Archive (Payload), XML (Descriptor) and a Signature file for trust level verification and you can configure it to each of 4 below mentioned acceptance level depends on your system management policies:

I.   Partner: VIB creating and testing will be done by partner and there is no VMware verification.

II.  VMware Certified: All processes will be done by VMware itself.

III. VMware Accepted: Testing will be done by partners but result verification rely on VMware.

IV. Community: All processes executed outside of VMware partner program and are not supported.

It's a good suggestion to don't trust to all community VIB packages

4. NTP configuration:

Time, Time and Time ... This is so important to remember to set it before doing every other configuration on your hosts. It's recommended to set at least one NTP server outside of your virtual infrastructure (like a router) for all of the hosts. ( I described it before on this post how to do it by CLI)

5. Versions of TLS:

It's always a real problem, Which version of TLS we should use on our managed hosts? and what version must be disabled? It's strongly recommended to use only TLS 1.2 but somehow maybe some of associated management products to the ESXi host can only communicate with older version. So before disable versions of 1.0 or 1.1, check this matter out.

 

Source of content inside my personal blog: Undercity of Virtualization: Security Recommendation and Hardening on Virtual Environments - Chapter I

routes inside the vCenter Server Shell. There is two ways to do that. One method is using "route add" command on shell access. For example:

# route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.100.1 dev eth0 

Result of this method is not persistent and will be clean after VCSA restart, Then it's useful only for testing or temporary situations. But if you want to save it, the Second way is editing of file *.network (such as 10-eth0.network) in and path "/etc/systemd/network" add intended routes in this form:

[Routes]

Destination=10.10.20.0/24

Gateway=10.10.100.2

Remember to add each route line in separated [Routes] brackets, otherwise it's not working as you expected. Then restart the network interface:

# ifdown eth0 | ifup eth0

or restart the networkd with these commands:

# systemctl restart systemd-networkd

# service network restart

And now if you want to check the results, run:

# route -n

# ip route show

https://3.bp.blogspot.com/-zfytKM3RkKQ/XERCGUlM0tI/AAAAAAAABco/qwuJmexLQhYY_s62eorOJbjNke07TNbrgCEwYBhgL/s1600/routes-list.PNG

Without shell access if you only login to VCSA console, there is many CLI for routing check and config, so you can use of these. To check them and how to use:

> routes.list --help

> routes.add --help

> routes.delete --help

> routes.test --help

Note I: There is another file here: "/etc/sysconfig/network/routes", if you view it's content, it will show only the system default gateway, no more routes will be shown here.

Note II: If you want to add routing to your ESXi hosts, just do:

# esxcli network ip route ipv4 add -n 10.10.20.0/24 -g 10.10.100.2

 

Source of content inside my personal blog: Undercity of Virtualization: Set Manual Routing for VCSA