Observations about 2.0

[ChipMcK]

Some items to consider for future improvements

Shared Folders:

Unable to specify the new folder name for an associated name;

Had to delete everything and start over from scratch.

Virtual Machine Library

no idea which is the production machine versus the 'testing back-up'

machine in a 'test' folder (verifying that the back-up is valid/runable);

If Quit Fusion and start up again, get big "?" if 'test back-up' is omitted.

- with 1.1.3, the in-residing folder name was appended to the duplicate

named VMs/bundles/packages

Starting up a Guest

The font used for the BIOS events appears random: at times so

small as to be unreadable; other times it is readable at ten feet.

Lck in the Back-Ups and Copies

There is an abundance of 'vmx.lck' files thru-out copy/back-up

bundles/packages. Also, the locks do not prevent updates by tools

like VMX Extras and TextEdit.

[WoodyZ]

Starting up a Guest

The font used for the BIOS events appears random: at times so

small as to be unreadable; other times it is readable at ten feet.Not sure what your seeing however it is quite normal for a BIOS Screen to display different sized text.

This is normal and to be expected.

Lck in the Back-Ups and Copies

There is an abundance of 'vmx.lck' files thru-out copy/back-up

bundles/packages. Also, the locks do not prevent updates by tools

like VMX Extras and TextEdit.

You should not be copying or backing up Virtual Machines while Fusion is running. This will eliminate the .lck file(s) and or folder(s).

If you have to do a Hard Shutdown this can cause the .lck file(s) and or folder(s) to be present.

[admin]

Shared Folders:

Unable to specify the new folder name for an associated name;

Had to delete everything and start over from scratch.

What do you mean? You can change the guest-visible name by clicking on it and waiting a second, just like changing a folder name in the Finder. It's true you have to create a new shared folder if you want to share a different host folder.

Virtual Machine Library

no idea which is the production machine versus the 'testing back-up'

machine in a 'test' folder (verifying that the back-up is valid/runable);

If Quit Fusion and start up again, get big "?" if 'test back-up' is omitted.

- with 1.1.3, the in-residing folder name was appended to the duplicate

named VMs/bundles/packages

You could give them different names, or use Show In Finder to differentiate them.

[WoodyZ]

Virtual Machine Library

no idea which is the production machine versus the 'testing back-up'

machine in a 'test' folder (verifying that the back-up is valid/runable);

If Quit Fusion and start up again, get big "?" if 'test back-up' is omitted.

- with 1.1.3, the in-residing folder name was appended to the duplicate

named VMs/bundles/packages

I have to admit I do not like the differences between 1.x and 2.0 in this respect either and while I could say more about this particular change, at the moment, I will not.

To add to what Eric (etung) has already said there is also the Notes: field that one can use to help differentiate between the Virtual Machine Library window entries do to the changes in how 2.0 handle this from 1.x.

[ChipMcK]

Shared Folders: I wanted a different host name (to reflect a different

version); this was

easy to do with 1.1.3

Virtual Machine Library: I am trying to verify that that back-up

actually works; once verified, the bundle/vm will be deleted

(reclaim the space) - used to be two

minute task.

[ChipMcK]

Lck files:

... while Fusion is running????? Do mean the Virtual Machine? Or

VMware?

With 1.1.3, VMware could be started and the VM bundles copied as long

as

the VM was not running. Your Help files stated that the VM must be

shutdown,

not that VMware had also to be stopped/quited.

[WoodyZ]

Lck files:

... while Fusion is running????? Do mean the Virtual Machine? Or

VMware?

With 1.1.3, VMware could be started and the VM bundles copied as long

as

the VM was not running. Your Help files stated that the VM must be

shutdown,

not that VMware had also to be stopped/quited.

FWIW VMware is the Company which has may virtualization products and to keep referring to the product as VMware is incorrect and confusing. The product is Fusion.

Fusion 2.0 is different then Fusion 1.x in many respects and any Virtual Machine that is listed in the Virtual Machine Library window will have an active *.vmx.lck folder containing a .lck file even the the Virtual Machine's display window is closed and this was not the same in Fusion 1.x so to avoid any possible issues involving .lck file(s) or folder(s) one should close Fusion when backing up any Virtual Machines that are listed in the Virtual Machine Library window.

Also note that if a Virtual Machine was abruptly shutdown as in a hard reset of the Host or the Virtual machine itself this can cause orphaned .lck file(s) or folder(s) to remain in the Virtual Machine Package or its Containing Folder if it's not bundled.

