Bug 1408806

Summary: A Cinder empty volume isn't represented on VMware's under "cinder-volumes" folder
Product: Red Hat OpenStack Reporter: Tzach Shefi <tshefi>
Component: openstack-cinderAssignee: Eric Harney <eharney>
Status: CLOSED NOTABUG QA Contact: Tzach Shefi <tshefi>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: knoha, scohen, sgordon, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-25 18:58:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot of cli and vsphere
none
New screen shoot none

Description Tzach Shefi 2016-12-27 11:44:43 UTC
Created attachment 1235496 [details]
Screenshot of cli and vsphere

Description of problem: Not sure if this is a Cinder or python-olso-vmware or a driver bug, maybe just a misunderstanding on my side.  

On a system with Glance Cinder and Nova all configured with vsphere 6. 
Cinder create volume from image creates a volume which is visible on Vsphere under "VM & template" view, under folder called "Cinder-volumes" as configured on cinder.conf

However when creating an empty Cinder volume, it too is created yet isn't represented under Vsphere's "Cinder-volumes" folder.

Attaching vsphere screen shoot. 
Notice VolFromImage is shown on vshepre, yet the other volume (EmptyVol) isn't. 

Version-Release number of selected component (if applicable):
RHEL 7.3
RHOS7
python-oslo-vmware-0.11.1-3.el7ost.noarch
python-cinderclient-1.2.1-4.el7ost.noarch
openstack-cinder-2015.1.3-11.el7ost.noarch
python-cinder-2015.1.3-11.el7ost.noarch

VMware 
vcenter: 6.0.0 (build 3634794) 
Also happens with Vcenter 5.5u3

How reproducible:
Every time, with both vc5.X/6.x 

Steps to Reproduce:
1. Configure Nova,Cinder with vmware backend

2. Create Cinder volume from an image, note it's shown under cinder-volumes folder on Vshpere's web. 

3. Create an empty Cinder volume, notice nothing is added under Vsphere's cinder-volume. 

4. If you attach that empty volume to an instance, looking at that instance/VM on Vsphere's side you will see that the empty volume/disk has indeed been attached. Under "Disk file" can see it's actual path. BTW the volume created from an image was also physically created under that same VMware data store path.

Actual results:
Empty Cinder volumes aren't represented under "cinder-volumes" folder on vhspere. 

Expected results:
Expecting all volumes to be represented under "cinder-volume" folder even if they are empty.

Comment 2 Tzach Shefi 2017-01-25 16:15:23 UTC
Same issue still happens on OSP10
puppet-cinder-9.4.1-3.el7ost.noarch
python-cinderclient-1.9.0-4.el7ost.noarch
python-cinder-9.1.1-3.el7ost.noarch
openstack-cinder-9.1.1-3.el7ost.noarch
python-oslo-vmware-lang-2.14.0-1.el7ost.noarch
python-oslo-vmware-2.14.0-1.el7ost.noarch
VMware vcenter 6

Created two volumes one empty one from image. 
Only imaged backed volume shows up on vcenter.
Attaching another print screen.

Comment 3 Tzach Shefi 2017-01-25 16:16:11 UTC
Created attachment 1244299 [details]
New screen shoot

Comment 5 Stephen Gordon 2017-01-25 18:58:41 UTC
Reached out to our contacts at VMware:

"""
We delay the volume creation in vCenter (if possible) in order to minimize the volume shadow VM relocate operations. If we create the volume on some random datastore and the instance's ESX host cannot access that datastore, we have to relocate the volume shadow VM during attach, which is not desirable for large volumes. Of course, the volume shadow VM may need to be relocated for subsequent attach operations. Therefore, we recommend using shared datastores, and prefer those datastores in our datastore selection algorithm.

See http://docs.openstack.org/newton/config-reference/block-storage/drivers/vmware-vmdk-driver.html#functional-context

When using an image source, there is no way we can delay the actual volume creation in vCenter because we need to copy the bits from the image source.
"""

Based on the above this is expected behavior and I believe we can mark CLOSED NOTABUG. Thanks for the report though Tzach as the above is useful to know.