Streaming support not working again in Player 7 and Workstation 12 Player

[jeremyd2019]

Hello again.  This is not the first time I've had a problem like this (see Streaming not working in Player 5.0.0 and 5.0.1 on Windows)

Streaming is documented in the manual, for Workstation 12 Player VMware Workstation 12 Player for Windows Documentation Center

When Player 7 was released, streaming stopped working again, popping up a "File not found" error.  I just stayed on Player 6.

Now I saw that the new Player was released.  I installed it, anxious to see if the killer feature I have come to rely on has started working again.  It has not.

Interesting excerpts from the log:

2015-08-25T22:33:09.479-07:00| vmplayer| I125: Command line: "C:\Program Files (x86)\VMware\VMware Player\vmplayer.exe" "http://my.host/vm_images/test/test.vmx"
2015-08-25T22:33:12.739-07:00| vmplayer| I125: DictionaryLoad: Cannot open file "http://my.host/vm_images/test/test.vmx": The filename, directory name, or volume label syntax is incorrect.
2015-08-25T22:33:12.739-07:00| vmplayer| W115: CnxFSVMDB::IsEncryptedConfigFile: Failed to load dictionary. Cannot open file "http://my.host/vm_images/test/test.vmx": The filename, directory name, or volume label syntax is incorrect.
2015-08-25T22:33:12.739-07:00| vmplayer| W115: 
2015-08-25T22:33:13.270-07:00| vmplayer| I125: VMMgr::OpenVM (cfgPath=C:\Users\myuser\mycwd\http:\my.host\vm_images\test\test.vmx)
2015-08-25T22:33:13.270-07:00| vmplayer| I125: DictionaryLoad: Cannot open file "C:\Users\myuser\mycwd\http:\my.host\vm_images\test\test.vmx": The filename, directory name, or volume label syntax is incorrect.
2015-08-25T22:33:13.270-07:00| vmplayer| W115: CnxFSVMDB::IsEncryptedConfigFile: Failed to load dictionary. Cannot open file "C:\Users\myuser\mycwd\http:\my.host\vm_images\test\test.vmx": The filename, directory name, or volume label syntax is incorrect.
2015-08-25T22:33:13.270-07:00| vmplayer| W115: 
2015-08-25T22:33:13.285-07:00| vthread-9| I125: VTHREAD initialize thread 9 "vthread-9" host id 2084
2015-08-25T22:33:13.285-07:00| vthread-9| I125: VMHS_ManageVM failed: ret = File not found
2015-08-25T22:33:13.285-07:00| vthread-9| I125: Cmd /host2/#_client/util/vm/cmd/##9/op/manageVM/ failed: File not found
2015-08-25T22:33:13.285-07:00| vmplayer| I125: DlgUI: Error while opening the virtual machine: File not found.
2015-08-25T22:33:13.301-07:00| vmplayer| I125: VMMgr: Failed to open pending VM: File not found
2015-08-25T22:35:02.782-07:00| vmplayer| I125: WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0
2015-08-25T22:35:02.797-07:00| vmplayer| I125: Clean exit.

Let me know if you need any more information to track down this bug, or if there's some better place to go about reporting it.  This forum seemed to work OK last time.  In retrospect, I should have reported the issue when Player 7 came out.  Maybe you guys need to add this as a regression test to your test suite

Thanks,

Jeremy

[dariusd]

Hi Jeremy,

I don't think you're going to like the news about this: The streaming VMs feature was removed as of Workstation 11 and Player 7. 

It appears to have been an oversight that led to the Player documentation still containing references to the feature.  I've filed a bug report to request that the documentation be corrected.

Thanks,

--

Darius

[jeremyd2019]

:smileyshocked:

OK, let me explain our use case and maybe you can either suggest a replacement workflow or put this into the hopper for consideration.

We run old, low-end hardware.  It's sad, really.  We could barely scrounge hardware capable of running VMware versions past Workstation 7/Player 3.  We're talking AMD X2 5400+ with 2GB ram.  Clearly, with hardware like that, we're only running 1 VM at a time, and then with considerable muttering of obscenities.

We have 2 developers, and 3 machines like the above.  Each developer has their machine, and there is one "server" machine.  That server has Workstation, the two developer machines have Player.  Both developers have MSDN licenses.

