Using VMWare: what files remain on host?

[Tom F 85]

I'm about to update to 10.4, having waited while EMB QA once again failed and we had to wait for them to remove bugs that should never have shipped. (Yes, I'm bitter about that, but that's a discussion to have another day.)

 

Rather than continuing to suffer from EBM releases that are defective, I'm going to for the first time develop on VMWare VM. This will of course allow me to easily roll back to a previous release.

 

One reason I haven't done this in the past is that I have never been clear about how much I should install in the VM itself, and how much should remain on my host machine.

 

If I put my source code (which is regularly backed up from the host to a repository) in the VM, then it seems that so many of my other tools also have to be in the VM, like my grep tools, and other utilities (like Beyond Compare, CI tools), etc.  

 

I don't know the best place to draw the line on what goes where. Perhaps I should leave my source on the host drive, accessing it from the VM?  This is less than ideal, because my archives would have two pieces (the VM, and the source on C:). And it also means that I'll have to remove all of the hardwired C:\ paths in my scripts and other tools.

 

To people using VMs for product development: how much do you install in your VM? Does your VM access your host drive for anything? Any suggestions?

 

Edited May 23, 2021 by Tom F

[FPiette 385]

You have to consider the content of your VM exactly like you would consider it if it was installed on a separate physical machine connected to the same LAN.

 

[Ruslan 6]

Think VM as a computer, it's not a container (like docker or jail), so if you think of moving the IDE to the VM than you should move the project(s) to othe VM and all the dev tools needed for that project.

I did like that. I've created a VM for Delphi development only, put my Delphi projects there and all the dev tools I need for my projects development, configured the git (git+TurtoiseGit+Bitbucket) and a additional a backup method. Every time I want to make some changes to my system (not in development manner), OS upgrade, IDE upgrade/downgrade - I make a full copy of my VM (because I have only a VMWare Player), but if you have a VMWare Workstation you could use the VM snapshot that is much comfortable.

[Rollo62 539]

On 5/23/2021 at 6:23 PM, Tom F said:

To people using VMs for product development: how much do you install in your VM? Does your VM access your host drive for anything? Any suggestions?

I find it very convenient to have a common _Transfer\ folder, which is available on the host, and shared in all VM's.

This helps to easily share files and data between the different VM's.

 

Thos files were stored on the host, and in the VM's they were only virtually binded.

Of course this is not intended to be opend for write from several VM's or the host at the same time, but just for manual exchange (e.g. for PAServer files, etc).

Edited May 24, 2021 by Rollo62

[Remy Lebeau 1436]

In my case, I used to have one IDE installed on the host itself, and then a bunch of other IDEs installed in VMs, so I kept my source files on the host and used shared folders for the VMs to access the files.  Worked fine.

[Tom F 85]

1 minute ago, Remy Lebeau said:

In my case, I used to have one IDE installed on the host itself, and then a bunch of other IDEs installed in VMs, so I kept my source files on the host and used shared folders for the VMs to access the files.  Worked fine.

Thanks, Remy (and to the other answers). Your approach is the one that appeals to me most. I'm glad it's working for you. I'll give it a try.

[Rollo62 539]

11 hours ago, Remy Lebeau said:

In my case, I used to have one IDE installed on the host itself, and then a bunch of other IDEs installed in VMs, so I kept my source files on the host and used shared folders for the VMs to access the files.  Worked fine.

@Remy Lebeau Interesting idea,

so I assume you still generate the heavy DCU's, BPL, binaries etc. inside each VM, to keep them well separated.

Does this help to reduce the overall VM size, if the sources were not inside the VM, I'm afraid not ?

 

How about compile speed when using the transfer folders instead of VM folders, could you see any difference ?

 

Since I use the host mainly as "empty, easy replaceable shell" for the VM's, I've tried to keep it clean and do everything in VM's inside,

but a common source folder can make sense.

[Remy Lebeau 1436]

11 hours ago, Rollo62 said:

so I assume you still generate the heavy DCU's, BPL, binaries etc. inside each VM, to keep them well separated.

Yes, each IDE would use its own default output folders within the VM.

11 hours ago, Rollo62 said:

Does this help to reduce the overall VM size, if the sources were not inside the VM, I'm afraid not ?

Source code is relatively small, so size was not an issue.  Besides, I typically used fixed-sized VMs anyway.  But no, storing the sources on the host did not affect the VM size.

11 hours ago, Rollo62 said:

How about compile speed when using the transfer folders instead of VM folders, could you see any difference ?

No.

11 hours ago, Rollo62 said:

Since I use the host mainly as "empty, easy replaceable shell" for the VM's, I've tried to keep it clean and do everything in VM's inside,

but a common source folder can make sense.

For me, being able to compile the same sources in multiple IDEs was important.  If I changed something, I didn't want to have to copy the changes to multiple VMs to test it, just change it in one place only and then recompile as needed.

[Cristian Peța 107]

I start a new VM for every major app version and I want old versions to be stable. In this case I prefer to keep the sources in VMs.

I don't write 3rd party components and I need only one Delphi version per my app version. It is easier so.

When I start a new version I do a copy of the VM and all is there.

[Tom Chamberlain 47]

We only install the IDE (+ 3rd party components/tools) and leave the source folders and source control on the host, build DCU/EXE/DLL's to the host share the so other VM's (2019 and Ubuntu) can access them.  For dot update 10.2.1 -> 10.2.2 just a simple backup copy of the VM before the upgrade.  We try to skip releases so 10.2 -> 10.4 was a clean VM and fresh install of the IDE, all mapped to the same source share on the host.

[Wil van Antwerpen 25]

Also using everything VMware down here.
All of my code and setup is in a VM.
If I need to share source with other VM's or host then that is done via source control.

Note that VMware shared folders (hgfs) can work for sharing source with host, but if it has a lot of files then I do expect a decreased performance while compiling.

Shared folders are convenient, but they are also known for not being very performant.

This is a common complaint at the VMware Forums.

 

My recommendation in that case is to use network shares as they tend to be faster.

Another thing to look into when troubleshooting performance issues with VMware shared folders is to make sure you antivirus is not checking your source.

[Uwe Raabe 2064]

1 hour ago, Wil van Antwerpen said:

If I need to share source with other VM's or host then that is done via source control.

Same here. This also helps to keep the VM independent from the host. All my VMs are self contained and can be moved to arbitrary hosts (with capable hardware of course).