Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Suggestions for Vimlan Backup - Player 15.5 on Windows 7

Scenario: Due to other software on Machine that is incompatible with Windows 8 or above, the Machine has to run Windows 7 OS which can't run VMWare Player 16. Due to needing a MacOS built as a Workstation 15 virtual machine, the VMWare player version cannot be downgraded. Catch 22 (can't upgrade OS and can't downgrade Player version)

Looking for suggestions on how to run Vimlan on that machine (if at all possible) by downloading VIX (where to get for that version of VMWare Player?)

Hi Kevin,

Downloading and installing VIX for an older version of Player might not make Vimalin work on these older versions of VMware Player.
I seem to recall that there was something that got confused in my code, but I can't remember what it was...
Vimalin needs VMware Player 16.x or up for being able to support it.

Trying to install VIX for Player got very very frustrating around Workstation 12.
I have an article about VIX here:
But I don't really recommend taking that route.

The alternative route is to install Workstation 12 Pro. That installs the 30 day limited version of Workstation, plus VIX and also VMware Player.
What not everybody knows is that VMware Player continues to run after those 30 days.

The confusing part however is that Vimalin will use the registered list of Virtual Machines in Workstation (but you can have the same VM registered in both Workstation as well as Player)

Not 100% ideal, but that's what you get once you are limited in your options.
I will attempt that now and try document my results. Thank you for the input.
Unfortunately after many hours of trying all sorts of suggestions, I was unable to get to a solution that worked for either the Workstation Player 15.5 or the Workstation Player 12. Eventually I had no choice but to change the Hardware on one of the machines to be able to install Workstation Player 16 and Windows Server 2016.

I then was able to use Vimalin, but have a few questions/issues:
* How do I select a specific directory for a backup rather than the root directory of a drive as a Target? I have temporarily gotten around this by doing a local drive mapping ("net use t: \\localhost\LOCALDRIVELETTER$\PATHTODIRECTORY /persistent:yes").
* Is it possible to set Vimalin to automatically compress after a backup has run? This would be very handy before copying to offsite backup due to space and bandwidth limitations
One other minor note:
* The storage directories seem to keep changing, this makes is very difficult to write automated scripts for other functions. Whilst this is human readable and nice, it makes automated scripts very hard to code to find the right directory to use. Possibly some kind of advanced feature in the schedules (like the auto compress) would help for directory structure to use?
* Keep getting an Access Violation error when trying to shutdown while tasks are busy and have to crash out. "Access Violation at address 00CCEBAE in module 'Vimalin.exe'. Read of address 0000005C."

Since most people who use and purchase this tool are reasonably tech savy, a config file or settings within the program that is able to be adjusted by advanced users would be a next step.

Ah - Also the option to restore from another directory, even if a Vimilan directory elsewhere (like copied from somewhere else)?
Hi Kevin,

You've been busy while I was away from the keyboard Smile

Let me try to answer some of your questions.

1) The backup location.
This is a design decision.
The reason for it is that it means that by selecting a disk the program can scan the disk and immediately locate the backups stored on it and offer to import the backups.

2) Automatic zip after backup
Yeah I know, it's on my list of things to do.
It should be easy as the components are all there and have been for a long time.
Just never got to the part to automate that and surprisingly you are the first to remind me of that.

3) Changing storage directory name
Another design decision, not likely to change soon.
I think the proper way to handle your request is to have the option to call a script after the backup finishes.
It's not exactly the first time I've had that idea, but I now made to sure to log it as a feature request.

4) access violation on vimalin.exe when you shutdown your host. I have no idea.. Might not be easy to track down as attaching a debugger on a machine that shuts down would only work on a remote debug session and even then the initiated shut down might succeed.
FWIW.. the vimalin.exe program is only a GUI. After you initiated or scheduled a backup, it can be closed. The worker process is what takes care of the backup, not the vimalin.exe app itself.

5) There's a config file with options Wink
Not that there's a lot you can do there now. You can turn off the file hashing in order to speed up the backup and there's a few hidden options that should make it into published functionality.
See for more details

6) Restore from another directory
I would have to investigate. For now I have logged this.

Hi Wil

Thanks for the info:

