Are there issues running DS in a Virtual Machine?
Torquinox
Posts: 3,520
Are there issues running DS in a Virtual Machine? I'm considering setting up a VM to run 4.23 separate from 4.22. I've never used a VM before. I would probably use Oracle VirtualBox because I'm on Win 10 Home. I may upgrade to 11 soon, but I haven't done it yet. I'm wondering, is anyone here using VirtualBox or any VM? If so, how well does it work?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
It would be down to the available virtual RAM, virtual disk, and the virtual implementations available for your host's graphic card, I think. A virtual machine isn't supposed to allow direct access to the hosting environment's hardware or software, so you'd probably be limited to 3DL or Filament renders. I've not tried it personally though. I think others have mentioned trying it on Linux Wine but I don't remember their results and that's been quite a while back too.
@Nonesuch00 thank you. I did not know that. It makes sense! I'm wondering what other strategies I might try, such as additional user ids on my system or something like that. Then maybe it's down to additional hard drive space. At worst, set it up on another computer. I actually have one available... technically it's in the household but not mine...
You can use the public beta for the new versions only, copy all your scene files to a second scene directory that only the public beta is configured to use. You could even go as far as having two seperate SSDs with the DAZ content you have installed, one SSD for the release 4.22, and one SSD for the public beta 4.23 & plus. I'm not sure though how the CSM dB handles that. I know though your plugins and other shared directories, including your plugin keys that are registered will be shared.
I remember DAZ stating with the release of DAZ Studio 5 we can have both release copy of DAZ Studio 4.x and DAZ Studio 5.x installed simultaneously. That would also mean the same for public betas although further development of public betas for 4.x would stop I would think. I think further develop for 4.x releases would stop then to, not even bug fixes, not I don't know that for a fact. DAZ 3D has never stated such.
@nonesuch00 Thanks again for sharing your thoughts on this. It all makes sense and I recall hearing a lot of it. I've used a workaround that @zombietaggerung told me about to run multiple versions, It was pretty good, though that method didn't seem to pick up all my plugins. It could be because of the way plugin information is stored in the user profile's roaming data. The fact that info is stored in the roaming data made me think I might be able to get around some of the limits via an additional user profile, but we still only have one install spot on the boot drive for release version and another for the beta. I might be able to add a second boot drive with its own installs and user profiles and configure the computer for multiple boot I've done that before for different versions of Windows, and it should work with your idea of having multiple libraries. Clearly, we're not intended to choose between multiple versions of the program the way I'm trying to do. Blender and 3D Coat are ok with that. DS? Not so much. It's never easy!
If I had to install 11 by threat I'd probably get another SSD to do so rather than run two or more OS's on the same CPU. If the app is not CPU intensive and you need to contain multiple services in limited space and hardware then that's where a hypervisor comes in very handy, otherwise your system is already eating away at resources before you tell it to virtualize another environment for your software.
Virtual machines have so much overhead it's not worth it unless you need to run a different operating system. Instead I would suggest sandboxing, which would give you can get the benefits of a virtual machine without the overhead.
Make a separate sandbox of each version you want to run, and install the desired version inside. You can choose if anything in a given sandbox is allowed to read or write anything outside the sandbox, so you can keep the library outside (and thus shared between different versions), but the settings inside (so each version can have their own, separate settings).
You can also save snapshots of a sandbox, which you can instantly roll back to at any time. I use this a lot for things like software that likes to auto-update to versions that are incompatible with the rest of my ecosystem (looking at you, Kindle
).
The real cost in a setup like this is disk space. Well, and the confusion when a sandboxed program writes to a location that only exists inside the sandbox, and you spend a several minutes looking for the file you're sure should be in this folder, before remembering.
So you would have an OS installed on each SSD and plug in the SSD you want to run? Is that the idea?
This is also a pretty cool idea. I expect any solution I wanted to try would eat a lot of disc space. Nature of the beast!
The main issue with this is graphics card passthrough, assuming you have an NVIDIA and want to render with acceleration. You might have to pass the entire card to the VM which means you need two (one for the host as well). Typically driver support for partitioning is for server class OSes (Windows Server) but not on Professional or Home versions. I've done it with Hyper-V before using a hack that was available at the time (involves copying driver files from host to VM - not recommended). At work I did it with VMware, however that was hosted on another, headless (no graphics card) box.
Thank you for your advice. Most appreciated! As I learn more (including from you and others here). I think the VM idea is a bit beyond my ability to pull off.