Mark_Bayliss
Contributor
Contributor

Adding physical disks

Hey All,

We have a mac server running leopard and wish to run Windows 2008 x64 within fusion. The server itself has 3x 1TB drives configured as RAID 5. I wish to mount or connect these physical drives to our Windows 2008 virtual machine but not sure how to do this. I cannot find any GUI option for this. Is there a way to do this from terminal?

Thanks in advance.

Regards,

Mark

0 Kudos
8 Replies
gbullman
Expert
Expert

You can certainly access the RAID 5 logical disk as a share, I don't believe you can have the same physical disk mounted on 2 OSs at the same time without something to mediate access involved.

If you turn on File sharing on the Mac and then go to Fusion Virtual Machines->Settings Sharing you should be able to map whatever you need access to within the Guest OS.

0 Kudos
asatoran
Immortal
Immortal

There is no GUI way to add a physical disk in Fusion. In Workstation, you can add a physical disk through the GUI, but in Fusion you'll have to modify the VMX file. I do not know the specific entries, ('ve never had a need to) and I don't know if it's really possible in Fusion. You can browse the Workstation instructions or support knowledgebase but I haven't seen any Fusion specific instructions. And as always, the usual warning about this being dangerous stuff only for advanced users and you should have backups, yada, yada, yada. Unless there is some specific need, safer to just create a virtual hard drive and store the VMDK on that array.

0 Kudos
Mark_Bayliss
Contributor
Contributor

Thanks for the reply all.

We have another volume that is 1.8TB in size and wish to add this to the Windows 2008 virtual machine. I am certain that VMDK's cannot be bigger than 1.2TB in size hence why I am asking if its possible to add the physical disks directly to the VM in fusion.

Any other options you may know of? Shared folders is not what I really want cause I need proper NTFS ACL permissions and so on.

Regards,

Mark

0 Kudos
asatoran
Immortal
Immortal

Any other options you may know of? Shared folders is not what I really want cause I need proper NTFS ACL permissions and so on.

Perhaps multiple VMDKs, then use Windows built-in software RAID to present the virtual array as one drive. Not the most elegant and probably has some data throughput performance loss, but the advantage is you still remain completely virtual so retain portability for the future....and no dangerous messing with the VMX file. Smiley Happy

0 Kudos
WoodyZ
Immortal
Immortal

If you turn on File sharing on the Mac and then go to Fusion Virtual Machines->Settings Sharing you should be able to map whatever you need access to within the Guest OS.

You do not need to turn on OS X File Sharing to use VMware Shared Folders. Only turn on OS X File Sharing if you need to use SMB/CIFS Shares independent and separate from VMware Shared Folders. In other words the two have nothing to do with each other.

0 Kudos
mudaltsov
Expert
Expert

Before Fusion 2.0.5, virtual disks were limited to 950 GB. That limitation has been removed in order to support Boot Camp disks up to 2 TB, but I think that file-based VMDKs haven't been extensively tested larger than 950 GB yet, especially with sparse disks and snapshots. So the Fusion UI and vmware-vdiskmanager still have the 950 GB limit, which means there's currently no simple way to create a virtual disk larger than 950 GB.

However, you can definitely use the physical disk (or in your case, the logical volume on the RAID array) with Fusion, without using file-based virtual disks or shared folders. There are two possible ways to do this.

Method 1: use rawdiskCreator

Fusion uses rawdiskCreator to set up virtual disks that reference the Boot Camp partition on the physical disk. In order to use rawdiskCreator, the disk device must be smaller than 2 TB, and must use the MBR partitioning scheme. It's a command-line tool located in /Library/Application Support/VMware Fusion/vmware-rawdiskCreator

1. The disk has to be partitioned before you start. The easiest way is to use Disk Utility, but you would need NTFS-3G to format the partition as NTFS (personally I wouldn't recommend it for general use - it's had some kernel panics on my system). You may also be able to partition the disk using fdisk in Terminal, but I haven't tried it.

