Are you over 18 and want to see adult content?
More Annotations
A complete backup of bandainamcoent.com
Are you over 18 and want to see adult content?
A complete backup of wgalltag.wordpress.com
Are you over 18 and want to see adult content?
A complete backup of laclinicaveterinaria.com
Are you over 18 and want to see adult content?
A complete backup of ablissfulnest.com
Are you over 18 and want to see adult content?
A complete backup of mulaimimpi.blogspot.com
Are you over 18 and want to see adult content?
A complete backup of galletitasrc.com.ar
Are you over 18 and want to see adult content?
Favourite Annotations
A complete backup of infinitekind.com
Are you over 18 and want to see adult content?
Text
STGRABER.ORG
LXD 2.0: REMOTE HOSTS AND CONTAINER MIGRATION [6/12SEE MORE ONSTGRABER.ORG
LXD 2.0: YOUR FIRST LXD CONTAINER LXD 2.0: Your first LXD container Posted on 2016/03/19 by Stéphane Graber. This is the third blog post in this series about LXD 2.0. As there are a lot of commands involved with managing LXD containers, this post is rather long. If you’d instead prefer a quick step-by-step tour of those same commands, you can try our onlinedemo instead!
LXD 2.0: LIVE MIGRATION NVIDIA CUDA INSIDE A LXD CONTAINER Container setup. First lets just create a regular Ubuntu 16.04 container: Then install the CUDA demo tools in there: At which point, you can run: ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed andrunning.
USB HOTPLUG WITH LXD CONTAINERS LXD 2.0: INSTALLING AND CONFIGURING LXD This is the second blog post in this series about LXD 2.0.. Where to get LXD and how to install it. There are many ways to get the latest and greatest LXD. We recommend you use LXD with the latest LXC and Linux kernel to benefit from all its features but we try to degrade gracefully where possible to support older Linux distributions. LXC 1.0: SOME MORE ADVANCED CONTAINER USAGE [4/10 The “ubuntu” template knows how to make use of qemu-user-static, so you can simply check that you have the “qemu-user-static” package installed, then run: sudo lxc-create -t ubuntu -n p3 -- -a armhf. After a rather long bootstrap, you’ll get a new p3 container which will be mostly running Ubuntu armhf. I’m saying mostly becausethe
LXD 2.0: IMAGE MANAGEMENT The easiest way by far to build an image with LXD is to just turn a container into an image. This can be done with: lxc launch ubuntu:14.04 my-container lxc exec my-container bash lxc publish my-container --alias my-new-image. You can even turn a past container snapshot into a new image: STÉPHANE GRABER'S WEBSITESTÉPHANE GRABER'S WEBSITEABOUT MEPROJECTSCONFERENCESWEBLIVECONTAINERS The previous post went over the planned redundancy aspect of this setup at the storage, networking and control plane level. Now let’s see how to get those systems installed and configured for this setup. Firmware updates and configuration. First thing first, whether its systems coming from an eBay seller or straight from the factory, the first step is always to update all firmware to the INEXPENSIVE HIGHLY AVAILABLE LXD CLUSTER: REDUNDANCYSEE MORE ONSTGRABER.ORG
LXD 2.0: REMOTE HOSTS AND CONTAINER MIGRATION [6/12SEE MORE ONSTGRABER.ORG
LXD 2.0: YOUR FIRST LXD CONTAINER LXD 2.0: Your first LXD container Posted on 2016/03/19 by Stéphane Graber. This is the third blog post in this series about LXD 2.0. As there are a lot of commands involved with managing LXD containers, this post is rather long. If you’d instead prefer a quick step-by-step tour of those same commands, you can try our onlinedemo instead!
LXD 2.0: LIVE MIGRATION NVIDIA CUDA INSIDE A LXD CONTAINER Container setup. First lets just create a regular Ubuntu 16.04 container: Then install the CUDA demo tools in there: At which point, you can run: ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed andrunning.
USB HOTPLUG WITH LXD CONTAINERS LXD 2.0: INSTALLING AND CONFIGURING LXD This is the second blog post in this series about LXD 2.0.. Where to get LXD and how to install it. There are many ways to get the latest and greatest LXD. We recommend you use LXD with the latest LXC and Linux kernel to benefit from all its features but we try to degrade gracefully where possible to support older Linux distributions. LXC 1.0: SOME MORE ADVANCED CONTAINER USAGE [4/10 The “ubuntu” template knows how to make use of qemu-user-static, so you can simply check that you have the “qemu-user-static” package installed, then run: sudo lxc-create -t ubuntu -n p3 -- -a armhf. After a rather long bootstrap, you’ll get a new p3 container which will be mostly running Ubuntu armhf. I’m saying mostly becausethe
LXD 2.0: IMAGE MANAGEMENT The easiest way by far to build an image with LXD is to just turn a container into an image. This can be done with: lxc launch ubuntu:14.04 my-container lxc exec my-container bash lxc publish my-container --alias my-new-image. You can even turn a past container snapshot into a new image: WEBLIVE | STÉPHANE GRABER'S WEBSITE As Michael mentioned on Friday we now have a pretty well working WebLive integration directly in Natty’s software-center.. All you need is qtnx to be installed and an up to date Software Center. Edubuntu 11.04 will ship with qtnx installed by default. We want to test the feature with all Edubuntu users first to see how it scales and make sure everything is stable before we consider using it LXD 2.0: LIVE MIGRATION Requirements. To have access to container live migration and stateful snapshots, you need the following: A very recent Linux kernel, 4.4 or higher. CRIU 2.0, possibly with some cherry-picked commits depending on your exact kernel configuration. Run LXD directly on the host. It’s not possible to use those features with container nesting. LXC | STÉPHANE GRABER'S WEBSITE Introduction. Today I’m very pleased to announce the release of LXC 2.0, our second Long Term Support Release! LXC 2.0 is the result of a year of work by the LXC community with over 700 commits done by over90 contributors!
LXD 2.0: INSTALLING AND CONFIGURING LXD This is the second blog post in this series about LXD 2.0.. Where to get LXD and how to install it. There are many ways to get the latest and greatest LXD. We recommend you use LXD with the latest LXC and Linux kernel to benefit from all its features but we try to degrade gracefully where possible to support older Linux distributions. LXD 2.0: RESOURCE CONTROL This is the fourth blog post in this series about LXD 2.0.. Available resource limits. LXD offers a variety of resource limits. Some of those are tied to the container itself, like memory quotas, CPU limitsand I/O priorities.
RUNNING KUBERNETES INSIDE LXD This is a nice, user friendly, tool that interfaces with Juju to deploy complex services. Start it with: lxc exec kubernetes -- sudo -u ubuntu -i conjure-up. Select “Kubernetes Core”. Then select “localhost” as the deployment target (uses LXD) And hit “Deployall
LXC 1.0: CONTAINER STORAGE With those it produces an empty snapshot, this should be fixed by the time LXC 1.0 is actually released. So, let’s say we want to backup our “p1-lvm” container before installing “apache2” into it, simply run: echo "before installing apache2" > snap-comment sudo lxc-snapshot -n p1-lvm LXC 1.0: YOUR FIRST UBUNTU CONTAINER LXC 1.0. So what’s that 1.0 release all about? Well, simply put it’s going to be the first real stable release of LXC and the first we’ll be supporting for 5 years with bugfix releases. It’s also the one which will be included in Ubuntu 14.04 LTS to be released in April 2014. It’s also going to come with a stable API and a set of LXC 1.0: TROUBLESHOOTING AND DEBUGGING API debugging. When debugging a problem using the API it’s often a good idea to try and re-implement the failing bit of code in C using liblxc directly, that helps get the binding out of the way and usually leads to cleaner stack traces and easier bug reports. It’s also useful to set lxc.loglevel to DEBUG using set_config_item on your EVER WANTED AN ARMHF CONTAINER ON YOUR X86 MACHINE? IT’S It took a while to get some apt resolver bugs fixed, a few packages marked for multi-arch and some changes in the Ubuntu LXC template, but since yesterday, you can now run (using up STÉPHANE GRABER'S WEBSITESkip to content
Skip to content
* Home
* About me
* Projects
* Photos
← Older posts
CUSTOM USER MAPPINGS IN LXD CONTAINERS Posted on 2017/06/15by Stéphane Graber
INTRODUCTION
As you may know, LXD uses unprivileged containers by default. The difference between an unprivileged container and a privileged one is whether the root user in the container is the “real” root user (uid 0 at the kernel level). The way unprivileged containers are created is by taking a set of normal UIDs and GIDs from the host, usually at least 65536 of each (to be POSIX compliant) and mapping those into the container. The most common example and what most LXD users will end up with by default is a map of 65536 UIDs and GIDs, with a host base id of 100000. This means that root in the container (uid 0) will be mapped to the host uid 100000 and uid 65535 in the container will be mapped to uid 165535 on the host. UID/GID 65536 and higher in the container aren’t mapped and will return an error if you attempt to use them. From a security point of view, that means that anything which is not owned by the users and groups mapped into the container will be inaccessible. Any such resource will show up as being owned by uid/gid “-1” (rendered as 65534 or nobody/nogroup in userspace). It also means that should there be a way to escape the container, even root in the container would find itself with just as much privileges on the host as a nobody user. LXD does offer a number of options related to unprivilegedconfiguration:
* Increasing the size of the default uid/gid map * Setting up per-container maps * Punching holes into the map to expose host users and groups INCREASING THE SIZE OF THE DEFAULT MAP As mentioned above, in most cases, LXD will have a default map that’s made of 65536 uids/gids. In most cases you won’t have to change that. There are however a few cases where you may have to: * You need access to uid/gid higher than 65535. This is most common when using network authentication inside of yourcontainers.
* You want to use per-container maps. In which case you’ll need 65536 available uid/gid per container. * You want to punch some holes in your container’s map and need access to host uids/gids. The default map is usually controlled by the “shadow” set of utilities and files. On systems where that’s the case, the “/etc/subuid” and “/etc/subgid” files are used to configurethose maps.
On systems that do not have a recent enough version of the “shadow” package. LXD will assume that it doesn’t have to share uid/gid ranges with anything else and will therefore assume control of a billion uids and gids, starting at the host uid/gid 100000. But the common case, is a system with a recent version of shadow. An example of what the configuration may look like is: stgraber@castiana:~$ cat /etc/subuidlxd:100000:65536
root:100000:65536
stgraber@castiana:~$ cat /etc/subgidlxd:100000:65536
root:100000:65536
The maps for “lxd” and “root” should always be kept in sync. LXD itself is restricted by the “root” allocation. The “lxd” entry is used to track what needs to be removed if LXD is uninstalled. Now if you want to increase the size of the map available to LXD. Simply edit both of the files and bump the last value from 65536 to whatever size you need. I tend to bump it to a billion just so I don’t ever have to think about it again: stgraber@castiana:~$ cat /etc/subuid lxd:100000:1000000000 root:100000:1000000000 stgraber@castiana:~$ cat /etc/subgid lxd:100000:1000000000 root:100000:100000000 After altering those files, you need to restart LXD to have it detectthe new map:
root@vorash:~# systemctl restart lxd root@vorash:~# cat /var/log/lxd/lxd.log lvl=info msg="LXD 2.14 is starting in normal mode" path=/var/lib/lxd t=2017-06-14T21:21:13+0000 lvl=warn msg="CGroup memory swap accounting is disabled, swap limits will be ignored." t=2017-06-14T21:21:13+0000 lvl=info msg="Kernel uid/gid map:" t=2017-06-14T21:21:13+0000 lvl=info msg=" - u 0 0 4294967295" t=2017-06-14T21:21:13+0000 lvl=info msg=" - g 0 0 4294967295" t=2017-06-14T21:21:13+0000 lvl=info msg="Configured LXD uid/gid map:" t=2017-06-14T21:21:13+0000 lvl=info msg=" - u 0 1000000 1000000000" t=2017-06-14T21:21:13+0000 lvl=info msg=" - g 0 1000000 1000000000" t=2017-06-14T21:21:13+0000 lvl=info msg="Connecting to a remote simplestreams server" t=2017-06-14T21:21:13+0000 lvl=info msg="Expiring log files" t=2017-06-14T21:21:13+0000 lvl=info msg="Done expiring log files" t=2017-06-14T21:21:13+0000 lvl=info msg="Starting /dev/lxd handler" t=2017-06-14T21:21:13+0000 lvl=info msg="LXD is socket activated" t=2017-06-14T21:21:13+0000 lvl=info msg="REST API daemon:" t=2017-06-14T21:21:13+0000 lvl=info msg=" - binding Unix socket" socket=/var/lib/lxd/unix.socket t=2017-06-14T21:21:13+0000 lvl=info msg=" - binding TCP socket" socket=:8443 t=2017-06-14T21:21:13+0000 lvl=info msg="Pruning expired images" t=2017-06-14T21:21:13+0000 lvl=info msg="Updating images" t=2017-06-14T21:21:13+0000 lvl=info msg="Done pruning expired images" t=2017-06-14T21:21:13+0000 lvl=info msg="Done updating images" t=2017-06-14T21:21:13+0000root@vorash:~#
As you can see, the configured map is logged at LXD startup and can be used to confirm that the reconfiguration worked as expected. You’ll then need to restart your containers to have them start using your newly expanded map.PER CONTAINER MAPS
Provided that you have a sufficient amount of uid/gid allocated to LXD, you can configure your containers to use their own, non-overlapping allocation of uids and gids. This can be useful for two reasons: * You are running software which alters kernel resource ulimits. Those user-specific limits are tied to a kernel uid and will cross container boundaries leading to hard to debug issues where one container can perform an action but all others are then unable to dothe same.
* You want to know that should there be a way for someone in one of your containers to somehow get access to the host that they still won’t be able to access or interact with any of the othercontainers.
The main downsides to using this feature are: * It’s somewhat wasteful with using 65536 uids and gids percontainer.
That being said, you’d still be able to run over 60000 isolated containers before running out of system uids and gids. * It’s effectively impossible to share storage between two isolated containers as everything written by one will be seen as -1 by the other. There is ongoing work around virtual filesystems in the kernel that will eventually let us get rid of that limitation. To have a container use its own distinct map, simply run: stgraber@castiana:~$ lxc config set test security.idmap.isolated true stgraber@castiana:~$ lxc restart test stgraber@castiana:~$ lxc config get test volatile.last_state.idmap The restart step is needed to have LXD remap the entire filesystem of the container to its new map. Note that this step will take a varying amount of time depending on the number of files in the container and the speed of your storage. As can be seen above, after restart, the container is shown to have its own map of 65536 uids/gids. If you want LXD to allocate more than the default 65536 uids/gids to an isolated container, you can bump the size of the allocation with: stgraber@castiana:~$ lxc config set test security.idmap.size 200000 stgraber@castiana:~$ lxc restart test stgraber@castiana:~$ lxc config get test volatile.last_state.idmap If you’re trying to allocate more uids/gids than are left in LXD’s allocation, LXD will let you know: stgraber@castiana:~$ lxc config set test security.idmap.size 2000000000 error: Not enough uid/gid available for the container. DIRECT USER/GROUP MAPPING The fact that all uids/gids in an unprivileged container are mapped to a normally unused range on the host means that sharing of data between host and container is effectively impossible. Now, what if you want to share your user’s home directory with acontainer?
The obvious answer to that is to define a new “disk” entry in LXD which passes your home directory to the container: stgraber@castiana:~$ lxc config device add test home disk source=/home/stgraber path=/home/ubuntu Device home added to test So that was pretty easy, but did it work? stgraber@castiana:~$ lxc exec test -- bash root@test:~# ls -lh /home/total 529K
drwx--x--x 45 nobody nogroup 84 Jun 14 20:06 ubuntu No. The mount is clearly there, but it’s completely inaccessible tothe container.
To fix that, we need to take a few extra steps: * Allow LXD’s use of our user uid and gid * Restart LXD to have it load the new map * Set a custom map for our container * Restart the container to have the new map apply stgraber@castiana:~$ printf "lxd:$(id -u):1\nroot:$(id -u):1\n" | sudo tee -a /etc/subuidlxd:201105:1
root:201105:1
stgraber@castiana:~$ printf "lxd:$(id -g):1\nroot:$(id -g):1\n" | sudo tee -a /etc/subgidlxd:200512:1
root:200512:1
stgraber@castiana:~$ sudo systemctl restart lxd stgraber@castiana:~$ printf "uid $(id -u) 1000\ngid $(id -g) 1000" | lxc config set test raw.idmap - stgraber@castiana:~$ lxc restart test At which point, things should be working in the container: stgraber@castiana:~$ lxc exec test -- su ubuntu -l ubuntu@test:~$ ls -lhtotal 119K
drwxr-xr-x 5 ubuntu ubuntu 8 Feb 18 2016 data drwxr-x--- 4 ubuntu ubuntu 6 Jun 13 17:05 Desktop drwxr-xr-x 3 ubuntu ubuntu 28 Jun 13 20:09 Downloads drwx------ 84 ubuntu ubuntu 84 Sep 14 2016 Maildir drwxr-xr-x 4 ubuntu ubuntu 4 May 20 15:38 snapubuntu@test:~$
CONCLUSION
User namespaces, the kernel feature that makes those uid/gid mappings possible is a very powerful tool which finally made containers on Linux safe by design. It is however not the easiest thing to wrap your head around and all of that uid/gid map math can quickly become amajor issue.
In LXD we’ve tried to expose just enough of those underlying features to be useful to our users while doing the actual mapping math internally. This makes things like the direct user/group mapping above significantly easier than it otherwise would be. Going forward, we’re very interested in some of the work around uid/gid remapping at the filesystem level, this would let us decouple the on-disk user/group map from that used for processes, making it possible to share data between differently mapped containers and alter the various maps without needing to also remap the entire filesystem.EXTRA INFORMATION
The main LXD website is at: https://linuxcontainers.org/lxd Development happens on Github at: https://github.com/lxc/lxd Discussion forun: https://discuss.linuxcontainers.org Mailing-list support happens on: https://lists.linuxcontainers.org IRC support happens in: #lxcontainers on irc.freenode.net Try LXD online: https://linuxcontainers.org/lxd/try-it Posted in Canonical voices, LXC
, LXD
, Planet Ubuntu
| Tagged containers
| 8 Comments
USING WAKE ON LAN WITH MAAS 2.X Posted on 2017/04/02by
Stéphane Graber
INTRODUCTION
I maintain a number of development systems that are used as throw away machines to reproduce LXC and LXD bugs by the upstream developers. I use MAAS to track who’s using what and to have the machines deployed with whatever version of Ubuntu or Centos is needed to reproduce a given bug. A number of those systems are proper servers with hardware BMCs on a management network that MAAS can drive using IPMI. Another set of systems are virtual machines that MAAS drives through libvirt. But I’ve long had another system I wanted to get in there. That machine is a desktop computer but with a server grade SAS controller and internal and external arrays. That machine also has a Fiber Channel HBA and Infiniband card for even less common setups. The trouble is that this being a desktop computer, it’s lacking any kind of remote management that MAAS supports. That machine does however have a good PCIe network card which provides reliablewake-on-lan.
Back in the days (MAAS 1.x), there was a wake-on-lan power type that would have covered my use case. This feature was however removed from MAAS 2.x (see LP: #1589140 ) and the development team suggests that users who want the old wake-on-lan feature, instead install Ubuntu 14.04 and the old MAAS 1.x branch. IMPLEMENTING WAKE ON LAN IN MAAS 2.X I am, however not particularly willing to install an old Ubuntu release and an old version of MAAS just for that one trivial feature, so I instead spent a bit of time to just implement the bits I needed and keep a patch around to be re-applied whenever MAAS changes. MAAS doesn’t provide a plugin system for power types, so I unfortunately couldn’t just write a plugin and distribute that as an unofficial power type for those who need WOL. I instead had to resort to modifying MAAS directly to add the extra power type. The code change needed to re-implement a wake-on-lan power type is pretty simple and only took me a few minutes to sort out. The patch can be found here: https://dl.stgraber.org/maas-wakeonlan.diff To apply it to your MAAS, do: sudo apt install wakeonlan wget https://dl.stgraber.org/maas-wakeonlan.diff sudo patch -p1 -d /usr/lib/python3/dist-packages/provisioningserver/ < maas-wakeonlan.diff sudo systemctl restart maas-rackd.service maas-regiond.service Once done, you’ll now see this in the web UI: After selecting the new “Wake on LAN” power type, enter the MAC address of the network interface that you have WOL enabled on and savethe change.
MAAS will then be able to turn the system on, allowing for the normal commissioning and deployment stages. For everything else, this power type behaves like the “Manual” type, asking the user to manually go shutdown or reboot the system as you can’t do that through Wakeon LAN.
Note that you’ll have to re-apply part of the patch whenever MAAS is updated. The patch modifies two files and adds a new one. The new file won’t be removed during an upgrade, but the two modified files will get reverted and need patching again.CONCLUSION
This is certainly a hack and if your system supports anything better than Wake on LAN, or you’re willing to buy a supported PDU just for that one system, then you should do that instead. But if the inability to turn a system on is all that stands in your way from adding it to your MAAS, as was the case for me, then thatpatch may help you.
I hope that in time MAAS will either get that feature back in some way or get a plugin system that I can use to ship that extra power type in its own separate package without needing to alter any of MAAS’ ownfiles.
Posted in Canonical voices, Planet Ubuntu
| Tagged MAAS
| 10 Comments
USB HOTPLUG WITH LXD CONTAINERS Posted on 2017/03/27by
Stéphane Graber
USB DEVICES IN CONTAINERS It can be pretty useful to pass USB devices to a container. Be that some measurement equipment in a lab or maybe more commonly, an Android phone or some IoT device that you need to interact with. Similar to what I wrote recently about GPUs , LXD supports passing USB devices into containers. Again, similarly to the GPU case, what’s actually passed into the container is a Unix character device, in this case, a /dev/bus/usb/ device node. This restricts USB passthrough to those devices and software which use libusb to interact with them. For devices which use a kernel driver, the module should be installed and loaded on the host, and the resulting character or block device be passed to the containerdirectly.
Note that for this to work, you’ll need LXD 2.5 or higher. EXAMPLE (ANDROID DEBUGGING) As an example which quite a lot of people should be able to relate to, lets run a LXD container with the Android debugging tools installed, accessing a USB connected phone. This would for example allow you to have your app’s build system and CI run inside a container and interact with one or multiple devices connected over USB. First, plug your phone over USB, make sure it’s unlocked and you have USB debugging enabled: stgraber@dakara:~$ lsusb Bus 002 Device 003: ID 0451:8041 Texas Instruments, Inc. Bus 002 Device 002: ID 0451:8041 Texas Instruments, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 021: ID 17ef:6047 Lenovo Bus 001 Device 031: ID 046d:082d Logitech, Inc. HD Pro Webcam C920 Bus 001 Device 004: ID 0451:8043 Texas Instruments, Inc. Bus 001 Device 005: ID 046d:0a01 Logitech, Inc. USB Headset Bus 001 Device 033: ID 0fce:51da Sony Ericsson Mobile Communications AB Bus 001 Device 003: ID 0451:8043 Texas Instruments, Inc. Bus 001 Device 002: ID 072f:90cc Advanced Card Systems, Ltd ACR38 SmartCard Reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Spot your phone in that list, in my case, that’d be the “Sony Ericsson Mobile” entry. Now let’s create our container: stgraber@dakara:~$ lxc launch ubuntu:16.04 c1Creating c1
Starting c1
And install the Android debugging client: stgraber@dakara:~$ lxc exec c1 -- apt install android-tools-adb Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed:android-tools-adb
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 68.2 kB of archives. After this operation, 198 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu xenial/universe amd64 android-tools-adb amd64 5.1.1r36+git20160322-0ubuntu3 Fetched 68.2 kB in 0s (0 B/s) Selecting previously unselected package android-tools-adb. (Reading database ... 25469 files and directories currently installed.) Preparing to unpack .../android-tools-adb_5.1.1r36+git20160322-0ubuntu3_amd64.deb ... Unpacking android-tools-adb (5.1.1r36+git20160322-0ubuntu3) ... Processing triggers for man-db (2.7.5-1) ... Setting up android-tools-adb (5.1.1r36+git20160322-0ubuntu3) ... We can now attempt to list Android devices with: stgraber@dakara:~$ lxc exec c1 -- adb devices * daemon not running. starting it now on port 5037 * * daemon started successfully * List of devices attached Since we’ve not passed any USB device yet, the empty output isexpected.
Now, let’s pass the specific device listed in “lsusb” above: stgraber@dakara:~$ lxc config device add c1 sony usb vendorid=0fce productid=51da Device sony added to c1 And try to list devices again: stgraber@dakara:~$ lxc exec c1 -- adb devices * daemon not running. starting it now on port 5037 * * daemon started successfully * List of devices attachedCB5A28TSU6 device
To get a shell, you can then use: stgraber@dakara:~$ lxc exec c1 -- adb shell * daemon not running. starting it now on port 5037 * * daemon started successfully *E5823:/ $
LXD USB devices support hotplug by default. So unplugging the device and plugging it back on the host will have it removed and re-added tothe container.
The “productid” property isn’t required, you can set only the “vendorid” so that any device from that vendor will be automatically attached to the container. This can be very convenient when interacting with a number of similar devices or devices which change productid depending on what mode they’re in. stgraber@dakara:~$ lxc config device remove c1 sony Device sony removed from c1 stgraber@dakara:~$ lxc config device add c1 sony usb vendorid=0fce Device sony added to c1 stgraber@dakara:~$ lxc exec c1 -- adb devices * daemon not running. starting it now on port 5037 * * daemon started successfully * List of devices attachedCB5A28TSU6 device
The optional “required” property turns off the hotplug behavior, requiring the device be present for the container to be allowed tostart.
More details on USB device properties can be found here.
CONCLUSION
We are surrounded by a variety of odd USB devices, a good number of which come with possibly dodgy software, requiring a specific version of a specific Linux distribution to work. It’s sometimes hard to accommodate those requirements while keeping a clean and safeenvironment.
LXD USB device passthrough helps a lot in such cases, so long as the USB device uses a libusb based workflow and doesn’t require a specific kernel driver. If you want to add a device which does use a kernel driver, locate the /dev node it creates, check if it’s a character or block device and pass that to LXD as a unix-charor unix-block
type device.
EXTRA INFORMATION
The main LXD website is at: https://linuxcontainers.org/lxd Development happens on Github at: https://github.com/lxc/lxd Mailing-list support happens on: https://lists.linuxcontainers.org IRC support happens in: #lxcontainers on irc.freenode.net Try LXD online: https://linuxcontainers.org/lxd/try-it Posted in Canonical voices, LXD
, Planet Ubuntu
| Tagged containers
| 1 Comment
NVIDIA CUDA INSIDE A LXD CONTAINER Posted on 2017/03/21by Stéphane Graber
GPU INSIDE A CONTAINER LXD supports GPU passthrough but this is implemented in a very different way than what you would expect from a virtual machine. With containers, rather than passing a raw PCI device and have the container deal with it (which it can’t), we instead have the host setup with all needed drivers and only pass the resulting device nodesto the container.
This post focuses on NVidia and the CUDA toolkit specifically, but LXD’s passthrough feature should work with all other GPUs too. NVidia is just what I happen to have around. The test system used below is a virtual machine with two NVidia GT 730 cards attached to it. Those are very cheap, low performance GPUs, that have the advantage of existing in low-profile PCI cards that fit fine in one of my servers and don’t require extra power. For production CUDA workloads, you’ll want something much betterthan this.
Note that for this to work, you’ll need LXD 2.5 or higher.HOST SETUP
Install the CUDA tools and drivers on the host: wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_8.0.61-1_amd64.deb sudo dpkg -i cuda-repo-ubuntu1604_8.0.61-1_amd64.debsudo apt update
sudo apt install cuda Then reboot the system to make sure everything is properly setup. After that, you should be able to confirm that your NVidia GPU is properly working with: ubuntu@canonical-lxd:~$ nvidia-smi Tue Mar 21 21:28:34 2017 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 375.39 Driver Version: 375.39 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 730 Off | 0000:02:06.0 N/A | N/A | | 30% 30C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ | 1 GeForce GT 730 Off | 0000:02:08.0 N/A | N/A | | 30% 26C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | | 1 Not Supported | +-----------------------------------------------------------------------------+ And can check that the CUDA tools work properly with: ubuntu@canonical-lxd:~$ /usr/local/cuda-8.0/extras/demo_suite/bandwidthTest- Starting...
Running on...
Device 0: GeForce GT 730Quick Mode
Host to Device Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 3059.4 Device to Host Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 3267.4 Device to Device Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 30805.1Result = PASS
NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.CONTAINER SETUP
First lets just create a regular Ubuntu 16.04 container: ubuntu@canonical-lxd:~$ lxc launch ubuntu:16.04 c1Creating c1
Starting c1
Then install the CUDA demo tools in there: lxc exec c1 -- wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_8.0.61-1_amd64.deb lxc exec c1 -- dpkg -i cuda-repo-ubuntu1604_8.0.61-1_amd64.deb lxc exec c1 -- apt update lxc exec c1 -- apt install cuda-demo-suite-8-0 --no-install-recommends At which point, you can run: ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running. Which is expected as LXD hasn’t been told to pass any GPU yet.LXD GPU PASSTHROUGH
LXD allows for pretty specific GPU passthrough, the details can befound here
.
First let’s start with the most generic one, just allow access toall GPUs:
ubuntu@canonical-lxd:~$ lxc config device add c1 gpu gpu Device gpu added to c1 ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi Tue Mar 21 21:47:54 2017 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 375.39 Driver Version: 375.39 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 730 Off | 0000:02:06.0 N/A | N/A | | 30% 30C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ | 1 GeForce GT 730 Off | 0000:02:08.0 N/A | N/A | | 30% 27C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | | 1 Not Supported | +-----------------------------------------------------------------------------+ ubuntu@canonical-lxd:~$ lxc config device remove c1 gpu Device gpu removed from c1 Now just pass whichever is the first GPU: ubuntu@canonical-lxd:~$ lxc config device add c1 gpu gpu id=0 Device gpu added to c1 ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi Tue Mar 21 21:50:37 2017 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 375.39 Driver Version: 375.39 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 730 Off | 0000:02:06.0 N/A | N/A | | 30% 30C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | +-----------------------------------------------------------------------------+ ubuntu@canonical-lxd:~$ lxc config device remove c1 gpu Device gpu removed from c1 You can also specify the GPU by vendorid and productid: ubuntu@canonical-lxd:~$ lspci -nnn | grep NVIDIA 02:06.0 VGA compatible controller : NVIDIA Corporation GK208 (rev a1) 02:07.0 Audio device : NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) 02:08.0 VGA compatible controller : NVIDIA Corporation GK208 (rev a1) 02:09.0 Audio device : NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) ubuntu@canonical-lxd:~$ lxc config device add c1 gpu gpu vendorid=10de productid=1287 Device gpu added to c1 ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi Tue Mar 21 21:52:40 2017 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 375.39 Driver Version: 375.39 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 730 Off | 0000:02:06.0 N/A | N/A | | 30% 30C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ | 1 GeForce GT 730 Off | 0000:02:08.0 N/A | N/A | | 30% 27C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | | 1 Not Supported | +-----------------------------------------------------------------------------+ ubuntu@canonical-lxd:~$ lxc config device remove c1 gpu Device gpu removed from c1 Which adds them both as they are exactly the same model in my setup. But for such cases, you can also select using the card’s PCI IDwith:
ubuntu@canonical-lxd:~$ lxc config device add c1 gpu gpu pci=0000:02:08.0 Device gpu added to c1 ubuntu@canonical-lxd:~$ lxc exec c1 -- nvidia-smi Tue Mar 21 21:56:52 2017 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 375.39 Driver Version: 375.39 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 730 Off | 0000:02:08.0 N/A | N/A | | 30% 27C P0 N/A / N/A | 0MiB / 2001MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | +-----------------------------------------------------------------------------+ ubuntu@canonical-lxd:~$ lxc config device remove c1 gpu Device gpu removed from c1 And lastly, lets confirm that we get the same result as on the host when running a CUDA workload: ubuntu@canonical-lxd:~$ lxc config device add c1 gpu gpu Device gpu added to c1 ubuntu@canonical-lxd:~$ lxc exec c1 -- /usr/local/cuda-8.0/extras/demo_suite/bandwidthTest- Starting...
Running on...
Device 0: GeForce GT 730Quick Mode
Host to Device Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 3065.4 Device to Host Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 3305.8 Device to Device Bandwidth, 1 Device(s) PINNED Memory Transfers Transfer Size (Bytes) Bandwidth(MB/s) 33554432 30825.7Result = PASS
NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.CONCLUSION
LXD makes it very easy to share one or multiple GPUs with yourcontainers.
You can either dedicate specific GPUs to specific containers or justshare them.
There is no of the overhead involved with usual PCI based passthrough and only a single instance of the driver is running with the containers acting just like normal host user processes would. This does however require that your containers run a version of the CUDA tools which supports whatever version of the NVidia drivers is installed on the host.EXTRA INFORMATION
The main LXD website is at: https://linuxcontainers.org/lxd Development happens on Github at: https://github.com/lxc/lxd Mailing-list support happens on: https://lists.linuxcontainers.org IRC support happens in: #lxcontainers on irc.freenode.net Try LXD online: https://linuxcontainers.org/lxd/try-it Posted in Canonical voices, LXD
, Planet Ubuntu
| Tagged containers
| 14 Comments
RUN YOUR OWN LXD DEMO SERVER Posted on 2017/03/05by
Stéphane Graber
THE LXD DEMO SERVER
The LXD demo server is the service behind https://linuxcontainers.org/lxd/try-it. We use it to showcase LXD by leading visitors through an interactive tour of LXD’s features. Rather than use some javascript simulation of LXD and its client tool, we give our visitors a real root shell using a LXD container with nesting enabled. This environment is using all of LXD’s resource limits as well as a very strict firewall to prevent abuses and offer everyone a great experience. This is done using lxd-demo-server which can be found at: https://github.com/lxc/lxd-demo-server The lxd-demo-server is a daemon that offers a public REST API for usefrom a web browser.
It supports:
* Creating containers from an existing container or from a LXD image * Choose what command to execute in the containers on connection * Lets you choose specific profiles to apply to the containers * An API to record user feedback * An API to fetch usage statistics for reporting * A number of resource restrictions:* CPU
* Disk quota (if using btrfs or zfs as the LXD storage backend)* Processes
* Memory
* Number of sessions per IP * Time limit for the session * Total number of concurrent sessions * Requiring the user to read and agree to terms of service * Recording all sessions in a sqlite3 database * A maintenance mode All of it is configured through a simple yaml configuration file.SETTING UP YOUR OWN
The LXD demo server is now available as a snap package and interacts with the snap version of LXD. To install it on your own system, allyou need to do is:
MAKE SURE YOU DON’T HAVE THE DEB VERSION OF LXD INSTALLED ubuntu@djanet:~$ sudo apt remove --purge lxd lxd-client Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED:lxd* lxd-client*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 25.3 MB disk space will be freed. Do you want to continue? (Reading database ... 59776 files and directories currently installed.) Removing lxd (2.0.9-0ubuntu1~16.04.2) ... Warning: Stopping lxd.service, but it can still be activated by:lxd.socket
Purging configuration files for lxd (2.0.9-0ubuntu1~16.04.2) ... Removing lxd-client (2.0.9-0ubuntu1~16.04.2) ... Processing triggers for man-db (2.7.5-1) ... INSTALL THE LXD SNAP ubuntu@djanet:~$ sudo snap install lxd lxd 2.8 from 'canonical' installedTHEN CONFIGURE LXD
ubuntu@djanet:~$ sudo lxd init Name of the storage backend to use (dir or zfs) : Create a new ZFS pool (yes/no) ? Name of the new ZFS pool : Would you like to use an existing block device (yes/no) ? Size in GB of the new loop device (1GB minimum) : Would you like LXD to be available over the network (yes/no) ? Would you like stale cached images to be updated automatically (yes/no) ? Would you like to create a new network bridge (yes/no) ? What should the new bridge be called ? What IPv4 address should be used (CIDR subnet notation, “auto” or “none”) ? What IPv6 address should be used (CIDR subnet notation, “auto” or “none”) ? LXD has been successfully configured. AND FINALLY INSTALL LXD-DEMO-SERVER ITSELF ubuntu@djanet:~$ sudo snap install lxd-demo-server lxd-demo-server git from 'stgraber' installed ubuntu@djanet:~$ sudo snap connect lxd-demo-server:lxd lxd:lxd At that point, you can hit http://127.0.0.1:8080 and will be greetedwith this:
To change the configuration, use: ubuntu@djanet:~$ sudo lxd-demo-server.configure And that’s it, you have your own instance of the demo server.SECURITY
As mentioned at the beginning, the demo server comes with a number of options to prevent users from using all the available resources themselves and bringing the whole thing down. Those should be tweaked for your particular needs and should also update the total number of concurrent sessions so that you don’t end up over-committing on resources. On the network side of things, the demo server itself doesn’t do any kind of firewalling or similar network restrictions. If you plan on offering sessions to anyone online, you should make sure that the network which LXD is using is severely restricted and that the host this is running on is also placed in a very restricted part of yournetwork.
Containers handed to strangers should never be using “security.privileged” as that’d be a straight route to getting root privileges on the host. You should also stay away from bind-mounting any part of the host’s filesystem into thosecontainers.
I would also very strongly recommend setting up very frequent security updates on your host and kernel live patching or at least automatic reboot when a new kernel is installed. This should avoid a new kernel security issue from being immediately exploited in yourenvironment.
CONCLUSION
The LXD demo server was initially written as a quick hack to expose a LXD instance to the Internet so we could let people try LXD online and also offer the upstream team a reliable environment we could have people attempt to reproduce their bugs into. It’s since grown a bit with new features contributed by users and with improvements we’ve made to the original experience on ourwebsite.
We’ve now served over 36000 sessions to over 26000 unique visitors. This has been a great tool for people to try and experience LXD and I hope it will be similarly useful to other projects.EXTRA INFORMATION
The main LXD website is at: https://linuxcontainers.org/lxd Development happens on Github at: https://github.com/lxc/lxd Mailing-list support happens on: https://lists.linuxcontainers.org IRC support happens in: #lxcontainers on irc.freenode.net Try LXD online: https://linuxcontainers.org/lxd/try-it Posted in Canonical voices, LXD
, Planet Ubuntu
| Tagged containers
| 2 Comments
← Older posts
*
SOCIAL
* Github
* Google+
*
FEEDS
* RSS feed
* RSS feed (comments)*
CATEGORIES
* Arkose
* Canonical voices
* Conferences
* Edubuntu
* gbtsco
* IPv6
* iTalc
* LTSP
* LXC
* LXCFS
* LXD
* mirrorkit
* pastebinit
* Planet Revolution-Linux* Planet Ubuntu
* Sandbox
* Ubuntu Touch
* WebLive
*
ARCHIVES
* June 2017
* April 2017
* March 2017
* February 2017
* January 2017
* December 2016
* October 2016
* June 2016
* April 2016
* March 2016
* December 2015
* April 2015
* September 2014
* February 2014
* January 2014
* December 2013
* September 2013
* July 2013
* February 2013
* November 2012
* October 2012
* September 2012
* July 2012
* May 2012
* March 2012
* February 2012
* January 2012
* September 2011
* August 2011
* July 2011
* June 2011
* May 2011
* April 2011
* March 2011
* February 2011
* January 2011
* December 2010
* November 2010
* October 2010
* September 2010
* February 2010
* January 2010
* December 2009
* November 2009
* October 2009
* July 2009
* April 2009
* March 2009
* December 2008
* September 2008
* July 2008
* June 2008
* May 2008
2020 - Stéphane Graber's website Proudly powered by WordPress. 2010 Weaver byWPWeaver.info
Details
Copyright © 2024 ArchiveBay.com. All rights reserved. Terms of Use | Privacy Policy | DMCA | 2021 | Feedback | Advertising | RSS 2.0