Why does a 6.5 VM create scsi0:0.mode = "undoable"

[continuum]

... noticed something strange ...

I had a 6.5 VM with a snapshot - next I added one disk and removed the two existing ones.

Workstation didn't like that ...

It created this entry in the vmx

scsi0:0.mode = "undoable"

After that it failed to start and complained about a strange thing that happened to the vmx - something like that.

Never saw such an error before - sorry - forgot to copy the full text.

AFAIK

scsi0:0.mode = "undoable"

was last used in WS 3 and GSX 2.5 ...

I never changed the virtual hardware version of this VM - it was a fresh 6.5 VM

___________________________________

description of vmx-parameters: http://sanbarrow.com/vmx.html

VMware-liveCD: http://sanbarrow.com/moa.html

[admin]

Is this reproducible?

If so, can you give more specific reproduction steps?

[continuum]

I just came across it accidentaly - looking for the cause of that strange error.

I'll try to reproduce it

___________________________________

description of vmx-parameters:

VMware-liveCD:

[continuum]

Haven't seen "undoable" again yet - but I noticed something else i don't understand.

Usually a VM doesn't need a vmx-parameter "fileSearchPath"

Though i never actively set that parameter a couple of my 6.5 VMs now use it.

As this introduces absolute paths into the vmx-file which makes it unportable I see no good reason why this entries are created at all ???

To reproduce it create VM with a disk in a subdir - then create a snapshot. Move that VM and try to start it.

When you move such a VM to a different location/host you then may need to browse for the disk - this adds another entry to the "fileSearchPath"

Well I have to admit that not many user may hit this issues as most of the times disks are used in the same directory as the vmx-file.

But when a user uses vmdks in a subdir - which in itself makes a lot of sense - this causes issues.

I can no longer fully automate move and launch of VMs that use a snapshot AND have the basedisk in a subdir. This is anoying because it is so useless ...

The vmx should use relative paths when ever possible.

When a file like a vmdk is available through a relative path - this should never be replaced by an absolute path.

Ulli

___________________________________

description of vmx-parameters:

VMware-liveCD:

[admin]

Yeah, that the .vmsd file references disks by absolute paths when they're in subdirectories sounds like a bug. Thanks.

[continuum]

Please also investigate the exact conditions when a VM creates the additional vmx-entry "fileSearchPath" - in none of the cases it appeared in my VMs it was really needed !

___________________________________

description of vmx-parameters:

VMware-liveCD:

[admin]

The real issue is that as soon as you take a snapshot of a VM that has a disk in a subdirectory, the .vmsd file and the generated delta disk both store absolute paths to the parent disk. The fileSearchPath part is just a side-effect of that (because if you move the VM, the absolute paths obviously will be broken, and you'll need to browse for the disk files).

[continuum]

Yes - i understand that ... but that doesn't explain the behaviour of the "fileSearchPath" parameter completely.

In case the already configured "fileSearchPath" doesn't work anymore and you need to browse for a new one - why then doesn't the path gets fixed ?

instead it just appends another entry.

So the suggested workaround for now is to always check the vmsd when ever you want to move a VM ... hope you can fix that soon

___________________________________

description of vmx-parameters:

VMware-liveCD:

[admin]

That's how the fileSearchPath value is supposed to work. We don't actually rewrite the paths in the .vmsd file and in the disk files (I don't remember why offhand, but possibly it's to allow some recoverability if someone picks the wrong directory). We also append to the existing fileSearchPath; you can imagine a linked clone of a linked clone where both the parent and grandparent VMs are missing, requiring multiple iterations of searching for the missing files.

[continuum]

Ok - that makes sense.

The revert-to-snapshot bug also has to do with the vmsd - do you already know when this happens ?

I came across it a few times - but not always ?

___________________________________

description of vmx-parameters:

VMware-liveCD:

[admin]

What revert-to-snapshot bug?

[continuum]

? - create a snapshot named "snap1" - revert to snapshot - then you get two items named "snap1" in Menu > VM > Snapshot > Snap1 and another Snap1

last lines of vmsd ...

snapshot.mru0.uid = "1"

snapshot.mru1.uid = "1"

___________________________________

description of vmx-parameters:

VMware-liveCD:

[admin]

Oh, that. Yeah, see my comments in this thread: http://communities.vmware.com/thread/173156

[continuum]

I don't need to look up that comment - I already know it by heart

- hey - I just looked up the Release notes - known issues.

The lines : "VMs that use vmdks in subdirs are not portable once a snapshot was created"

use a rather funny stylesheet-information : white text on white background

___________________________________

description of vmx-parameters:

VMware-liveCD:

[continuum]

Ignore post - yes - it works now after manually fixing vmsd and delta-vmdk.

Doing this on the default monolithicSparse disktype which Workstation uses is surely beyond average users skill - please fix soon

___________________________________

description of vmx-parameters:

VMware-liveCD: