Mount iSCSI target from FreeNAS

[JavaScriptDude]

I have a need to mount an iSCSI target from FreeNAS. The iSCSI target is hosted on the same FreeNAS server.

I have tried following documentation online for FreeBSD and creating iscsi initiators but its failing with the following message:

[qdw@freenas] /dev# iscontrol -v -d targetaddress=127.0.0.1 initiatorname=`hostname`
adding 'targetaddress=127.0.0.1'
/dev/iscsi: No such file or directory​

... I have found similar errors on your forum with the statement that this may not be possible however the answer is a bit terse.

Can someone please let me know if it is possible to access an iSCSI target from FreeNAS? If its not possible, why?

If you are interested in my usecase, it is as follows: I want to use FreeNAS as a low cost backup for VMware vms. I have created an ZVol for vmware and have it accessible via iSCSI. There are hardware and performance reasons for me to use iSCSI over NFS. I want to write a program in FreeNAS that can read the backed-up VM in the ZVOL, tar it and compress it and move it to regular volume for next phases in backup. I prefer to do this all from FreeNAS as its closest to the files and would get the best possible performance.

Thanks!

 

[jgreco]

So you're proposing to implement the vmfs3 or vmfs5 file system layer in userspace?

 

[JavaScriptDude]

Good point. You have cought that I am an iSCSI n00b! My usecase cannot utilize iSCSI from FreeNAS. Your quick response has saved me a bunch of time spinning my wheels on a solution. I'll switch to plan B which will likely use NFS instead of iSCSI or a combination thereof and utilize some scripting in vsphere.

:)

 

[jgreco]

Not a problem. NFS is probably a better choice. Do note that ESXi plays rough with NFS, and the very first problem that you will encounter is horrid write speeds. ESXi wants its writes to be sync, which makes sense; it really has no clue what a VM is writing to disk or what might cause breakage if it was lost - should make complete sense I hope.

The ESXi storage paradigm therefore relies on having a battery backed write cache for direct-attached RAID controllers (in which case it'll be able to go fast) or, in the case of NAS, a NAS server with some form of safe write caching, which for NFS+ZFS happens to be a ZIL.

So then you can read up on this.

So basically the short form is that it's perfectly fine to use sync=disabled if you understand what is going on. It would be very dangerous to run live VM's on top of a NFS share with sync=disabled - any unexpected crash or power loss or reboot would virtually guarantee that in-flight writes would be lost and therefore your vmdk's would ultimately be inconsistent with what the running VM's expect, and further writes would be likely to be actively shredding your VM filesystem in the vmdk. However, if you're using something like GhettoVCB, what is happening is that a snap image is being written. A crash or pl or rb will still corrupt that snap image and quite possibly render it unusable. However, even without operator intervention, that gets "fixed" during the next round of backups. So it isn't perfect but it is certainly nowhere near as damaging as the NFS-sync=disabled-for-live-VM scenario.

So while NFS may have some problems, there are definite options for fixing the problems.

 

[JavaScriptDude]

Sweet!

I decided on my first go-around with ZFS to avoid caching my ZIL to SSD. As such using NFS for live VMs is not an option for me.

I have FBWC based HW Raid on my ESX Servers and have no intention of running VMs from FreeNAS. I have seen the horrid performance with NFS. I'll investigate sync=disabled as I am only planning on writing the VM to the NFS share for backup purposes or for restoring VM back to a new Host in a failure scenario.

I may be able to use a combination of the ghettoVCB scripts and some scripts under BSD server to handle packaging and compression to get a full end to end backup and recovery solution.

 

[JavaScriptDude]

Confirmed. I set sync=disabled for ZFS "VM Backup" NFS volume and the speed is amazing. Just as fast as iSCSI. I just have to make sure that my procedures leaves no ambiguity that this datastore is for backups must never be used for booting a VM.

 

[jgreco]

Call it "backups" or something like that.