jonp

The pass through method you quoted me on is for passing through an entire controller, not just an individual interface. For passing through an interface, see this in the libvirt documentation.

VMs and Docker are key features of the software and most users will want to at least try them out if the hardware supports it. Setting up those shares makes this process easier for those folks. Leaving the services on by default increases that simplicity. If we don't, this puts more onus on the user to have to manually generate them and create settings for them within VM Manager and Docker Manager. If you don't want those shares because you are not using those features, just delete them and they won't regenerate unless you once again enable those services. Also, the domains and system shares are set to NOT export over the network (SMB, AFP, or NFS) by default, so they shouldn't add any clutter to that usage

There has to be a step missing or something else as I do the exact same thing and the option to increase the resolution is available under display properties. Sent from my SM-G930P using Tapatalk

You need to install the graphics driver for the display adapter. Open device manager, look for the display adapter (should say Microsoft Basic Display Adapter). Right click it and select update driver. Point it to the qxl folder on your Virtio ISO disk and let 'er rip! Sent from my SM-G930P using Tapatalk

I just enabled some control options around forum signatures. The fact of the matter is that we do need to be somewhat strict on this to prevent users from creating signatures that are too large to display. As such, the following policy has been put in place for forum signatures: Users are allowed to have up to 1 image in their forum signature. The max size allowed for this image is 475 x 100 px. Signatures are allowed to go up to 5 lines of text, no more. These policies apply to all users in the forum except for Administrators and Moderators (for the time being). Thanks!

You can pass through block devices to guest VMs without using iSCSI. In fact, its super easy to do. First, login via SSH or Telnet and type this command: v /dev/disk/by-id Locate the disk you wish to pass through and copy its name. Now go create your VM and under vDisk location, select "Manual" and in the path field, type /dev/disk/by-id/ and then paste in the name of the disk you wish to pass through. You can optionally include the partition so if you want, you can have one disk with 3 partitions and pass through different partitions to different VMs if you want. What does iSCSI gain you over this method?

Only when passing through a GPU, but yes, this should be noted. Also add that ballooning is not available whenever you pass through a PCI device to a virtual machine. Those VMs will always fully allocate the max amount of memory assigned.

Yes, we did get your e-mail. No, we don't have any updates yet.

We have plans to incorporate QEMU 2.7 into the next release of unRAID.

See here: https://wiki.unraid.net/Manual/Changing_The_Flash_Device

If the VM is stored on a BTRFS-formatted device, you can use the cp command to create reflink copies which are essentially the best of snapshots and clones in a single method: cp --reflink /path/to/vdisk.img /path/to/snapshotorclone.img The only catch is that both the source and destination file must exist in the same BTRFS volume. This can be inside a btrfs pool or a single btrfs device. An example of an INVALID use of the command: cp --reflink /mnt/disk1/domains/domain1/domain1.img /mnt/disk2/domains/domain2/domain2.img This won't work even if both disk1 and disk2 are btrfs because they will be separate volumes. Also, you cannot use this command through the user share file system (/mnt/user). Instead, always path through the device itself (e.g. /mnt/disk or /mnt/cache).

Based on QEMU's track history, 2.7 should be out sometime in August. We have every intention of continuing to maintain support for QEMU/KVM in unRAID, but know that in addition to QEMU needing to support this, libvirt will as well. There will likely be a small time-gap between when QEMU 2.7 is released and when libvirt support for IGD assignment will be there. The bottom line here is that we definitely want to support this as a feature in unRAID when it's available and ready for prime time.

Just an FYI guys, I think your container is broken. I tried updating this today for a customer and the container starts, tries to update the app, then fails. This is one of the reasons I'm not a big fan of containers that auto-update the app as part of their startup process. Here's a copy of the container log:

So did you already test it with the PhAzE plugin mentioned in the link I gave above? I can well remember the bad old days of v5 when syslogs were full of plugins installing one version of something, then another plugin comes in and deletes all that so it can install a different version. Nope. Don't care about plugin to plugin compat. Just that it works on 6.1.

I'm going to move this to the 6.1 Verified forum, but please send me a PM if anyone discovers an incompatibility that I haven't yet.

Tom requested that I post the below message here as johnodon's e-mail address doesn't appear to be working (the one associated with the forum account):

Couldn't have said it better myself.

Its only because you have been saying 6.2 is soon™ and whenever people have issues that 6.2 fixes those issues, since November. We've fixed quite a few issues with incremental 6.1 releases too, just an FYI. Regardless, we are in the final stretch now.

I thought it was dogs bollocks?

