Hardware acceleration can be done using PCI passthrough to pass your graphics card on to the guest OS. IOMMU and VFIO are two terms I commonly see associated with this, but having never done it myself I am not sure what the difference between them is - perhaps someone can chime in?
VT-d = Virtualization Technology for Directed I/O
which basically means the CPU has an IOMMU, the IOMMU is a piece of hardware for doing PCIe DMA re-mapping to provide VM isolation. VFIO is the linux driver for passing through IOMMU devices.
AFAIK the only way to achieve this is to pass-through a GPU via VT-d. This config does not appear to support this though. If you search github for this line, you will find other configs that support doing this- https://github.com/kholia/OSX-KVM/blob/master/macOS-libvirt....
Edit: It's relatively easy- blacklist (or uninstall) GPU drivers from host machine, and pass the PCI address to qemu. Performance is not perceptibly different from native. Other things you probably want to do are enable hugepages, pin virtual cpus to physical cores, and use vfio for network- https://github.com/pmj/virtio-net-osx.
It's also possible to run boot OSX using UEFI mode, which removes the need for the binary blobs in this repo.
The script seems to use qemu's default VGA graphics chip. I'm not sure whether you can get anything faster to work, given Apple's limited graphics driver support.
And you can't easily switch between several virtualized machines like that. Windows will bluescreen if you remove a graphics card while in use, and I'm not sure OSX/Linux guests will fare better.
Passthrough only really works reliably if you only have one guest active at a time and never try to use the graphics card from the host.
VGA passthrough is also possible with KVM. I wonder if Oracle has any plans to add it to VirtualBox? It seems they have made room for KVM support, so in theory they could.
I have seen all OSX versions from Leopard to El Capitan successfully running as a VB guest, but the graphics support has always been bad, since there are no Guest Additions for OSX (BTW this also means no bidirectional clipboard, drag & drop of files, etc..)
Suprisingly OS X actually has decent support for a wide array of video cards out of the box, all of the AMD GCN 1.0 (7000 series and the R7/R9 2XXX rebrands of them) work out of the box as does the R9 290X/390X, along with a bunch of the older HD4000-HD6000 cards. NVidia provides native drivers for all their cards online, and if you're using an Intel GPU that was ever in a Mac it has support as well.
Of course, it's in violation of the macOS EULA to run it on non-Apple hardware in the first place, but you'd be surprised just how much hardware it supports.
Up to a point. There's Hardware Partitioning in which the hardware allows you to specify which processors or memory are dedicated to which OS but there's little dynamic sharing. The only real way to do dynamic resource sharing is with software virtualization (which does still require hardware features, but many platforms support this nowadays) where either the OSes run under a Hypervisor layer, or one OS runs in a virtual machine running as an application within another. Arguably the latter is just a variation on the former. Or vice versa depending who you ask.
So, what would be the best solution to run three (Fedora, Windows 8 or 10 and OSX or more) OS' under a common hypervisor and achieve (almost) full speed? Or alternatively, Fedora as main and the other ones as VMs, but also with (almost) full speed and graphics acceleration.
A KVM Hypervisor would be ideal, in my experience and opinion. Using the virtio drivers will give you great performance for virtualized devices like disks and NICs, and you can also directly attach devices and use PCI passthrough to achieve full-native performance for a device in the guest OS.
You're not going to get full speed, but it depends on what you want to be fast. Graphics intensive activities are going to be constrained by the specifics of the design you go for. Apart from that the biggest constraint is memory since every GB allocated to one OS will by definition not be available to the others. However CPU support for virtualization is pretty good these days. Most of the i7 and i5 CPUs have built in instructions to make it pretty efficient for processor tasks.
Personally I have a 2014 5K iMac i7 with a fusion drive. I have a Fedora VM on it I run occasionally. I run it using Virtualbox which is a free virtualization system. I've allocated 4 GB of memory and it's very performant. It's a great way to try out virtualization at home and you can run Virtualbox on Linux, OSX or Windows as the host OS.
Crap situation for me then since I need CPU, GPU, and RAM to the max for Video and 3D DCC apps.
Somehow, I thought there was this magical hypervisor that would give all to one OS that I could use and then, out of nowhere, I could switch to another OS in a way that first one would go to sleep and its memory put on hard drive and the other one would wake up its memory from hard drive and show up. I wouldn't need them running concurrently, but I would like to have them switch fast.
In a way I would like to consolidate three machines into one without having to run three machines or wait for shutdown/boot sequences (with multi boot).
Bonus would be to share disks (non boot ones) and copy and paste. That would be really great.
Of course. I run ESXi (bare metal hypervisor) with various Windows and Linux VMs running on it. One of the Windows VMs even has my GPU passed through to it and gets near-native gaming performance.
Non-Quadro NVIDIA cards don't want to work in a VM so you need to disguise KVM to get them to work. NVIDIA says this is a bug but I think they just want you to buy quadro cards. [1]
AMD Bonaire and Hawaii architecture cards have issues with resetting in a VM, so you can't let the VM go to sleep or shutdown. Newer (R9 480) or older AMD cards don't have this issue. [2]
Do you have a source that confirms that the 480 doesn't have this issue? I currently have a set of scripts that disable/enable my 380X automatically when my VM stops/starts and I would love to get rid of them (and get a new card as well).
I tried doing this the other day, hoping that I would finally be able to get a working OSX setup on my desktop (have made several attempts with no success at getting it working bare-metal on my Z600). Sadly it just ended with more kernel panics, something I was hoping would be avoided as I got the impression from some sources that QEMU was a more straightforward solution than trying to run it on bare-metal.
Having said that, I've been getting more and more frustrated with OSX (had a great experience with Leopard on a PowerBook G4, and my 2013 MacBook Air is easily the best laptop I've owned, however personally I don't care for the direction that they are taking OSX these days), and ended up using it as an excuse to update to the latest version of elementary OS, which certainly isn't without its teething problems.
That's a bit old. Modern Hackentoshes are actually pretty solid on consumer hardware. Z79/Z79, Z170 are pretty much fully supported. Some forum posters claim they've gotten dual 4th Xeon boards to work.
I set one up on my Z79+i7-4790k. It was a breeze. Took about 90minutes following tutorials. My biggest problems were:
-I set up the wrong sound driver
-Nvidia won't detect/modify hot plugging displays you have to manually edit OSX's version of xorg.conf
-Apple's Nvidia driver didn't support GSync or 144Hz. So I had to dealing with image tearing :\
-Non Apple keyboards had weird character mismatching. Had to purchase an Apple USB keyboard.
I ended up reverting because I like my IBM Model M, and losing hardware level vsync was a no-go.
-Some converters that support it, are disabled by the motherboard as the converter is exceeding spec.
but valarauca why don't you use an externally powered hub?
I've actually tired 4 different models, none have worked. I've just accepted that using a PS/2 plug on the motherboard is less of a head ache.
I do have a PS/2 -> USB converter that works, but only with 1 of my motherboards (a VIA). Except it knocks out the other USB port stacked above/below it. I don't plug anything into that port for the PS/2 -> USB converter, just that port will never recognize something is plugged into it. I think it is a power draw issue.
Unfortunately Karabiner is broken on Sierra; they are working on workarounds though.
--
macOS Sierra support status
Karabiner does not work on macOS Sierra at the moment.
We are developing Karabiner-Elements which provides simple key modification for macOS Sierra at first.
(Karabiner-Elements works on macOS Sierra except prefernces GUI.)
---
https://pqrs.org/osx/karabiner/
Unfortunately Karabiner is broken on Sierra; they are working on workarounds though.
--
macOS Sierra support status
Karabiner does not work on macOS Sierra at the moment.
We are developing Karabiner-Elements which provides simple key modification for macOS Sierra at first.
(Karabiner-Elements works on macOS Sierra except prefernces GUI.)
---
https://pqrs.org/osx/karabiner/
From the ARS review: "It’s not related to AES encryption acceleration, since there are Core 2 Duo and Core i3 CPUs in supported Macs that don’t support Intel’s AES-NI acceleration."
That is pretty impressive. I spent hours upon hours getting OS X to run on a Linux host in KVM and QEMU. Eventually I did get it to work, but things like Messages.app had no chance of working. That was actually my goal - to create my own little Messages API so that I could send automated messages to myself. I ended up just scripting Messages.app on a real Mac and that works really well, even 2 years after. I remote control my house that way.
In some ways, yes. On the other hand, free software is also everywhere.
Linux, Webkit/Blink/Firefox, Apache/nginx, LLVM/GCC, Emacs/Vim… it's a pretty big list.
Instant messaging and Pro Photo/Video apps are a particularly sore point.
I've installed an AppleScript handler from within Messages.app. The script below is called ReceiveMessage.script and is located in ~/Library/Application Scripts/com.apple.iChat and basically accepts messages. That's how I handle inbound messages, and for outbound I basically also have a separate script for sending out messages. I do the actual work in separate python scripts called by the shell scripts though.
-- snip snip --
using terms from application "Messages"
on message received theText from theBuddy for theChat
set quoted_message to quoted form of theText
set quoted_id to quoted form of (id of theBuddy as text)
do shell script "echo " & quoted_message & " | ~/bin/MessageReceive.sh " & quoted_id & " > /dev/null 2>&1 &"
# make messages happy
return true
end message received
on message sent theMessage for theChat
end message sent
on active chat message received
end active chat message received
on chat room message received theMessage from theBuddy for theChat
end chat room message received
on addressed chat room message received theMessage from theBuddy for theChat
end addressed chat room message received
on addressed message received theMessage from theBuddy for theChat
end addressed message received
on av chat started
end av chat started
on av chat ended
end av chat ended
on login finished for theService
end login finished
on logout finished for theService
end logout finished
on buddy became available theBuddy
end buddy became available
on buddy became unavailable theBuddy
end buddy became unavailable
on completed file transfer
end completed file transfer
I like the project, but I really don't like applescript. In programming languages, it seems there is a tension between easy-to-write and easy-to-read. And I suppose a fork in the continuum with easy-to-read-for-novices and easy-to-read-for-programmers.
applescript went overboard on the easy-to-read-for-novices at severe cost to easy-to-write.
What's hard to read about it? Obviously (to me), those are all event handlers. Not sure why (or if?) you have to define the ones that don't actually do anything, though.
I'm pretty sure he's saying that they made it too easy to read, at the expense of being easy to write (with the premise that these are opposite ends of a spectrum stated above)
Section 2B(iii): "to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
The grant set forth in Section 2B(iii) above does not permit you to use the virtualized copies or instances of the Apple Software in connection with service bureau, time-sharing, terminal sharing or other similar types of services."
I write software for free and as a living, so I surely take it seriously. How can a software developer justify stealing software, unless they're trapped in a poor or technologically restricted situation (Cuba)?
EDIT: There's some confusion as to what I replied to:
My reply is to this
Who actually takes software licenses seriously in their own home?
If this doesn't imply one's okay with stealing, then I take my comment back.
> How can a software developer justify stealing software
Oh come on. Running a legally obtained OSX installation on hardware you own is hardly stealing.
I don't see why OSX "fanboys" constantly bring up this tiresome meme about OSX being this near "holy" OS which cannot run on anything but this similarly holy Apple hardware.
It's a generic consumer OS designed to work on what is mostly run of the mill X86 hardware. Get with the times.
I read it as "who cares about obscure constraints which if violated will severely limit my ability to get support should I need it", not as a blanket licence to pirate software.
Obviously in a professional context, you will care about things like support. But probably not for your lets have fun hackety hack project at home.
Think you're reading too much into it. Most software license agreements have silly rules and restrictions that nobody takes any notice of - at home. Businesses have to be more careful.
I would hope that most people on HN are knowledgeable enough to agree with the EFF's take on EULAs -- they are of questionable legality, and "dangerous for consumers and innovators alike"[1].
Look, from a legal perspective this is a matter of civil procedure. For Apple to enforce this agreement it has to first discover your usage and then prove its damages in a court. The damages would likely be the cost of Mac hardware of equivalent power to the VMs plus legal fees.
What this means is that no one should spin up a server farm of OS X VMs and then blog about it. For everyone else, Apple is not going to discover you and if they do they are not going to pursue damages against you for the cost of a Mac Mini. Apple is just not out there doing that type of lawsuit
You know, after spending sooooo many thousands of dollars on iPads, MacBooks, iPhones, iTunes, iTunes Match, and the developer program, I just can't bring myself to feel bad about running an instance or two of OSX in a VM.
The part of that EULA section that really gives me trouble is "...that is already running the Apple Software...".
I want to run OSX in a VM on my MacBook Pro with Windows as the host OS. I used to do it the other way around, boot into OSX and run Windows in a Parallels VM. These days most of my work is in Windows, especially VR work, so it's more practical to boot into Windows. (And I like Windows better than OSX anyway.)
But I still do need to test on OSX occasionally. In an ideal world, since I have VMware installed on Windows, I could just boot up an OSX VM.
But because of that one EULA phrase, OSX will never be supported by a commercial vendor like VMware or a large open source product like VirtualBox - even on Mac hardware!
This leaves booting back to OSX as the only way to run it, and rebooting back and forth is a real pain.
All I want to do is run my legally licensed Windows and legally licensed OSX, and have it be my own choice which one to run as the host OS.
Thank you very much! That looks like a perfect solution for me.
I especially like the fact that it's Python source code, so I can look at the code and get some sense of comfort that it doesn't have anything sketchy in it.
There is a "VMware Unlocker" tool of extremely questionable legality that can enable running OS X as a guest of VMware Player / Workstation on Windows.
You don't really need to do anything besides a normal `git clone`; any clone is as good as any other, really.
If the project disappears from Github someone would need to find a different place to host collaborative development, though. Maybe there needs to be some sort of Github-alternative in a friendly jurisdiction for projects that are too controversial to host on a mainstream provider in the US? E.g. for DMCA-violating projects, video codecs, DRM removal tools, etc.? I'm not that familiar with the alternatives but it wouldn't surprise me if there are better options in terms of resistance to US court orders.
Very cool; currently the bash script assumes the old "OS X" naming convention of the installation app. To make it work with "macOS" Sierra, some simple changes are required.
I doubt that line ("ourhardworkbythesewordsguardedpleasedontsteal") is creative enough to meet the threshold of originality required for something to be protected by copyright.
Even if it actually were copyrightable/trademarked it wouldn't be a valid legal strategy to prevent fair-use:
95 comments
[ 4.3 ms ] story [ 147 ms ] threadEdit: It's relatively easy- blacklist (or uninstall) GPU drivers from host machine, and pass the PCI address to qemu. Performance is not perceptibly different from native. Other things you probably want to do are enable hugepages, pin virtual cpus to physical cores, and use vfio for network- https://github.com/pmj/virtio-net-osx.
It's also possible to run boot OSX using UEFI mode, which removes the need for the binary blobs in this repo.
Not sure if it's possible with OSX.
What we really need are video drivers for OSX, for virtualbox and/or other virtualisation solutons, so OSX as a guest can work really well.
Passthrough only really works reliably if you only have one guest active at a time and never try to use the graphics card from the host.
I have seen all OSX versions from Leopard to El Capitan successfully running as a VB guest, but the graphics support has always been bad, since there are no Guest Additions for OSX (BTW this also means no bidirectional clipboard, drag & drop of files, etc..)
https://www.virtualbox.org/manual/ch09.html#pcipassthrough
Of course, it's in violation of the macOS EULA to run it on non-Apple hardware in the first place, but you'd be surprised just how much hardware it supports.
For the record, VMware Fusion also does not support PCIe passthrough.
https://en.wikipedia.org/wiki/Logical_partition http://www.computerworld.com/article/2593387/server-partitio...
Personally I have a 2014 5K iMac i7 with a fusion drive. I have a Fedora VM on it I run occasionally. I run it using Virtualbox which is a free virtualization system. I've allocated 4 GB of memory and it's very performant. It's a great way to try out virtualization at home and you can run Virtualbox on Linux, OSX or Windows as the host OS.
Somehow, I thought there was this magical hypervisor that would give all to one OS that I could use and then, out of nowhere, I could switch to another OS in a way that first one would go to sleep and its memory put on hard drive and the other one would wake up its memory from hard drive and show up. I wouldn't need them running concurrently, but I would like to have them switch fast.
In a way I would like to consolidate three machines into one without having to run three machines or wait for shutdown/boot sequences (with multi boot).
Bonus would be to share disks (non boot ones) and copy and paste. That would be really great.
The last time I looked, there were significant challenges with getting a Nvidia or iGPU to work.
Non-Quadro NVIDIA cards don't want to work in a VM so you need to disguise KVM to get them to work. NVIDIA says this is a bug but I think they just want you to buy quadro cards. [1]
AMD Bonaire and Hawaii architecture cards have issues with resetting in a VM, so you can't let the VM go to sleep or shutdown. Newer (R9 480) or older AMD cards don't have this issue. [2]
[1]: http://vfio.blogspot.com/2014/08/vfiovga-faq.html?m=1 [2]: http://vfio.blogspot.com/2015/04/progress-on-amd-front.html?...
(not my blog)
Having said that, I've been getting more and more frustrated with OSX (had a great experience with Leopard on a PowerBook G4, and my 2013 MacBook Air is easily the best laptop I've owned, however personally I don't care for the direction that they are taking OSX these days), and ended up using it as an excuse to update to the latest version of elementary OS, which certainly isn't without its teething problems.
I set one up on my Z79+i7-4790k. It was a breeze. Took about 90minutes following tutorials. My biggest problems were:
-I set up the wrong sound driver
-Nvidia won't detect/modify hot plugging displays you have to manually edit OSX's version of xorg.conf
-Apple's Nvidia driver didn't support GSync or 144Hz. So I had to dealing with image tearing :\
-Non Apple keyboards had weird character mismatching. Had to purchase an Apple USB keyboard.
I ended up reverting because I like my IBM Model M, and losing hardware level vsync was a no-go.
The Mac drivers Nvidia released yesterday finally support G-Sync.
> Non Apple keyboards had weird character mismatching. Had to purchase an Apple USB keyboard.
You can fix this by not skipping the keyboard setup wizard that pops up when you plug in an unknown keyboard.
-Not all converters support it
-Some converters that support it, are disabled by the motherboard as the converter is exceeding spec.
I've actually tired 4 different models, none have worked. I've just accepted that using a PS/2 plug on the motherboard is less of a head ache.I do have a PS/2 -> USB converter that works, but only with 1 of my motherboards (a VIA). Except it knocks out the other USB port stacked above/below it. I don't plug anything into that port for the PS/2 -> USB converter, just that port will never recognize something is plugged into it. I think it is a power draw issue.
Karabiner is useful for this - for pretty much every keyboard layout you have a tick that remaps it to PC keyboard.
Karabiner does not work on macOS Sierra at the moment.
We are developing Karabiner-Elements which provides simple key modification for macOS Sierra at first. (Karabiner-Elements works on macOS Sierra except prefernces GUI.) --- https://pqrs.org/osx/karabiner/
Karabiner does not work on macOS Sierra at the moment.
We are developing Karabiner-Elements which provides simple key modification for macOS Sierra at first. (Karabiner-Elements works on macOS Sierra except prefernces GUI.) --- https://pqrs.org/osx/karabiner/
1) more bloat (but almost every OS has this problem).
2) cuts off support for some older Macs for no good reason.
One thing I really like the new default terminal font: San Francisco Mono. I don't know if that font is new to the OS entirely but I really like it.
I also really like that you can have the Finder sort folders before files. This should have been added a long time ago, but better late than never.
SF Mono is indeed new. Thank you for pointing that out. I missed it. Very nice.
http://arstechnica.com/apple/2016/09/macos-10-12-sierra-the-...
That sounds pretty neat, do you have more details written down anywhere?
It's sad though that one has to virtualize an entire OS just because a messaging system doesn't offer an open API.
Instant messaging and Pro Photo/Video apps are a particularly sore point.
-- snip snip --
using terms from application "Messages" on message received theText from theBuddy for theChat set quoted_message to quoted form of theText set quoted_id to quoted form of (id of theBuddy as text) do shell script "echo " & quoted_message & " | ~/bin/MessageReceive.sh " & quoted_id & " > /dev/null 2>&1 &"
end using terms fromapplescript went overboard on the easy-to-read-for-novices at severe cost to easy-to-write.
Edit: my email is in my profile
It only allows you:
Section 2B(iii): "to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
The grant set forth in Section 2B(iii) above does not permit you to use the virtualized copies or instances of the Apple Software in connection with service bureau, time-sharing, terminal sharing or other similar types of services."
Who actually takes software licenses seriously in their own home?
EDIT: There's some confusion as to what I replied to:
My reply is to this
If this doesn't imply one's okay with stealing, then I take my comment back.Oh come on. Running a legally obtained OSX installation on hardware you own is hardly stealing.
I don't see why OSX "fanboys" constantly bring up this tiresome meme about OSX being this near "holy" OS which cannot run on anything but this similarly holy Apple hardware.
It's a generic consumer OS designed to work on what is mostly run of the mill X86 hardware. Get with the times.
Because you seem to assume I use a mac, I must confess to not owning one and therefore not using macos.
Obviously in a professional context, you will care about things like support. But probably not for your lets have fun hackety hack project at home.
I am surprised at how many people on HN show negative attitude toward compliancy with the EULA. I thought HNers had a respect for software license.
[1]: https://www.eff.org/wp/dangerous-terms-users-guide-eulas
Any specific information about the Apple EULA in the EU, for instance?
What this means is that no one should spin up a server farm of OS X VMs and then blog about it. For everyone else, Apple is not going to discover you and if they do they are not going to pursue damages against you for the cost of a Mac Mini. Apple is just not out there doing that type of lawsuit
I want to run OSX in a VM on my MacBook Pro with Windows as the host OS. I used to do it the other way around, boot into OSX and run Windows in a Parallels VM. These days most of my work is in Windows, especially VR work, so it's more practical to boot into Windows. (And I like Windows better than OSX anyway.)
But I still do need to test on OSX occasionally. In an ideal world, since I have VMware installed on Windows, I could just boot up an OSX VM.
But because of that one EULA phrase, OSX will never be supported by a commercial vendor like VMware or a large open source product like VirtualBox - even on Mac hardware!
This leaves booting back to OSX as the only way to run it, and rebooting back and forth is a real pain.
All I want to do is run my legally licensed Windows and legally licensed OSX, and have it be my own choice which one to run as the host OS.
I especially like the fact that it's Python source code, so I can look at the code and get some sense of comfort that it doesn't have anything sketchy in it.
If the project disappears from Github someone would need to find a different place to host collaborative development, though. Maybe there needs to be some sort of Github-alternative in a friendly jurisdiction for projects that are too controversial to host on a mainstream provider in the US? E.g. for DMCA-violating projects, video codecs, DRM removal tools, etc.? I'm not that familiar with the alternatives but it wouldn't surprise me if there are better options in terms of resistance to US court orders.
[1] https://github.com/kholia/OSX-KVM/blob/476ae8b082088049f2f8c...
https://github.com/kholia/OSX-KVM/blob/476ae8b082088049f2f8c...
I would not be surprised if a DMCA takedown will be filed against this repository soon.
More information here: http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_3_2_1
Even if it actually were copyrightable/trademarked it wouldn't be a valid legal strategy to prevent fair-use:
https://en.wikipedia.org/wiki/Sega_v._Accolade
https://docs.google.com/document/d/1VwLJqgc2VkD-EZnMzSFmZRq0...
I'm having a really hard time running the Apple App Store BEFORE I install the OS. There's kind of a circular dependency there.