• Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Baltostar

  • Rank


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Changed Status to Open Changed Priority to Annoyance
  2. Note: I have a workaround in place for this issue, so mostly calling it out here for awareness. Description: I have a share called 'dev'. After upgrading to 6.9.0-rc2, the share is no longer accessible from the network and isn't shown on the 'shares' tab. Troubleshooting: Downgraded to stable branch. Share became accessible. Upgraded to rc2 again, the share then disappeared again. Verified the drive path still exists so no data was lost. Tried adding 'dev' as a share while the share name is already on disk and got the following error: "Do not us
  3. The script I wrote was to detect and attach the vive components to the PC because of one key issue. I discovered that editing the xml and specifying the IDs will work but only as you don't change anything on your pc configuration. If you unplug any of the vive USBs and plug them back in, you will loose connection to your vive. The script is to attach the vive to the running VM without reboot. If you do reboot your VM, it will give a device error because the USB Vive is registered as a different ID when you plug it back in. Do you have time to test unplugging the Vive, rebooting the V
  4. I'm not sure if this is a bug or a feature request. When running with 'Ransomware Protection' configured to create file shares and files. That plugin creates files with same name but different camel casing. Duplicate files with different casing is something that 'Fix Common Problems' is designed to find. I want to exclude Fix Common Problems from searching my 'Ransomware Protection' created folders that have these incorrect casing issues are reporting on. I added the folders to the 'Permission Test/Fix Excluded On' section however they are still scanned for the same files with
  5. The best way to run the vive on a VM is by passing the USB controller. Some controllers still have issues. Even without running on a VM, there can be issues. I pass a USB 3.1 controller on my new ASUS x99 board and run my vive off that. I started this post when I didn't have such options with my older x99 ASRock board. If you pass a USB 2/3 controller though and you still have issues, then consider buying one of the PCIe USB 3.1 cards and passing that though. To be honest with you. It to
  6. My command: mapusb viveTempFolder '0bb4 0d8c 0424 28de' '1 GPU Middle WIN 10' Based on your post. These are the Vive devices: [b]Devices that normal passing the USB works fine because the ids are different.[/b] Bus 001 Device 002: ID 0bb4:2744 HTC (High Tech Computer Corp.) #Identified by row containing: 0bb4 Bus 001 Device 004: ID 0bb4:2134 HTC (High Tech Computer Corp.) #Identified by row containing: 0bb4 Bus 001 Device 005: ID 0bb4:0306 HTC (High Tech Computer Corp.) #Identified by row containing: 0bb4 Bus 001 Device 007: ID 0424:274d Standard Microsystems Corp. #Identified b
  7. -- Attached text copy of the script I was using when I last worked on this.
  8. When I started this guide, the script worked and I had success. The vive was very touchy. As soon as I started to do anything like update firmware or troubleshooting steps, everything went wrong. The Vive software tells the devices to disconnect or reboot because they physically become disconnected from the computer for a moment. When they come back, they are assigned new USB IDs and are not automatically connected back to that VM. I would have to run the script again to reattach the devices at that time. The short of that experiences is: Do not update firmware while doing USB passthough
  9. After the vive 'disconnects' it readdresses it self as a USB device. so it isn't virtually plugged in anymore. (Catching up on the thread, back from vacation)
  10. First slot pass though sometimes requires telling the video card to load a specified rom that you copied from the card before using a different slot. The video passthough is very touchy. I'm not an expert on the subject as this is my first go. Unraid reports my cards as follows and I have to pass both for the vm to see it. 09:00.0 VGA compatible controller: NVIDIA Corporation Device 17c8 (rev a1) 09:00.1 Audio device: NVIDIA Corporation Device 0fb0 (rev a1) _____ For anyone watching this thread. I had overheating issues and am switching to water cooling. The parts come in Septe
  11. PCI-USB I agree it is possible, but I have several reason why I don't want to do that, including how it would look. how is your core assignment for 4 VMs with 6 cores? 6 cores is 12 Virtual cores to assign due to hyper threading. I'm giving each VM 2-3 virtual cores. Unless the games are designed for multi threading, 2 cores are usually enough for games. I won't be doing multi tasking on the VMs. Each VM will be running only its game. I don't even have Virus scanners on them. (I redo the image every 30 days to keep them clean and I don't browse the internet). Does 1 single
  12. It is possible to run the vive though the VM without a dedicated usb controller. I'm running 4 GPUs without water block modifications. All 7 of my PCIe slots are used / covered. Unless I use a riser PCIe adapter, i won't be able to install a PCIe USB card. With that said, PCIe usb card passthough would defiantly work for the VIVE, but I wouldn't call it a requirement. I prefer being able to hot swap the VIVE between the running VMs. I will be doing a better write up on this for the guide. I made the script generic and posted it to show the concept of I'm doing.
  13. I'm working on a script for dynamic assigning of USB devices to running VMs for my post
  14. Migrating replies from my topic in wrong location. This sounds like exactly what is needed to help polish the USB handling of unraid's KVM management. So as not to duplicate work, I strongly suggest that you email limetech at their support address and point them to this post. I suspect they would be very supportive and possibly offer some suggestions so you don't reinvent the wheel if they already have some of this worked out for an upcoming release. This sounds like exactly what is needed to help polish the USB handling of unraid's KVM management. So as not to duplicate work