jwegman

...to answer my own question, the issue was resolved by changing the bridge interface's model type from 'vmxnet3' to 'e1000-82545em' (as Gridrunner uses in his example vm.xml): <interface type='bridge'> <mac address='52:54:00:51:66:48'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </interface> ...which Unraid resulted in altering the bridge interface element with the following (it automatically added the target dev, and alias): <interface type='bridge'> <mac address='52:54:00:51:66:48'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='e1000-82545em'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </interface>

Are people able to log into the App Store on a fresh/clean Sierra 10.12.6 vm? I've tried several VM creation attempts and they've all resulted in "Verification Failed. There was an error connecting to the Apple ID server". Upon finalizing the Fusion VM, I had verified that I could log in using a valid Apple ID into the App Store, however after converting to KVM and running it in unraid, I hit upon the above error. Here's my VM xml: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>Sierra_10.12.6</name> <uuid>190d9ca4-3e22-8b21-bcfe-eba9a9a53d31</uuid> <metadata> <vmtemplate xmlns="unraid" name="Ubuntu" icon="ubuntu.png" os="ubuntu"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='10'/> <vcpupin vcpu='1' cpuset='26'/> <vcpupin vcpu='2' cpuset='11'/> <vcpupin vcpu='3' cpuset='27'/> <vcpupin vcpu='4' cpuset='12'/> <vcpupin vcpu='5' cpuset='28'/> <vcpupin vcpu='6' cpuset='13'/> <vcpupin vcpu='7' cpuset='29'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-2.9'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/190d9ca4-3e22-8b21-bcfe-eba9a9a53d31_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/disks/OCZ_VERTEX460_A22BF061439003586/VM_Images/MacOS_Sierra_10.12.6/sierra_10.12.6_new.img'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='piix3-uhci'> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <model name='i82801b11-bridge'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:51:66:48'/> <source bridge='br0'/> <model type='vmxnet3'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x046d'/> <product id='0xc52b'/> <address bus='1' device='6'/> </source> <address type='usb' bus='0' port='1'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='none' model='none'/> <qemu:commandline> <qemu:arg value='-cpu'/> <qemu:arg value='Penryn,vendor=GenuineIntel'/> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=02:00.0,bus=pcie.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=02:00.1,bus=pcie.0'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=00:1d.0,bus=root.1,addr=00.0'/> </qemu:commandline> </domain>

