My home setup consists of a few PCs / laptops runnings Windows OSes and a PC that used to run ESXi 5, which I have now converted into unRAID 6. ESXi was used mostly for storing multimedia files but also the occasional VM for learning and testing things.

 

I have ended up with 6 HDDs in VMFS format, which proved to give some challenge when trying to access VMFS disks over Windows 10. I have tried a number of ways in doing so, and I have planned a few more to try, but to save time as it's quite time consuming I 'd like to mention it here for your suggestions, as well as make it known to others who may try it.

 

Tried and succeeded:

1. Access it directly from my Windows 10 PC (vmfs.jar). vmfs.jar loads the (unrecognized - unsuable HDD) and display its contents. Which proved to be VMWare files including a .vmdk file. So what do you do now with a .vmdk file in Windows 10? Actually, nothing. You still need to open it and surprise - surprise Windows clients handling vmdk files do not like the VMFS vmdk. Not even VMWare Workstation manages to open it / mount it as a disk as it should, it gives an error. I ended up trying to save it locally through the webdav interface exposed, but "saving it as" from a web explorer adds a strange bandwidth limitation so for a 2TB HDD it took 7 hours to copy it. And then you still have to open the .vmdk file which you can't. Which took me to the next try.

 

2. Access it directly from my Windows 10 PC (DiskInternals Reader). DiskInternals Reader proved to be the only software capable in accessing the VMFS HDD and displaying the contents for browsing and copying, and the only one managing proper HDD speeds while copying them (from VMFS HDD to NTFS HDD on the same system). But that again has some weird limitations forced by its developers: it likes only physical devices and will not display anything else, no matter how you try to slice it (map it, mount it, beg it etc). Which means that you first need to copy the data locally through DiskInternals Reader and then copy it over the network to the Array from Windows Explorer. So the faster times gained were lost as a second copy was needed.

 

There are many other applications that say they can access VMFS / VMDK from your Windows PC, but they all failed big time. I tried many. Either they just mount the disk, which is useless as the format is not recognized from Windows, or they load a driver for reading the format (ext5 was it I think?) or they don't like the vmdk file from the VMFS disk (cannot open it). Even VMWare "mount" application, which does exactly that, will not work. It 's been deprecated from VMWare as its not part of the current VM Tools provided for free. You can still  download it and install it on our own but the installation fails. Why? Because vmware mount wants to install its own driver, and the driver is 32bit, and OSes now are 64bit, and you can't do that. You are either in luck and you have an old Windows 32bit OS somewhere or you must be willing to host a new VM with a 32bit OS.

 

What I am half way through:

3. Do it DiCaprio's Inception-style: A Windows PC running a hosting system, running a hosting system, running a PC. Which is one level deeper as Inception was about a dream withing a dream within a dream. I spend once some time for the initial configuration: Windows 10 running VMWare Workstation 12. In there I host ESXi 6. And in ESXi 6 I host another Windows 10 PC. After this is set up (actually only the deeper nested Windows 10 machine takes some time as it's an OS installation, windows updates and short configuration), the idea is that Workstation 12 passes directly the VMFS HDD as hardware, which is then recognized by the ESXi as a disk with a file system, and the .vmdk file is passed then as an already existing HDD to the Windows 10 machine. The Windows 10 machine should then view all files directly in Windows Explorer and copy it over the network. Not the whole process has being followed yet, but as this process already works by some other means, it should work. Will come back with the results for this. The "other means" were that Windows 10 should have it's own files (vmdk disks) as I would like to convert it in a KVM machine and host it in unRAID. I didn't want to mess it up with ESXi 6 data storage. I didn't want to have to recreate in unRADI another VM and go through the process of installing the OS, updating and configuring it. So, Workstation 12 created a 40GB .vmdk HDD file, which it passed as a device to the ESXi. ESXi recognized it as a normal storage device, which it also prepared as a VMFS disk for further usage. It then made it available as an HDD on the hosted VM which installed the Windows OS under NTFS.

 

I am guessing that people who have not watched Inception yet are a bit lost...

 

What I haven't tried

4. From previous tries, it was proven that in order to avoid building Inception 2 in your machine, you could "probably" get away in hosting a Workstation 12 Windows VM with a 32bit OS, so that vmware mount would work. Then you should be able to pass to the VM the HDD VMFS directly to the VM, which should be able to mount it and open it. Mind you, I 'm guessing that the result would still be the VMFS files plus the .vmdk, which so far cannot be opened by any application other than DiskInternals Reader. Which produces again the problem of not displaying network drivers so a local copy and then a network copy is required.

 

5. On unRAID, host a VM with Linux OS (Ubuntu? SuSex?) This should be the best solution, which I have not yet tried and would value your input. The idea is the same, pass the not-so-friendly VMFS HDD to a hosted VM that can open it easier, with the added bonus that copying files between the VMFS and the Array "should" occur on same-system HDD speeds and not over the network. For this I personally prefer a Linux solution with a Desktop GUI as transferring files would be easier / nicer for a Windows user. Linux would open the vmdk file with the use of vmfs tools that can be installed (for which I don't know if I should post the link of the guide, but you can Google it anyway). The big question here is, will unRAID treat the copying over between the HDD and the Array as a physical disks copy (and gain the max speed the HDDs can offer), or will it try to pass it over some other layer / network-like, as it's a Linux VM copying files over a shared (networked) folder? If so, which would be the best practice in making the copy occur over the system and not over the network, while at the same time, you know, surviving a possible data corruption / loss / tears in doing stuff we shouldn't (already did that mind you during my first approach on unRAID and Linux by managing to mount the container's data folders in /mnt/appdata/ and then scratching my head where the data went after a power failure...)

 

These comments should prove useful to someone trying to copy a few files or TBs of files between a file system not easily recognizable.

 

If there are any other tried solutions please say so! 6x2TB of VMFS HDDs will take some time to transfer...

Whew. Sounds like it would have been easier to do before the esxi box was shut down. 

 

Someone had gotten esxi to run on top of unRaid.  But that wasn't easy.  Don't know if that helps at all. 

Nah I couldn't, I had to use the same hardware (24GB RAM on i7) for unRAID and ended up with a bunch of VMFS HDDs and no where to plug them (no pun intended).

Call this crazy... but what if you use either a Linux/Unix VM... or even better. Run ESXi... as the guest? (play this for effect)

Not sure exactly the vm you have  but I used the guide here to convert an esxi win7 image to run on unraid kvm pretty easily

 

http://lime-technology.com/wiki/index.php/UnRAID_Manual_6#Windows_7_Conversion_Procedure

... or even better. Run ESXi... as the guest?)

 

Yeap I guess that would work too, as another intermediate until I can get rid of both ESXi and its VM.

 

Nice touch with the URL btw, especially since it played rather loud on my speakers.