lionelhutz

You're right. Install W10 directly and then record the key and uuid combo for future reference.

I think I tried changing that too and W10 stays activated. I've got the W7 to W10 upgrade pretty much nailed down. - Use the Microsoft tool to create a W10 iso. - Create a VM and install W7. Turn off automatic updates during the install. - Shut down the VM and change the install iso to the W10 iso. - Restart and run the W10 install. I've been picking to not keep anything. Once you have the VM created if you make note of the uuid you can delete it and then create a new one using the W10 install iso directly. When creating the VM uncheck the start after creation box and edit the xml after it's created. Paste in the uuid and then start the VM and do the W10 install.

I didn't really solve the issue but I have it working now. I could not find anything that would help so I bought a new Intel processor, ASRock motherboard and DDR4 ram and the driver now installs. So, something was off with the AMD parts not properly allowing Windows to access the video card. Maybe the bios has an issue. When testing I tried both W7 and W10 with both the onboard and Nvidia PCIe cards and it was the same issue with the video driver failing to install every time. I did a lot of searching and only found one case of a video driver failing to install and there was nothing useful in that thread that helped. For the most part, it seems there are usually issues getting the VM to boot up and use the hardware, not with drivers.

Nice, using the uuid is the key to keeping the activation. I screwed up my W10 install with a bad driver so I deleted it and created a new VM but copied the uuid from the old VM into the xml. The new W10 VM install came up activated. Dan - I would upgrade them all and record the uuid for each install. Then you can switch some back to W7 installs. In the future, to "upgrade" one of the W7 install to W10 you delete the W7 VM and create a new W10 VM using the same uuid. W10 activation is stored online keyed to the machine, so once the machine has been upgraded and registered at Microsoft you can switch it back and forth between W10 and any other OS as much as you want. A new install of W10 on the machine will be activated as soon as it goes online. In my test example above, the original W10 install was seabios and I used OVMF for the new install and it still activated fine. You can only change the bios by creating a new VM so it's not a huge concern. I have also tried changing the machine type and the number of cores and the activation has stuck so far.

I've been playing with W10 upgrades to see what happens. I've found it seems to activate only one the virtual disk that you are using. Microsoft says that W10 activiation is tied to hardware but the VM's don't seem to work right. I setup one activated W10 VM. Then I created a second identical VM but it would not activate. I can at least somewhat understand this one, but in theory the ID of both VM's should be the same. I setup an activated W10 VM and copied the virtual disk. I created a new VM using the copied virtual disk and when I started it that version of W10 was not activated. I'm not sure why this works since one was a copy of the other. So, I have this feeling that you can upgrade W7 to W10 but if you lose or damage the VM beyond repair you likely can't recreate it without buying W10.

Volume map to a server location where the file is stored and simply copy it inside the docker?

There is a sticky about pinning a specific core to a docker, but I think that is about it. They just use the ram they need.

It's a Gigabyte card.

361.43 said there is no compatible hardware. The next oldest 361.75 wouldn't install either.

I'll try those older drivers. I have no need for the DU utility since the VM typically gets messed up and starts blue screening so I start with a clean install each time I try something new. The card should have been stupidly easy to use. I just can't understand why the VM's work fine but the drivers won't install. I've done a bunch of Google searching and can't find anyone else having this issue with a KVM VM. I've read a ton of things about crashing, not starting, IOMMU group and MSI but none of them seem to apply here. If the video driver you recommend doesn't work then I'm thinking new motherboard and CPU is the only thing left to try.

I tried a quite older version and it "wasn't compatible". I did try the GT710 in another PC and it worked fine there so I have no reason to think the card is bad.

