sparkysplace

Thats exactly what I'm wondering. Right now I have the UPS plugged (usb) in to the host without passing it through to unRAID. There are various options that will gracefully shutdown VMs and the ESXI host in the event of a power outage, and I assume "graceful shutdown" that means "send power-off signal to VM and hope it handles it right". I don't know if unRAID handles a power-off signal properly (stop array, shutdown). The other option is to passthrough the UPS to unRAID, let it shutdown, and deal with any host corruption from a unclean shutdown. My data on unRAID is much more important to me than the host.

Hi All, quick question. I notice there is a plugin Open VM Tools for unRAID that hasn't been updated for 6.2. I'm curious if I should, for the sake of data integrity, passthrough the UPS directly to unRAID, or will ESXI magically powerdown the VM gracefully? Thanks!

Hi All, I haven't see any posts in regards to using SPICE in 6.2.0-rc, but thought I'd share my experience for others looking to use SPICE (which, by the way, is incredibly slick). Unfortunately, it seems like SPICE support isn't included in the WebGUI yet, so it does require a bit of manual intervention with the XML file. NOTE: This example does NOT implement any security features whatsoever. If you don't want your VMs to be open to everyone, read up a little about implementing TLS or SSL. Step 1: Create your VM as you normally would, have it set for VNC. Step 2: Add the SPICE <graphics> section (overwrite any existing <graphics> section) <graphics type='spice' port='20001' autoport='no' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> Step 3: Add the SPICE Audio section (slot 0x06 is an unused address in my config, adjust as necessary so it isn't a duplicate). SPICE will pass audio from VM to guest. <sound model='ac97'> <alias name='sound0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </sound> Step 4: Add the QXL video section if it doesn't already exist <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> And voila! You should be able to use something like virt-viewer on a Windows PC to access your VM GUI along with passthrough audio. This is very basic configuration, there are tons of other options that may or may not work yet such as guest additions (copy/paste, folder sharing, USB redirection, etc). Obviously this is a sort of workaround until the unRAID team officially slots in SPICE support - though including SPICE in the builds is a step in the right direction (I'm not a VNC fan).

Hi All, question for those using VMs to host whatever HTPC software (I use openelec). Now that I have it working perfectly on my unraid server, I'm trying to figure out what is the best way to transmit IR and HDMI over about 50'. I've seen HDBaseT and HDMI Extenders, and can't really decide on a cost effective solution, so I'd be interested in hearing what the other folks are using. 4K support would be cool for futureproofing, but not necessary. I've been eyeballing this from Monoprice: http://www.monoprice.com/product?c_id=109&cp_id=10110&cs_id=1011012&p_id=15521&seq=1&format=2 (PS: Sorry if this is in the wrong forum, mods feel free to move if need be) Thanks! Sparky

To expand on this further for those that may have the same problem, there is an easy way to check. Use lspci to find the ID of your device Use lspci again to see the details: If it says "MSI: Enable-" like mine did before using bungee91's fix, and you have that weird audio, that is probably what your problem is.

You, my friend, are a genius. This worked perfectly. It's funny, after hours of google searching I came across a devel bug tracker that talked about the MSI setting, and noticed mine was off. Next step was to figure out how to force it on. You saved me another few hours of google searching. Thanks!!

Hi Everyone, I'm really at a loss here. Using unraid 6.2.0-rc1, I've attempted to use the LibreELEC/OpenELEC pre-packaged VMs (both do the exact same thing) and I have a Zotac GT730 connected via HDMI to a Samsung TV. The NVIDIA Graphics controller AND NVIDIA Audio device are both passed through. Once Libre/Open boots, and I go into sound settings and pick HDMI 1 (identified by SAMSUNG in Kodi) and return to the menu I immediately get indefinite clicking sounds (much like if you were to hold down an arrow key and continually scroll through the main menu). Oddly enough, if I kill kodi and use speaker-test, I get the expected static out of the L&R speakers. If I use aplay to play a wav file to the same hw port, I get no sound. I've even connected the HDMI cable direct to a different TV to rule that out, with the same result. To make things interesting (and to rule out other possibilities), I installed xubuntu 16.04 using the generic "Linux" template and sound works perfectly both in the OS and Kodi. The only thing that is different is that xubuntu uses pulseaudio, but I'm not overly familiar with pulse, so I'm not sure what relationship that has with alsa. Finally, I also passed through the AMD igpu and associated audio device instead of the nvidia card, and get the exact same result, which leads me to believe it is a VM issue not a Open/Libreelec issue. If anyone has any suggestions, that would be awesome. Here are my specs and logs: Hardware Info 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Root Complex [1022:1422] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) I/O Memory Management Unit [1022:1423] 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:1313] 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri HDMI/DP Audio Controller [1002:1308] 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1424] 00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:1425] 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1424] 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Root Port [1022:1426] 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1424] 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7814] (rev 09) 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7814] (rev 09) 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7801] (rev 40) 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 11) 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 11) 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 11) 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 11) 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] (rev 16) 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller [1022:780d] (rev 01) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:780e] (rev 11) 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge [1022:780f] (rev 40) 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7809] (rev 11) 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Function 0 [1022:141a] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Function 1 [1022:141b] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Function 2 [1022:141c] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Function 3 [1022:141d] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Function 4 [1022:141e] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Function 5 [1022:141f] 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208 [GeForce GT 730] [10de:1287] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation GK208 HDMI/DP Audio Controller [10de:0e0f] (rev a1) 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06) lspci on VM: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:07.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 01:01.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge 02:01.0 Unclassified device [0002]: Red Hat, Inc Virtio filesystem 02:02.0 Ethernet controller: Red Hat, Inc Virtio network device 02:04.0 SCSI storage controller: Red Hat, Inc Virtio block device 02:05.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1) 02:06.0 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) 02:07.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon aplay -l on vm: **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 0/1 Subdevice #0: subdevice #0 VM xml: <domain type='kvm' id='28'> <name>LibreELEC</name> <uuid>155ce985-0987-ed1c-9045-26e1c29ed71a</uuid> <metadata> <vmtemplate xmlns="unraid" name="LibreELEC" icon="libreelec.png" libreelec="7.0.1_1"/> </metadata> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>1</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/155ce985-0987-ed1c-9045-26e1c29ed71a_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='1' threads='1'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/appdata/vms/LibreELEC/LibreELEC-unRAID.x86_64-7.0.1_1.img'/> <backingStore/> <target dev='hdc' bus='virtio'/> <readonly/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='sata' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <model name='i82801b11-bridge'/> <alias name='pci.1'/> <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'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <filesystem type='mount' accessmode='passthrough'> <source dir='/mnt/cache/appdata/LibreELEC/'/> <target dir='appconfig'/> <alias name='fs0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </filesystem> <interface type='bridge'> <mac address='52:54:00:ee:46:88'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </interface> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x04f2'/> <product id='0x0963'/> <address bus='4' device='2'/> </source> <alias name='hostdev2'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x07' function='0x0'/> </memballoon> </devices> </domain>

