1812

For me, the updater only places the new files on the mac partition, not the EFI (even when loaded, the installer never gives me the option of selecting the mounted EFI disk.) So if you don't move the files manually to it, then it doesn't stick because it doesn't actually update. And when I do move them manually, it craps out after the boot options screen. I think a @gridrunner video about this would be most excellent. My guess is that it has something to do with needing a patched version of clover, as all the other ones used to run the vm are patched. And I don't know what occurs in the patch, so maybe that info could also be included.

I'm not using web drivers so i did the following update clover via clover configurator rebooted to verify clover update---- no joy after boot menu side question: is the "combo" different than updating via the app store? (it downloaded in about 2-3 minutes for me.)

If you can post the right procedure for updating I would appreciate it! Evidently I "thought" I was doing it right....

I'm making another clone, will also update it, and then try upgrading as well. It's not like this is a race or anything..... GO! ---- actually, you win. I was updating clover, broke it, then a project came up....

of course not!

without adjusting anything, a clone of one of my vm's is now stuck in a boot loop after clover screen exits. This is while passing a gt 730. after removing the gt 730, boot progresses to kernel panic, then reboot. good thing it was a clone.

updating one of mine currently, we'll see what happens. in the mean time, some reading:

Cheap PNY

a place to start: https://lime-technology.com/replace-key/ so, make a backup, move key registration over, back in business. I have 7-10 year old usb drives that are still (slowly) going strong. I have 2 year old ssd's that are in the trash can.

i'm curious! can you do some benchmarking and let us know? I'm hoping in the future to move to a 80 thread machine.... muahahahaha.....

Updating this as the issue has come up 3 times in 2 days recently, including on another of my servers after updating from 2010 firmware to 2015 firmware. According to HP, the RMRR problem stems from an upgrade to Linux above kernel version 3.16. There are discussions around the internet about an unofficial path but with varying results. HP has a published sheet on this, with a fix for some: https://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=7271259&docId=emr_na-c04781229&docLocale=en_US The steps outlined above solves the problem that occurs when part of the GPU (specifically the audio component) becomes marked ineligible. The resolution above splits the video and audio components into 2 iommu groups, and then does not attempt to passthrough the ineligible component.The workaround for me to getting sound back was to use a USB audio device. It may also work with a pci sound card or other pci audio device. So this topic should more appropriately be marked "solved" vs solved, as the underlying issue still remains. For those of you on newer (G8+) hardware, there is a bios fix: https://docs.hpcloud.com/hos-4.x/helion/networking/enabling_pcipt_on_gen9.html For those of you on older hp hardware, you can try going into bios and booting with the backup rom/earliest firmware you have.

my fault, I should have reminded poster to not leave it in xml.

where is the vm image located? cache or array? what type of disk? post your xml

You are moving the vm/host functions off the cores being utilized for the vm, so you are allowing more processing power to be dedicated to the vm, regardless of the os. But, i've found that when benchmarking with and without an emulator pin on a vm with many cores, there is only a very small difference in performance. My suspicion is that when you have 1-3 cores that are being pushed to full utilization, or on a host with low cpu power, that is when you'll find the most benefit.

that happen on mine every once in a while if i leave a tab open.

typically you should run each test a minimum of three times to find the average. your system could have been doing something in the background at any time causing a variance. Your first and last tests are within 3% of each other and both using all the cores. VM performance is more than just a raw benchmark score. On one of my transcoding cluster servers, I usually give it all processor cores since the entire server is only doing 1 task assigned remotely. This does not take into account any audio/video latency that could occur because I don't never use those interfaces. CPU pinnings are typically done to improve the ability to run multiple instances of something, be it vm's, dockers, etc... And find a balance that works to be able to do all at the same time. So it's not surprising that your tests showing all cores being used are similar in speed. Additionally, your numbers will be different depending on what you have running in the background. If you have a docker or two trying to use 30% of 2 cores, vs 30% of 4 cores, you vm will have a noticeable difference in your benchmark scores.

that's good! sometimes vfio works, sometimes using pcie acs override after specifying device id' works... I'm sure there is a technical reason between the two, but I don't remember it off the top of my head?

your core assignments look soooo wonky, which is fine because windows 10 doesn't care about where the cores come from (as shown through benchmarking tests) or even using threaded pairs. If you're using all the cores, there is no need to really specify an emulator pin. There might be a super small gain? But if you want to, make it 2 or 3

It's is probably complaining because you're trying to only pass through 1 device from the group when allowing unsafe interrupts (which i won't allow,) and conversely not allowing unsafe interrupts when only passing the single devices which isn't working because you are not using the correct device id's from your specific cards. Try this in your syslinux.cfg: append vfio-pci.ids=XXXX:XXXX,YYYY:YYYY vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot XXXX:XXXX is your video card id YYYY:YYYY is your sound card id you can obtain your video/sound card id's by going to tools>system devices, and look under pci device for 09:00.0 and 09.00.1 the device id will be at the end of he description in the brackets. replace the X's and Y's above with those numbers, reboot, and try again. If it doesn't work, then post your server diagnostics and xml for the vm.

Yes. Just because a cpu is isolated/not isolated from unRaid doesn't keep it from being assigned to a vm. If you do that, my suggestion would be to ensure that vcpu 0 of the vm is an isolated core, as windows and most other operating systems will use that as a primary resource and favor it, especially during initial booting of the vm. If you did not change it, then the vm and unraid would try to use that as primary, resealing in decreased performance. Also note that using the shared cores (non isolated) may contribute to latency, diminishing he point of isolating cores.

I don't use those, so you'll have to try and see. nope.

if you want to run your vm on those threads and want to increase performance and decrease latency, yes. you only need 1 cpu for emulator pin, use just cpu 2 Yes and no. Yes if you are doing tasks which require more cpu power, like transcoding via plex docker or heavy downloading/etc... No if you're only running a vm and network file transfers since you need less cpu resources for unRaid.

post fresh diagnostics since the old ones are... old... also post again what cores you have assigned where currently, since there has been movement.

72GB in the main server with a few vm's and plex/crashplan. Main VM used for video editing. 40GB in the backup server, which also has a few vm's/plex/crashplan. 12GB in the other 2 servers which only host a single vm.