Most of the VMware virtual machines are configured with few virtual disks with different size according to the project requirement. When it comes to the Linux VM , there will be a dedicated disk for the root filesystem and other disks are used for application/data. So whenever there is request for resizing the existing drive , it is very easy to figure-out with fewer disks with help of variable size. But how do you map if any VM is running with 50+ virtual disks and fewer disks are directly mapped from the SAN using RDM(Raw Device Mapping) method. It’s quite complicated thing. In this article , we will find an easy solution to map the Virtual Machine disks to Linux disks or vise-versa.
Here the my virtual Machine disks details:
Here , I have added one more disk from SCSI controller 3.
- Hard Disk 1 – 8GB (SCSI 0.0)
- Hard Disk 2 – 1GB (SCSI 0.1)
- Hard Disk 3 – 1GB (SCSI 0.2)
- Hard Disk 4 – 1GB (SCSI 3.15)
In the Linux VM:
[root@UA-RHEL7 ~]# df -h |grep u0 /dev/sdb 1014M 33M 982M 4% /u01 /dev/sdc 1014M 33M 982M 4% /u02 /dev/sdd 1014M 33M 982M 4% /u03 [root@UA-RHEL7 ~]# [root@UA-RHEL7 ~]# fdisk -l /dev/sda Disk /dev/sda: 8589 MB, 8589934592 bytes, 16777216 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000c7226 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 16777215 7875584 8e Linux LVM [root@UA-RHEL7 ~]#
- /dev/sda – 8GB
- /dev/sdb – 1GB
- /dev/sdc – 1GB
- /dev/sdd – 1GB
Disks Mapping (VMware virtual machine to Linux)
From the above screenshots and Linux disks lists , we are able to map only one disk with the help of size.
- Hard disk 1 – 8GB (SCSI 0.0) (VMware ) = /dev/sda – 8GB (Linux)
What about other three disks ? How can we map it ?
1. Login to Linux VM and execute the dmesg command with “grep” function like below.
[root@UA-RHEL7 ~]# dmesg |grep -i attached |grep disk [ 1.465282] sd 0:0:1:0: [sdb] Attached SCSI disk [ 1.465695] sd 0:0:0:0: [sda] Attached SCSI disk [ 53.458928] sd 0:0:2:0: [sdc] Attached SCSI disk [ 1818.983728] sd 3:0:15:0: [sdd] Attached SCSI disk [root@UA-RHEL7 ~]#
2. In the above screenshots , you might seen the SCSI id’s for each disks. Just compare the VMware SCSI ID’s with Linux guest SCSI id. Apart from the no of digits , both SCSI id’s are identical and this is the easiest way of mapping the disks.
Linux Disk Name | Linux SCSI ID | VMware SCSI ID | Size of the Disk | VMware Disk Number |
/dev/sda | 0:0:0:0 | 0.0 | 8GB | Hard Disk 1 |
/dev/sdb | 0:0:1:0 | 0.1 | 1GB | Hard Disk 2 |
/dev/sdc | 0:0:2:0 | 0.2 | 1GB | Hard Disk 3 |
/dev/sdd | 3:0:15:0 | 3.15 | 1GB | Hard Disk 4 |
But in some cases(RDM disk are assigned to VM) , the above mapping is not sufficient to map the VMware guest disks. You might require another validation prior to confirming the disk mapping.
1. Login back to Linux VM and execute the below command. Just look at the “sgx” numbers . (sg0, sg1, sg2, sg3, sg4)
[root@UA-RHEL7 ~]# dmesg |grep sg |grep Attached [ 10.220942] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 10.220974] sd 0:0:1:0: Attached scsi generic sg1 type 0 [ 10.221002] sr 2:0:0:0: Attached scsi generic sg2 type 5 [ 53.458334] sd 0:0:2:0: Attached scsi generic sg3 type 0 [ 1818.958156] sd 3:0:15:0: Attached scsi generic sg4 type 0 [root@UA-RHEL7 ~]#
2. The “sgX” numbers will be always stays in the “N-1” to the VMware disk numbers. So just do N+1 for sgX to match the VMware Disk numbers. Let me bring up the table for you.
We have successfully mapped the VMware guest’s virtual disks to Linux OS disks. Its always recommended to perform multiple checks to confirm the disk mapping. The above testing have been performed on VMware vSphere 6.x and Redhat Linux 7.x .
Hope this article is informative to you .
numberOne says
Hi,
This won’t work for me:
# dmesg |grep -i attached |grep sdv
[ 0.945572] sd 1:0:6:0: [sdv] Attached SCSI disk
# lsscsi –device|grep sdv
[1:0:6:0] disk VMware Virtual disk 1.0 /dev/sdv [65:80]
# fdisk -l /dev/sdv|grep Disk
Disk /dev/sdv: 268.4 GB, 268435456000 bytes, 524288000 sectors
but in Vmware it has the wrong size:
Hard Disk 22 150 GB SCSI(1,6)
There are a totel of 54 discs on the VM client.
Virtualgeekster says
Hey this doesnt work.
Id appreciate some help on this, I am getting random IDs in my environment.
Marcus Ba says
This command is better
#udevadm info -q all -n /dev/sda | grep -i phy
And you need to find phy##-lun0 for scsi controller 0
Kalle says
Followed this guide to remove multiple disks in vSphere, and to start with it looked promising. But after removing the first disk, I found the Disk numbers i vSphere was updates. Removing Disk 10 caused Disk 11 to be the new 10 etc.
Ended up in resizing all disk to some odd sizes to be able to identify them.
Fabio says
Very helpful.
However you fail to notice that the command
dmesg |grep sg |grep Attached
will also list the Virtual CD ROM, and that would be the 3rd line in your example output
sr 2:0:0:0: Attached scsi generic sg2 type 5
For all the disks above the CD ROM the VMware number is x+1 (where x is the number following sg)
But for those listed below the CD ROM it is just x
Note also that most of the times the CD ROM will be listed at the top, thus for most drives the corresponding VMware disk file will be x and not x+1.
Thomas says
I know this is old, but wanted to suggest instead for RDM to use “ls -al /dev/disk/by-id/”
it will provide lines like wwn-0x60050768018087935800000000000537 -> ../../sde
Inside vmware gui you can find that number in the middle of the vml for the disk.
Edit settings on the VM, then Open the disk in question and see the Physical Lun line.
No fancy mapping, and no errors as the linux admin, the VMware admin, and the SAN team can talk the same language.
toloo says
the solution is :
from esx : for i in `ls *.vmdk | grep -v flat ` ; do echo $i ; vmkfstools -J getuuid $i ;done
from vm : for i in /dev/sd* ; do echo $i ;scsi_id $i ;done
and compare
toloo says
vmx file scsi pci slot number
scsi0.pciSlotNumber = “160”
scsi1.pciSlotNumber = “256”
scsi2.pciSlotNumber = “1216”
scsi3.pciSlotNumber = “1248”
toloo says
r 1:0:0:0: Attached scsi generic sg0 type 5
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 3:0:0:0: Attached scsi generic sg2 type 0
sd 3:0:1:0: Attached scsi generic sg3 type 0
sd 4:0:0:0: Attached scsi generic sg4 type 0
sd 4:0:1:0: Attached scsi generic sg5 type 0
sd 5:0:0:0: Attached scsi generic sg6 type 0
sd 5:0:1:0: Attached scsi generic sg7 type 0
sd 5:0:2:0: Attached scsi generic sg8 type 0
sd 5:0:3:0: Attached scsi generic sg9 type 0
toloo says
It should be like this , but it isn’t . Do not suggest on this instruction!!!!!!!!!!!!!!!
in my case all scsi paravirtual
guest vm Red Hat Enterprise Linux Server release 6.6 (Santiago)
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0
[2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda hard disk 1 scsi (0:0) in vsphere
[3:0:0:0] disk VMware Virtual disk 1.0 /dev/sdb can’t determine for 100% sure
[3:0:1:0] disk VMware Virtual disk 1.0 /dev/sdc can’t determine for 100% sure
[4:0:0:0] disk VMware Virtual disk 1.0 /dev/sdd can’t determine for 100% sure
[4:0:1:0] disk VMware Virtual disk 1.0 /dev/sde can’t determine for 100% sure
[5:0:0:0] disk VMware Virtual disk 1.0 /dev/sdf hard disk 2 scsi (1:0) in vsphere
[5:0:1:0] disk VMware Virtual disk 1.0 /dev/sdg hard disk 3 scsi (1:1) in vsphere
[5:0:2:0] disk VMware Virtual disk 1.0 /dev/sdh hard disk 4 scsi (1:2) in vsphere
[5:0:3:0] disk VMware Virtual disk 1.0 /dev/sdi hard disk 5 scsi (1:3) in vsphere
ELB says
There is a bug in your logic . 0.0.2.0 is listed as sg3 in dmesg |grep sg |grep Attached
so should be Hard Disk 4 !! but you map is as Disk3 !!
Jim says
I was following you up until the end, then I got confused. By comparing the linux guest and vmware scsi id’s, you’ve determined your /dev/sdc is disk 3 in vmware, but in the last part it says sg3, so wouldn’t +1 be sg4, and not correspond with the disk number?
Lingeswaran R says
When you have RDM (Raw Device Mapping), then the VM disks numbers are distributed. In my case , +1 worked.
If you do not have RDM ,you can ignore last two steps ..
Regards
Lingesh