Cinder local loopback

savecancel

Nope just a local SMB share configured as //localhost/Cinder$ no CSV or anything complex. Just trying to use the local storage in the box. I will flip on debug as the local cinder-volume-smb just contains the above over and over.

Flipped on verbose in cinder-volume-smb.conf and nothing really enlightening. http://paste.openstack.org/show/605417/

And added a debug=true statement to the conf and oddly I did bsod the box, but after booting still getting the context error. http://paste.openstack.org/show/605425/

I mean honestly I don't even want to use the SMB share which I thought the mitaka driver handled internally to make the S2D lookup try local first.

As a workaround for now, just set the actual hostname instead of 'localhost'. This should let the driver pick it up as a local share (which is simply resolving addresses). I'm going to send a fix ASAP, sorry for the inconvenience. Let me know how it went.

I had the same thought yesterday, but it didn't resolve the core issue with the attach. I am not getting the WMI error so that is good. Likely in my TP5 test I was using hostname, but used localhost in the deploy script thinking it wouldn't matter. http://paste.openstack.org/show/605513/

So I figured out one err... using gen1s and you can't attach when powered on. so I need to handle that better as the smbfs driver seems to just do a terminate with no error. After powering down though I get the same wmi session err even w \\hostname\share$

So the issue is on the Nova side. Could you please check the logs and paste them here? What Nova MSI are you using? You can in fact attach disks to powered on Gen1 VMS. It's just that you can't attach/detach IDE disks in this case (we're using the SCSI bus in this case, except for BFV).

Not sure on that, but it's the mitaka release? I had tested using hv manager to try and attach the vmdk and that's where I noticed it would fail if the g1 vm's were on. I know I need to set the metadata for g2. I'd there any more granular debugging in cinder?

On pto till next week, but we'll try to grab versions and any Nova logs that corelate to the attach events when I am back in the office.

So, at this point, everything works fine on the Cinder side, there's nothing else to debug there. When Nova fails to attach a disk, it will request Cinder to terminate the volume connection, which is expected.

Ahh I follow now. Honestly didn't even think of checking Nova since it was all volume work, but makes more sense now. We'll try to remote in and take a look.

You can issue the following powershell command to fetch the exact Nova product version: http://paste.openstack.org/raw/605618/ The idea is that from time to time we release updated MSIs for stable releases.

Man feel like a dunce now as there is some solid info in there. http://paste.openstack.org/show/sQzF5Fox30oXmi3VMaOe/ including the session expire error. I don't have an A record for this lab and it is not a domain member, but maybe just create a hosts entry if the hostname isn't cutting it?

And compute version 13.0.0.0

@lpetrut any additional thoughts on this one?

From Nova and trimmed to fit comment max. HyperVException: WMI job failed with status 10. Error details: Failed to add device 'Physical Disk Drive'. - 'instance-0000048b' failed to add device 'Physical Disk Drive'. (Virtual machine ID ...) - Error code: 32773

That 32773 seems to reference a bad param (https://msdn.microsoft.com/en-us/library/hh850023(v=vs.85).aspx) but couldn't find any more details on what params were used in evtLogs.

Sorry for the delayed answer. For some reason, the Nova Mitaka MSI hasn't been updated in a while and a known issue remained there. We've been testing a new Mitaka release for the last few days, so I think today we'll update the MSI from our website, including the fix for this issue as well.

Is there a patchId for the fix I could snag and see if it covers it? If not I can hold tight, but figured I could make the best of the down time before the push is complete.