-
Notifications
You must be signed in to change notification settings - Fork 95
VM hard-locks after adding vSphere Docker Volume, sometimes lists un-wanted docker volumes. #2075
Comments
Here's the logs from one of the VMs that eventually hard locked: |
I have the VIB log files as well from each of our ESXi hosts, but there's a lot of other info in them unrelated to the problem at hand, so I'd prefer a direct message to send the log files to, rather than posting here. Is that possible? |
@kmott, are EQL1-DevOpsVol-01 and CMP1-WorkstationVol-01 datastores in the ESX host (ls /vmfs/volumes)? These extra volumes seem to be what docker seems to be creating on its own. Could check if Minio creates these volumes via Docker. Can you also post "cat /proc/mounts", if these volumes are all mounted and hence in use, that may indicate why the VM goes slow over time (assuming that these many volumes are in use at once). |
@govint, the datastores are legit on each of our 4 ESXi hosts, but the large-hash prefix that Docker is creating is not. Minio doesn't create the volumes (as far as I know), it just uses whatever path(s) you specify when starting the container (and if the path(s) you specify point to docker volumes that are not initialized, minio will initialize them for you). Here's the
Interestingly, it seems like if I do not re-start the Minio job in Nomad (e.g., just leave it DEAD and reboot both docker nodes), I don't have any additional stability issues. Note that |
From the vsphere plugini logs, these volumes with long names are actually anonymous volumes that docker creates when its asked to create a volume on the fly. One example is below, will need to check with docker logs why its causing these volumes to be created. 2018-03-09 15:36:08.835927686 -0800 PST [ERROR] Failed to get volume meta-data error="Volume 634bc83d5c9346d11d58b9d9c493a5402f1b18d7b1fe1cc322c0383b8e801fa7 not found (file: /vmfs/volumes/EQL1-DevOpsVol01/dockvols/_DEFAULT/634bc83d5c9346d11d58b9d9c493a5402f1b18d7b1fe1cc322c0383b8e801fa7.vmdk)" name=634bc83d5c9346d11d58b9d9c493a5402f1b18d7b1fe1cc322c0383b8e801fa7 2018-03-09 15:36:11.116030901 -0800 PST [INFO] Device file found. device="/dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:5:0" 2018-03-09 15:36:15.32395768 -0800 PST [INFO] Volume and filesystem created fstype=ext4 name=634bc83d5c9346d11d58b9d9c493a5402f1b18d7b1fe1cc322c0383b8e801fa7 Doesn't seem to be an issue with the plugin as far as these volumes go. For the lock up, please post the dmesg Linux kernel logs when that happens. Again, could try increasing memory for the VM in case thats the issue for the workload generated with Minio. |
@govint, the VMs have 32GB RAM each. I will get the dmesg and docker output from the lock-up, I just re-started all of the services this morning, should be able to post something tomorrow. |
Note that I am not able to get the dmesg output--the system is hard-locked, and nothing is dumped to kern.log. Console is also unresponsive during this time, I have to hard-reset it to get anything back. Attached some docker logs during the time of the lock-up (system locked up just after Apr 9 @ 20:42:19 PST, local time on the box). |
@kmott thanks I'll check these and get back. |
@govint Did you have a chance to check things out? |
Description:
I am trying a test run of the vDVS plugins, and am running into a few problems. The main issue I am having is that our cluster VM's that are running the Docker daemon seem to hard-lock after a little while. When I reboot them and re-add the Docker vSphere volumes, it actually shows up with a bunch more other volumes in 'docker volume ls' output (note that the only 4 I added via the
docker volume create --driver=vsphere volname@datastore
command are at the bottom, the minio volumes)Environment Details:
Steps to Reproduce:
docker volume create --driver=vsphere minio1@CMP1-DevOps-Docker1
docker volume create --driver=vsphere minio1@CMP1-DevOps-Docker2
docker volume create --driver=vsphere minio2@CMP1-DevOps-Docker1
docker volume create --driver=vsphere minio2@CMP1-DevOps-Docker2
docker volume ls
output.Expected Result:
VM system should not lock up, and
docker volume ls
should only emit added volumes from vSphere viadocker volume create ...
syntax.Actual Result:
VM system hard-locks, and emits un-wanted docker volumes in
docker volume ls
output.Triage:
I am working on getting the VIB log files from each of the hosts, as well as the VM log file
vsphere-storage-for-docker.log
as well. Here's a snippet fromdocker volume ls
:The text was updated successfully, but these errors were encountered: