How do I make host local drive letters available to VM guest?

[DSperber]

I can't figure out how to do this, and I'm sure it must be possible. So please, somebody, tell me the step-by-step process to accomplish what I know must be possible.

My host Win10 machine has three local drives, with multiple partitions on each drive. So the host machine has local drive letters C-M.  C is the Win10 system partition, and I realize I can't expect to access it as "C" within the Win7 VM guest.  But I at least would like to see D-M in the Win7 VM environment, as "local drives" with those letters.  Ideally they should just appear in My Computer of the Win7 VM as D-M, but I'll do whatever it takes to "map" them that way.

It's not a matter of just getting to the data on those partitions (i.e. drive letters). I can easily do that by MAP NETWORK DRIVE as D-M through NETWORK, since all of the drives on the host are genuinely visible through NETWORK in Windows Explorer, since the host machine itself shows up in NETWORK (as well as all the other desktops and laptops on my LAN, since I've got "bridged network" set so that I can see all the LAN devices within the Win7 VM).  So I know I can easily get to the host partitions with the identical drive letters D-M if only that would be acceptable to my need.  Unfortunately that method of getting drive letters D-M via MAP NETWORK DRIVE is unacceptable to Windows Media Center for "Record Storage", where only genuine true "local drives" are acceptable for recording, not mapped network drive locations.

So when I go into WMC -> Recorder storage, all I see is C, which is the virtual C provided by VMWare Workstation Player to the Win7 VM.  This partition is too small, and is not the drive letter I actually want to set as "recorder storage" target location. That drive is actually F.  So I need to get at least F (true F, from the host) available to Win7 VM as a "local drive" (ideally F).

How do I do this?  I can't use MAP NETWORK DRIVE. And there's no point in using "shared folders", because just getting to the data is not the goal. The goal is providing the drive letter to Win7 VM so that WMC sees it as a local drive, so that it appears usable for "Recorder Storage".

So, can somebody tell me: is this possible or not? Are you telling me the local drive letters of the host are NOT available as "local drive letters" to guests?  Or, if they are and I'm just a rookie who doesn't know how to make this happen, please let me know how to do it and/or point me to a VMWare FAQ document or forum thread or something which will provide me clear and appropriate instructions for what I need to do.

If it's possible, I'm sure it's quite easy... if only I knew the technique. But I'm a true rookie/newbie to VMWare, so any help for experienced gurus is much appreciated.

thanks in advance.

[RDPetruska]

Are you telling me the local drive letters of the host are NOT available as "local drive letters" to guests?

That is correct.  Most computer resources/devices are designed to only respond to ONE master driver.  So, in the case of virtualization, a device (your hard disk in this example) can either be attached to the host, or to the guest, NOT both at the same time.  You will see the same behavior with USB devices - either attached to the host, or to the guest, never both at the same time.  Hard disks/drives are used via network sharing (whether standard SAMBA/CIFS shares, or the backdoor VMware Shared Folders feature).

If you prefer, you *could* directly attach your physical disk or partition to the guest via "Raw disk access".  However, you MUST NOT allow the host to see the drive/partition at the same time, or you WILL end up with data corruption!  You must ensure the host does not assign a drive letter within Disk Manager to the partition in question.  This is certainly an advanced feature, as it is dangerous to your data if done incorrectly.

[DSperber]

Thank you for the clarification.

Now let me propose another idea. The problem with only C showing up in "recorder storage" for WMC in Win7 VM is that it is too small. I only allocated 60GB for virtual C when I created the VM, never having done any of this before so it was all really just first-time "proof of concept" to see how far I'd get. Turns out I got all the way home, but with a C that's not large enough if I can't use F like I want.

So, I'd like to make C MUCH LARGER... i.e. relocate C:\Users\<userid>\Documents\Virtual Machines to be on my host's F partition which is about 5TB large.  Then I could allocate a HUGE virtual partition for C, and I assume I could simply "expand" it since I don't want to start all over from scratch. Is there a maximum size for virtual C? I probably could find that out myself.

Since File -> Open can point anywhere, I assume I can just COPY my VM definition from where it is in \Documents\Virtual Machines, to a new location on host F, and then File -> Open it from there, and do the enlargement of C using that new VM.  Then I could let WMC use C for Recorder Storage, and I'd have solved my problem.

And for all the rest of the host drive letters, I'm perfectly fine using MAP NETWORK DRIVE for them, so that I can access them through Windows Explorer in Win7 VM using the same drive letters as they truly are in the host.  Again, this was never a problem. The problem was "Recorder Storage" for WMC which MUST be on a local drive, not a mapped network drive.

So, can I simply copy the virtual machine definition to a new location on F and then open it from there?  Would it be that simple?

[RDPetruska]

