Without the templating (which is still present for imperative containers), it
will be possible to set individual dependencies. Like depending on the network
only if the hostbridge or hardware interfaces are used.
Ported from #3021
This allows the containers to have their interface in a bridge on the host.
Also this adds IPv6 addresses to the containers both with bridged and unbridged
network.
NixOps has infrequent releases, so it's not the best place for keeping
the list of current AMIs. Putting them in Nixpkgs means that AMI
updates will be delivered as part of the NixOS channels.
We now generate a qcow2 image to prevent hitting Hydra's output size
limit. Also updated /root/user-data -> /etc/ec2-metadata/user-data.
http://hydra.nixos.org/build/33843133
Previously this was done in three derivations (one to build the raw
disk image, one to convert to OVA, one to add a hydra-build-products
file). Now it's done in one step to reduce the amount of copying
to/from S3. In particular, not uploading the raw disk image prevents
us from hitting hydra-queue-runner's size limit of 2 GiB.
Allow usage of list of strings instead of a comma-separated string
for filesystem options. Deprecate the comma-separated string style
with a warning message; convert this to a hard error after 16.09.
15.09 was just released, so this provides a deprecation period during
the 16.03 release.
closes#10518
Signed-off-by: Robin Gloster <mail@glob.in>
This is a regression introduced by merging the EBS and S3 images. The
EBS images had a special marker /.ebs to prevent the initrd from using
ephemeral storage for the unionfs, but this marker was missing in the
consolidated image.
The fix is to check the file ami-manifest-path on the metadata server
to see if we're an S3-based instance. This does require networking in
the initrd.
Issue #12613.
The default behavior with an m3.medium instance is to relocate
/nix and /tmp to /disk0 because an assumption is made that any
ephemeral disk is larger than the root volume. Rather than make
that assumption, add a check to see if the disk is larger, and
only then relocate /nix and /tmp.
This addresses https://github.com/NixOS/nixpkgs/issues/12613
See http://nixos.org/nixpkgs/manual/#sec-package-naming
I've added an alias for multipath_tools to make sure that we don't break
existing configurations referencing the old name.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
When using `--ensure-unique-name`, don't needlessly append `"-0"` if the
container name is already unique.
This is especially helpful with NixOps since when it deploys to a
container it uses `--ensure-unique-name`. This means that the container
name will never match the deployment host due to the `"-0"`. Having the
container name and the host name match isn't exactly a requirement, but
it's nice to have and a small change.
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
Modifies libvirt package to search for configs in /var/lib and changes
libvirtd service to copy the default configs to the new location.
This enables the user to change e.g. the networking configuration with
virsh or virt-manager and keep those settings.
This reverts commit 6353f580f9.
Unfortunately cache=none doesn't work with all filesystem options.
Hydra tests error out with: file system may not support O_DIRECT
See http://hydra.nixos.org/build/30323625/
Setting nixosVersion to something custom is useful for meaningful GRUB
menus and /nix/store paths, but actuallly changing it rebulids the
whole system path (because of `nixos-version` script and manual
pages). Also, changing it is not a particularly good idea because you
can then be differentitated from other NixOS users by a lot of
programs that read /etc/os-release.
This patch introduces an alternative option that does all you want
from nixosVersion, but rebuilds only the very top system level and
/etc while using your label in the names of system /nix/store paths,
GRUB and other boot loaders' menus, getty greetings and so on.
The docker module used different code for socket-activated docker daemon than for the non-socket activated daemon.
In particular, if the socket-activated daemon is used, then modprobe wasn't set up to be usable and in PATH for
the docker daemon, which resulted in a failure to start the daemon with overlayfs as storageDriver if the
`overlay` kernel module wasn't already loaded. This commit fixes that bug (which only appears if socket
activation is used), and also reduces the duplication between code paths so that it's easier to keep
both in sync in future.
As @domenkozar noted in #10828, cache=writeback seems to do more harm
than good:
https://github.com/NixOS/nixpkgs/issues/10828#issuecomment-164426821
He has tested it using the openstack NixOS tests and found that
cache=none significantly improves startup performance.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This seems to be the root cause of the random page allocation failures
and @wizeman did a very good job on not only finding the root problem
but also giving a detailed explanation of it in #10828.
Here is an excerpt:
The problem here is that the kernel is trying to allocate a contiguous
section of 2^7=128 pages, which is 512 KB. This is way too much:
kernel pages tend to get fragmented over time and kernel developers
often go to great lengths to try allocating at most only 1 contiguous
page at a time whenever they can.
From the error message, it looks like the culprit is unionfs, but this
is misleading: unionfs is the name of the userspace process that was
running when the system ran out of memory, but it wasn't unionfs who
was allocating the memory: it was the kernel; specifically it was the
v9fs_dir_readdir_dotl() function, which is the code for handling the
readdir() function in the 9p filesystem (the filesystem that is used
to share a directory structure between a qemu host and its VM).
If you look at the code, here's what it's doing at the moment it tries
to allocate memory:
buflen = fid->clnt->msize - P9_IOHDRSZ;
rdir = v9fs_alloc_rdir_buf(file, buflen);
If you look into v9fs_alloc_rdir_buf(), you will see that it will try
to allocate a contiguous buffer of memory (using kzalloc(), which is a
wrapper around kmalloc()) of size buflen + 8 bytes or so.
So in reality, this code actually allocates a buffer of size
proportional to fid->clnt->msize. What is this msize? If you follow
the definition of the structures, you will see that it's the
negotiated buffer transfer size between 9p client and 9p server. On
the client side, it can be controlled with the msize mount option.
What this all means is that, the reason for running out of memory is
that the code (which we can't easily change) tries to allocate a
contiguous buffer of size more or less equal to "negotiated 9p
protocol buffer size", which seems to be way too big (in our NixOS
tests, at least).
After that initial finding, @lethalman tested the gnome3 gdm test
without setting the msize parameter at all and it seems to have resolved
the problem.
The reason why I'm committing this without testing against all of the
NixOS VM test is basically that I think we can only go better but not
worse than the current state.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Commit 9bfe92ecee ("docker: Minor improvements, fix failing test") added
the services.docker.storageDriver option, made it mandatory but didn't
give it a default value. This results in an ugly traceback when users
enable docker, if they don't pay enough attention to also set the
storageDriver option. (An attempt was made to add an assertion, but it
didn't work, possibly because of how "mkMerge" works.)
The arguments against a default value were that the optimal value
depends on the filesystem on the host. This is, AFAICT, only in part
true. (It seems some backends are filesystem agnostic.) Also, docker
itself uses a default storage driver, "devicemapper", when no
--storage-driver=x options are given. Hence, we use the same value as
default.
Add a FIXME comment that 'devicemapper' breaks NixOS VM tests (for yet
unknown reasons), so we still run those with the 'overlay' driver.
Closes#10100 and #10217.
When using the ZFS storagedriver in docker, it shells out for the ZFS
commands. The path configuration for the systemd task does not include
ZFS, so if the driver is set to ZFS, add ZFS utilities to the PATH.
This will resolve https://github.com/NixOS/nixpkgs/issues/10127
[Bjørn: prefix commit message with "nixos/docker:", remove extra space
before ';']
The EBS and S3 (instance-store) AMIs are now created from the same
image. HVM instance-store AMIs are also generated.
Disk image generation has been factored out into a function
(nixos/lib/make-disk-image.nix) that can be used to build other kinds
of images.
Booting the demo/installer image won't work if the video memory is too
low. It boots into KDE, shows the background image and doesn't do
anything, according to @domenkozar.
Thanks to @domenkozar for reporting and testing this with 32MB.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
pkgs/os-specific/linux/kernel/common-config.nix defines HIGHMEM64G on
line 441 for 32bit systems, which implies PAE.
We now creating the OVA with PAE support enabled, which fixes bootup of
the image if people are just importing it without setting PAE
explicitly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