[ChipMcK]

With 1.1.3 I never had a 'orphan' problem unless the power failed.

Please, explain again why is 2.0 riddled with orphans.

[WoodyZ]

With 1.1.3 I never had a 'orphan' problem unless the power failed. Please, explain again why is 2.0 riddled with orphans.

Other then the message board screwing up the formating of my last post by injecting some of my reply as part of quoting what you had said (which I have now corrected) what is there to explain again? What explicitly and specifically do you not understand? I see nothing in my last reply that need addition explanation regarding the differences of the presence of .lck's between Fusion 2.0 and Fusion 1.x. as it relates to how they can be in a backup if the backup was made while Fusion was running even if the VM was not. As to orphaned .lck's this can occur in any version although why specifically the conditions per incident can of course vary due to the difference that in Fusion 2.0 it opens a .lck to all VM's in the Library window when Fusion loads and Fusion 1.x didn't do this. The two version have different features which can, in part, be responsible... period, enough said!

[ChipMcK]

Before either 'work-around' can be implemented, one must first figure

out which is which.

There is no difference in the Library presentation - it is no longer

quick/simple (reminds

me of Vista: nice appearance, but not ease to use)

[admin]

Before either 'work-around' can be implemented, one must first figure out which is which.

Sure, but that's a one-time thing. Ctrl-click one of the two, choose Show In Finder, and figure out which it is. Go back to the Virtual Machine Library and change the name or add a note to differentiate it.

[ChipMcK]

Or delete it if it is the 'to be verified' back-up after running it.

Also, the name displayed is the "displayName" in the .vmx file; you need

to start up an editor (TextEdit, VMX Extras, etc.) to change the name.

[Pat_Lee]

Or delete it if it is the 'to be verified' back-up after running it.

Also, the name displayed is the "displayName" in the .vmx file; you need

to start up an editor (TextEdit, VMX Extras, etc.) to change the name.

Actually, you don't need to fire up an editor. Just select the VM and in the right hand pane, click on the Name above the notes and you can edit the display name directly in the Virtual Machine Library and can add notes below as well...

Pat

[ChipMcK]

Not bad. You can change the displayName setting on the fly, while the

VM is running.

Certainly, something unexpected. Is this why the 'orphan' vmx.lck

happen?

[WoodyZ]

Certainly, something unexpected. Is this why the 'orphan' vmx.lck

No that has nothing to do with the .lck file(s) or (folder(s) and I have all ready covered the .lck issue so you don't understand what I've already explained in the thread regarding this subject then why don't you quote what I've already said and ask a question about what you seem to not be understanding.

[ChipMcK]

Are there any other items of the vmx file that can be updated while

the VM is running?

[admin]

Are there any other items of the vmx file that can be updated while the VM is running?

You never want to edit the .vmx file while the virtual machine is running or locked. Many parameters in the .vmx file are reflected in Fusion's UI under Settings, though these generally can't be changed when the virtual machine is running.

[ChipMcK]

But yet Fusion edits the displayName setting while the VM is running.

[WoodyZ]

But yet Fusion edits the displayName setting while the VM is running.

There is a big difference between Fusion making modification to the .vmx configuration file while it's in use and the user manually editing it while it's in use. If you need to make manual edits to the .vmx configuration file because the target parameter cannot be modified by Fusion while it's in use then you need to shutdown, not suspend, from within the Guest OS and close Fusion to make the edits.

Message was edited by: WoodyZ

Of course I'm referring to the parameters that Fusion cannot change even when the Virtual Machine is shutdown and not changeable through Settings when referring to manual edits.

[wila]

Hmmm are you sure this is a VMware Fusion 2.0 issue?

Did you create the VMs that you are comparing here with the same VMware product?

Let me see if I can explaint his properly. If you create a VM with for example VMware workstation and then ask the VM to shutdown it will acdtually power off.

If you create the VM with VMware Fusion and then ask the VM to shutdown it will not really shutdown, but it will do a soft shutdown.

See also VMware Fusion Help (Yes I mean the Help option menu)

Book:" Running VMware Fusion and Virtual Machines"

Chapter: Options for VMware Fusion Power Commands

and Chapter:

Shutting down a Virtual Machine's Operating system

COuld this be your problem with the .lck files?

Good question about that change the name while running (can't test it now unfortunately)

--

Wil