LXD For Linux Containers Had A Very Fruitful 2018

[phoronix]

Phoronix: LXD For Linux Containers Had A Very Fruitful 2018

While Canonical often takes heat for their various project "forks", their work on LXD for further innovating atop LXC for Linux containers has really paid off. Over the past few years LXD has really evolved into quite a capable system container manager beast...

http://www.phoronix.com/scan.php?page=news_item&px=LXD-2018-Progress

[schmidtbag]

Although I know this isn't their purpose, I think containers have real potential for multi-seat PCs in a way that's far more affordable and easier to maintain than using VMs, especially if you can get by with just a single copy of each program installed. It's nice to see LXD make so much progress.

[skeevy420]

Although I know this isn't their purpose, I think containers have real potential for multi-seat PCs in a way that's far more affordable and easier to maintain than using VMs, especially if you can get by with just a single copy of each program installed. It's nice to see LXD make so much progress.

Funny, I was thinking the exact same thing. With all the 8+ core processors these days one could setup a multiseat box that would be good enough to play two ore more high-quality games at once. All you really need is a GPU and a USB hub (keyboard/mouse/game controllers/etc) per setup. I only mention it like that because if multiple games can be played, the ports are the limit in regards to office work.

An old Bulldozer or Westmere with most low end 2013+ GPUs would be awesome to make into multiplayer multiscreen libretro boxes. Pick 2016+ gear and you can have a 1080p 4 player LAN party with one PC. Just do not skimp on the power supply.

These are wonderful times we live in. Just a little bit of creativity and elbow grease and a person can have a really awesome setup.

[tildearrow]

Typo:

The biggest achivement for this project

[Britoid]

Funny, I was thinking the exact same thing. With all the 8+ core processors these days one could setup a multiseat box that would be good enough to play two ore more high-quality games at once. All you really need is a GPU and a USB hub (keyboard/mouse/game controllers/etc) per setup. I only mention it like that because if multiple games can be played, the ports are the limit in regards to office work.

An old Bulldozer or Westmere with most low end 2013+ GPUs would be awesome to make into multiplayer multiscreen libretro boxes. Pick 2016+ gear and you can have a 1080p 4 player LAN party with one PC. Just do not skimp on the power supply.

These are wonderful times we live in. Just a little bit of creativity and elbow grease and a person can have a really awesome setup.

wouldn't be the securest thing, a lxc container would use the parent GPU driver.

[andreano]

parent gpu

Wayland with render nodes ftw

[schmidtbag]

Funny, I was thinking the exact same thing. With all the 8+ core processors these days one could setup a multiseat box that would be good enough to play two ore more high-quality games at once. All you really need is a GPU and a USB hub (keyboard/mouse/game controllers/etc) per setup. I only mention it like that because if multiple games can be played, the ports are the limit in regards to office work.

An old Bulldozer or Westmere with most low end 2013+ GPUs would be awesome to make into multiplayer multiscreen libretro boxes. Pick 2016+ gear and you can have a 1080p 4 player LAN party with one PC. Just do not skimp on the power supply.

These are wonderful times we live in. Just a little bit of creativity and elbow grease and a person can have a really awesome setup.

Haha you pretty much read my mind. I've had plans to do this sort of thing myself for a while, but I don't know enough people who can/will do local multiplayer for me to justify buying the extra hardware.
But if you're seriously considering trying this, I do have some ideas to help save on time and system resources. Hopefully you (or someone) can continue where I left off.
For example, install your DRMs (like Steam) and games on the host OS. Then in your container, use an ftp mount in /etc/fstab to access the host. Append your $PATH and ld.so.conf to use the hosts's bin and lib folders. This alone should save you a lot of time not having to re-install everything (of course, there are plenty of instances where you're going to need to install a few things inside each container, particularly anything that meddles with the /etc directory). Then, each of the containers should log into your steam account offline. This will allow you to run multiple Steam sign-ins without them knowing. Direct Steam to download your game library to the same folder in the host drive, which in turn should spare you from needing to re-download every single game. I haven't tested this, but I'm sure any game that creates/modifies files within its install directory (rather than your home folder) will need the bulk of its contents re-downloaded, but I'm sure you could symlink most of it.

wouldn't be the securest thing, a lxc container would use the parent GPU driver.

Considering he's talking about a gaming rig, security isn't really that relevant. Pretty much the only time the container would be logged-in is to play a game.

[skeevy420]

wouldn't be the securest thing, a lxc container would use the parent GPU driver.

I agree, but a home multiplayer gaming setup isn't an environment where you really have to worry about users hacking the system or trying to break the jail. IMHO, that's only a real concern for a public computing setups like libraries, offices, workstation clusters, and "the cloud".