I would recommend adding a second virtual drive for your storage, instead of enlarging the main C drive.  That way, it's not impacted by OS updates, etc.  Just create a new virtual disk, with the file itself on your host's F drive where there is enough space.  I'm not positive of the max size of the virtual drives currently - that depends on which virtual hardware version you chose (appears in the wizard as Workstation version compatibility).  And, I would accept the default of slices - if you ever have to defrag/shrink/enlarge the disk, Workstation will need as much free host hard disk space as the largest piece of virtual disk file - if you use the split disk, then it does each section at a time, and only needs a little more than the 2 GB(4 GB now?) split disk size; if you use a monolithic disk, then it will need as much free space as you allocated the disk for (i.e. if you created a 100GB drive, even if it's only partly full to say 35 GB, if you want to do disk utility operations on it, it will require a little more than 100GB of free space to do so).

[DSperber]

If I create a new virtual disk, do I have my choice of drive letters to assign to it?

If you say I can place this on a host partition of my choice (and obviously that would be F), why then couldn't I just letter this second virtual drive F, and mentally everything would then be completely consistent and intuitive, and I wouldn't have to think of any mappings or whatever. F "virtual" is located on F "host-real", which is perfectly fine with me.

As long as this virtual F shows up in WMC's recorder storage offering... with any letter other than C... I'm happy.

[RDPetruska]

Absolutely, within the guest you can use Disk Management and assign whatever drive letter you wish to it.  By default, it will be the next available letter, so with your main disk as C, and likely an optical drive as D, it will default to E.  But you can change it to F.

[DSperber]

Well, I think I have a problem.

I allocated a 500Gb virtual disk, and throughout the dialog I never was given the opportunity to place it on some physical partition of the host.  But it was created, and does now show up as a second hard disk.  By the way I chose SATA, even though SCSI was recommended (and SCSI is how C shows up). Is there a reason for the offering of SATA or NVMe?  Why would I choose SCSI if it is "slower", which I think is what I saw when I stumbled into an earlier attempt at allocating space and let it go with SCSI but then when I went to use it I was warned that it is "slower".  Can you please clarify?

Anyway, it's there, as a second hard disk of 500GB, "New hard disk (SATA)".

Now there is a "Disk Utilities" section which offers "Map", with the description "map this virtual machine disk to a local volume". This sounds to me like exactly what I want to do, placing this second hard disk on F.  Unfortunately... the "Map" function is grayed-out.

I am suspicious that this "Map" function is not available with the "free for personal use" version of VMWare Workstation Player, which is what I am using. I suspect it might only be available in the licensed non-free version.  I hadn't jumped in that deep originally because I was still in the "proof of concept" stage, trying to see if I could actually run Windows Media Center in Win7 VM and have it access my Ceton ETH network tuner and my extenders, thereby providing complete transparency for WMC so that I can exit from Win7 as my host HTPC and instead from WMC in Win7 VM in a Win10 host.

So, if "Map" is what I now need to relocate my second virtual disk onto local F (and then use Diskmgmt.msc to re-letter it to virtual F, for consistency), and if the only way I can get "Map" not to be grayed out is to pay a license fee, well then I supposed I will do that.

Can you confirm that "Map" is really what I now need to use, and that it is also true that this is a non-free licensed feature?  Or what?

[RDPetruska]

I believe by default a new virtual disk file will be created in the same folder as the rest of the VM files.  Either move the entire folder to your larger host disk drive, or just move that one file.   If you move the entire folder, you will simply remove the entry from the Favorites, and Open an existing virtual machine, browse to the new location, and open.  If you move just the one hard disk file(s) [*.vmdk files] to the second drive, I would then go into the options of the virtual machine, remove the second hard disk, add a second hard disk again, but choose "use existing" and browse to where you copied those files to.

I can't offer any advice on SCSI vs. SATA vs. NVMe.

The "Map" option is ONLY when the VM is powered off (including the Guest OS inside, not just suspended) - to mount a virtual disk to your host as a drive letter, so you can copy/move files between them easier/quicker.

[DSperber]

Many thanks for the direction you've pushed me in.

I have now successfully defined the 500GB virtual disk (which I then created as a GPT simple volume and formatted it as NTFS, all using DISKMGMT.MSC).

I used the trick you suggested, namely defining it first as "new", which placed it on the same local host  C location (in Documents) where the virtual C also was.  Then I copied it (i.e. the whole set of files that corresponded to that virtual disk) over to host F, in a parent folder name of my own creation, and deleted all those files from their original location on host C (Documents).  Then I went back into settings, deleted that hard disk, and then created a new hard disk again... but this time defining it as "existing" and navigated to where I'd placed the set of files on host F. So far, so good.

