VMWare Workstation 12.5 toggle hardware disks in VM

[Lapsio]

Hello I'm using host OS with old kernel (4.6) and I'm passing physical btrfs RAID array drives to VM with kernel 4.12. The thing is one of arrays managed by this VM is removable (made of USB HDDs). In orded to increase i/o performance LUKS encryption is handled by host OS and guest receives already decrypted drives to work with.

I figured out that I can change line:

scsi0:10.present = "TRUE"
to:
scsi0:10.present = "FALSE"

And it makes VM boot properly when drives are not present. When they're attached again I can just change this line back to "TRUE" and everything works nice. However I'd prefer to do it via actual Workstation UI, not text editor. Is it possible to perform such change easier?

[continuum · Accepted solution]

Setting

scsi0:10.present = "TRUE"

to

scsi0:10.present = "FALSE"
is the appropriate action if your virtual disk is just out to lunch and is expected to return later.
Doing so keeps scsi0:10.filename and all other scsi0:10.parameter just as they are.
You cant send your vmdk to lunch via the UI - when you remove a vmdk via the UI WS assumes that this vmdk will never return and removes all its parameters.

Ulli

[RParker]

I figured out that I can change line:

scsi0:10.present = "TRUE"
to:
scsi0:10.present = "FALSE"

And it makes VM boot properly when drives are not present. When they're attached again I can just change this line back to "TRUE" and everything works nice. However I'd prefer to do it via actual Workstation UI, not text editor. Is it possible to perform such change easier?

Even if it were possible you can't do it live, you would still need to modify the settings via txt file.  Workstation and any VMware product will not let you modify files while VM is running, so you would need to keep doing it the old fashioned way...

But some settings are not visible via the GUI hence the method to directly modify files in the vmx. 

It seems you can do this via the guest OS instead of the host .  It's like changing BIOS settings to 'trick' the OS into not using those drives, then going back and enabling those features..  The guest OS should have a dynamic way of always using those drives with a command line, so the devices are present during boot of VM but guest OS ignores them since they are not usable.. but if you set a 'soft' setting in guest OS it should be disabled and when are able to use those drives you can double click the drive in guest OS to make them 'wake up' so to speak.

Same principle for offline network drives in Windows they are there (with a red 'X') and once they are available (such as a laptop with wireless connection) when you are connected to that network it should let you connect otherwise they stay offline but still technically attached just the OS will ignore them until they are available..

Seems it should be pretty easy to get Guest OS to not use those drives until you are ready since its apparent you don't need them at boot.

[Lapsio]

RParker​ It's not problem with guest but with VMWare itself. It doesn't allow me to boot VM when drives are missing throwing "No such file or directory" error when I try to launch VM. I don't need to do it live I just don't feel really comfortable with editing .vmx file every time I'm connecting drives. I mean you know - i could accidentally delete some other line some day or screw up something. Editing 2 lines in quite complex text file manually with text editor, once a week is not really best solution ever. It's offsite, offline backup RAID array so It's transported back and forth from/to other site. When it's not here I still need to access primary array. I considered making 2 separate VMs, one being just for this detachable array but terrible performance drop while performing heavy i/o over virtualized network discouraged me to do so (780 MB/s -> 120 MB/s)

Is there maybe CLI way to change this line? (And I don't mean using `sed` to search & replace those lines)

[continuum]

Damian
In this special case - users that try to achieve their goal via the UI have a higher chance to make mistakes than users who carefully edit their vmx-files after creating a backup first.
As the UI also removes the path to your vmdk when you remove it, it is way easier to make an error while re-adding for example -mydisk-000037.vmdk.
Hu - was it really *-37 ????
Just toggling "true" and "false" is way easier.