sharing virtual machines

B

badsandwich

Member
i'm sure this has been asked before, but it's late and i'm tired...
Is it possible to store the virtual machines on a NAS or SAN, and then open them from different computers?
I.e. if I have a windows server vm stored on a network drive, can i open that from my mac pro, then close it and open it later on my macbook?
Are there any implications to doing this?
 
Beware of V4.0 behaviour differences

I wanted to report this but I figured I would post it here because it is relevant.

I have one Windows VM which I "share" with my wife on the same mac. Of course we can't have it running at the same time under our respective MAC logins. We have to make sure to shut it down before the other one wants to bring it up under their MAC login.

This is awkward at best and I wish there was a way to bring up the VM outside the context of our MAC logins. Oh well. We have gotten used to it. A "feature" of V3.0 was that if one of tried to bring the VM up while the other one already had it running under their MAC ID, Parallels would thankfully throw an error and say it could not be started because it was already in use.

!! V4 does not appear to work this way and the new way IS BAD !!

V4 Will attempt to start the VM anyway. It will get an error accessing all the hard disks and then try and boot over the network. You have to terminate the VM with the Shutdown VM option. When returning to the other login ID that had the VM running, all hell starts to break loose. The VM terminates abnormally and if you relaunch it, it terminates abnormally again and puts up the dialog to report a problem (which I did: # 38508 for the benefit of the Parallels folks). There was no way for me to restart this VM. Thankfully, rebooting the MAC cleared the problem and I could start the VM.

Question for the Parallels folks: How can I put a protection in place for this similar to how V3 protected me? As I said, V3 was awkward but the worst case was that my wife had to ask me to login and shutdown the VM if she got the "in use error". Inconvenient but not as bad as how it appears to work now.
 
Beware of V4.0 behaviour differences with shared VMs

4.0 apparently has changed how it behaves when a VM start is attempted when someone else on the same MAC has left the VM running under a different MAC login ID.

And it appears to have CHANGED FOR THE WORSE. I just upgraded today from V3 and discovered this.

Under V3, if I tried to start a VM that was already running under another login ID, Parallels would throw up an error stating that the VM could not be started because it's already in use. I think there was a lock file in the .pvs package file that governed this. That afforded me a measure of protection. I could then ask my wife to log in and shutdown the VM so I could start it up under my login ID.

Under V4, Parallels goes ahead and tried to start the VM but fails to access all the hard disks and then tries to boot from the network apparently indefinitely. I have to force shutdown the VM. When I then login to the MAC user ID that has the VM running, all hell breaks loose. The VM terminates abnormally. If I try to start it again, it terminates again and puts up the dialog box to submit a problem report. (which I did: #38508).

I got worried that I would never be able to start this VM again but a reboot of the MAC cleared the condition and I could start it again.

Is there anyway that I can setup a protection similar to what was afforded with the lock file in V3?? This is very undesireable behaviour. Frankly, I still thing the V3 behaviour was inconvenient - I wish I could start a VM outside the context of a MAC ID and we could both share it from different IDs but that is a mere inconvenience compared to what is happening how.

Bill Smith
 
I have read that KB article

I have read the one that applies to permissions and had already followed those instructions. That is the only way I was able to get the VM to come up at all. My problem pertaining to lack of protection from trying to start the VM twice is a separate problem.

Thank you.
 
You must log in or register to reply here.
Back
Top