Then I started the VM, and got into DISKMGMT which recognized the presence of the new "raw, unformatted" drive and asked me if I wanted to prepare it as MBR or GPT (I chose GPT).  Then I right-clicked on it and created the "simple volume", quick-formatted it as NTFS and gave it a sensible label, and assigned a letter of Z. That way I could still have my actual host F mapped as F in Win7 VM, so I could actually still see F as F.  This new 500Gb drive is Z, but did in fact now show up in WMC's Recorder Storage for my selection!!!  YAY!!!

I then went to the WMC Guide, tuned to a station, pressed RECORD, and let it run for a minute. Sure enough it worked, and the correctly named WTV file got placed in the new Z:\Recorded TV folder exactly as it should have.  And I was also able to then play it back.

Bottom line:  I HAVE EMERGED VICTORIOUS (thanks to you and your help and guidance, for which I am genuinely most appreciative).  This WMC "recorder storage" was the only folder which had to be located on a genuinely "local" drive (from Win7 VM's perspective), and this technique you provided to me solves that perfectly.  All other host drives can be used exactly as mapped network drive letters, and work 100% just fine that way.  Only this "recorder storage" folder presented the super-challenge.

Post-script, which is very interesting.

The major objective for this entire VM project was to get WMC working in Win7 VM on a Win10 host.  This would handle my copy-protected content delivered by Spectrum Cable, through the cablecard-enabled Ceton ETH network tuner.  And this now has been proven to work completely perfectly.

I also have a Hauppauge WinTV QuadHD PCIe tuner card in the physical machine, for OTA/ATSC copy-freely content provided through my roof antenna.  But because PCIe cards on the host aren't passed through to the Win7 VM, WMC running in Win7 VM cannot see this Hauppauge card.  So unlike in a real Win7 HTPC where both the Ceton ETH network tuner as well as the Hauppauge WinTV QuadHD tuner would both be supported by WMC, in the Win7 VM environment only the Ceton tuner is available to WMC in the Win7 VM, with recorded files as WTV.

To overcome this dilemma, I installed NextPVR in the native Win10 world, because NextPVR runs in VM and also supports the QuadHD card through the WinTV 8.5 drivers provided by Hauppauge (for its own WinTV 8.5 product which also runs in native Win10).  NextPVR creates recording files as TS, in its own "recordings" folder, which it can also play back.  But it turns out WMC can also play TS files, but as "videos" played through its "Video" interface, rather than as "recorded TV" through its "Recorded TV" interface.  This is only a minor inconvenience, and the real "win" here is that the recordings file from NextPVR are on a host drive letter which is visible to WMC in the Win7 VM.  So I can play back both (a) WTV files recorded by WMC as "recorded TV", and (b) TS files recorded by NextPVR as "videos".  Perfectly fine with me.  As far as I'm concerned, I have emerged victorious in that I've supported both Ceton and Hauppauge tuners and recordings, played back through WMC extenders running in Win7 VM.  Out there at the TV's around my house, it all looks almost just like it did under real Win7 HTPC.

Final astonishing discovery... regarding DRM, and the ability to play copy-protected WTV files only on the original Win7 WMC which did the original recording.  In theory you cannot play copy-protected content on any other machine, or even if you reinstall Win7 on the same machine. Only the original recording Win7 WMC, on the original hardware machine, can play a WTV recording of copy-protected content.  Well, it turns out that a COPY of a Win7 VM apparently retains all of the identification characteristics (i.e. both hardware as well as Win7 and WMC) to convince PlayReady that the COPY Win7 VM is actually "the same physical machine and the same installed Win7 and WMC". This means copy-protected WTV recordings made in on Win7 VM CAN BE PLAYED by a second COPY of that Win7 VM!!!  This has not been known before, and is terrific news to learn.

Now as it turns out today's project was in order to create a test platform to allow the tech support engineers from BitDefender to connect to my machine (through TeamViewer), in order to allow me to demonstrate a problem with their product specifically related to WMC extender RDP sessions.  Rather than using my real Win7 HTPC to do this, I decided it would be great if I could have two Win7 VM's for them to see, one VM with Microsoft Security Essentials installed and which works perfectly with the WMC extenders, and a second VM with BitDefender installed and which has the major defect.

So after completing the setup of the MSE Win7 VM, and doing one copy-protected recording from the Ceton card, I did a manual COPY of the Win7 VM into a second Win7 VM (copying both the C:\Documents main definitions as well as the F:\VirtualDisk folder). Then I OPEN'd this second VM in Workstation Player, deleting the second hard disk and then re-creating it (so that I wouldn't break the second hard disk of the original MSE VM).  So now I had two usable Win7 VM setups, both with the second 500GB drive on which there was a Ceton copy-protected WTV recording which had been made by the first MSE VM.

I then uninstalled MSE from the second VM, and installed BitDefender.  I then took a NovaBACKUP of BOTH pairs of folders (which defined the VM and the external drive), so that I now had preserved my "starting point" which I could always now restore in the future any time I wanted to re-demonstrate anything, or from which I might want to "clone" (i.e. COPY again) another Win7 VM for me to "play in the sandbox" for any reason.