I've been trying to setup a Windows VM for the last few days. It works fine EXCEPT the video/audio drivers will not install. The display will flicker and then the VM either crashes and reboots or crashes and is broken and refuses to boot. My hardware is a F2A88XM-D3H & A8-7600. I tried it with the AMD video and I also added a GT710 video card. Still, it's always the same thing. Works fine except for the damn display driver. Since I NEVER get past the display driver install the audio driver never installs either. I've tried a whole bunch of combinations of these... W7 W10 Seabios OVMF Passing through the CPU Emulating the CPU PCIe ACS Override ON and OFF I even tried adding "vfio_iommu_type1.allow_unsafe_interrupts=1" to syslinux since that seemed to be a popular thing to do even though I didn't expect it to help... I've also tried OpenELEC. It works great on the GPU. It worked on the GT710 but the audio stuttered badly. I only tried it with the PCIe ACS Override OFF and think it should have been ON since there are other PCI devices in the same group as the GT710. Here is my XML from the last W10 attempt. <domain type='kvm'> <name>Win10</name> <uuid>a2a4feb9-6201-cad6-920d-fc1eb02e0a2a</uuid> <metadata> <vmtemplate name="Custom" icon="windows.png" os="windows"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>1</vcpu> <cputune> <vcpupin vcpu='0' cpuset='3'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> <loader type='pflash'>/usr/share/qemu/ovmf-x64/OVMF-pure-efi.fd</loader> </os> <features> <acpi/> <apic/> </features> <cpu> <topology sockets='1' cores='1' threads='1'/> </cpu> <clock offset='localtime'> <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/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/Images/Win10/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='mnt/cache/ISO/Windows10.iso'/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='mnt/cache/ISO/virtio-win-0.1.109.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:f3:96:a1'/> <source bridge='virbr0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/Win10.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' 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> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x0c16'/> <product id='0x0002'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </memballoon> </devices> </domain> Can anyone help with a suggestion that might work?

If BTRFS is working without any issues then stick with it. Some people have had issues with BTRFS corruption so just keep an eye on it and run scrub every now and then until you know it's good.

If you're happy with performance then don't bother. I'm not. Over the years people have recovered from really serious "oops" on their ReiserFS formatted drives so it's still a good file system overall.

Could you install pear as part of this Docker?

It will; 1 - fill disk4 until 750gig is free 2 - fill disk5 until 750gig is free 3 - fill disk4 until 375gig is free 4 - fill disk5 until 375gig is free etc, etc. Since disk5 is already under the 750gig mark it will skip step 2 and go right to step 3. Disk4 will keep getting used until it's under 375gig of free space. With mismatched sizes the larger disks get used more though the first few iterations of high water. The larger the mismatch the more cycles of larger disks getting used first.

If your hot swap bays use drawers then check them because some have the screws for a SSD. Mine didn't so I drilled the required holes and it works good.

Use the notifications to tag the threads. In the profile on the left there is a notifications you can click to see the list.

Double check your global share settings to ensure you're not excluding the disks by mistake. Also make sure you share includes the disks. Why bother re-arranging data?

I added a couple of 240gig Kingston SSD's into my system as a BTRFS cache array just over a month ago and so far they have been working well. It was just time to upgrade my cache drive since it was an old WD drive. As I have posted before, test your BTRFS drives to ensure they are stable. BTRFS does work for many people but it does causes issues for others. Overall, I doubt I'd try BTRFS for the array drives but in a RAID1 configuration it should be good. I do agree that ReiserFS is a very robust filesystem despite it typically being shunned. It really was ahead of it's time, but the developers personal situation basically killed it as an acceptable filesystem.

I've used usenetserver for 4 or 5 years now. I buy their $96/year package. I have had pretty good luck indexing the popular groups myself with Newznab. I'm probably not a huge user compared to some people. At peak times I'm downloading up to 30 shows a week or averaging around 150GB a month. I index and grab and download as fast as possible to ensure I get it before the inevitable takedown occurs. The only issue I have is the indexing not indexing the show and even that is fairly rare. I haven't had a failed download in many months. But I don't even try to download any old items. I use SickBeard. I tried Sonarr and when I tried to test it I had the setup wrong and the blacklisting kept me from testing it again so I booted it. Sickbeard just plain works for me and the only advantage of Sonarr I could see is the prettier interface which I could really care less about. I would be interested in what usenet servers don't takedown the older shows??

Yes, the share is considered a directory or folder. 1 = the share can be on multiple disks but no directory below the share can be on multiple disks.

Unfortunately, over the years people have posted these 2 ways to count the split level. The first way is the official LimeTech way. Start numbering at the share = split level equals the last directory that can exist on multiple disks. Start numbering at the first directory into the share = split level equals the first directory that can ONLY exist on a single disk. The pictures are correct. Take level 3 for example. What the picture is saying is that the share (1), top level (2) and second level (3) can exist on multiple disks. However, the movie folder is only created on one disk which means all the movie files must exist on one disk. I'm not a big fan of the text descriptions in the newest unRAID versions. The first top level directory is the share, which isn't the clearest for some people. The levels in the new unRAID settings do not match those Simple Features drawings. Your splits look OK.

You keep talking Dockers running on Windows, not a Windows Docker. I'm not sure how you'd create a really small minimalistic Windows base OS for a Docker even if it was possible. Dockers run closer to the equivalent of Dos with some application packages installed.

You need to use a VM for Windows. Its not really that hard to install a Windows VM.