NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD iSCSI target on ZVOL used as block device for Qemu - iSCSI: NOP timeout



Hello Chavdar and Michael,

Am 18.09.2022 um 16:28 schrieb Chavdar Ivanov:


On 18 September 2022 13:46:33 (+01:00), Matthias Petermann wrote:

 > Hi,
 >
 > Am 18.09.2022 um 14:22 schrieb Michael van Elst:
 > > mp%petermann-it.de@localhost (Matthias Petermann) writes:
 > > >> thanks for your suggestion. Do you mean this package:
 > > >> http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/net/netbsd-iscsi-target/
> >> ? I'm not sure if you mean this one, because the last change here was 9
 > >> years ago.
 > > Use the net/istgt package.
 > >
 > thanks - will build it right away and give it a try :)
That's what I meant, I was out and forgot the name of the package.
Years ago I had a NetBSD target serving a number of (mainly Windows) initiators; using the NetBSD built-in target I couldn't get them to reconnect after a restart of the server or of the workstations (I had to disconnect and reconnect every time). With net/istgt this wasn't the case and the connection worked reliably. More recently I used to use several zvols served by NetBSD-current (istgt) and from FreeBSD, the physical connection being through WiFi-PowerLine-Ethernet, and it worked (not particularly fast because of the PowerLine link). >
 > Kind regards
 > Matthias
 >

Chavdar


You have both helped me a lot with your advice. With net/istgt it works perfectly! The speed is also completely sufficient for me - even over 54 MBit/s Wifi.

Just out of interest - how can the state of the iscsi implementation in NetBSD-Base be assessed in general? Is the implementation outdated and/or unstable, or are there (compatibility?) reasons for this? According to the description, isgt is the same as the FreeBSD iscsi implementation. As far as I can tell, both target implementations run in user space, i.e. operate on the same logical level, and neither can claim any advantages, e.g. running directly in kernel space and thus saving context switches. Of course, I realise that there are more important issues and that such a complex protocol does not port itself. But would it be a far-future option to adopt the istgt implementation in NetBSD-base?

Anyway, another knowledge gap closed and a piece of the puzzle placed. Very cool: my continuously running NUC-based energy-saving server replicates its ZVOLs (Qemu backing stores) to my occasionally running (not quite as economical) NAS with RAIDZ2. With iSCSI, I can now boot the replicas exported from the NAS directly to my laptop for diagnostic or recovery purposes if needed. If you know the stumbling blocks, NetBSD/ZFS/NVMM can be used to create a virtualisation platform that is quite suitable for small enterprise usage. I think it's about time that I write an article for the NetBSD Wiki :)

Thanks again, and kind regards
Matthias


Home | Main Index | Thread Index | Old Index