So, once I had this second Win7 VM with a copy-protected WTV file in its "Recorded TV" folder which had been made by the first Win7 VM, I could test the ability of WMC in the copied second VM to play the copy-protected content made by the first VM... and in fact it could.  So that's how I learned this amazing discovery.

And of course, I also had the MSE vs. BitDefender VM's to work with independently, to present to the BitDefender engineers as proof that their product is "fatally broken" with regard to WMC extender sessions and their termination.  The bug causes the extender RDP sessions to not terminate properly, hanging up Windows and making it impossible to shut down gracefully... requiring a manual re-boot.  In the VMWare Win7 VM world attempting to shut down results in an infinite "logging off", and there's no way to "power off" successfully as that hangs too.  Instead, I must take the "suspend" option which closes the VM, and then I can delete the entire pair of definition folders and RESTORE them both from my NovaBACKUP backups... and I'm once again right back where I started.

AMAZING!!!  It all works.

Again, many many thanks for your guidance and help.

[DSperber]

"I believe by default a new virtual disk file will be created in the same folder as the rest of the VM files.  Either move the entire folder to your larger host disk drive, or just move that one file.   If you move the entire folder, you will simply remove the entry from the Favorites, and Open an existing virtual machine, browse to the new location, and open.  If you move just the one hard disk file(s) [*.vmdk files] to the second drive, I would then go into the options of the virtual machine, remove the second hard disk, add a second hard disk again, but choose "use existing" and browse to where you copied those files to."

I discovered tonight that I can actually share these "secondary external virtual disks" amongst multiple VM's.  In other words the same VMDK set of file can be pointed to as "existing" in any number of VM's.

Kind of like have an external USB drive that you can plug into multiple PC's and it is then visible and usable on that PC.  So you can write to that drive using one VM, and when you open a second VM that is pointing to this same VMDK the data written by the first VM is visible in the second VM.  So it really is just like having a portable external drive.  Excellent!! I no longer need TWO 500GB external Z-drives for my primary and secondary Win7 VM.  I can simply use the same single Z-drive in both Win7 VM's.  Perfectly useful.

Now my next question concerns something unrelated to virtual disks. It pertains to the machine hardware seen by Win7 VM guest as provided by VMWare running on Win10 host. Does VMWare always provide a Skylake VM to a Win7 that you create, even if you're running on newer physical hardware which would not otherwise be acceptable to install Win7 on. For sure my current Skylake physical machine I'm using for Win10 is seen as a Skylake machine with the true i7-6700 CPU inside Win7 VM (using CPUZ to confirm). But then there's no issue here, because Skylake and i7-6700 CPU is perfectly acceptable for Win7. Memory seen by Win7 VM is "virtual" and graphics is "virtual", not reflecting my true physical machine hardware, but that's not as critical as chipset and CPU.

The issue is could I buy a current-generation brand new machine newer than Skylake which because of its current-generation chipset and CPU would otherwise NOT be usable for Win7 but only Win10, and install Win10 on it and then install VMWare on it and then install Win7 VM on it, and have it still look like a Skylake machine which is the final hardware compatible with Win7 and normal Windows Update support from MS?  Or would the hardware seen by Win7 VM mirror the true physical hardware of the machine as seen by Win10?

Seems like it would be required to simulate Skylake to the Win7 VM in order for me to be able to install and run WIn7 VM under VMWare on a new Win10 host machine. If the newer hardware were actually passed through to the VM I would think Win7 Windows Update would not work and I wouldn't be able to complete the Win7 install. And besides, how could Win7 be installed if there weren't proper Win7 drivers available for this newer hardware which in fact would likely be the case?

So you'd think VMWare would need to simulate a Skylake machine and CPU and other Skylake-level hardware to Win7 VM running on a newer generation physical machine, to guarantee drivers could be found and that Win7 install completed. But I don't know this for sure, since I don't have that hardware to play with.

If it's truly possible to still run Win7 VM (as simulated Skylake?) on newer hardware which only Win10 supports then this is fabulous, given what I've now established for WMC being usable under Win7 VM. This means there is "eternal lifetime" for WMC, even if real Win7 is "dead to MS" and Skylake is truly the final hardware usable for WIn7. Instead, Win7 VM and WMC can live on forever (in its final "legacy" form with no further Windows Updates from MS) using EPG123 in the virtual reality of Win7 VM guest on any modern up-to-date Win10 host machine.

Kind of like "San Junipero" on "Black Mirror".

So what does Win7 VM think the hardware is that it is running on, if you install Win7 run on Kaby Lake or Coffee Lake or newer hardware?  Can Win7 VM be installed on these newer machines?