Please enable javascript, or click here to visit my ecommerce web site powered by Shopify.

Community Forum > Snapshots - LUN assignment > 255 "bug" - no access from ESXi

Hi again....

I was playing with the very nice StorageVolume snapshot features... really a great feature!
I have configured some hourly/daily/weekly... snapshots just to see how is it working, what kind of changes there are in such time periods etc.
Yesterday, after quite some time not doing this, I tried to mount an older snapshot volume snapshot to get some data I managed to destroy.

I have two esx hosts, connected to QS via FC.
I assigned the snapshot to the hosts and at first all seemd "like usual"... but my esx hosts (v5.5) did not see any "new" drives...
After a little peeking arrount I noticed the snapshot volume was assigned the FC SCSI LUN 527 - a little "strange" LUN ID I would say...

OK, after some more peeking and digging I finally found some answers...
The documents from VMWare says max LUN ID supported is 255 and I also found some other references and tests confirming that:

So.... is there a way to change the LUN assignment for the volumes? I know your documentation says "LUNs are assigned automatically" but.... that assignment is not really "useful" it seems.
There is no problem with the iSCSI access as there the LUN is always 0... but for FC... it's a real problem...
Is it really possible that noone noticed this before??

QS version

Any suggestion?

Best regards,

March 12, 2017 | Registered CommenterM.Culibrk


In this case, you should be able to use the lun id with the latest version of vSphere, which supports lun id's up to 1023. If you have a specific need beyond this, then perhaps some more information about the issue you are having would help to provide better understanding.

Also, would you be able to clarify if this is for the free community edition? Otherwise, are you looking to consult or become a partner and have direct support access? If so, you can contact Sales Engineering at if you have a particular customer and pending sale up for discussion.


March 13, 2017 | Registered CommenterAaron Knodel

Hi M,
Just to add to Aaron's feedback, I think that we could be doing a better job in picking FC LUN numbers. With iSCSI we are always using LUN 0 because each volume and snapshot has a unique IQN with the device on LUN 0. With FC the model is different and we have to account for ALUA environments where the same volume is presented from multiple appliances and we want those to be exposed with the same LUN number. I think that the issue is that we're picking the LUN number too soon, essentially we should have "lazy" allocation of LUN numbers once the storage is assigned. That would prevent these scenarios where you're seeing these high LUN numbers. Could you share the number number of volumes and snapshots you have in your configuration?

April 3, 2017 | Registered CommenterSteve