Contents

Previous Next

Configuring Dual- or Multiple-Boot SCSI Systems to Run with VMware GSX Server on a Linux Host
It may be possible to configure GSX Server so that you can use an operating system already installed and configured on a SCSI disk as a guest operating system inside a GSX Server virtual machine.
Using an existing physical SCSI disk — also called a 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 Physical Disks.
Before You Create the Virtual Machine Configuration
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.
1. Before starting, you should read Setting Up Hardware Profiles in Virtual Machines if you are running a Windows guest operating system. You should boot the guest operating system natively on the computer and create a hardware profile for the virtual machine before proceeding.
2. Check to see what SCSI ID is set for the drive you plan to use in the virtual machine.
3. Make certain that in addition to any SCSI drivers you have configured for the host, you have also installed the driver for a Mylex® (BusLogic) BT/KT-958 compatible host bus adapter. Drivers for BusLogic controllers are available from the LSI Logic Web site — www.lsilogic.com. Search the site for Mylex BusLogic BT/KT-958.
The BusLogic driver needs to be installed in the profile for the guest operating system.
Note: To use SCSI devices in a Windows XP virtual machine, you need a special SCSI driver available from the download section of the VMware Web site at www.vmware.com/download.
4. Check operating system partition mounts. Be sure the existing physical disk partitions that you plan to configure the virtual machine to use are not mounted by the Linux host.
Caution: A physical disk partition should not be used (mounted) simultaneously by the host and the guest operating system. Because each operating system is unaware of the other, data corruption may occur if both operating systems read or write to the same partition. It is critical that the virtual machine not be allowed to modify any partition mounted under the Linux host or in use by another virtual machine. To safeguard against this problem, be sure the partition you use for the virtual machine is not mounted under the Linux host.
5. Set the device group membership or device ownership. The master physical disk devices must be readable and writable by the user who runs GSX Server. On most distributions, the raw devices (such as /dev/hda and /dev/hdb) belong to group ID disk. If this is the case, you can add GSX Server users to the disk group. Another option is to change the owner of the device. Please think carefully about security issues when you explore different options here.
It is typically a good idea to grant GSX Server users access to all /dev/hd[abcd] raw devices that contain operating systems or boot managers and then rely on GSX Server's physical disk configuration files to guard access. This provides boot managers access to configuration and other files they may need to boot the operating systems. For example, LILO needs to read /boot on a Linux partition to boot a non-Linux operating system that may be on another drive.
6. If you plan to run a second Linux installation from an existing partition as a guest operating system, and your physical machine's /etc/lilo.conf has a memory register statement such as Append= "mem...", you may want to adjust the append memory parameter or create a new entry in LILO for running Linux in a virtual machine.
Many newer Linux distributions recognize all physical memory in the physical machine, whereas many older Linux distributions see only the first 64MB of memory by default. Machines with more than 64MB of memory that run the older distributions may have the Append= "mem=..." parameter added under the Image=... section of lilo.conf to tell Linux to look for more memory than seen by default.
If the amount of memory configured in lilo.conf exceeds the amount of memory assigned to the virtual machine, the guest operating system is likely to panic when the virtual machine tries to boot the second Linux installation.
You can create another entry in lilo.conf for running Linux in a virtual machine by specifying a different amount of memory than what should normally be recognized when Linux boots directly on the physical machine.
Setting Up the Virtual Machine Configuration
1. Launch the VMware Virtual Machine Console.
2. Start the New Virtual Machine Wizard (File > New > New Virtual Machine) and select Custom.
3. When you reach the Select a Disk step, select Use a physical disk. The Select a Physical Disk screen appears.
Link to w_newvm_phys_sel.png
4. In the Device list, select the physical drive.
Under Usage, select whether to use the entire disk or individual partitions.
If you selected Use entire disk, click Next then go to step 5.
If you selected Use individual partitions, the Select Physical Disk Partitions screen appears.
Link to w_newvm_phys_part_sel.png
Select the partitions you want the virtual machine to use, then click Next.
5. In the entry field, enter a name of your choice for the physical disk.
Caution: If you browse to place the disk file in another directory, do not select an existing virtual disk file.
To specify a device ID for the physical disk, click Advanced. In the Virtual device node list, select the SCSI ID that corresponds to the one used by your SCSI drive. For example, if your SCSI drive has SCSI ID 2, select SCSI 0:2. If you do not know the SCSI ID set on your physical SCSI drive, try using SCSI 0:0.
On the advanced settings screen, you can also specify a disk mode. This is useful in certain special-purpose configurations in which you want to exclude disks from the snapshot. For more information on the snapshot feature, see Taking Snapshots.
Normal disks are included in the snapshot. In most cases, this is the setting you want.
Independent disks are not included in the snapshot. You have the following options for an independent disk:
  • Persistent — changes are immediately and permanently written to the disk.
  • Nonpersistent — changes to the disk are discarded when you power off or revert to the snapshot.
    • When you have set the filename and location you want to use and have made any selections you want to make on the advanced settings screen, click Finish.
    6. Begin using your virtual machine.
    Known Issues and Background Information on Using SCSI Physical Disks
    Some known issues with SCSI physical disks involve disk geometry, appropriate drivers and operating system configuration.
    Geometry
    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, GSX Server might crash or GSX Server 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:
    Disk size
    Heads
    Sectors
    <= 1GB
    64
    32
    > 1GB and <= 2GB
    128
    32
    > 2GB
    255
    63
    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.
    Drivers
    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 is likely not 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.
    Operating System Configuration
    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 /etc/fstab and other configuration files.
    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 physical disk configured as SCSI ID 3 on the host and as SCSI ID 0 in your virtual machine's 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 physical disks in a virtual machine using the same SCSI ID as they use on the host.


    Previous Next