monkeyfoahead wrote:vmware-rawdiskCreator I presume.
I was asking because, when you specify partitions and not just fullDevice, vmware-rawdiskCreator uses both UUIDs and the block device name, whereas VBoxManage internalcommands createrawvmdk only uses block device name. I am not sure whether the use of UUIDs by vmware-rawdiskCreator allows VMware Fusion to figure out which partitions to use even if the block device name has changed or if it merely blocks it from using a partition if the block device name is the same but the UUID is different.
monkeyfoahead wrote:scasady wrote:I did something similar for a while and it worked but every time you boot you have to rename the disks or start the add process over again because OS X renames them each time it boots and vmware can't deal with that. So I gave up on it.
Damn it. I remembered this being an issue on OSX. Isn't there someway of static assignment within OSX?
No I don't think this is possible, but it is usually easy to workaround. In your case, one way you can work around the issue is by programmatically editing the vmdk files to put in the correct block device name.
No. /etc/fstab allows you to specify what you want the mount point for a volume to be, which is entirely different from specifying the index of the block device. For instance, if you use a UUID in /etc/fstab it is the UUID of the filesystem volume (as reported, for example, by diskutil info -plist /dev/disk1s5), not the UUID of the physical partition. The UUID that vmware-rawdiskCreator inserts into a rawdisk vmdk file is the UUID of the physical partition (as reported by, for example, gdisk /dev/disk1, option i, then 5
http://sourceforge.net/projects/gptfdisk/).
If you want to programmatically rewrite the vmdk, you can get the block device name for a given physical partition UUID by running diskutil info -plist 245A12BF-91BA-45FE-BEA7-97255FCF7CED (if 245A12BF-91BA-45FE-BEA7-97255FCF7CED is the UUID) which will give you the block device name under the DeviceIdentifier key. Using the -plist switch gives you plist output which is easy to parse.
I assume your hard drives have a block size of 512, right? You had said you have eight 2TB disks, I assume in a raidz2, since you said the pool is 12TB. 2TB disks still usually have 512 bytes block size, not 4k. You can check by running diskutil info /dev/disk1 (whatever disk number) and looking at Device Block Size. I believe VMware Fusion still does not understand Advanced Format (4k) drives for the purposes of raw device mapping.
monkeyfoahead wrote:Also, even if i do get it to work. Is there anything inherent in the vmware fusion passthrough that would jeopardize the operation of zfs?
Not that I know of. The feature is intended to make Boot Camp partitions directly bootable within VMware Fusion. Presumably VMware has tested their product sufficiently to prevent nuking people's Boot Camp partitions. (Also, raw device mapping is a primary feature of ESXi, so I think they know what they're doing).
I think if VMware Fusion crashes, the impact should be like a power outage.
If anyone has a bad experience using raw device maps with ZFS it would be nice to hear details.