how to check which volume belong to which volume store

[shenxg13]

got three volume stores: root@ph1 [ ~/vic ]# docker info Containers: 1 Running: 0 Paused: 0 Stopped: 1 Images: 1 Server Version: v1.2.1-13858-c3db65f Storage Driver: vSphere Integrated Containers v1.2.1-13858-c3db65f Backend Engine VolumeStores: share default opt

got two volumes: root@ph1 [ ~/vic ]# docker volume ls DRIVER VOLUME NAME vsphere f95c62c9-bf8b-11e7-9671-0050568b7403 vsphere mysql_data

inspect one volume: root@ph1 [ ~/vic ]# docker volume inspect mysql_data [ { "Name": "mysql_data", "Driver": "vsphere", "Mountpoint": "f60e4c47c6b9f204", "Labels": {}, "Scope": "" } ]

how can i know this volume belongs which volume store?

[sflxn]

This is an interesting question. Volume store is a unique VIC concept. There are a few fields that we are not filling out on docker volume inspect, specifically the volume options, which is used to specify a volume's volume store at create time. The docker API server router appears to write out every field in the volume struct to json so filling out that options should output to the CLI.

If the above is does not pan out, we can also overload the Mountpoint with this data for volume inspect.

We need to make sure the call to the portlayer can also retrieve the options data. Therefore, I rate this issue as a 3 but could be a 2.

[shenxg13]

and another question, how to check the data store path in the vsphere of a volume store?

[matthewavery]

Hey @shenxg13 that is another really great question. I recommend making a separate ticket for this question as it would need to go into the vic-machine inspect output. No vSphere credentials or topology can be leaked out through the VCH or docker commands. The VI admin(or the person in charge of deploying the VCH should be responsible for this kind of information). In this case the vic-machine inspect output should have the name of the store and then a correlation to a vsphere pathing including datastore and namespacing used. :) I will keep an eye out for a second ticket and copy this comment there as well.

[anchal-agrawal]

This is a feature enhancement and not a bug - per PM input (cc @pdaigle) and @matthewavery, we may not include this in the VIC 1.3 release.

[sflxn]

I don't think we need a second issue for this. Let's just make this a lifecycle task to add to vic-machine inspect.

[hickeng]

@shenxg13 For now you can see which datastore a given volume store is on by using the vic-machine inspect config command. The following is an example from one of my local development systems:

$ ./vic-machine-linux inspect config --target=https://192.168.78.128 --compute-resource= --name=localtls --thumbprint=2D:99:AB:AD:F3:91:5F:78:79:05:32:24:95:5D:B3:25:CF:F5:EE:06
INFO[0000] ### Inspecting VCH ####
INFO[0000] Validating target
INFO[0000]
INFO[0000] Target VCH created with the following options:
        --target=https://192.168.78.128
        --thumbprint=2D:99:AB:AD:F3:91:5F:78:79:05:32:24:95:5D:B3:25:CF:F5:EE:06
        --name=localtls
        --compute-resource=/ha-datacenter/host/localhost.localdomain/Resources
        --ops-user=drone
        --image-store=ds://datastore1/localtls
        --volume-store=ds://datastore1/volumes:default
        --volume-store=ds://datastore1/other-volumes:others
        --dns-server=10.132.71.1
        --dns-server=10.132.71.2
        --bridge-network=localtls
        --public-network-gateway=192.168.78.2
        --public-network-ip=192.168.78.127/24
        --container-network=VMExternal2:open
        --container-network=VMExternal3:outbound
        --container-network=VMExternal:external
        --container-network-gateway=VMExternal2:192.168.78.2/24
        --container-network-ip-range=VMExternal2:192.168.78.10-192.168.78.20
        --container-network-firewall=VMExternal3:outbound
        --container-network-firewall=VMExternal:published
        --container-network-firewall=VMExternal2:open

[hickeng]

@wjun This is particularly relevant when it comes to storage quotas for volume stores.