2. Run vmware-rawdiskCreator print /dev/diskN with N changed to the appropriate disk number (use Disk Utility or diskutil list to get it if you're not sure). This should show you the partition information, something like this:

Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
 1         63   -2097274 BIOS  7 HPFS/NTFS

(ignore the negative size - that's a side effect of partitions larger than 1 TB)

3. To create the virtual disk, run vmware-rawdiskCreator create /dev/diskN 1 /path/to/raw_disk ide with N and /path/to/raw_disk substituted appropriately. This will create /path/to/raw_disk.vmdk (virtual disk that references the partition) and /path/to/raw_disk-pt.vmdk (copy of the partition table used by the virtual disk).

4. Skip to the Adding the disk to the VM section.

Method 2: create a VMDK referencing the whole disk (not officially supported)

The alternative is to manually create a VMDK file that references the entire disk device. This will allow you to use disks larger than 2 TB (with a GUID Partition Table), and it's simpler than rawdiskCreator since it uses the whole disk and doesn't require partitioning beforehand. Note that this is not a common configuration, and as far as I know it's not typically tested in Fusion. However, I believe that the underlying disk IO works the same way as it does for Boot Camp VMs, so it should be ok. I have tried this with a physical 250 GB disk, and a 3 TB sparse disk image (used as if it was a disk device), and both appear to work correctly. So you're welcome to try it, just keep backups of important data!

1. Run diskutil info /dev/diskN to find out the sector size of the disk. You should see a line like this:

Total Size:               3.0 Ti (3298534903808 B) (6442450984 512-byte blocks)

2. Create a text file with these contents:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="fullDevice"

# Extent description
RW 6442450984 FLAT "/dev/diskN" 0

# The Disk Data Base 
#DDB

ddb.geometry.cylinders = "401024"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.geometry.biosCylinders = "401024"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosSectors = "63"
ddb.adapterType = "ide"

You'll have to change the size (6442450984) to the block size from step 1, and replace /dev/diskN with the actual disk number. Also, change the ddb.geometry.cylinders and ddb.geometry.biosCylinders to (blockSize / (255*63)), rounded down. These values are for backward compatibility, so I'm not sure if they are actually used anywhere, but it shouldn't hurt to keep them correct.

3. Save the text file with a .vmdk extension.

There's one catch: Any partitions on the disk have to be unmounted in OS X before powering on a VM with this disk, otherwise you'll get an access denied error. If you don't want OS X to mount the disks at every boot, you can add some entries to your /etc/fstab file, as described here: http://www.macosxhints.com/article.php?story=20060930150059172

Adding the disk to the VM

After you've got the .vmdk file ready, you'll need to edit the virtual machine's .vmx config file, and add the disk manually (you can add it through the Fusion UI, but the config file would still need to be edited). The following lines need to be added:

ide0:0.present = "TRUE"
ide0:0.fileName = "/path/to/raw_disk.vmdk"
ide0:0.redo = ""
ide0:0.mode = "independent-persistent"

Again, modify the path according to where the disk is. If you place the .vmdk file directly in the VM bundle, you can just use a filename instead of an absolute path.

You may also need to change 0:0 to 0:1, 1:0, or 1:1 depending on which other IDE devices your VM already has. The CD/DVD drive is typically attached to 1:0.

The independent-persistent mode is important - it specifies that the data should be written directly to the disk, and that it should not be part of snapshots. It will also cause snapshots to be disabled while the VM is running to avoid inconsistent disk contents. You can still take snapshots with the VM's main virtual disk while the VM is powered off. Technically, there should also be a line ide0:0.deviceType = "rawDisk" but that would disable snapshots altogether.

<br/>

I hope this helps. I would be great to know if this works for you.

One more thing - the disk number may change between boots, or if the disk is external and you unplug it and plug it back in after mounting other disks. If that happens, you may need to edit the .vmdk file and change the /dev/diskN value to point to the appropriate disk again. In the rawdiskCreator case, it will be using a specific partition, such as /dev/disk2s1.

0 Kudos
Mark_Bayliss
Contributor
Contributor

Hey Mudaltsov - You are one champion!

I used method two and everything appears to be working. Just in the process of aligning the disk (64K + GPT) then formatting it. The existing partitions that were on the disk have been removed. Since we are using internal disks I dont need to worry about the disk numbers changing between boot. I will update the /etc/fstab file to exclude the current logical volume - just to be on the safe side.

I decided against Method 1 cause I noticed major performance issues when using both NTFS-3G / Fusion. I also believe this adds another layer of complexity which isnt required.

One question though - Does it matter if the VMX file is configured to use SCSI or IDE for the reference disk?

Again thanks for your support!

Cheers,

Mark

0 Kudos
mudaltsov
Expert
Expert

I used method two and everything appears to be working. Just in the process of aligning the disk (64K + GPT) then formatting it. The existing partitions that were on the disk have been removed. Since we are using internal disks I dont need to worry about the disk numbers changing between boot. I will update the /etc/fstab file to exclude the current logical volume - just to be on the safe side.

Even internal disks may switch numbers, though it might only happen if you have 3 or more disks. The boot device always seems to be disk0, but the others are somewhat random. On my machine I have 3 internal SATA disks, and /dev/disk1 and /dev/disk2 seem to switch around pretty much every boot. We're trying to figure out a solution for this since it's very annoying for Boot Camp users, since a new disk number shows up as a separate Boot Camp VM in Fusion.

I decided against Method 1 cause I noticed major performance issues when using both NTFS-3G / Fusion. I also believe this adds another layer of complexity which isnt required.

I was suggesting that NTFS-3G could be used to partition and format the drive as NTFS with Disk Utility, using NTFS-3G to actually access the disk afterwards isn't something I recommend. But I agree that using an individual partition is not necessarily the best solution in your case. It's mostly geared toward Boot Camp users, which may have the Windows partition on the same physical disk as OS X, which prevents Fusion from using the entire /dev/disk0 device.

One question though - Does it matter if the VMX file is configured to use SCSI or IDE for the reference disk?

I tried setting up the disks as "lsilogic" and running Windows 7 x64, and had some trouble - the 250 GB disk could be read but the 3 TB couldn't. And in both cases, Windows had trouble writing to the disk. I'm not really sure what would cause this problem, I'll follow up with some other engineers about it.

Again thanks for your support!

You're welcome, good to hear it works for you!

Of course I still recommend keeping backups of important data in case something goes wrong (you can never be too safe after all).

0 Kudos