@pax0707 i've just re-acquainted myself with "targetcli" - imma migrate all my VM-storage onto the NAS, and export it via #iSCSI!

#libvirt / virt-manager

I'll run my VMs on the big-ram daily-driver , but the storage lives on the #NAS, with all that #ZFS fancy

aye-skussi

@dalias @eniko Personally, I'll sooner or later have to engange the whole #ARMv5 / #ARM11r7 / #RaspberryPi architecture anyway with OS/1337.

• Tho given it's a minimalist Linux merely booting an initramfs and never doing any writes, there should be no indurance issues.

But I know a #readonly - OS isn't practical and where it is people already use #iPXE & #iSCSI for #diskless setups!

• THO AFAICT there should be an option to basically partition the system and only keep /boot on an SD card, and the rest could be on any USB mass storage device (i.e. SSD or even HDD)...

That being said Raspberry Pi do have the key advantage of being by far the best in terms of #documentation.

@http @Rob298 precisely that!

• Also most corp/org/edu networks only backup the $HOME directory and sometimes even allow syncing them across distros & keep them across version updates, so all the settings, addons and stuff remaib where they are: in said /home/ subfolders!

• In fact most places with a sizeable #Linux-#Desktop landscape will just keep the /home/ directory on a redundant, #iSCSI-SAN and #netboot their #DisklessWorkstation|s via #iPXE, as this way burglars stealing devices most likely end up with a locked-down machine (anything but booting the preset network targets won't work without admin password!) that is a paperweight to them and espechally no data, which is crucial when it comes to #ITsec, #InfoSec, #OpSec & #ComSec.

Cuz it's way easier to secure 1-5 server rooms than thousands of publicly accessible machines on multiple campuses.

• It's also a real godsent for technicians as they can just login / boot into a diagnostics system and quickly see what's wrong if a system has issues (if they don't already see it in their dashboard that collects logs, telling them they need to replace the CPU fan or clean a machine as it's overheating)...

@uastronomer it's something I.did implement in the past (abeit #KVM + #Proxmox, but the steps are similar enough):

You can seperate #Storage and #Compute given you have a Storage-LAN that is fast enough (and does at least 9k if not 64k Jumbo Frames) and have the "Compute Nodes" entirely #diskless (booting via #iPXE from the #SAN) and then mount the storage via #iSCSI or #Ceph.

• Basically it allows you to scale Compute and Storage independently from each other as they are transparent layers and not be confined to limits of a single chassis & it's I/O options...

Did a bigger project (easily 8-digits in hardware, as per MSRP) where a Employer/Client did #CloudExit amidst escalating costs and #ROI being within quarters (if not months at the predicted growth rate)...

@uastronomer now if you seperate the compute and storage layer with diskless compute nodes accessing the filesystem via #iSCSI or #Ceph, you can even do superfast updates by merely rebooting the jail/host...

@SweetAIBelle @OS1337
So instead of relying on some non-#reproduceable system images for cheap SBCs, why not make something like #OS1337 that is compact enough that one can easily build everything one wants for it to get at least started with something.

• After all, rarely does a project call for a fancy, hardware-accelerated GUI desktop with a Cube-Style animated Virtual Desktop switcher.

Sometimes one just needs to bood a system, check it's hardware and #ddrescue something off the internal harddrive because one doesn't have any other system that can run it...

• Or have something to #netboot into as a #RescueSystem because #DisklessWorkstations and #DisklessServers are a thing espechally in big hosting envoirments where everything is done in seperately scalable layers and abstracted to APIs and Oroticols like #iSCSI...https://github.com/OS-1337/netboot

@xssfox I mean, why shouldn't #iSCSI prevent you from tunneling any #SCSI hardware?

@melissabeartrix then consider #iSCSI or #FCoE (#FibreChannel over #Ethernet) over #OM5-fiber - based #100GBASE-SR1.2 as per 802.3bm-2015 Ethernet.

Just make shure your devices have #QSFP28 ports to chug' in the LC-Duplex connectors of the fibers...

https://en.wikipedia.org/wiki/100_Gigabit_Ethernet

WD barely won but I think I'm ignoring 3 of you anyway and going for Exos ​​ Now I'm deciding between:

5x Exos x16 20T (a single raid-z2 60G pool for bulk smb/nfs and iscsi and jails and..)
or
3x Exos x16 14T (raid-z1, 28T for #k3s iscsi PVs) plus 5 exos x14 10T (raid-z2, 30T for bulk file storage and db jails)

The difference between them is only about $10 and 2T loss of usable bulk space, but there might be an advantage to moving the #k3s cluster pvs and such away from the bulk nfs/samba archival storage.

I can't use the entire pool with iscsi because its huge and my clusters aren't, but in general it would be nice to have more variety in storage options. (Z2 vs Z1 depending on value/performance)

Please jump in and tell me why I'm wrong before I spend all of my money screwing up.

#truenas #k3s #k8s #iscsi #storage #homelab #snarkhome #sata #zfs #nas #spinningrust #seagate

@rodirik @Natanox I know, it just rarely makes sense to me...

But maybe I'm an old #Linux uers who's used to #NFS, #SMB & #iSCSI as well as #Ceph...

Tho TBH #SMB / #Samba is better in terms of #UX than #NFS and #iSCSI would be nice to have but then again being able to mount an #SFTP / #FTPS as a drive/folder under i.e. /media/$USER/ would be sufficient for expansion beyond the local storage...

@nixCraft You forgot #Ceph & #NFS as well as #GlusterFS but I guess those are less seen as #filesystems but protocols to provide data access like #SFTP, #FTP & #iSCSI...