nexenta storage support

mir

Famous Member
Apr 14, 2012
3,568
127
133
Copenhagen, Denmark
Hi all,

I have a few questions related to the nexenta storage support in proxmox.

1) Since the nexenta storage support in Proxmox provides support for snapshots over iSCSI why is this not available for iSCSI to other backends?
2) When creating configuration of nexenta storage you are required to provide both the pool and the target. Why is that?

Especially 2) opens up for errors since a target can be a subset of a pool causing Proxmox to use the wrong size for the storage. And example:

pool: mypool size 200 GB
target: mytarget size 100 GB

In proxmox summary view for the storage the size is wrongly displaying 200 GB while the actually storage size is only 100 GB. What happens if an allocation on the storage is requested so that the total used storage will amount to 130 GB?
 
Hi all,

I have a few questions related to the nexenta storage support in proxmox.

1) Since the nexenta storage support in Proxmox provides support for snapshots over iSCSI why is this not available for iSCSI to other backends?
2) When creating configuration of nexenta storage you are required to provide both the pool and the target. Why is that?

Especially 2) opens up for errors since a target can be a subset of a pool causing Proxmox to use the wrong size for the storage. And example:

pool: mypool size 200 GB
target: mytarget size 100 GB

In proxmox summary view for the storage the size is wrongly displaying 200 GB while the actually storage size is only 100 GB. What happens if an allocation on the storage is requested so that the total used storage will amount to 130 GB?

1) because we use nexenta api to create iscsi volumes. (1 disk = 1 iscsi volume). So we need apis to manage other iscsi storages. (create disk, snapshots,clone,...)

2) pool : your nexenta Volume (http://nexentastorage:2000/data/datasets/)
target : your nexenta iscsi target : iqn.1986-03.com.sun:02..... (http://nexentastorage:2000/data/scsitarget/iscsi/targets/)
 
Yes, but it seems the GUI uses the size of the pool and not the target opening up for errors since a pool <> target ( there is a one to many relation from pool to target) and since a target can only belong to a specific pool I find this information dubious and error prone.
 
Yes, but it seems the GUI uses the size of the pool and not the target opening up for errors since a pool <> target ( there is a one to many relation from pool to target) and since a target can only belong to a specific pool I find this information dubious and error prone.

For me, it make sense to have the size of the pool, as this is the real storage space you have.
A target is just an iscsi network entry point to the storage.

Maybe can you provide me an example, maybe it don't understand exactly what you say ?
 
For me, it make sense to have the size of the pool, as this is the real storage space you have.
A target is just an iscsi network entry point to the storage.
The storage you have access to is the storage provided through the iSCSI target so the size of the provided storage is limited to the size assigned on the storage to the iSCSI target.
Maybe can you provide me an example, maybe it don't understand exactly what you say ?
I did provide an example:
pool: mypool size 200 GB
target: mytarget size 100 GB

See attached dataset(volume).png and target.png.
dataset(volume).jpg dataset

target.jpg target

But I see now why both you and I get confused. Apparently nexenta creates snapshots outside the target which means nexenta does make a distinction between a target and a pool but this is very different from the way iSCSI works in general since in iSCSI in general the target is an absolute boundary for the assigned storage in which case in ordinary iSCSI you can compare a target to a pool in nexenta. See attached screenshot.
snapshots.jpg

This obvious lets me to ask: Why then use a target when assigning storage from nexenta or have I misunderstood the concept of target in nexenta? In normal iSCSI you assign the storage pool to the target which is then made available over iSCSI whereas it seems in nexenta that the target is merely the mount point which serves as the communication tunnel between clients and the storage pool.
 
Yes, I think you didn't have understand the concept of target ;)

1 zvol != 1 target.

You can have 1 iscsi target, and multiples zvols (luns) by target.

(With classic iscsi on a linux host, you logon to an iscsi target, then you get all luns in /dev/....).

Proxmox create 1lun(zvol) for each volume disk.

(It's not like with lvm partitions on a big lun)
 
Well, I do not think you can call nexentas way modern as opposed to classic since AFAIK all others do it the oppersite way than nexenta and since this also includes Solaris, OpenSolaris, Omnios, OpenIndiana which are parents to nexenta my conclusion is that nexenta has chosen a different path. But now I know it I can easily adapt to this approach. Having the opportunity to make snapshots is a big gain.

BTW. is GUI support for nexenta storage scheduled for 3.0?
 
It's not really a nexenta path, you can manage it with a big lun if you want and do lvm to create volume.
But In this case, you cannot management snapshots,clones,rollback,... was it doesn't work with shared lvm.
if you want to manage snapshots,rollback,clones,... you need to do it on the storage, so the only way is to use 1zvol = 1 virtual disk.
That's why our nexenta plugin manage it like that.


>>BTW. is GUI support for nexenta storage scheduled for 3.0?
It's already work since 1 year ;)
only adding to storage is not implemented, so manual edit your /etc/pve/storage.cfg and then you can create disks from proxmox.
Adding the storage from gui is not added, because proxmox team doesn't have enough ressources to support it officially.

 
1) because we use nexenta api to create iscsi volumes. (1 disk = 1 iscsi volume). So we need apis to manage other iscsi storages. (create disk, snapshots,clone,...)

I have given this some thoughts. Provided the file system behind a iscsi target/volume is zfs based then providing such an api should not be to difficult to make since zfs has all tools available for doing so. I know off create 'disk', snapshot and clone but which other functionality is required?

Any interest in having such an api developed for pve? (using perl should guaranty support on all storage solutions known to me - Linux, FreeBSD and Solaris et al)

- - - Updated - - -

>>BTW. is GUI support for nexenta storage scheduled for 3.0?It's already work since 1 year ;)only adding to storage is not implemented, so manual edit your /etc/pve/storage.cfg and then you can create disks from proxmox.Adding the storage from gui is not added, because proxmox team doesn't have enough ressources to support it officially.
I have found that out and it works marvelous;-)It was the thing about the manual configuration of the storage I had in mind. If someone did the hard work could it then be included? (My feelings toward nexenta are getting warmer:)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!