I am trying to run the Elasticsearch image on my Mac m1 laptop using podman. It will fail with the message:
ERROR: [1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.
bootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
I can solve this temporarily by using ssh to enter the podman machine vm and setting vm.max_map_count with
sudo sysctl -w vm.max_map_count=262144
However, if I stop and restart the podman machine vm, the setting is back to the default 65530.
Is there a way to permanently set vm.max_map_count for the podman machine vm?
I came across this recently too. You make have already sorted it out.
To modify kernel parameters at boot just add an entry do one of your sysctl configs and it will be applied on reboot.
# echo "vm.max_map_count = 262144" >> /etc/sysctl.d/99-sysctl.conf
Related
Is anyone else having this problem when running podman?
I used normally and now when running
podman machine start
this error appears:
Print
I tried to change the podman configuration and increase the resources but I didn't authorize it;
I'm not sure what's going on but here's what I did:
➜ ~ podman system connection list
Name URI Identity Default
podman-machine-default ssh://core#localhost:51014/run/user/501/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default true
podman-machine-default-root ssh://root#localhost:51014/run/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default false
➜ ~ podman machine rm podman-machine-default
The following files will be deleted:
/Users/xxxxx/.ssh/podman-machine-default
/Users/xxxxx/.ssh/podman-machine-default.pub
/Users/xxxxx/.config/containers/podman/machine/qemu/podman-machine-default.ign
/Users/xxxxx/.local/share/containers/podman/machine/qemu/podman-machine-default_fedora-coreos-36.20220918.2.2-qemu.x86_64.qcow2
/Users/xxxxx/.local/share/containers/podman/machine/podman-machine-default/podman.sock
/Users/xxxxx/.config/containers/podman/machine/qemu/podman-machine-default.json
Are you sure you want to continue? [y/N] y
➜ ~ podman system connection list
Name URI Identity Default
At this point I switched to the Activity Monitor and killed the qemu service. Then I ran the following:
➜ ~ podman machine init
Downloading VM image: fedora-coreos-37.20230122.2.0-qemu.x86_64.qcow2.xz: done
Extracting compressed file
Image resized.
Machine init complete
To start your machine run:
podman machine start
➜ ~ podman system connection list
Name URI Identity Default
podman-machine-default ssh://core#localhost:51014/run/user/501/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default true
podman-machine-default-root ssh://root#localhost:51014/run/podman/podman.sock /Users/xxxxx/.ssh/podman-machine-default false
➜ ~ docker machine start
Starting machine "podman-machine-default"
Waiting for VM ...
Mounting volume... /Users/xxxxx:/Users/xxxxx
This machine is currently configured in rootless mode. If your containers
require root permissions (e.g. ports < 1024), or if you run into compatibility
issues with non-podman clients, you can switch using the following command:
podman machine set --rootful
API forwarding listening on: /var/run/docker.sock
Docker API clients default to this address. You do not need to set DOCKER_HOST.
Machine "podman-machine-default" started successfully
Hope this helps.
I try running Elasticsearch 6.x on LXC using Ansible, when try to start Elasticsearch service in elasticsearch log I see:
[2020-01-04T08:45:58,744][ERROR][o.e.b.Bootstrap ] [4WUODd8] node validation exception
[1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
when I searched for this I found :
sysctl -w vm.max_map_count=262144
but When I running this I get :
sysctl: setting key "vm.max_map_count": Read-only file system
I tried change file manually but didn't work , Is there any way change this environment variable in LXC?
Solved by executing command :
sysctl -w vm.max_map_count=262144
on Ansible hosts it self
i'm new to Docker and i've just intalled Docker ToolBox 1.11.1 on my Windows 7 (64 bit).
When running Quickstart Terminal i've got problems with creating default container.
After reading a bunch of forums i've invoked :
docker-machine rm -f default
docker-machine --debug create -d virtualbox default
But still without result. Full logs from last operation are :
https://gist.github.com/anonymous/117e302c047492170a6f0c7d4e79199a
They end up with phrase :
"(default) DBG | Error dialing TCP: dial tcp 127.0.0.1:49659: connectex: No connection could be made because the target machine actively refused it."
I've have no idea how to fix that. Can someone help me ?
In windows and Mac OS Docker run in a virtual machine. When you install Docker using the Docker Toolbox, it takes care of install Virtual Box, create a “default” virtual machine and configure it to run a Boot2Docker image.
With the command:
docker-machine rm -f default
you are removing this default VM. Then running the command:
docker-machine --debug create -d virtualbox default
you are creating a new VM called “default”, so you are not creating or starting any default windows container.
"Actively refused it" means that the host sent a reset instead of an ack when you tried to connect. Please, check the firewall or the proxy configuration because this is a communication problem.
Hope this can help.
I have installed the cloudera quickstart using docker based on the instructions given here.
https://blog.cloudera.com/blog/2015/12/docker-is-the-new-quickstart-option-for-apache-hadoop-and-cloudera/
docker run --privileged=true --hostname=quickstart.cloudera -p 7180 -p 8888 -t -i 9f3ab06c7554 /usr/bin/docker-quickstart
You can see that I am doing -p 7180 and -p 8888 for port mapping.
when the container booted successfully. I saw that the hue service startup failed. but i ran it manually using sudo service hue restart and it showed OK.
Now I ran
/home/cloudera/cloudera-manager --express --force
this command was successful I got a message to connect to the CM using http://cloudera.quickstart:7180
Now on my host machine I did docker-machine env default and I could see the output
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/abhishek.srivastava/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
Now in my browser on host machine I did
http://192.168.99.100:7180
http://192.168.99.100:8888
http://quickstart.cloudera:7180
http://quickstart.cloudera:8888
but everything fails to connect to any page. So even after doing port forwarding... I am not able to access either cloudera manager or HUE UI from the host machine.
I am using OSX.
I also went into virtualbox manager UI and selected the default VM. I went into settings -> network -> port forwarding. and made the following entries
but still I cannot access the cloudera manager and HUE....
When you run docker using -p 7180 and -p 8888, it will allocate a random port on your windows host. However, if you use -p 7180:7180 and -p 8888:8888, assuming those ports are free on the host, it will map them directly.
Otherwise you can execute docker ps and it will show you which ports it mapped the 7180 and 8888 to. Then in your host browser you can enter
http://192.168.99.100:<docker-allocated-port>
instead of
http://192.168.99.100:7180
If its all on your local machine, you shouldn't need the port forwarding.
Since you're running the docker machine inside a VM, you need to open the port on VirtualBox.
You can do this from the Port Forwarding button in the network adapter panel in VirtualBox.
Settings > Network > Advanced > Port Forwarding
You should see an SSH port already being forwarded for docker. Just add any additional ports like that one.
And here are lists of all the ports used by CDH. Of course you don't need all of them. I would suggest at least Cloudera Manager (7180), namenode and datanode UI (50070 & 50075), and the job servers like mapreduce (8088,8042 & 10020) or spark (18080 & 18081). And I personally don't use it, but Hue is 8888.
The same issue happened to me. I was able start hue successfully after increasing the number of CPUs in VirtualBox.
I also increased the amount of RAM earlier. The original CPU I had was 1, changed to 3
I have encountered the same issue here, and resolved now based on the comments and posts above. There are two issues mentioned above:
Failed to start Hue.
In my case, this is caused by limited resources allocated with default docker VM settings. According to #Ronald Teo's answer, going to
VirtualBox -> 'default'[your docker-machine name] -> Settings ->
System
, increase base memory to 8192MB, and processors to at least 3, have fixed my problem.
Can not access Hue from my host machine. Based on the original post, Try docker run --privileged=true --hostname=quickstart.cloudera -p 7180:7180 -p 8888:8888 -t -i 9f3ab06c7554 /usr/bin/docker-quickstart should solve this problem.
Restart Hue after container is up
Increase the memory of docker to 8GB if you can. Otherwise, set it at least 4GB.
Let hue fail while starting the container.
After that, attach to the docker container and access its shell to run the following command,
To stop the Hue Server:
$ sudo service hue stop
To start the Hue Server:
$ sudo service hue start
I was just trying to spin up the Cloudera quickstart docker myself, and it turns out this seems to do the trick:
http://127.0.0.1:8888
Note the http, not https, and that I use 127.0.0.1 (or localhost)
Note that this assumes that the internal 8888 port is mapped to your 8888 port.
Suppose docker inspect yields something like
"8888/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "32769"
}
Then you would want
http://127.0.0.1:32769
I am trying to set up docker machine on Windows and this problem has annoyed me for a few days.
I downloaded and installed DockerToolbox-1.9.1a on my Windows, so it came with Virtual Box version 5.0.10. After that I ran this command to create my virtual machine:
docker-machine create --driver virtualbox --engine-insecure-registry docker.pre-prod.ss.local:5000 --virtualbox-hostonly-cidr 192.168.99.100/24 mymachine
Here is what I got:
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available... Detecting
operating system of created instance... Detecting the provisioner...
Provisioning created instance... Copying certs to the local machine
directory... Copying certs to the remote machine... Setting Docker
configuration on the remote daemon... WARNING >>> This machine has
been allocated an IP address, but Docker Machine could not reach it
successfully.
SSH for the machine should still work, but connecting to exposed
ports, such as the Docker daemon port (usually :2376), may not
work properly.
You may need to add the route manually, or use another related
workaround
This could be due to a VPN, proxy, or host file configuration issue.
You also might want to clear any VirtualBox host only interfaces you
are not using
The machine was created successfully. So I ran the docker-machine env command:
docker-machine env --shell=powershell mymachine| Invoke-Expression
and I got:
Error running connection boilerplate: Error checking and/or
regenerating the certs: There was icates for host
"192.168.99.100:2376": dial tcp 192.168.99.100:2376: connectex: No
connection target machine actively refused it. You can attempt to
regenerate them using 'docker-machine regenerate-certs name'. Be
advised that this will trigger a Docker daemon restart which will stop
running containers.
Running docker version returned
Client: Version: 1.9.1 API version: 1.21 Go version:
go1.4.3 Git commit: a34a1d5 Built: Fri Nov 20 17:56:04 UTC
2015 OS/Arch: windows/amd64 An error occurred trying to connect:
Get http://localhost:2375/v1.21/version: dial tcp connection could be
made because the target machine actively refused it.
Can someone help to point out the direction to fix this issue? It is really troublesome to set up docker on Windows. Thank you very much.
I use docker 1.9.1 on Windows (7, 8 and even 10), but without docker registry, and without using --virtualbox-hostonly-cidr.
If you are to use that last option, check "Set a specific address ip when i create a docker container", where I mention issue 1709, which uses cidr in .1, not .100 (but getting a .100 ip address as a result):
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.99.1/24" m99
If there's no other machine with the same cidr (Classless Inter-Domain Routing), the machine should always get the .100 IP upon start.