(this is second post - 1st post did not appear on forum?)

I am running a 64-bit Linux (Devuan) and want to create separate VM's to contain Wine as 64-bit and 32-bit respectively, as well as the needed development(coding/IDE/debug) tools for each.
My options:
1. LXC; can this be done using LXC, and if so where can I find guides to do it? (Googling delivers a mess of at times contradictory info)
2. Qemu/KVM: where can I find guides to do it? will this be optimal for resource usage?
3. Virtualbox - do-able but not ideal (space/duplications/optimal?/..)
4. ?

Which option should I use, and where will I find the needed info to implement the option?
(the jackpot would of course be a noddy-guide

This sounds like a crazy project, but that's ok. I'll answer
4?

Use some VM tool. I use virtualbox, which just works, but knock yourself out with whatever you want. Install ONE VM, Slackware64. I'd advise current, download the iso because current keeps changing.

On top of current, install multilib (for 32bit compatibility). That will reinstall glibc & GcC for allowing 32 bit compiles. Install Slackware's wine, which is also 64/32 bit.
Add whatever debuggers, compilers, simulators, & whatever.

Then pursue your project, write the report on how you got the box, and contribute it to the community.

@business_kid:
"crazy project" - my current distro is just the way I want it & I do not want to mess with it.
I want to do minimal installs if possible that's why I'm looking at LXC first but do not know how to get it going.
I want one VM to be pure 64-bit with Wine (& the dev-tools I need), and then a second pure 32-bit VM with Wine, etc.

I know how to do it with Virtualbox but that may not be the best way. I would preferably stay 'pure' Linux with VM's.

Using LXC or classic OpenVZ containers would be lighter and faster, but require installing the right packages on the host. Your machine should be almost LXC ready without many changes.
There is nothing 'pure' or 'impure' about Virtualbox, and it provides a more pure GUEST than a container system as that used by LXC.On the other hand it also has more overhead and your compiles will take longer.

Ignoring the objective and just looking at creating guest environments for the development: either should work and I have done both (on much earlier versions than current) and found a HUGE number of references and tutorials on the internet. Have a look around for yourself, but watch the version numbers: many of those I found were for obsolete versions of the software.

Obsolete documentation does not hurt much when working with Virtualbox, but LXC has undergone rapid development and major changes.

Doubt anyone can provide the perfect solution except you slashmais.

I guess if I had virtualbox additions available for your host then I'd use virtualbox and maybe get some prebuilt VM's of some JEOS or minimal OS to host this wine configuration.

I would prefer using Linux-based tools like LXC or straight Qemu/KVM. Searching
the web gives lots of sometimes contradictory information on how to use these tools,
and I would like to be set on the right path by the Linux gurus on this site.

Only as a last resort will I use the Oracle-product (- meaning that Linux virtualization is a failure?)

I do exactly this ( compile wine ) in lxc

setup LXC "as normal"

in the each of the /var/lib/lxc/64bit/config /var/lib/lxc/32bit/config

add
note, the path on lxc side does not have a leading /
( i.e. not a typo )


now
in each 32/64 build dir

Edit, forgot to say, this file should be named configure and executable
I actually use dpkg-buildpackage to create .deb files


you can configure && make both the 32 and 64 at the same time

I connect to the LXCs via ssh, and open a gnu/screen session

tmux would also work

1 members found this post helpful.

@Firerat: this is compiling wine itself and as such a very handy reference.

My need is (maybe) simpler: I want to set up environments in which I install wine and such tools(for dev on windows) for both
32- and 64-bit. The aim is to develop apps that will run on windows(/wine), not to develop wine itself.

a thought, since this concerns lxc(/lxd) maybe this part of my question should be moved to the 'Linux - Containers'-forum?
can the moderators do that or should I cross post this part to that forum?

oh, ok

you want to run wine in the container

presumably you would want Xserver

not something I have tried myself
I did play around with Xforwarding over ssh , just for fun

I did find this which looks interesting
https://discuss.linuxcontainers.org/...container/5022

assuming plenty of ram, then I would probably go the VM route,
KVM/qemu or virtualbox ( as has already been mentioned )

xen is also worth a mention
but won't be as easy to get going as the above VMs

"VirtualBox is a powerful x86 and AMD64/Intel64 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 2. See "About VirtualBox" for an introduction."

https://www.virtualbox.org/

OK, but that's a rod for your own back. Wine64 doesn't tolerate 32bit and vice versa.

The main VirtualBox package is free/libre. Most distros have a package. The extension pack is proprietary and non-free, but there is no proprietary license restrictions with the main Virtualbox package. That seems reasonably 'pure' to me.

If it is very important that you remain pure OSS, then LXC is the best option. I have built 32 and 64 bit development guests using OpenVZ (which is not pure OSS) and LXC in the past. It should be easier now than it was two years ago when I last did such a project.

1 members found this post helpful.

I would point out that the more layers of software go in, the more errors, the less performance and the less real this is going to be. Personally I would keep compiling as low level as possible.

Good point. If you use LXC in full distribution mode, the most like full virtual guests rather than app or service guest, the leaner the compile environment looks. The compiler sees ONLY the libraries installed in the guest and not whatever is installed on the host. This has implications. For one, if you need a package for the compile you do NOT need to install it on the host, ONLY in the guests. This keeps your host more "pristine". If you ONLY install exactly what is needed for the compile in your guests, they are smaller and things compile faster because the loader and compiler have less checking to do, and it is done in a thinner environment. This also implies that your finished product has the POTENTIAL to have fewer dependencies, fewer opportunities for vulnerabilities, and less unintended complexity under the hood.


Of course, half of that (the part that is NOT the performance advantage) also applies to full virtualization solutions like VirtualBox as well. LXC container advantage here is that performance is about as close as you can get to native iron performance.