You beat me to it We learned this when working up the VMBackup script a few months back. Thanks for that, it never even crossed my mind - I use rsync every day at work, and the z flag is one of those muscle memory things. So, now I'm floating between 2.5MB/s and 70MB/s. Files are finishing on average around 15MB/s. So a little faster, but parity is still the bottleneck. I'd still love to disable parity as my 3TB drives are next and I don't want to wait 30 hours for these to finish copying.

I'm actually doing this now, bouncing stuff around and converting each disk to xfs. The thing thats killing me is the damn parity (well, I'm assuming it's parity). I'm using 'rsync --progress -avzh /dev/disk1 /dev/disk4' and it bounces anywhere between 2.5MB/s and 20MB/s. It is quite erratic. Anyway, the data isn't mission critical, but I do want to avoid restoring from backups and I want to avoid thrashing the parity drive. Does anyone have any suggestions on temporarily disabling/removing parity so I can get the moves done then rebuild parity once complete?

I've experienced this before (I use Chrome) and I think I narrowed it down to large cookies. Easy test, run any docker that generates large cookies (say LazyLibrarian) and access it in your browser, then try to access the unraid interface. You'll find those "input line too long" errors in syslog. Clear your cookies, access the unraid interface again, and it magically works.

Just curious, but why isn't anyone talking about ext4?

Confirmed. Yeah, lazylibrarian is based on Headphones, and there are previous unraid forum posts related to headphones causing this same issue. It just so happens I never noticed it when all my stuff was in a VM because of the different IPs. Because all the containers share the hosts IP, all the cookies get lumped together.

I segfaulted emhttp somehow, probably out of memory (I was creating a share, copying data through smb, installing a docker app at the same time. No syslog for this, I'll try to recreate). This threw me off. After rebooting, I kept getting that error. Anyway, I rebooted again, saw emhttp running, and tried accessing as I normally do in Chrome. Same error. Tried accessing it in Opera, and it worked. For some reason, Chrome on my PC is causing this error even though it worked not 20 minutes ago. Sorry for the false alarm. Edit: I guess the problem with a huge cookie LazyLibrarian created. Odd.

After adding my 7th docker app and adding a new share, I lost emhttp. I was adding a docker app though the GUI (a lazylibrarian repo), it started fine, I created a new share, then emhttp died shortly after. All my docker containers were working normally. Shutdown, restarted, no effect. Shutdown again, pulled the usb stick and checked for errors, no problem, still no emhttp. First reboot: Sep 1 19:58:52 Media kernel: br0: port 1(eth0) entered forwarding state Sep 1 19:59:04 Media emhttp: read_line: read_line: input line too long Sep 1 19:59:16 Media last message repeated 27 times Sep 1 19:59:20 Media in.telnetd[1483]: connect from 192.168.1.5 (192.168.1.5) Sep 1 19:59:22 Media login[1484]: ROOT LOGIN on '/dev/pts/0' from 'my-pc' Sep 1 20:00:03 Media emhttp: read_line: read_line: input line too long Sep 1 20:00:45 Media last message repeated 3 times Sep 1 20:00:47 Media last message repeated 11 times Sep 1 20:03:06 PookieMedia kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Second reboot: Sep 1 20:15:07 Media avahi-daemon[1490]: Service "Media" (/etc/avahi/services/ssh.service) successfully established. Sep 1 20:15:07 Media avahi-daemon[1490]: Service "Media" (/etc/avahi/services/smb.service) successfully established. Sep 1 20:15:07 Media avahi-daemon[1490]: Service "Media" (/etc/avahi/services/sftp-ssh.service) successfully established. Sep 1 20:15:21 Media kernel: br0: port 1(eth0) entered learning state Sep 1 20:15:36 Media kernel: br0: topology change detected, propagating Sep 1 20:15:36 Media kernel: br0: port 1(eth0) entered forwarding state Sep 1 20:16:06 Media emhttp: read_line: read_line: input line too long Sep 1 20:16:10 Media last message repeated 9 times

Fantastic explanation, I get it now. Thanks!