cinder + Unity

Huang, Yong Yong.Huang at Dell.com
Thu Apr 22 11:13:00 UTC 2021


Hi Albert,



Could you execute the `cinder get-pools` command to check if Unity driver report the valid pools correctly? the output should be:

--------------------------------------------------

stack at ubuntu-xenial:/opt/stack/cinder$ cinder get-pools

+----------+--------------------------------+

| Property | Value |

+----------+--------------------------------+

| name | ubuntu-xenial at unity#Flash_Pool |

+----------+--------------------------------+

+----------+---------------------------------+

| Property | Value |

+----------+---------------------------------+

| name | ubuntu-xenial at unity#Manila_Pool |

+----------+---------------------------------+

+----------+---------------------------------+

| Property | Value |

+----------+---------------------------------+

| name | ubuntu-xenial at unity#Cinder_Pool |

+----------+---------------------------------+

--------------------------------------------------



If no valid pools, one possibility is Unity driver not initialized successfully, if the driver initialized successfully, there should be a log in cinder-volume.log like:

--------------------------------------------------

Apr 21 03:20:07 ubuntu-xenial cinder-volume[29607]: INFO cinder.volume.manager [None req-4b345a29-0d78-4cf7-8bae-ae541a48aaf3 None None] Driver post RPC initialization completed successfully.

--------------------------------------------------



Did you install the storops library which Unity driver relies on? Please check the version info of storops:

--------------------------------------------------

stack at ubuntu-xenial:/opt/stack/cinder$ pip show storops

Name: storops

Version: 1.2.8

Summary: Python API for VNX and Unity.

Home-page: https://github.com/emc-openstack/storops

Author: Cedric Zhuang

Author-email: cedric.zhuang at gmail.com<mailto:cedric.zhuang at gmail.com>

License: Apache Software License

Location: /usr/local/lib/python2.7/dist-packages

Requires: requests, python-dateutil, persist-queue, cachez, bitmath, enum34, six, PyYAML, retryz

--------------------------------------------------



Thanks

Yong Huang

[EXTERNAL EMAIL]
Hi Albert,

On Mon, Apr 19, 2021 at 11:45 PM Albert Shih <Albert.Shih at obspm.fr<mailto:Albert.Shih at obspm.fr>> wrote:
Hi everyone,

I'm a total newbie with openstack, currently I'm trying to put a POC with a
Unity storage element, 4 computes, and few servers (cinder, keystone,
glance, neutron, nova, placement and horizon).

I think my keystone, glance, placement are working (at least they past the
test).

Currently I'm trying to make cinder working with my Unity (480), the
objectif are to use iSCSI.

Here the configuration of my /etc/cinder/cinder.conf

  [DEFAULT]
  rootwrap_config = /etc/cinder/rootwrap.conf
  api_paste_confg = /etc/cinder/api-paste.ini
  iscsi_helper = tgtadm
  volume_name_template = volume-%s
  volume_group = cinder-volumes
  verbose = True
  auth_strategy = keystone
  state_path = /var/lib/cinder
  lock_path = /var/lock/cinder
  volumes_dir = /var/lib/cinder/volumes
  enabled_backends = unity
  transport_url = rabbit://openstack:XXXXXX@amqp-cloud.private.FQDN/openstack
  auth_strategy = keystone
  debug = True
  verbose = True

  [database]
  connection = mysql+pymysql://cinder:XXXXXXX@mariadb-cloud.private.FQDN/cinder

  [keystone_authtoken]
  www_authenticate_uri = http://keystone.private.FQDN:5000/v3 [keystone.private.fqdn]<https://urldefense.com/v3/__http:/keystone.private.FQDN:5000/v3__;!!LpKI!x37Ut-hhgzyfd251eExF9xxSy9m4V243W1wvIl5o39J3VnlmGQWl2I2XK_Kd1yxpcbFM$>
  auth_url = http://keystone.private.FQDN:5000 [keystone.private.fqdn]<https://urldefense.com/v3/__http:/keystone.private.FQDN:5000__;!!LpKI!x37Ut-hhgzyfd251eExF9xxSy9m4V243W1wvIl5o39J3VnlmGQWl2I2XK_Kd11uttafM$>
  identity_uri = http://keystone.private.FQDN:5000 [keystone.private.fqdn]<https://urldefense.com/v3/__http:/keystone.private.FQDN:5000__;!!LpKI!x37Ut-hhgzyfd251eExF9xxSy9m4V243W1wvIl5o39J3VnlmGQWl2I2XK_Kd11uttafM$>
  memcached_servers = memcached-cloud.private.FQDN:11211
  auth_type = password
  project_domain_name = default
  user_domain_name = default
  project_name = service
  username = cinder
  password = XXXXXX

  [oslo_concurrency]
  lock_path = /var/lib/cinder/tmp

  [unity]
  # Storage protocol
  storage_protocol = iSCSI
  # Unisphere IP
  san_ip = onering-remote.FQDN
  # Unisphere username and password
  san_login = openstack
  san_password = "XXXXX"
  # Volume driver name
  volume_driver = cinder.volume.drivers.dell_emc.unity.Driver
  # backend's name
  volume_backend_name = Unitiy_ISCSI

