VMware Workstation 4Features | Documentation | Knowledge Base | Discussion Forums
It may be possible to configure VMware Workstation so that you can use an operating system already installed and configured on a SCSI disk as a guest operating system inside a VMware Workstation virtual machine.
Using an existing SCSI disk - or SCSI raw disk - inside a virtual machine is supported only if the host has a BusLogic SCSI adapter. It may be possible to configure a host with a different SCSI adapter so the same operating system can be booted both natively and inside a virtual machine, but this approach is not supported by VMware. For details on some of the key issues involved, see Known Issues and Background Information on Using SCSI Raw Disks.
You must create a separate configuration for each guest operating system. Allow read and write access to the partitions used by that operating system only.
In some cases, it is not possible to boot a raw SCSI drive inside a virtual machine because the SCSI adapter in the physical computer and the BusLogic adapter in the virtual machine describe the drive in different ways. The virtual machine might hang during the boot, VMware Workstation might crash or VMware Workstation might fail with an ASSERT or other error message.
This problem is most likely to affect smaller drives - less than 2GB.
In order to share the same BIOS interface used by IDE disks (which is required in order to boot), all SCSI disks need to have a geometry, which is a fabricated value for the number of cylinders, sectors and heads on the disk.
In fact, a SCSI disk appears to a computer as a single flat entity from sector 1 up to the highest sector on the disk. As a result, every SCSI vendor has its own approach to taking the capacity of a SCSI disk and generating a geometry to use for booting.
The conversion from a given geometry to an absolute sector number depends on the geometry. If you have a disk with a boot sector written by a program running on the host and you try to boot that disk inside a virtual machine, the boot program can fail if the host geometry does not match the geometry used by the BusLogic virtual SCSI adapter. The symptoms are that you see the first part of the boot loader - possibly an LI from LILO, for example - but then the boot either stops or crashes.
BusLogic uses the following rules for generating disk geometries:
In each case the number of cylinders is calculated by taking the total capacity of the disk and dividing by (heads*sectors). Fortunately, for sufficiently big disks, practically all vendors use 255 heads and 63 sectors.
In contrast to IDE adapters, SCSI adapters are not interchangeable and cannot all use the same drivers. That is, if you have an Adaptec SCSI host adapter in your machine and you remove it and replace it with a BusLogic SCSI host adapter, your operating system will most likely fail to boot unless you install a BusLogic driver.
Dual booting from a disk that is also used as a virtual disk is no different. To your operating system, it appears that the SCSI card in the machine suddenly changed from whatever you own to a BusLogic card, and your operating system needs to have a valid BusLogic driver installed. If that driver is not installed, you get a panic, a blue screen or some similar fatal error as soon as the boot process tries to switch from the BIOS bootstrap to the disk driver installed in the operating system.
Many operating systems have configuration information that is different for SCSI and IDE drives. For example, Linux uses /dev/hd[x] as the device name for IDE disks and /dev/sd[x] for SCSI disks. References to these names appear in
This is one reason that booting a raw IDE disk as a SCSI disk or vice versa does not work well (if at all).
However, even when you are dealing only with SCSI devices, it is possible for an operating system to encode information in a way that causes problems when you are dual booting. For example, Solaris names its SCSI disks /dev/c[x]t[y]d[z]s0, where the y represents the SCSI ID. So if you had a raw disk configured as SCSI ID 3 on the host and as SCSI ID 0 in your VMware Workstation configuration file, it would move if you were running Solaris, and most likely Solaris would not boot.
The precise dependencies in various operating systems can be complex. That is why it is safest to configure SCSI raw disks in a virtual machine using the same SCSI ID as they use on the host.