1 & 6) Ok, so the best option for me then is to ensure I add a target which behaves as root for the program by mapping a drive via "net use" or the "subst" commands. Since on some machines you might not have permissions to directly work with the root directory.
2) At the moment I am zipping the 001/2/3 directories via a script before copying them to a 200Gb Google Drive sync directory - Lets see how well that holds up. Thanks.
3) Love the script idea, for now I am using the Task Manager to run the script above, but it would be nice to have directly in Vimalin so that it would run on success only (for now the task manager script runs whether success or failure of the backup)
4) I think I traced that to a weird permissions issue, started seeing that Vimalin wasn't able to create snapshots, so used the vmrun command directly. Not sure why but if I start the VM from a desktop shortcut the permission for Administrator weren't applied to the VM even though set to run as Administrator. If I use Vimarun to start the VM then had no problem.
5) Thanks, I was only looking in the Program directory for config files. This came in handy when I moved the VMWare Player directory while running additional tests.

Now will wait out the week and see how it goes.

Last thing, then promise I will eventually go to sleep:
* Sometimes after a successful backup, VMWare Player throws an error message "invalid option: --reload". Not sure where that is being called from.
re 4) Note that if you are using BitLocker and the VM lives on an external disk that you -by default- don't have access to the external disk until you login. Not sure if that is relevant for your case, but figured to mention it.

re 5) Originally the idea for storing the program's location was to be able to override it. Sadly though it gets overwritten each time you run Vimalin. But .. the important location is not so much where VMware Player lives, more important is where VIX is installed as that's the automation mechanism that Vimalin uses.

re --reload ) ... It is the very first time I hear about this. As mentioned, Vimalin uses VIX for its automation. If the VMware Player UI throws that error then it sounds like something in VMware Player going awry. What version of VMware Player is this?
4) Not applicable - all local physically connected disks
5) spotted that, but it was the vmrun that needed a temporary redirect - think that worked
--reload) I have finally tracked that down, and it does create a problem for Vimalin, but is not rooted in Vimalin software (read on if interested):

a. After any restart via Vimarun, there was no problem running the first scheduled backup.
b. Sometimes there would be a "VMPlayer.exe" error about the reload, but most of the time not. (see below)
c. Next scheduled backup would sometimes work and sometimes not?
d. The error reported by Vimalin was always "Could not create the Snapshot"

My Actions to prove the problem to VMRun (too much work to list/type all steps as how I eventually traced, but this is what eventually tracked it down: I went through the detailed logs of successful backups to see an idea of what was being run at each step):
a. Start a small VM via Vimarun
b. Go to an Administrator command prompt and run "VMRun -T ws snapshot ..." (with all relevant parameters)
c. Create second/third snapshot with different names - No problems encountered
d. Tried to delete any of the snapshots using "VMRun -T ws DeleteSnapshot ..." (this is a function that the Vimalin does in the background I think as per the log files which I managed to find)
e. The delete worked quite happily sometimes, but occasionally an error window (not error message to console but a window) was thrown by VMRun directly, which contained an error thrown by VMPlayer.exe saying that the option --reload was not a valid option - Can send a pic as can't attach in the forum
f. While still in the console window (and NOT removing the error window), I was still able to create another snapshot. I left the window open in case it was locking a process, but this didn't seem to be the case at this point.
g. The error message is being thrown immediately after the delete snapshot process by vmrun (be aware that this is a VMWare Player 16 install on Windows 2016 server, in case that is relevant)
h. If I let Vimalin hit this error through the schedule by itself after the delete of the snapshot, then nothing breaks after the first backup/snapshot, but sometimes (and not every time which makes it difficult to repeat) something gets locked and now gets a permissions problem (The error doesn't get thrown to the local screen always, although I did see it once just after all the new installs), so maybe a fluke or I was doing something else that threw this error and not via Vimalin?)
i. If I try run the VMRun snapshot command directly after some backups then I get an "Insufficient Permissions" error (be aware that after research I know that this is very different from a insufficient permissions on guest issue, this is not a guest problem)
j. I am sure that this is where the problem lies, and I have no idea why vmrun tries to call this reload option (maybe it exists in full Workstation Pro version, but definitely doesn't exist in the VMPlayer shipped with VMWare Player 16)

No amount of Google Jutitsu and Forum work has any answers on this right now, so for VMWare Player 16 there might be only 2 options for now for Vimalin software to internally solve the problem until fix for VMWare Player:
a) Don't delete the Snapshot for now and name it as something like "Vimalin202109282005". This might increase the size of each backup, but maybe this could be described as an extra "Feature" (That's what my boss would say - he he) - All Snapshots included.
b) Require either a shutdown or suspension if it's a VMWare Player installation (think can do via VMRun, haven't tried yet been busy with everything else), and then backup, and restart the VM. VMWare Player is not a commercial product, theoretically shouldn't be run in Production and a bit of downtime for backup is not a great hurt, even if used for a non-profit. My non-profits should be happy with this and WILL be if I say so (Free Servers cost me EU300/mnth to host on a South African developer salary - 1/3 of my Salary, excluding time - so if I say that's how it has to work, then that's how it will work, or go somewhere else for your absolutely free and 24hr supported services - he he). Besides, that's almost how I used to build my Task Scheduler scripts anyway previously. A live backup process was just a bonus for me to prevent some of my headaches.