LXC was always about containers (if you might recall, Docker sprouted from LXC). LXD switched to the image concept (vs LXC's tarball approach) and scrapped the various C and shell script user space tools for a REST based client (which confusingly is name lxc)... There are Public (and private) image servers from which you can share and pull an image (just like Docker). LXC, while they touted the idea of application containers, it was primarily focused on system containers (para-virtualized linux instances). With LXD, they are 100% focused on system containers and defer application containers to the likes of Docker. Heck, they tout hosting Docker within an LXD system container. Docker's application container approach is great for single use things like Plex, nzbget, and sickrage, etc... However it sucks if you need an instance that runs more than a single application such as a LAMP environment, where you don't want to orchestrate a spin up of each individual docker instance for each component. LXD is great if you need a linux instance that you can run your suite of daemons/applications without the overhead of HVM (hardware virtualized) QEMU/KVM. You can even 'pass-through' devices such as graphics/audio cards for a Desktop instance (although I have no experience with GPU passthrough on LXC/LXD). I would love to see the addition of LXD to Unraid for the linux vm use-case where you don't want the bloat or performance implications of HVM and the purpose of the VM is more sophisticated than a single use Docker instance.

If people are looking for options, here's an auction for the same Mellanox ConnextX 2 10GbE (with 3 meter DAC) in which the seller accepted Best Offer of $18/ea (I bought 4 a few weeks ago): 671798-001 666172-001 MNPA19-XTR HP 10GB ETHERNET NETWORK INTERFACE CARD W/CABLE http://www.ebay.com/itm/282041554175 ...which works well in Unraid 6.1.x+

Right on! Upon a cursory look, it's mounting remote NFS shares without apparent issue! ... Mar 11 17:26:36 Mount SMB/NFS command: mount -t nfs -o defaults 'nas1://mnt/user/Movies' '/mnt/disks/nas1_Movies' Mar 11 17:26:36 Successfully mounted 'nas1://mnt/user/Movies' on '/mnt/disks/nas1_Movies'. Mar 11 17:26:36 Defining share 'nas1_Movies' on file '/etc/samba/unassigned-shares/nas1_Movies.conf' Mar 11 17:26:36 Adding share 'nas1_Movies' to '/boot/config/smb-extra.conf' Mar 11 17:26:36 Reloading Samba configuration... Mar 11 17:26:36 Directory '/mnt/disks/nas1_Movies' shared successfully. Mar 11 17:26:36 Adding NFS share '/mnt/disks/nas1_Movies' to '/etc/exports'. Mar 11 17:26:36 Adding NFS share '/mnt/disks/nas1_Movies' to '/etc/exports-'. Mar 11 17:26:36 Device 'nas1://mnt/user/Movies' script file not found. 'ADD' script not executed. root@Tower:/var/log# exportfs /mnt/disks/nas1_Movies <world> A very large thank you for your efforts. This IMHO is an essential plugin. Regards, Jake

On the remote server sharing (exporting) the NFS volume: root@nas1:~# cat /etc/exports # See exports(5) for a description. # This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. "/mnt/user/Movies" -async,no_subtree_check,fsid=101 *(sec=sys,rw,insecure,anongid=100,anonuid=99,all_squash) And on the server that needs to mount the remote NFS volume, we'd use something like: root@Tower:~# mount -t nfs nas1:/mnt/user/Movies /mnt/disks/nas1_Movies/ Then verify: root@Tower:~# mount | grep nas1 nas1:/mnt/user/Movies on /mnt/disks/nas1_Movies type nfs (rw,addr=192.168.0.138)

I believe error code 111 is a connection refused. Authentication problem? Look at the UD log and you should see more information on why the remote NFS share is not mounting. If you take another look at those log snippets, it's trying to use CIFS to connect, not NFS. I do *not* have samba running on that remote server. That's the problem, whenever I create an NFS mount, UD uses SMB instead. That's the way it works. It mounts the remote NFS locally then shares it as an SMB and/or NFS share based on the UD settings. Please post a UD log or I can't help you. EDIT: Ok I think I get it. Your server with the NFS share is not sharing it as SMB. Yes, Here's the output generated when trying to Mount a Remote SMB/NFS Share using the NFS protocol - you see it's trying to mount it as cifs instead of NFS. Interesting observation is that after the remote share is added, it adds it as SMB regardless of having the NFS protocol selected when creating the share: Mar 08 17:40:32 Mount SMB command: mount -t cifs -o rw,nounix,iocharset=utf8,_netdev,file_mode=0777,dir_mode=0777,username=guest,password=******* '//nas1/Movies' '/mnt/disks/nas1_Movies' Mar 08 17:40:32 Mount of '//nas1/Movies' failed. Error message: Unable to find suitable address. Regards, Jake

I believe error code 111 is a connection refused. Authentication problem? Look at the UD log and you should see more information on why the remote NFS share is not mounting. If you take another look at those log snippets, it's trying to use CIFS to connect, not NFS. I do *not* have samba running on that remote server. That's the problem, whenever I create an NFS mount, UD uses SMB instead.

I''m having an issue with mounting remote NFS volumes; it keeps trying to mount as SMB and uses CIFS despite selecting the NFS protocol: Mar 7 17:23:07 Tower kernel: CIFS VFS: Error connecting to socket. Aborting operation. Mar 7 17:23:07 Tower kernel: CIFS VFS: cifs_mount failed w/return code = -111 Regards, Jake