Using a virtual machine within a “chroot” configuration

I would like to construct a customised virtual machine for my needs.
I accordingly installed recent software components at the usual places.

:\ Can the virtual machine work (without extra Linux kernel modules) also within a system configuration based on a “changed root” environment?
Which settings will need special development considerations?

Would an application like “GNOME Boxes” be appropriate for such an use case?

You’re going to have to be more specific about whatever you’re describing… Too many references to stuff like “extra” (extra compared to what?)

I don’t know why anyone would want to run anything virtualized within a chroot… One of the features of nearly all virtualization is the ability to isolate virtual machine processes from each other and from the HostOS.

I would recommend you just run some virtualization and experiment with it… With just a little exposure you should notice characteristics and features, and you’ll likely find answers immediately on your own.

If you have specific answers about a specific virtualization, post your detailed question.

TSU

I propose to reconsider reasons like the following:

  • Virtual machines are applied as a general component for known programming languages.
  • Software versions can differ according to selected execution environments.
  • I would also occasionally prefer to restrict the data processing effects for the system user “root” (or “admin”).

Re using a virtual machine programmatically is not typical, although it might not be unusual to create a devops script to manage virtual machines.
In other words, the focus and purpose of your application is important… Is creating an isolated running instance only a temporary means to a desired result or are you managing a virtual machine? And, identify why you’re running the process in a virtual machine, if you truly understand the reasoning for that idea you may determine there are better ways to execute the idea.
I could run down a list of my own that could be addressed various ways but would likely be counter productive since only your reasons are relevant to what you have in mind.

If you’re talking about software versioning and execution environments, the development language itself may have its own solutions… like for python there are solutions like virtualenv an venv. There are similar versions or Ruby. “Managed” code like Java and the CLR (eg Mono or .NET) address this in their own ways. Part of being proficient in a coding language are the options to set up properly (both your development environment and the runtime environment).

Regarding root/admin on Linux systems, you’ll be limited by the fundamental Linux security model which is fundamentally based on system and not User security so doesn’t have the same granular User security as Windows, but there are a number of workarounds people have developed that still get the job done. This subject is very large, and covers decades of various efforts probably filling a book, so won’t be covered here.

So,
Am recommending a “back to basics” approach to what you’re doing…
Define your objective clearly with as much detail as possible so you also have a list of lesser objectives ranked from required to only desirable.
Specify a chosen coding language you feel comfortable with, it should be something you feel comfortable with although some languages are more suited for some projects than others.
From what you described, it’s unclear if your code would be a DevOps solution, if so then that is a whole different area of solutions many which are available off the shelf (already built, don’t have to re-invent the wheel).

Then you can start penciling out how you might actually execute your concept.
Embedding security in your app requires some knowledge of your options, sometimes security can be made an integral part of your app, when that’s not possible or simply by preference, it might be possible to simply wrap the flow within a layer of security. There are numerous ways of executing security even on your own, including component selection, use of labels, taking advantage of built 0n Linux or coding language, more.

I’m sure someone else would probably suggest other ways of looking at your project,
Good luck,

TSU