As promised I will continue monitoring the backups this week, and will provide as much feedback as I can. I would really like to back your software due to simplicity for my companies businesses paying clients, so I am testing hard on my side on my personal non-profit clients.

Regards, and hope this helps in some way, will continue to send any updates.

PS (Other Info for Wil):
I work for a very small South African software dev company that does a lot of backend type work (not really UI's) in C# & many other languages, and most of the time they are very willing to assist with knowledge to help my non-profits (I have provided everything from basic email/websites to non-profits since 1995, and started with VMWare Server 2.0 for virtual services - horribly disappointed when that never moved on). They know that what I learn here will probably benefit them on their own commercial resources. After my testing personally (which had no initial company involvement), they have become very interested in your tools. This is a long winded way of asking what you use for your development and testing! This would help me convince them on certain ways forward.
PS1) The business would like to stay with Win2016 for now, but would like to know what you are using for testing
PS2) Which VMWare Product are you using for main testing (Workstation/Player/Etc)

I am leaving an open email here to contact me privately on to take this communication offline if interested (only valid for next 2 weeks - we control our own servers remember - he he):

I'm always interested in hearing about issues and do try to address them if possible.

re. shutdown before backup. Certainly possible to do with vmrun, but it is not a very common request. This could be useful for servers, less suitable for desktop use.

re. the error that comes up only sometimes. It's weird.. the permissions bit in it does sound like something that one other customer bumped into.
Just wondering. Could it be that something is locking the files?
Like an antivirus product?
If for example Windows Defender is active then it is always a good idea to exclude the VM folder (or at the very least the .vmdk/.vmem/.vmsn/.vmss files.

re. renaming a snapshot. That's not really an option as then things become unmanagable over time.
FWIW, if Vimalin fails to delete the snapshot, it will complain about that, but the backup itself is actually fine. Also next backup that you take it will see that the old snapshot is still there and try to remove it before starting a new backup. If the deletion of the snapshot then fails as well, it will not continue.

re. pictures/attachments.. you can email me at Wink please also include a support bundle (you can create from the help menu)

re. testing.
The beauty of VMware products is that you can run things nested.
Which makes testing a lot easier. So I can test against Workstation as well as Player and Fusion.. testing different versions is a matter of a quick install and snapshot.
Run a test, rollback the snapshot.. test again.
Most of the recent tests for Workstation/Player have been against the latest v16 versions and Windows 10 Insider Preview.
So that's a Windows 10 VM with Workstation installed in there with Workstation VM's running in the VM.
Testing other platforms tends to be a snapshot away...

Of course I also test on hardware, but the majority of the tests are nested as it streamlines the tests by a lot.

I started with VMware around VMware Server 1.x, Workstation 5, ESX 2.x
Hi Wil

Due to a lot of testing and stuff, I eventually came across another solution to the original issue and a few more. My stuff on this post is still a work in progress, but I think the new post will make this a bit more accessible to your users.


Forum Jump:

Users browsing this thread: 1 Guest(s)