No storage options shown when creating new VM in upgraded 3.1

[donty]

We just upgraded from 2.3 to 3.1 on a cluster of nodes.

We have a couple of storage arrays connecting via iSCSI as LVM and NFS managed from the Proxmox web manager. All existing VMs are running fine and the interface show the iSCSI, LVM abnd NFS stores. When clicked the contents show up in the listing and all looks fine.

However when we try to create a new VM there is no option available (greyed) to set the storage target and when the pressing go, the creation attempt fails with:

TASK ERROR: create failed - storage 'undefined' does not exists.

The area we are concerned with is that we ran the upgrade script that seemed to complete without issue.

We also manually removed old pve kernels that seems to remain from way back.

Then ran the /purge option to clear down unnecessary packages and it seemed to removed pve-manager etc.

To fix that we then ran:
apt-get install pve-qemu-kvm proxmox-ve-2.6.32 vzctl pve-manager qemu-server ceph-common libpve-storage-perland

most things came back fine, but we are not sure if we have missed any packages.pveversion -v shows:

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-1
pve-cluster: 3.0-7
qemu-server: 3.1-1
pve-firmware: 1.0-23
libpve-common-perl: 3.0-6
libpve-access-control: 3.0-6
libpve-storage-perl: 3.0-10
pve-libspice-server1: 0.12.4-1
vncterm: 1.1-4
vzctl: 4.0-1pve3
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-17
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.0-2

Which looks right.

Anyone have any ideas why storage is not showing where expected?

Other than that the upgrade looks good, thanks!

 

[dietmar]

Please can you post your storage configuration /etc/pve/storage.cfg?

 

[donty]

Here's a sample:

dir: local
path /var/lib/vz
content images,iso,vztmpl,backup,rootdir
maxfiles 0

iscsi: ISCSI-SA-001
target iqn.2013-03.net.company:storage-group001.lun1
portal xxx.xxx.xxx.200
content none

lvm: LVM-ISCSI-SA-001
vgname LVG-LVM-ISCSI-SA-001
base ISCSI-SA-001:0.0.0.scsi-149455400000000003e3bfc4b99d474034cc60b3f6489f086
shared
content images

iscsi: ISCSI-SA-002
target iqn.2013-04.net.company:storage-group002.lun1
portal xxx.xxx.xxx.201
content none

lvm: LVM-ISCSI-SA-002
vgname LVG-ISCSI-SA-002
base ISCSI-SA-002:0.0.0.scsi-14945540000000000929e032383e786e02d3d91fdb1962629
shared
content images

nfs: NFS-SA-001
path /mnt/pve/NFS-SA-001
server xxx.xxx.xxx.200
export /mnt/nfs-share
options vers=3
content images,iso,vztmpl,backup,rootdir
maxfiles 5

nfs: NFS-SA-002
path /mnt/pve/NFS-SA-002
server xxx.xxx.xxx.201
export /mnt/nfs-share
options vers=3
content images,iso,vztmpl,rootdir,backup
maxfiles 5

 

[dietmar]

What is the output of

# pvesm status

 

[dietmar]

And what user do you use ('root'?) - If you use another user you may have set wrong permissions?

 

[donty]

OK, root user now works! We had logged on as root before and tested access but it seemed not to make a difference, possibly our error.

We were then using the Proxmox authentication service and a user with Administrator group privileges which worked fine before the upgrade. Adding them into PVE admins group specifically now works.

Does a user need anything specific now that it didnt before? Is this related to the newer storage migration options? Has the perms model changed?

Thanks for the prod, not sure why it didn't work previously, but we did take the 002 array offline as it had some valuable backups. First by shutting off access by the cluster, to ensure we has access from elsewhere, then by shutting it down.

Could it relate to problems with a storage system that is configured but unavailable perhaps? I recall an odd issue previously with NFS shares being dropped and a hanging interface?