Haha you pretty much read my mind. I've had plans to do this sort of thing myself for a while, but I don't know enough people who can/will do local multiplayer for me to justify buying the extra hardware.
But if you're seriously considering trying this, I do have some ideas to help save on time and system resources. Hopefully you (or someone) can continue where I left off.
For example, install your DRMs (like Steam) and games on the host OS. Then in your container, use an ftp mount in /etc/fstab to access the host. Append your $PATH and ld.so.conf to use the hosts's bin and lib folders. This alone should save you a lot of time not having to re-install everything (of course, there are plenty of instances where you're going to need to install a few things inside each container, particularly anything that meddles with the /etc directory). Then, each of the containers should log into your steam account offline. This will allow you to run multiple Steam sign-ins without them knowing. Direct Steam to download your game library to the same folder in the host drive, which in turn should spare you from needing to re-download every single game. I haven't tested this, but I'm sure any game that creates/modifies files within its install directory (rather than your home folder) will need the bulk of its contents re-downloaded, but I'm sure you could symlink most of it.

If Steam is any indication, Overlays and Symlinks usually work just fine. Before my GPU started dying and I switched from Arch to Manjaro, I had it setup so my Windows Steam games would be overlayed onto my Linux Steam game directory and I'd turn the the default Steam Linux install directory into a symlink to that directory so I didn't have to redownload my games just for Proton, didn't have to waste drive space copying stuff from my Windows drive to my Linux storage drive, and didn't have to worry about setting up the default directories...just mount the overlay during init and set a symlink before launching Steam the first time...something I picked up distro hopping a lot...

Depending on the game, luckily, Steam doesn't have to actually be running. Those games, like KSP, will be the easiest ones to work with.

I've never actually messed with containers or multiseat yet. Never had an actual reason until very recently. The only two GPUs I have that would work are a pair of old Quadro NVS 295s and I'd prefer to do it and learn it with AMD cards.

I'm going to have to remember those $PATH, ld.so.conf, and /etc stuff. Thanks for the tips.

Hopefully I'll be in a position in the next two months to start working on it.

[starshipeleven]

Haha you pretty much read my mind. I've had plans to do this sort of thing myself for a while, but I don't know enough people who can/will do local multiplayer for me to justify buying the extra hardware.

This. I'd be surprised if anyone that actually has the free time and inclination to do something like this isn't in a similar situation.



Ok, I'll go back into my corner.

For example, install your DRMs (like Steam) and games on the host OS. Then in your container, use an ftp mount in /etc/fstab to access the host. Append your $PATH and ld.so.conf to use the hosts's bin and lib folders. This alone should save you a lot of time not having to re-install everything (of course, there are plenty of instances where you're going to need to install a few things inside each container, particularly anything that meddles with the /etc directory). Then, each of the containers should log into your steam account offline. This will allow you to run multiple Steam sign-ins without them knowing. Direct Steam to download your game library to the same folder in the host drive, which in turn should spare you from needing to re-download every single game. I haven't tested this, but I'm sure any game that creates/modifies files within its install directory (rather than your home folder) will need the bulk of its contents re-downloaded, but I'm sure you could symlink most of it.

A less hacky (and illegal) way would be to use a cache server, which exists already for Steam specifically in an easy docker container https://steamcache.github.io/

But there are also others for other gaming services.

Normal cache servers would not be a good idea as these types of downloads always come from some kind of CDN (i.e. a large bunch of different servers chosen at download time depending on load). So for a normal cache server there is no way to know that you are downloading the same thing if you are assigned a different download server from the CDN.

[schmidtbag]

If Steam is any indication, Overlays and Symlinks usually work just fine. Before my GPU started dying and I switched from Arch to Manjaro, I had it setup so my Windows Steam games would be overlayed onto my Linux Steam game directory and I'd turn the the default Steam Linux install directory into a symlink to that directory so I didn't have to redownload my games just for Proton, didn't have to waste drive space copying stuff from my Windows drive to my Linux storage drive, and didn't have to worry about setting up the default directories...just mount the overlay during init and set a symlink before launching Steam the first time...something I picked up distro hopping a lot...

True, I've done something similar myself. But that only works when everything is operating on the same "level". When going from host to guest/container, you can't see all files from one or the other unless you explicitly share them.

Depending on the game, luckily, Steam doesn't have to actually be running. Those games, like KSP, will be the easiest ones to work with.

Haha yup. So far, most of those games are ones that depend on their own DRM though, which further complicates things.

I've never actually messed with containers or multiseat yet. Never had an actual reason until very recently. The only two GPUs I have that would work are a pair of old Quadro NVS 295s and I'd prefer to do it and learn it with AMD cards.

I've messed with multiseat a few times. It's very powerful but also very fiddly. You can do some pretty weird stuff on multi-seat, like being able to use 2 keyboards with the same user typing on different applications, or using the same sound card to output 2 different audio channels based on the user. I've also dabbled a little bit with VMs but never bothered getting to a point where I'd passthru a GPU (if you use something like Xen, I'm pretty sure any GPU can work, not just Quadros). I never tried containers but I know they function very similarly to VMs.

A less hacky (and illegal) way would be to use a cache server, which exists already for Steam specifically in an easy docker container https://steamcache.github.io/

The point of my method is to have 1 instance of a game installed, which as far as I'm aware, isn't illegal. What probably is illegal is running multiple instances of Steam from the same user account, which a cache server isn't going to fix.
In other words, if you want to minimize disk usage and network bandwidth while still remaining legal, sign in to 2 separate Steam accounts but have them share the same game library (assuming they have the same games available).