Iscsi targets + vmware

[jwhitt]

So im building out some iscsi targets for a 3 node vmware cluster.

Right now im attaching 1 dev extent per target as i remember reading that freenas had issues handeling multiple luns per target. and this brings up two questions.

Is there a multiple LUN per target issue? Also on this note is it prefferable to have several small luns with fewer VM's on a target, etc? my assumption is yes, and i know this question will result in the answer of it depends. Performance is key in my scernaio, i dot have alot of heavy disk io issues (its a lab) but i noticed that when i was running one large lun on one target things seemed to slow down considerably. (FYI im only running 1 gig E connection for my Vmware Iscsi on its own network separate from my LAN)

Also i noticed that in order for Vmware hosts to see the LUN i had to stop the iscsi service and restart. Is this a bug? I foresee this being an issue when part of my lab is in a more production role?

thanks

Jason

[praecorloth]

So im building out some iscsi targets for a 3 node vmware cluster.
...

Also on this note is it prefferable to have several small luns with fewer VM's on a target, etc? my assumption is yes, and i know this question will result in the answer of it depends. Performance is key in my scernaio, i dot have alot of heavy disk io issues (its a lab) but i noticed that when i was running one large lun on one target things seemed to slow down considerably. (FYI im only running 1 gig E connection for my Vmware Iscsi on its own network separate from my LAN)

I would imagine that at a certain size you would run in to a bottleneck at the drive level, but I'd think you would hit a bottleneck at the network connection first. For that you can always do jumbo frames or link aggregation. I'd say you could also do a dedicated iSCSI network, but hopefully you're doing that at this point anyways.

Also i noticed that in order for Vmware hosts to see the LUN i had to stop the iscsi service and restart. Is this a bug? I foresee this being an issue when part of my lab is in a more production role?

I have had to do this once out of several reboots/shutdowns of my FreeNAS box. For some reason it was having trouble starting the iSCSI target and so it was failing silently on start up. Only caught it when I had the system logs displayed in the footer. A reboot didn't fix it. I had to stop and start the iSCSI service and then life was good. So I think it is a bug. But it's going to be a fun one to track down as it obviously doesn't get triggered on every reboot or shutdown. Aside from that one time, I have rebooted and shutdown the system and as long as I give the FreeNAS box ample time to start up before the ESXi box, it has no trouble seeing the iSCSI target on boot and autostarting VMs works like a charm.

[jwhitt]

Thanks for the reply however i reread my post and the issue that i am seeing is a bit different than the one you are describing.

Also i noticed that in order for Vmware hosts to see the LUN i had to stop the iscsi service and restart. Is this a bug? I foresee this being an issue when part of my lab is in a more production role?

I have had to do this once out of several reboots/shutdowns of my FreeNAS box. For some reason it was having trouble starting the iSCSI target and so it was failing silently on start up. Only caught it when I had the system logs displayed in the footer. A reboot didn't fix it. I had to stop and start the iSCSI service and then life was good. So I think it is a bug. But it's going to be a fun one to track down as it obviously doesn't get triggered on every reboot or shutdown. Aside from that one time, I have rebooted and shutdown the system and as long as I give the FreeNAS box ample time to start up before the ESXi box, it has no trouble seeing the iSCSI target on boot and autostarting VMs works like a charm.

What i have happening is the freenas system is compleatly up and services are running. However when i create a new lun and attach it to a new target, then refresh both teh HBA and rescan for new file systems the new lun wont show up untill i stop the iscsi service and start it manually through the web GUI.

Jason

[aviegas]

Interesting, I'm having the same problem and it happens both with 8.0 release and 8.0.1-BETA4.

It does not matter what happens to VMWare ESXi (in my case 4.1U1). It can start before and after FreeNAS. There is no way I can get the iSCSI target to become visible to ESXi unless I stop and restart the iSCSI service (istgt). I'm using a UFS mirror (2x 1.5TB).

It's really strange.

[daveymg]

This behaviour seems to be a function of using the istgt service, ie config changes aren't available until the service has restarted. A couple of net articles mention it, one of which is
http://www.squidoo.com/freenas-or-openfiler

[aviegas]

There is no "change" involved in this case, but merely the fact that the service was started before the disks to be exported by istgt were mounted. As a result the mount point gets exported. Starting istgt after all required mount points are properly mounted fix this particular issue.

[Milkwerm]

does anyone know what the issue is that prevents multiple LUNs per iSCSI target and if it is going to be addressed at any stage?

[jwhitt]

Also this issue seems like it will cause issues if i have some Luns with running VM's and would like to add another?

I do not recall this issue with 7.x releases

[majorindian]

What i have seen is if you have two or more ESX Host and you try to share a iscsi Target between two or more host. Then SORRY. FreeNAS doesn't work. You can add target on both Host but after sometime it will become Inactive and then you have to reboot each and every box. What a beautiful software. Shame on developers. New release also behave same way . No improvement at all.

I have almost read most of the thread and not able to see any solution related to this problem. So the conclusion i can was. THIS SOFTWARE (FreeNAS SUCKS)

[pirateghost]

perhaps you should learn to read VMWare documentation and troubleshooting before spouting off such nonsense

http://communities.vmware.com/thread/200479