Interesting, but doesn't change our recommendations. When Linus did the gaming + NAS video (not 2 gamers or 7), he had a skylake system and the ACS override didn't work for him. Luck of the draw on the hardware I guess. Certainly doesn't change anything with respect to igd pass through support. So, Jon, any comments on when us, the great unwashed, will be able to have a play with this..... Eric sent this to us last night suggesting this is the current feel from the community about 6.2: Yes, we know everyone is excited ;-) I have been going through final upgrade testing this past week to make sure folks won't have any rude surprises and this weekend will be spent writing up upgrade instructions. That's a pretty good sign that we are close.

Interesting, but doesn't change our recommendations. When Linus did the gaming + NAS video (not 2 gamers or 7), he had a skylake system and the ACS override didn't work for him. Luck of the draw on the hardware I guess. Certainly doesn't change anything with respect to igd pass through support.

Type lspci -k and report back what driver is assigned.

It should be no different than in a physical environment, but again, limited testing. To be perfectly honest, the way I had to test this was to use our OpenELEC VM. I took the XML from that VM and ran it through a parser that libvirt provides to convert it to a QEMU command string, then I just modified the command string to pass it the additional items needed for IGD pass through and fired it up (no KB/mouse assigned yet). The monitor lit up with OE running on it and that was good enough for me to say "test successful."

Hi all, It's been a while since I chimed in on this topic and given some recent updates / patches from the QEMU team and some testing I've been performing, I thought it was about time I provide an update. Background Many Intel CPUs feature support for an on-die GPU. We refer to this as an Intel IGD (Integrated Graphics Device). This essentially means being able to supply and power graphics for a system without needing a discrete GPU (either soldered onto the chipset like with many AMD systems and their Radeon graphics chips or as a PCIe device). However, up and through this point, unRAID has not supported assigning that GPU to a virtual machine in the same way we support it for PCIe add-on GPUs such as AMD and NVIDIA. However, that will be changing in the future. Why is IGD pass through to VMs important? While discrete GPUs can provide a powerful performance boost to 3D applications (making them ideal for gaming), they do require an additional investment above and beyond the CPU/motherboard, increase the demand for power, generate more heat, and require you to supply an enclosure (case) that is large enough to house it effectively. If all you want is a VM with a local desktop for basic 2D applications (office / productivity / browser), an IGD has more than enough horsepower to satisfy those tasks. A powerful use-case could be to build a small 4-bay NAS for the living room that has a CPU with both an IGD and Intel VT-d support. This small form-factor system could be placed in the living room and a video connection could be made from the IGD directly to the main TV, while also using the NAS for streaming media to other devices over the LAN. The VMs that system could run would include both OpenELEC (for playing media) and SteamOS (for streaming games from another PC). Why doesn't IGD pass through work today? In short, IGDs are not like your atypical discrete GPU. They behave very differently and therefore require a lot of special coding to pass them through to VMs. Are there any efforts to support IGD pass through to VMs? There is an entire project dedicated towards the use of IGDs with virtual machines: Intel GVT. This project is hard at work to bring multiple benefits to users. From the projects dedicated site: You can read more about the project on it's official site: https://01.org/igvt-g What hardware will be supported? Initial support will be for Intel Haswell and Broadwell CPUs only. But wait, what about my shiny new Skylake?! Sorry but no, it doesn't appear that there are any plans to support Skylake at this time, but that may change in the future. Note that Skylake CPUs are not recommended for VMs with GPU pass through (harder to isolate the IOMMU groups; no support for the ACS override). What about my Ivy-Bridge or <INSERT OLDER CPU HERE>? Nope. What is the current status of IGD pass through? Back in December, a patch was released for QEMU to add support for passing through Intel IGDs to virtual machines. This patch has yet to be merged in the stable branch for QEMU, but we at Lime Tech built a special version of QEMU to include this patch and tested it ourselves. In short...[glow=red,2,300]it works[/glow]. However, it is not yet ready for prime time inclusion with unRAID. First and foremost, there is no libvirt support for this at all yet, which means to do it we have to invoke QEMU manually, which is a huge problem from a manageability standpoint. We also need to thoroughly test this (with various hardware and VM configurations). And lastly, we need to do the logic coding on VM manager to then make it as simple as just allowing folks to select the IGD from the graphics device list when adding/editing a VM. So??? When??? Supporting IGD pass through to VMs should be an achievable objective for us in 2016. I will be able to narrow down that time-line sometime in the next 1-2 months as that will be the earliest we will be able to dedicate significant R&D time towards this item.

The current release of unRAID is still using docker 1.7.1 which doesn't have compose. This will be rectified in 6.2, but we are not adding compose to the UI yet, though other UIs could probably connect to the service and of course there is always command line.