This might be something to look at with the wrong spelling causing mismatch.

  unity_io_ports = *_enp1s0
  unity_storage_pool_names = onering

When I'm trying to create a storage through a

    openstack volume create volumetest --type thick_volume_type --size 100

I don't even see (with tcpdump) the cinder server trying to connect to

  onering-remote.FQDN

Inside my /var/log/cinder/cinder-scheduler.log I have

  2021-04-19 18:06:56.805 21315 INFO cinder.scheduler.base_filter [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Filtering removed all hosts for the request with volume ID '06e5f07d-766f-4d07-b3bf-6153a2cf6abd'. Filter results: AvailabilityZoneFilter: (start: 0, end: 0), CapacityFilter: (start: 0, end: 0), CapabilitiesFilter: (start: 0, end: 0)

This log mentions that no host is valid to pass the 3 filters in the scheduler.

  2021-04-19 18:06:56.806 21315 WARNING cinder.scheduler.filter_scheduler [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] No weighed backend found for volume with properties: {'id': '5f16fc1f-76ff-41ee-8927-56925cf7b00f', 'name': 'thick_volume_type', 'description': None, 'is_public': True, 'projects': [], 'extra_specs': {'provisioning:type': 'thick', 'thick_provisioning_support': 'True'}, 'qos_specs_id': None, 'created_at': '2021-04-19T15:07:09.000000', 'updated_at': None, 'deleted_at': None, 'deleted': False}
  2021-04-19 18:06:56.806 21315 INFO cinder.message.api [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Creating message record for request_id = req-4808cc9d-b9c3-44cb-8cae-7503db0b0256
  2021-04-19 18:06:56.811 21315 ERROR cinder.scheduler.flows.create_volume [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. No weighed backends available: cinder.exception.NoValidBackend: No valid backend was found. No weighed backends available


It seem (for me) cinder don't try to use unity....

The cinder-volume service is responsible for communicating with the backend and this create request fails on scheduler only, hence no sign of it.

Any help ?

Regards

Looking at the scheduler logs, there are a few things you can check:

1) execute ``cinder-manage service list`` command and check the status of cinder-volume service if it's active or not. If it shows an X sign then check in cinder-volume logs for any startup failure.
2) Check the volume type properties and see if ``volume_backend_name`` is set to the right value i.e. Unitiy_ISCSI (which looks suspicious because the spelling is wrong and there might be a mismatch somewhere)

Also it's good to mention the openstack version you're using since the code changes every cycle and it's hard to track the issues with every release.

Thanks and regards
Rajat Dhasmana


--
Albert SHIH
Observatoire de Paris
Heure local/Local time:
Mon Apr 19 08:01:37 PM CEST 2021
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210422/b77d6464/attachment-0001.html>


More information about the openstack-discuss mailing list