Mismatch in SCSI controllers between vSphere and Linux using pvscsi driver

A few days ago, I had to remove some disks from a linux virtual database server. When I received the sizes and SCSI ID from device names, I compared them and found that they did not match. The server had 4 paravirtual controllers and many disks. So to be sure about what I had to remove I had to see how to map a SCSI device with the virtual disk configured in the virtual machine. This can be accomplished by comparing the SCSI ID listed in the Linux Guest operating system and the virtual machine configuration. 

From the the guest os side run 

[root@linuxdbsrv ~]# lsscsi -w

[0:0:0:0]    disk    0x6000c2945521671d0c476cdbecfd76a3  /dev/sda

[0:0:1:0]    disk    0x6000c295c91dfd6f02cfe3605badf928  /dev/sdb

[0:0:2:0]    disk    0x6000c29002870543f54f495d7ae05477  /dev/sdc

[0:0:3:0]    disk    0x6000c29b33acea6a7429359befa28782  /dev/sdd

[0:0:4:0]    disk    0x6000c294ac8f64855d703991b8314833  /dev/sde

[0:0:5:0]    disk    0x6000c297c2613875bc61c908e9166017  /dev/sdf

[0:0:6:0]    disk    0x6000c294200d2f4c7c081c2873d2111b  /dev/sdg

[0:0:8:0]    disk    0x6000c298eea0dc918a36b8f0465a5d30  /dev/sdh

[0:0:9:0]    disk    0x6000c292d70c33a62b1a3ebc94aedc74  /dev/sdi

[1:0:2:0]    disk    0x6000c298639718de1196e12086828c05  /dev/sdl

[1:0:3:0]    disk    0x6000c291b629e817469aeaa3963dee10  /dev/sdm

[1:0:4:0]    disk    0x6000c29918f96c6d98fe773533bb3bc0  /dev/sdn

[1:0:5:0]    disk    0x6000c290b051f741501ec4c1f596a41c  /dev/sdo

[1:0:6:0]    disk    0x6000c29b63027d2f33730a4de80bd6af  /dev/sdp

[1:0:8:0]    disk    0x6000c29e401ce8d48ed13db70457ac35  /dev/sdq

[1:0:9:0]    disk    0x6000c29a2c37977c710e0faa1702e690  /dev/sdr

[1:0:10:0]   disk    0x6000c29b251db3780226813fa010071a  /dev/sds

[1:0:13:0]   disk    0x6000c29bf9bdbb740cd23c5f8557a2a3  /dev/sdv

[1:0:14:0]   disk    0x6000c294841557a36af83b6235da0ad5  /dev/sdw

[2:0:0:0]    disk    0x6000c2947e954bf3c0b53f8196c4c1a8  /dev/sdx

[2:0:1:0]    disk    0x6000c294f5f81232dced2500353c39e8  /dev/sdy

[2:0:2:0]    disk    0x6000c29adfa81cdda82bcdccda0e7b7f  /dev/sdz

[2:0:10:0]   disk    0x6000c2940b6e96f65acfa97d48992cf1  /dev/sdag

[2:0:11:0]   disk    0x6000c29433619f3195ded54ccfea9e54  /dev/sdah

[2:0:12:0]   disk    0x6000c29d53073ceb21b754d1bcd05f10  /dev/sdai

[2:0:13:0]   disk    0x6000c2968b0449f5254a3e6864f5a873  /dev/sdaj

[2:0:14:0]   disk    0x6000c29eb466fa018b710a53f35bbb1c  /dev/sdak

[2:0:15:0]   disk    0x6000c29abdd276550ab43c1fd125b086  /dev/sdal

[3:0:0:0]    disk    0x6000c29e8605f713580c4af5524b30e0  /dev/sdam

[3:0:1:0]    disk    0x6000c2930529942096c5b33a8d87d12a  /dev/sdan

[3:0:2:0]    disk    0x6000c29fce26a8044fe3b5c09bc41ee8  /dev/sdao

[3:0:3:0]    disk    0x6000c29d99f62da321ca4b50be19d1b2  /dev/sdap

[3:0:4:0]    disk    0x6000c29f4eac6b7aa542d68c2a309679  /dev/sdaq

[3:0:5:0]    disk    0x6000c29c32b361d715cffef30955f565  /dev/sdar

[3:0:6:0]    disk    0x6000c290e400eaa7d24a74bbf694a857  /dev/sdas

[3:0:8:0]    disk    0x6000c29ab928c2c98a0cfbea1ecceb57  /dev/sdat

Using PowerCli obtain information about disks from the vm.

PS C:\> Connect-vIServer vcenterserver

PS C:\> Get-VM linuxdbsrv | Get-HardDisk | Select @{N='VM';E={$_.Parent}},@{N='Disco';E={$_.Name}}, @{N='UUID';E={$_.ExtensionData.Backing.Uuid}}

VM             Disco        UUID

--             -----        ----

linuxdbsrv Hard disk 1  6000C290-0287-0543-f54f-495d7ae05477

linuxdbsrv Hard disk 2  6000C29e-8605-f713-580c-4af5524b30e0

linuxdbsrv Hard disk 3  6000C293-0529-9420-96c5-b33a8d87d12a

linuxdbsrv Hard disk 4  6000C29f-ce26-a804-4fe3-b5c09bc41ee8

linuxdbsrv Hard disk 5  6000C29d-99f6-2da3-21ca-4b50be19d1b2

linuxdbsrv Hard disk 6  6000C29f-4eac-6b7a-a542-d68c2a309679

linuxdbsrv Hard disk 7  6000C29c-32b3-61d7-15cf-fef30955f565

linuxdbsrv Hard disk 8  6000C290-e400-eaa7-d24a-74bbf694a857

