New Question

Cinder local loopback

asked 2017-03-31 20:32:04 +0300

jrack gravatar image

I am using cinder AZs to expose local disk for volume services running on a Hyper-V 2016 instance. Using the mitaka cinder driver it can do the local detect (for S2D efficiency) which works most of the time. But after a while I will start getting what I would imagine is a token expiration that breaks attaching volumes to instances.

2017-03-31 13:07:02.532 3436 ERROR cinder.volume.drivers.remotefs [req-9695f713-81a8-4b0e-b04f-1b9d26f9bf2e - - - - -] Exception during mounting Unable to mount SMBFS share: \localhost\Cinder$ WMI exception: <x_wmi: a="" specified="" logon="" session="" does="" not="" exist.="" it="" may="" already="" have="" been="" terminated.="" &gt;<="" p="">

I am betting I just need to do a more precise configuration in my New-SmbShare with perms or something, but wasn't sure. And HV server is a bit of a black box so harder to track down might might be going on. As a note volume creation and nova ops all work, but that attachment is what is blowing up.

edit retag flag offensive close merge delete

1 answer

Sort by » oldest newest most voted

answered 2017-04-04 10:52:46 +0300

lpetrut gravatar image

I think that happens when it tries to cleanup a failed mount. Could you please include the whole trace? Thank you.

I guess you're using CSVs, right? We're usually placing scale-out shares on top of them, simplifying share address resolution. I'd suggest using share locations such as //<sofs-name>/<volumes_share>. Those will be resolved to their local mount points.


edit flag offensive delete link more


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.

jrack gravatar imagejrack ( 2017-04-04 15:11:22 +0300 )edit

Flipped on verbose in cinder-volume-smb.conf and nothing really enlightening.

jrack gravatar imagejrack ( 2017-04-04 17:53:48 +0300 )edit

And added a debug=true statement to the conf and oddly I did bsod the box, but after booting still getting the context error.

jrack gravatar imagejrack ( 2017-04-04 18:12:28 +0300 )edit

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.

jrack gravatar imagejrack ( 2017-04-04 18:25:59 +0300 )edit

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.

lpetrut gravatar imagelpetrut ( 2017-04-05 13:28:25 +0300 )edit

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.

jrack gravatar imagejrack ( 2017-04-05 17:14:29 +0300 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2017-03-31 20:32:04 +0300

Seen: 500 times

Last updated: Apr 04 '17