On the server machine, we have a VM library of different OS versions with snapshots of different service packs, ie versions, and updates, etc.  Because the server machine is no more powerful than the developer machines (actually it's less, AMD 4XXX+) and because there are two developers who may want to use the same VM at the same time, the shared vm feature wouldn't work for us, because it runs the VM on the server and sends the display to the client.  It takes a lot of time to maintain all of the VMs with windows updates, and the vm library uses a lot of disk space, so we don't want to make both developers maintain their own libraries.

Right now, the only idea I have is to make a network share of the previously streaming VM library (which are full clones off of specific snapshots, followed by vmware-vdiskmanager -r -t 5 to prepare the disks for streaming) and have the developers copy down the image they want to use to their local machine and run it.  I seem to remember having issues running a VM this way though with the -t 5 vmdk.

Any suggestions as to how to replace the streaming feature in our workflow?

[jessepool · Accepted solution]

Sorry for the surprise removal of this feature Jeremy! We'll get the docs fixed. FWIW the usage stats that we collect indicated less than 10 streaming VM power on operations per month. While it's a cool feature, the developer maintenance cost wasn't justified.

> Any suggestions as to how to replace the streaming feature in our workflow?

How about trying this: Put the VM library on a network share. When someone wants to use a specific snapshot from the VM library on their local machine, use vmrun to create a linked clone (the clone can be on a local disk). Since everyone will have write access to the VM library, make sure to back it up. I haven't tried it myself (I don't have the setup handy), but I think should work.

[jeremyd2019]

FWIW the usage stats that we collect indicated less than 10 streaming VM power on operations per month

Really?!?  Only 10?  If we had the feedback option turned on (and it actually worked from our locked-down network, which i doubt), I figure you'd see at least a 500% increase in that figure.

Still, us and maybe one other user is not enough to keep a feature alive, unfortunately.

How about trying this: Put the VM library on a network share. When someone wants to use a specific snapshot from the VM library on their local machine, use vmrun to create a linked clone (the clone can be on a local disk). Since everyone will have write access to the VM library, make sure to back it up. I haven't tried it myself (I don't have the setup handy), but I think should work.

Played with some ideas today.  My first thought was to use the OVF format.  I had a recollection from ages ago when I looked at OVF that it could import from an HTTP source, and boot while it was still downloading.  Passing an http URL to an OVF to vmplayer.exe on the command line launched an import OVF dialog, but the import failed, and looking at the log it was trying to load c:\http:\my.host\....  No good there.  Calling ovftool with the args in the log (but with the proper URL) seems to download the whole disk without opportunity to start up before it's done.  So that was a fail.

The linked clone idea is interesting.  Problem 1, player doesn't come with vmrun.exe.  No problem, downloaded VIX and installed it.  Then, when I tried to create a linked clone with vmrun -T player, it would fail.  Interesting bits from the log

vthread-6| I125: CnxAuthdConnect: Returning false because CnxAuthdConnectPipe failed
vthread-6| I125: CnxConnectAuthd: Returning false because CnxAuthdConnect failed
vthread-6| I125: Cnx_Connect: Returning false because CnxConnectAuthd failed
vthread-6| I125: Cnx_Connect: Error message: Failed to read vmware-authd port number: Cannot connect to VMX: \\myhost\VMs\win7_32\win7_32.vmx
vthread-6| I125:
vthread-6| I125: Vix: [2800 foundryVMPowerOps.c:5940]: Error VIX_E_HOST_TCP_SOCKET_ERROR in FoundryVMOpenSocketToVMXThroughAuthd(): unable to contact authd: Failed to read vmware-authd port number: Cannot connect to VMX: \\myhost\VMs\win7_32\win7_32.vmx
vthread-6| I125:

However, what did work was creating the linked clone with Workstation, then copying it to the machine with Player, opening it, and browsing for the parent vmx file on the network share.  I'd bet vmrun would work from the Workstation machine as well.  If I created a snapshot in the linked clone immediately after creating it, with the prompt for snapshot option enabled on the VM, I even get a keep/rollback prompt on shutdown which meshes well with the streaming save/discard prompt (which, btw, was broken and didn't actually discard for quite some time).  And we don't get the REALLY ANNOYING bubble that shows streaming throughput that hung out on top and would never go away.

This technique has potential, with the downside of increased network traffic (the vmdks before were "optimized for streaming" with vmware-vdiskmanager, and player would cache the bits of vmdk it downloaded locally whereas the linked clone would presumably just do normal copy-on-write).

For now, we'll probably stick with Player 6, but I do have to revamp the vm "server" anyway, because it is running Vista, and I found out after finally getting approval to buy the Workstation 11 upgrade that apparently Vista isn't a supported host anymore.  I'm figuring on Debian for that, the only reason this machine was Windows to begin with was it started out as a physical test machine before I got my co-workers hooked on the VMware Kool-Aid .