linuxdbsrv Hard disk 9  6000C29a-b928-c2c9-8a0c-fbea1ecceb57

linuxdbsrv Hard disk 16 6000C298-6397-18de-1196-e12086828c05

linuxdbsrv Hard disk 17 6000C291-b629-e817-469a-eaa3963dee10

linuxdbsrv Hard disk 18 6000C299-18f9-6c6d-98fe-773533bb3bc0

linuxdbsrv Hard disk 19 6000C290-b051-f741-501e-c4c1f596a41c

linuxdbsrv Hard disk 20 6000C29b-6302-7d2f-3373-0a4de80bd6af

linuxdbsrv Hard disk 21 6000C29e-401c-e8d4-8ed1-3db70457ac35

linuxdbsrv Hard disk 22 6000C29a-2c37-977c-710e-0faa1702e690

linuxdbsrv Hard disk 23 6000C29b-251d-b378-0226-813fa010071a

linuxdbsrv Hard disk 26 6000C294-7e95-4bf3-c0b5-3f8196c4c1a8

linuxdbsrv Hard disk 27 6000C294-f5f8-1232-dced-2500353c39e8

linuxdbsrv Hard disk 28 6000C29a-dfa8-1cdd-a82b-cdccda0e7b7f

linuxdbsrv Hard disk 35 6000C294-0b6e-96f6-5acf-a97d48992cf1

linuxdbsrv Hard disk 36 6000C294-3361-9f31-95de-d54ccfea9e54

linuxdbsrv Hard disk 37 6000C29d-5307-3ceb-21b7-54d1bcd05f10

linuxdbsrv Hard disk 25 6000C29b-33ac-ea6a-7429-359befa28782

linuxdbsrv Hard disk 29 6000C294-ac8f-6485-5d70-3991b8314833

linuxdbsrv Hard disk 34 6000C297-c261-3875-bc61-c908e9166017

linuxdbsrv Hard disk 33 6000C294-200d-2f4c-7c08-1c2873d2111b

linuxdbsrv Hard disk 32 6000C296-8b04-49f5-254a-3e6864f5a873

linuxdbsrv Hard disk 31 6000C294-5521-671d-0c47-6cdbecfd76a3

linuxdbsrv Hard disk 30 6000C295-c91d-fd6f-02cf-e3605badf928

linuxdbsrv Hard disk 24 6000C29b-f9bd-bb74-0cd2-3c5f8557a2a3

linuxdbsrv Hard disk 15 6000C298-eea0-dc91-8a36-b8f0465a5d30

linuxdbsrv Hard disk 14 6000C294-8415-57a3-6af8-3b6235da0ad5

linuxdbsrv Hard disk 13 6000C292-d70c-33a6-2b1a-3ebc94aedc74

linuxdbsrv Hard disk 12 6000C29e-b466-fa01-8b71-0a53f35bbb1c

linuxdbsrv Hard disk 11 6000C29a-bdd2-7655-0ab4-3c1fd125b086

linuxdbsrv Hard disk 10 6000C292-db59-6901-cc66-9f780686c7a5

In yellow I marked an example with the match using de UUID's.

vSphere 7: Performing a Reconfigure for VMware HA operation on a primary node causes an unexpected virtual machine failover

After enable Skyline Health you may see error telling you something like this:

“When you perform a Reconfigure for VMware HA operation on the primary node in an HA cluster, an unexpected virtual machine failover occurs for the virtual machines running on that primary node.

When the primary HA host is manually reconfigured for HA, it causes the remaining secondary host to enter an election to find a new primary host.

The newly elected primary host places the virtual machines that were running on the old primary host in an unknown power state, and waits for up to 10 seconds for notification that the virtual machines on the old primary host are powered on and running.

If the old primary host does not become secondary within that 10-second interval, the new primary host assumes that the virtual machines are down, and attempts to restart them. This causes a false failover event to occur, and consequently the failover task fails because the virtual machines were never powered off. The virtual machines remain unaffected in this scenario.

To resolve this issue, increase the monitor period:
Notes: 

• Starting with vCenter Server 7.0 Update 1, the Property name for fdm.policy.unknownStateMonitorPeriod has changed to fdm.unknownStateMonitorPeriod.
• The das.config can be prefixed to these properties, which when completed can apply to all the hosts in the cluster.

    1. In vCenter, right-click the cluster and select Edit Settings.

    

2. Click vSphere HA and then Advanced Options.

    

3. Add a new option (if not already present)
        For 7.0U1 or greater:
            Default Option is 10
            das.config.fdm.unknownStateMonitorPeriod = 10
        Pre 7.0U1:
            das.config.fdm.policy.unknownStateMonitorPeriod = 10

        For this issue change the value from 10 to 30.

        For 7.0U1 or greater:
            das.config.fdm.unknownStateMonitorPeriod = 30
        Pre 7.0U1:
            das.config.fdm.policy.unknownStateMonitorPeriod = 30

    

4. Disable and re-enable HA settings of the cluster.

Vmware Tanzu Vanguard

The VMware Tanzu Vanguard is a select group of active customers, cloud users, and practitioners that are passionate about our products and services. They openly share their experiences and knowledge with the community and the industry.

MEMBER BENEFITS

Access to VMware Tanzu product and service groups

Exclusive invitations to our conferences and user group meetups

Networking with a small group of peers to get complex IT challenges solved

Recognition and rewards for contributions and achievements

Digital Tanzu Vanguard badges

Community-branded swag

Detailed information about the program can be found at: https://tanzu.vmware.com/vanguard

Want to join?

Sign up today! https://tanzu.vmware.com/vanguard#join

When you do, please say that you come from me, @Fernando Perez