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

VMworld 2020 | September 29 - October 1 | VMware

VMworld 2020 Will Be A Digital Event For The First Time 

VMworld 2020 is a unique online global experience that not only allows you to attend according to your time zone and schedule, but also choose your level of participation.

General Pass

Cost: Free    

Includes the following:    

7 live VMworld channels covering:
• Vision and Innovation
• App Modernization
• Digital Workspace
• Intrinsic Security
• Virtual Cloud Network
• Multi-Cloud
• Telco 5G

500+ on-demand VMworld sessions, including business-level overviews and technical deep dive sessions

Solutions Exchange, including VMware and sponsor demo zones

VMware Self-paced Hands-on Labs

Additional opportunities for learning and fun to be announced

Premier Pass

Cost: $299 (Limited Quantity)

Includes all the features of a General Pass PLUS:    

Includes the following:    

• Limited capacity sessions hosted in two time zones

  (UTC -7 and UTC +2)

• Roundtables: led by VMware experts, get answers to   technical VMware questions keeping you up at night

• Birds of a Feather: led by the VMware community,   participate in informal discussion focused on shared   professional interests

• VMware Hands-on Labs guided workshops

• 1:1 Expert Consultations

Additional opportunities for networking, learning, games and prizes

$100 off VMworld 2021 registration

Option to purchase a VCP certification exam voucher at 50% off*. (*Exams must be taken October 1 - 16, 2020. To receive the offer, you must purchase the voucher during VMworld registration.)

Register Now -->> https://www.vmworld.com/en/index.html

Help! I needed to vMotion a VM and the Migrate option is grayed!!!

Help! I needed to vMotion a VM and the Migrate option is grayed!!! 

A couple of weeks ago, I had to migrate a database server vm from one vSphere cluster to a new one. The vSphere Infrastructure is at version 6.7.

At the moment I selected the virtual server and tried to select from the Actions menu the Migrate option was grayed.

I didn't find any snapshot running, usb, vmware tools, virtual hw incompatibility or error, or the same problem on the rest of the virtual servers.

Checking deeper on the logs I found an error with the tsm4ve backup and doing some research i found that this issue occurs due to invalid entries from the VPX_DISABLED_METHODS table. In different kind of operations it's updated to disable migrations of a virtual machine. Some situations can cause these entries to persist after the operation is complete.

Follow this steps:

        1. Open a browser to https://vcenter fqdn or ip/mob and login using your Virtual Center Server admin password.

        2. Click RetrieveServiceContent under Methods.

        3. Click Invoke Method

        Note: Clicking Invoke Method may attempt to download a file the first time it runs. If so close the window                 and click the content hyperlink.

        4. Click the rootFolder: group-d1 (Datacenters).

5. To attain the ManagedObjectReference ID of your VSA virtual machine, follow these steps:

• Click the Datacenter that contains your VSA virtual machine under ChildEntity
• Under hostFolder select the folder. For example: group-h23 (host).
• Find the Datacenter under ChildEntity (if you have one).
• Click one of the ESXi hosts that contains a VSA virtual machine.
• Click the datastore that VM resides on. For example: datastore1
• Under vm copy the virtual machine’s ManagedObjectReference ID. For example: vm-110

6. To enable virtual machine operations, open the AuthorizationManager. It is hidden from the main vCenter Server M.O.B Web UI. You can access it through this URL: 

https://vcenter fqdn or ip/mob/?moid=AuthorizationManager&method=enableMethods

7. In the first parameter entity, replace the string MOID with the ManagedObjectReference ID you copied in step 5.
 
For example:
<!– array start –>
<entity type=”ManagedEntity” xsi:type=”ManagedObjectReference”>vm-110</entity>
<!– array end –>
  
8. To allow you to modify the VSA virtual machine, paste this list of operations in the second parameter method:




<method>RelocateVM_Task</method>



9. In the third parameter sourceId, paste the string: abracadabra.


10. Click Invoke Method.

VCPs and VCAPs Around the World: Where we are?

Where we are?

VMware Certified Professional (VCP) and VMware Certified Advanced Professional (VCAP) have been a highly popular certifications offered by VMware to validate our knowledge and skills. 

Enjoy the infographics provided by VMware Education Services.
 
You can find more info about

• Certifications and Badges
• Certification Levels
• Popular Certifications

at VMware Certifications. 

Welcome to Sympathy for the Devil and Virtualization Blog!

A couple of months ago I was thinking of starting a personal blog. Since I'm not a writer for me it’s hard to know where and how to start.

I grabbed a cup of coffee, settled down and started outlining the uniting content I’ll going to share. The focus will be on troubleshooting, tips and tricks on VMware vSphere, Site Recovery Manager, other products and also VMware Certification Roadmaps.

I hope you find this blog useful and I look forward to your feedback.

Fernando A. Perez
VMware VCP6-DCV | VCP-DCV 2019 | VCP-DCV 2020
"If you want something you've never had, you must be willing to do something you've never done." - Thomas Jefferson.