For those running Docker, check out > Nutanix Container Volume Plug-in on the Docker store. Nutanix Volume Plugin enables container persistent storage. Try it out today and let me know your experience.
Page 1 / 1
NVM ... i clicked a 2nd time and it opened fine .... browser woes!
However, I did notice that this looks to be redhat tested only. Is there a Ubuntu version of this? Do we know if there is one in the works?In my company we are heavy docker users, but we use Ubuntu as the base, so it would be wonderful to try that.
However, I did notice that this looks to be redhat tested only. Is there a Ubuntu version of this? Do we know if there is one in the works?In my company we are heavy docker users, but we use Ubuntu as the base, so it would be wonderful to try that.
Hi,
Is there an email address or somewhere where we can ask questions or create issue if we encounter some problems with DVP installation/configuration ?
When i install or enable the plugin on CentOS7 i get the following error :
docker plugin enable nutanixError response from daemon: dial unix /run/docker/plugins/4ff9072aa1e8a894926d95a65037a505c5abb24021273074716b11e98c9e2b47/nutanix.sock: connect: no such file or directory
Thanks
Is there an email address or somewhere where we can ask questions or create issue if we encounter some problems with DVP installation/configuration ?
When i install or enable the plugin on CentOS7 i get the following error :
docker plugin enable nutanixError response from daemon: dial unix /run/docker/plugins/4ff9072aa1e8a894926d95a65037a505c5abb24021273074716b11e98c9e2b47/nutanix.sock: connect: no such file or directory
Thanks
I keep getting the same error as @tperelle @aluciani on CentOS. At first I used the docker version that comes with the distribution and docker complained about an unknown -console options. So I switched to docker repo and now I keep getting /run/docker/plugins/.../nutanix.sock no such file or directory
Hi @sks !
In my case it was because apps and management were separate in different VLANs which could not communicate with each other.
The Volume plugin need to communicate with management to create storage volumes.
Nutanix seems to have improved the solution in last releases of AOS by separating cluster management and storage management, so the volume plugin may address storage management without having permissions on cluster management.
I have not tested anymore because of lack of time but give us your feedback if you can test !
Thanks
In my case it was because apps and management were separate in different VLANs which could not communicate with each other.
The Volume plugin need to communicate with management to create storage volumes.
Nutanix seems to have improved the solution in last releases of AOS by separating cluster management and storage management, so the volume plugin may address storage management without having permissions on cluster management.
I have not tested anymore because of lack of time but give us your feedback if you can test !
Thanks
Thanks for the feedback folks @tperelle @sks @Justin-DynamicD - Best to share your experiences here in the forums. I'll ping the team and see what we can do to help here. Thanks
Hi @Justin-DynamicD @sks @tperelle
The plugin has been qualified on Centos 7, Rhel 7.3 and Ubuntu 16.04.2 and there are instructions on that Docker page that can help.
With respect to the error you are getting might be best to give Nutanix support a call - that way you can securely transfer any logs, etc that might be need.
When you get things going, might also be best to share the fix on this thread for other in the community to benefit from. Thanks
The plugin has been qualified on Centos 7, Rhel 7.3 and Ubuntu 16.04.2 and there are instructions on that Docker page that can help.
With respect to the error you are getting might be best to give Nutanix support a call - that way you can securely transfer any logs, etc that might be need.
When you get things going, might also be best to share the fix on this thread for other in the community to benefit from. Thanks
Thanks for the followup.
For those just finding this thread We have implemented this in our corp services division and leverage it in conjunction with Docker + Nomad to provide a complete container solution that runs very well.
Essentially we can declare the storage requirements in our nomad storage stanza, and the requested volume will be mounted if present, and created if missing. We then use the data protection feature to snapshot the data volumes so that we have a complete backup solution that works with containers. Pretty elegant all in all!
For those just finding this thread We have implemented this in our corp services division and leverage it in conjunction with Docker + Nomad to provide a complete container solution that runs very well.
Essentially we can declare the storage requirements in our nomad storage stanza, and the requested volume will be mounted if present, and created if missing. We then use the data protection feature to snapshot the data volumes so that we have a complete backup solution that works with containers. Pretty elegant all in all!
We are receiving the same error message about /run/docker/plugins/.../nutanix.sock no such file or directory.
Running
AOS 5.6.1
Hypervisor 20170830.124
Tried on:
CentOS 7
Ubuntu 16.04 / 18.04
The docker-volume-plugin:1.1.1 is in play. Using Docker 18.03.1-ce.
The Nutanix Documentation and Knowledge Base are a mess with respect to Docker because they are obviously written at different points for different audiences, pre and post 'calm.io' acquisition and include no troubleshooting guidance at all. Even the practice labs associated with calm include no information on what to do if something goes wrong.
Nutanix Workshop Lab 7 - Docker Volume Plugin
Running
AOS 5.6.1
Hypervisor 20170830.124
Tried on:
CentOS 7
Ubuntu 16.04 / 18.04
The docker-volume-plugin:1.1.1 is in play. Using Docker 18.03.1-ce.
The Nutanix Documentation and Knowledge Base are a mess with respect to Docker because they are obviously written at different points for different audiences, pre and post 'calm.io' acquisition and include no troubleshooting guidance at all. Even the practice labs associated with calm include no information on what to do if something goes wrong.
Nutanix Workshop Lab 7 - Docker Volume Plugin
Thanks @smoodo I will pass this along to the team and see if I can get you an answer.
Hi @smoodo
I spoke with a few folks and it was suggested that it might be best for you to open a support ticket. I'll also pass along the documentation concerns. Thanks
I spoke with a few folks and it was suggested that it might be best for you to open a support ticket. I'll also pass along the documentation concerns. Thanks
Thanks @smoodo
Yes, please do share back to this post your findings - it's great to have community members like you wanting to give back
Yes, please do share back to this post your findings - it's great to have community members like you wanting to give back
Happy to report that I made it beyond various obstacles and have some small discoveries that could improve the experience a bit. One of the unfortunate bits is that the docker volume plugin does not emit much in terms of errors that will let you know what precisely went wrong.
Basics:
iSCSI initiator tools that you can see in Centos (iscsi-initiator-utils) and Ubuntu (open-iscsi)
https://store.docker.com/plugins/nutanix-dvp-docker-volume-plug-in
What those instructions do not tell you is the following.
You will need to get the initiator id out of your CentOS or Ubuntu and add it to a Nutanix Volume Group as 'clients'. The Nutanix Volume Group does not have to have disks. I think this is because Nutanix needed a way to know that the VM's are allowed access to the iSCSI targets that get created through 'docker volume create' stanzas. On my system if I did not have the iqn added to a Volume Group, the docker_volume_plugin would create volumes and disks in those volumes, but they would not be usable by containers running within the VM. iSCSI would report that the disk could not be found. You could, in fact, see it within the Nutanix Storage section. The initiator id on my CentOS 7 system ended up within /etc/iscsi/initiatorname.iscsi and looked like iqn.1994-05.com.redhat:cefadfb997de the one for Ubuntu was in the same place but looked like iqn.1993-08.org.debian:01:70a35537367
Another stumbling block was accidentally typing the password wrong and in another iteration trying a Nutanix Volume Group name for the 'DEFAULT_CONTAINER' parameter, which should have been the Nutanix Storage Container name. In all cases of getting something wrong, the only error you will get is about the nutanix.sock file not being found. I have not found a way to change an already installed plugin's configuration. Doing a 'docker plugin rm nutanix' was sufficient and then I reran the docker plugin install line.
A small detail on the plugin install line is the "--alias nutanix" part. That is from docker, and allows you to use the "--driver nutanix" versus the more verbose "--driver ntnx/nutanix_volume_plugin:1.1.1".
These issues were hard to resolve because various sets of instructions left out details or the labs or tutorials assumed perfection. Another helpful tidbit came from a Nutanix Tech video locked within a series about improvements (so you have to wade through the whole series) where they explain that the docker volume plugin is essentially using the REST calls to orchestrate creating and destorying volumes used with Docker. Perhaps that should have been more obvious in hindsight, but knowing that told me how to think about what could go wrong with the plugin. (Password changes, port 443 problems, iscsi issues).
It looks like there will be some lasting burdens from the configuration:
The DATASERVICES_IP is an IP that is accessible in the IP Range of the Nutanix Cluster. Said in a fancier way 'in the same subnet'. There is nothing mysterious about it, but once you set it and start to configure things to expect it, you will have to own all of those configuration changes down the line. Password changes will probably not be elegant either, so a service account might be appropriate for production.
My production use cases will be multi-docker-container clustered databases and clustered application specific repositories. We will likely try the orchestration on Kubernetes next, but first some experimentation with docker swarm and stacks.
Basics:
iSCSI initiator tools that you can see in Centos (iscsi-initiator-utils) and Ubuntu (open-iscsi)
https://store.docker.com/plugins/nutanix-dvp-docker-volume-plug-in
What those instructions do not tell you is the following.
You will need to get the initiator id out of your CentOS or Ubuntu and add it to a Nutanix Volume Group as 'clients'. The Nutanix Volume Group does not have to have disks. I think this is because Nutanix needed a way to know that the VM's are allowed access to the iSCSI targets that get created through 'docker volume create' stanzas. On my system if I did not have the iqn added to a Volume Group, the docker_volume_plugin would create volumes and disks in those volumes, but they would not be usable by containers running within the VM. iSCSI would report that the disk could not be found. You could, in fact, see it within the Nutanix Storage section. The initiator id on my CentOS 7 system ended up within /etc/iscsi/initiatorname.iscsi and looked like iqn.1994-05.com.redhat:cefadfb997de the one for Ubuntu was in the same place but looked like iqn.1993-08.org.debian:01:70a35537367
Another stumbling block was accidentally typing the password wrong and in another iteration trying a Nutanix Volume Group name for the 'DEFAULT_CONTAINER' parameter, which should have been the Nutanix Storage Container name. In all cases of getting something wrong, the only error you will get is about the nutanix.sock file not being found. I have not found a way to change an already installed plugin's configuration. Doing a 'docker plugin rm nutanix' was sufficient and then I reran the docker plugin install line.
A small detail on the plugin install line is the "--alias nutanix" part. That is from docker, and allows you to use the "--driver nutanix" versus the more verbose "--driver ntnx/nutanix_volume_plugin:1.1.1".
These issues were hard to resolve because various sets of instructions left out details or the labs or tutorials assumed perfection. Another helpful tidbit came from a Nutanix Tech video locked within a series about improvements (so you have to wade through the whole series) where they explain that the docker volume plugin is essentially using the REST calls to orchestrate creating and destorying volumes used with Docker. Perhaps that should have been more obvious in hindsight, but knowing that told me how to think about what could go wrong with the plugin. (Password changes, port 443 problems, iscsi issues).
It looks like there will be some lasting burdens from the configuration:
The DATASERVICES_IP is an IP that is accessible in the IP Range of the Nutanix Cluster. Said in a fancier way 'in the same subnet'. There is nothing mysterious about it, but once you set it and start to configure things to expect it, you will have to own all of those configuration changes down the line. Password changes will probably not be elegant either, so a service account might be appropriate for production.
My production use cases will be multi-docker-container clustered databases and clustered application specific repositories. We will likely try the orchestration on Kubernetes next, but first some experimentation with docker swarm and stacks.
Thanks for the feedback @smoodo very detailed and I will share with the team.
It's great to have you as a community member.
It's great to have you as a community member.
Is this for AHV only? I would assume so but wanted to check.
Hi @pgemme
The plugin has been qualified on Centos 7, Rhel 7.3 and Ubuntu 16.04.2. It may work for older versions, but not every distro / version have been tested for this. Please use with caution. Best way would be to test it in a non-production VM and make sure that everything works, before installing this in your production Docker hosts / nodes.
Check out this video as well:
The plugin has been qualified on Centos 7, Rhel 7.3 and Ubuntu 16.04.2. It may work for older versions, but not every distro / version have been tested for this. Please use with caution. Best way would be to test it in a non-production VM and make sure that everything works, before installing this in your production Docker hosts / nodes.
Check out this video as well:
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.