Skip to content

Commit 3896bc8

Browse files
committed
v0.9.3 - XML conversion tool, AP fixes, more docs
1 parent 057aed8 commit 3896bc8

File tree

23 files changed

+1032
-53
lines changed

23 files changed

+1032
-53
lines changed

.gitignore

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,12 @@
11
gpu-check1.py
22
BaseSystem.img
33
blobs/*.apb
4-
blobs/stale/*
4+
blobs/stale/*.apb
5+
blobs/user/*.apb
6+
*xml
57
resources/config.sh
68
baseConfig
9+
scripts/__pycache__/
710
scripts/__pycache__/dlosx.cpython-310.pyc
811
HDD.qcow2
912
boot.sh

.version

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
0.9.2
1+
0.9.3

README.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
# ultimate-macOS-KVM
22

3-
### v0.9.2
3+
### v0.9.3
44

55
Helping you build the ultimate macOS virtual machine, powered by KVM.
66

7-
*[What's new?](https://github.com/Coopydood/ultimate-macOS-KVM/blob/main/docs/changelogs/v0-9-2.md)*
7+
*[What's new?](https://github.com/Coopydood/ultimate-macOS-KVM/blob/main/docs/changelogs/v0-9-3.md)*
88

99
[![GitHub](https://img.shields.io/github/license/Coopydood/ultimate-macOS-KVM?label=Licence&logo=unlicense&logoColor=white&style=for-the-badge)](https://github.com/Coopydood/ultimate-macOS-KVM/blob/main/LICENSE) [![GitHub repo size](https://img.shields.io/github/repo-size/Coopydood/ultimate-macOS-KVM?label=Size&logo=envoy-proxy&logoColor=white&style=for-the-badge)](https://github.com/Coopydood/ultimate-macOS-KVM) [![Discord](https://img.shields.io/discord/574943603466436628?color=7d86ff&label=Discord&logo=discord&logoColor=white&style=for-the-badge)](https://sl.coopydood.com/discord)
1010

blobs/stale/.stale_control

Whitespace-only changes.
File renamed without changes.

docs/AutoPilot.md

Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
## Introduction
2+
So, what is AutoPilot? Are we talking about an Airbus A320? Nope, just some random GitHub project on the internet. Regardless, here's the rundown.
3+
4+
AutoPilot is a script developed by me - Coopydood - to automate the creation of an executable QEMU script file. However, it doesn't just automate it, it also **personalises it based on your preferences.**
5+
6+
The way it works is by asking you - the user - a series of questions about your preferences for the virtual machine. This includes things like the virtual CPU cores, allocated RAM, target OS, etc. Then, AutoPilot uses this information to generate a fully-customised script file, derived from a pre-made base script - with all your preferences.
7+
8+
The generated script file is **immediately valid** and can be run instantly after AutoPilot completes - which in most cases is under 3 minutes - depending on what you choose to customise. This makes it super easy to get a basic macOS VM up and running with zero user tinkering, all while catering to personal preferences.
9+
10+
With the intro out of the way, I'll now go into more detail about each AutoPilot stage, including acceptable values and how to enter them.
11+
***
12+
NOTE: Any "Accepted" values with a **bold** suffix indicate that you must include it when inputting your custom value into AutoPilot, such as file extensions.
13+
14+
***
15+
## 1. Name your config file
16+
This really is as simple as it sounds. You can choose what you want the file name of the config script to be. This can be an **alphanumeric string** with no special characters except `_` and `-`.
17+
18+
| **Default** | Accepted | _Examples_ |
19+
|:-----------:|:---------------:|:--------------------------------------------:|
20+
| boot.sh | [string]**.sh** | macOS.sh<br>macOS-1015.sh<br>ultimate_kvm.sh |
21+
22+
***
23+
## 2. Set target OS
24+
This setting only really has one definitive use right now - virtual network adapter model auto selection. Other than that, it is purely cosmetic at this time. It's still recommended to set this value properly in case future functionality and features depend on it.
25+
26+
If defining a custom value, only a **4-digit value for macOS 10.XX releases**, or a **2-digit value for macOS 11 or later** is accepted.
27+
Do NOT include any subversions (i.e. 10.13.6, 10.15.7, etc.).
28+
29+
In project versions v0.8.6 and later, this value is also now used to add a boot entry to the main menu for easy access. Again, this is purely cosmetic but something to consider.
30+
31+
| **Default** | Accepted | _Examples_ |
32+
|:-----------:|:-----------------:|:------------:|
33+
| 1015 | 10XX<br>_(10.XX)_ | 1013<br>1014 |
34+
| | XX<br>_(>=11)_ | 11<br>12 |
35+
36+
***
37+
## 3. Set number of CPU cores
38+
Like any other virtual machine, the guest needs virtual cores to work with. As a general rule, use no more than **80%** of your _host's_ total cores. For example, if your host has _10 cores_, you shouldn't use any more than __8 virtual cores__. That's all I can recommend here - use your own judgment and scale to your hardware appropriately.
39+
40+
| **Default** | Accepted | _Examples_ |
41+
|:-----------:|:--------:|:-----------:|
42+
| 2 | [number] | 4<br>6<br>8 |
43+
44+
***
45+
## 4. Set number of CPU threads
46+
Similar to the previous step, your guest needs **virtual threads** to work with.
47+
48+
**THIS VALUE IS A MULTIPLIER.** This is calculated as **_virtual cores__virtual threads_**.
49+
50+
For example, if you wanted a total of 4 virtual cores and 8 virtual threads, you would input 2 here. (4 ✕ [_**2**_] = 8)
51+
52+
If this confuses you - and I don't blame you, I've confused myself - then leave this value as it is.
53+
54+
| **Default** | Accepted | _Examples_ |
55+
|:-----------:|:--------:|:----------:|
56+
| 2 | [number] | 1<br>2 |
57+
58+
***
59+
## 5. Set CPU model
60+
This sets the model of the virtual CPU, and subsequently what the guest OS recognizes it as.
61+
62+
**THIS SHOULD NOT BE CHANGED UNLESS YOU KNOW WHAT IT MEANS!** Refer to the [official QEMU documentation on CPU models](https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html) for a comprehensive list of acceptable values.
63+
64+
If you _**know**_ your **host** CPU model is supported natively by macOS (i.e. Intel Core i3, i5, i7, i9) or at least a **similar variant of a supported model** (such as the i9-10900K being similar to Apple's i9-10910), you can expose the real model to the guest using the `host` value. It might do something. Use at your own risk.
65+
66+
| **Default** | Accepted | _Examples_ |
67+
|:-----------:|:-----------:|:--------------------:|
68+
| Penryn | [cpu_model] | Broadwell<br>IvyLake |
69+
| | host | |
70+
71+
***
72+
## 6. Set CPU feature arguments
73+
This lets you change the feature set of the virtual CPU. If you're a nerdy nerd nerd who nerds then you might find benefit in tinkering with this, but otherwise:
74+
75+
**Don't change this unless you know what you're doing.**
76+
77+
| **Default** | Accepted | _Examples_ |
78+
|:-------------------------------------------------------:|:-------------------:|:----------------:|
79+
| +ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check | +[arg] | +kvm |
80+
| | +[arg1],+[arg2] ... | +avx,+kvm,+ssse3 |
81+
82+
***
83+
## 7. Set amount of allocated RAM
84+
This one is very similar to the virtual CPU cores option in that it should be scaled relative to your host's hardware. macOS is surprisingly lenient when it comes to lesser RAM amounts, so you don't need to overdo it.
85+
86+
My only recommendation would be: [_total host RAM_][_host idle RAM usage_] − 1GB >= **total virtual RAM**
87+
88+
Example: If your host has 16GB total RAM, your host uses 4GB of RAM when idle, don't use any more than 11GB of RAM for the virtual machine. ([_16GB_][_4GB_] − 1GB = 11GB)
89+
90+
| **Default** | Accepted | _Examples_ |
91+
|:-----------:|:-------------:|:---------------:|
92+
| 4G | [number]**G** | 2G<br>8G<br>16G |
93+
94+
***
95+
## 8. Set hard disk capacity
96+
You should think carefully about this one as it might be hard to change later. This is the capacity of your primary virtual hard drive that will be used for your macOS installation. Keep in mind **macOS uses upwards of 40GB for the system**, so you should base your total on how much you think you'll need.
97+
98+
If you're just testing the project, you can leave it as is. If you plan on using the virtual machine long-term, perhaps make it a bit bigger to give yourself room.
99+
100+
**NOTE: This is a dynamically-growing disk. The virtual hard disk file will grow as you use it. The full capacity is NOT used on the host's storage upon creation. If you've ever used VMware's virtual disks, it's the same as that.** Please also note that the _actual_ virtual capacity of the hard disk may be slightly larger than the value you specify.
101+
102+
| **Default** | Accepted | _Examples_ |
103+
|:-----------:|:-------------:|:-------------------:|
104+
| 80G | [number]**G** | 60G<br>120G<br>256G |
105+
106+
***
107+
## 9. Set network adapter model
108+
This one is a bit more picky. macOS has a limited number of network drivers due to the limited hardware configurations that natively run macOS, therefore you need to pick a model with driver support.
109+
110+
**Based on your target OS you chose earlier, the default option will auto-select the best model for your macOS version.**
111+
112+
You can still override this if you'd like, but for most people, whatever is auto-selected will be fine.
113+
114+
| **Default** | Accepted | _Examples_ |
115+
|:-------------:|:---------------:|:-----------------:|
116+
| e1000-82545em | [adapter_model] | e1000m<br>vmxnet3 |
117+
| vmxnet3 | | |
118+
119+
***
120+
## 10. Network MAC address
121+
The virtual network adapter needs a virtual MAC address to identify it.
122+
123+
**The default is fine unless you intend on using features such as iMessage and FaceTime, as these services require specific MAC address values.**
124+
125+
In this case, you should use your own custom one, or you can even have the script generate a random compatible one for you. I'd recommend the latter to make it more unique, at the risk of being perhaps a bit less reliable.
126+
127+
| **Default** | Accepted | _Examples_ |
128+
|:-----------------:|:-------------------------------------:|:-----------------------------------------------------------:|
129+
| 00:16:cb:00:21:09 | XX:XX:XX:XX:XX:XX | 00:16:cb:00:48:02<br>00:16:ca:00:27:09<br>00:16:cr:00:87:33 |
130+
131+
***
132+
## 11. macOS Recovery image file
133+
To install macOS, you'll need an image of the macOS Recovery.
134+
135+
The script can automatically download a recovery image of a macOS version of your choosing, or you can use one you already have. If you are using a custom image, it should be in the ***.img** format. You can drag a file onto the terminal window, or place a file called `BaseSystem.img` in the root of the project directory to have it be detected automatically. If it is in the ***.dmg** format - this is okay - the script will automatically detect this and convert it for you during the configuration process.
136+
137+
You can also choose to skip this step, but this is not recommended.
138+
139+
| **Default** | Accepted | _Examples_ |
140+
|:--------------:|:---------------:|:-----------------------------------:|
141+
| BaseSystem.img | [file_name].img | BaseSystem.img<br>macOSRecovery.img |
142+
| | [file_name].dmg | BaseSystem.dmg<br>InstallESD.dmg |
143+
144+
***
145+
## 12. Screen resolution
146+
As of [v0.9.2](https://github.com/Coopydood/ultimate-macOS-KVM/releases/tag/v0.9.2), you can now pre-select what screen resolution you'd like to use for the virtual screen.
147+
148+
This is done by utilising a pre-made OVMF variable file, with the desired screen resolution built in. Based on what you choose, the corresponding OVMF variable file will be used by AutoPilot to complete setup.
149+
150+
The default resolution is **1280x720** and is recommended for most users - at least until macOS is installed. However, for a more "native" look, you can choose your monitor's screen resolution if it's supported. This means that in full screen mode, the VM will be running native to your whole screen.
151+
152+
Custom values are not supported. When inputting a value at this stage, you will be given a list of supported resolutions to select from. You must then type the number next to the corresponding resolution to select it, *do not type the resolution itself*.
153+
154+
**NOTE: This becomes irrelevant if you use GPU passthrough. Virtual screens are replaced by your physical monitors and their EDID data, which defines available resolutions. This stage is only useful for those not interested in using passthrough.**
155+
156+
| **Default** | Accepted | _Examples_ |
157+
|:-----------:|:-----------------------------------------------------------------------------------------------:|:---------------------:|
158+
| 1280x720 | 800x600<br>1024x768<br>1280x720<br>1280x1024<br>1440x900<br>1920x1080<br>2560x1440<br>3840x2160 | 1024x768<br>1920x1080 |
159+
160+
***
161+
## Review your preferences
162+
You'll now get a chance to see your choices displayed in the form of a summary screen. An example of this screen can be found below:
163+
164+
![AutoPilot summary screen](https://github.com/Coopydood/ultimate-macOS-KVM/assets/39441479/996fb2b5-28ef-4949-bbc3-4107193b1187)
165+
166+
From here, you can confirm and continue, go back and change your settings, start over, or exit entirely.
167+
168+
***
169+
## Process checklist
170+
The process checklist is displayed upon confirming your preferences, in the form of a traffic light system.
171+
172+
| **Red** | **Yellow** | **Green** |
173+
|:---------------:|:-----------:|:---------:|
174+
| Not yet started | In progress | Complete |
175+
176+
![AutoPilot progress screen, showing traffic light system](https://github.com/Coopydood/ultimate-macOS-KVM/assets/39441479/b6390adc-62ff-4a91-bf00-a9b911a5cb29)
177+
178+
If a sub-operation is required, this will be indicated by a dropdown arrow underneath the current parent operation.
179+
180+
***
181+
## Summary
182+
After everything has been completed without issue, you will be presented with a small summary view of what your boot config script is called, the command you can use to run it, and the time it took to complete AutoPilot (speedrunning anyone?).
183+
184+
![AutoPilot post-success screen.](https://github.com/Coopydood/ultimate-macOS-KVM/assets/39441479/a95f7741-b029-4596-be99-c9fa8b51bb9f)
185+
186+
You'll also receive the option to boot the file straight away, open it in your default text handler (v0.9.2 or later), or exit the program.
187+

docs/Extras.md

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
## extras.py
2+
**THIS PAGE NEEDS UPDATING!**
3+
4+
**⚠ THIS SCRIPT SHOULD NOT BE RUN DIRECTLY BY THE USER!**
5+
6+
It should be run through the `main.py` file instead. Use the **E** option at the main menu.
7+
8+
![image](https://user-images.githubusercontent.com/39441479/215358442-ea028ed6-9611-46c7-b04b-3c48507343e7.png)
9+
10+
This page will go over some of the features in the Extras menu, without too much detail.
11+
12+
***
13+
## 1. Create and import XML file
14+
15+
This option allows you to automatically convert a QEMU config script previously generated by AutoPilot into an XML file compatible with **virt-manager** (Virtual Machine Manager), which is a GUI frontend that makes management of your VMs easier and nicer to work with.
16+
17+
After conversion, you'll have the option to automatically import the XML file into virt-manager.
18+
19+
***
20+
## 2. VFIO-PCI passthrough assistant
21+
If AutoPilot wasn't tiring enough for me to make, this takes the cake. It's an extension to AutoPilot itself - providing you with an easy(ier) way to correctly set up your config file with VFIO-PCI devices.
22+
23+
After completing AutoPilot, you're left with a bare-bones / no-frills macOS virtual machine that has been customised to your liking. This itself is probably enough for most people. But, if you demand more and are categorically not "most people" - this is for you.
24+
25+
Providing you have [a compatible GPU](https://github.com/Coopydood/ultimate-macOS-KVM/wiki/Main-Menu#3-check-gpu-compatibility), you can
26+
use this assistant to utilise GPU passthrough and enable 3D acceleration in macOS.
27+
28+
***
29+
## 3. Create a backup of config files
30+
**✖ THIS IS NOT YET IMPLEMENTED!**
31+
32+
A cute 'lil script made to save you from yourself when you inevitably do something really, really stupid.
33+
34+
***
35+
## 4. Dump VBIOS to ROM file
36+
**✖ THIS IS NOT YET IMPLEMENTED!**
37+
38+
Utilising the Linux filesystem's sexy device management, this script lets you easily dump your GPU's VBIOS to a ROM file for use with VFIO-PCI passthrough. *This isn't always required*, but depends on your specific GPU.
39+
40+
***
41+
## R. Reset OpenCore image and vNVRAM
42+
**☢ THIS IS INTENTIONALLY DESTRUCTIVE!**
43+
44+
This project is set up to try and make your oopsie-whoopsies as painless as possible, by providing you with plenty of opportunities to back up your personal config files and images.
45+
46+
Aside from backups, the project also keeps fresh copies of its main components stashed in its resources folder, for safe keeping *from you*.
47+
48+
Basically, this means that if you somehow corrupt your OpenCore boot image, or something in the virtual NVRAM, you can overwrite it with a fresh working copy from the repo's secret stash. This option is like a "soft-reset", and doesn't affect your config files or virtual hard disk files - just the virtual bootloader and NVRAM.
49+
50+
***
51+
## X. Download and restore all
52+
**☢ THIS IS INTENTIONALLY DESTRUCTIVE!**
53+
54+
Now you've done it. The biggest oopsie-whoopsie f*cky-wucky of them all - and my repo has been tainted with your mess. Somehow, if you have to use this option, you've messed up **so badly** that you feel like you have to reset the repo itself.
55+
56+
While this *shouldn't* be destructive for *your* personal files (i.e. configs and vHDDs) it carries some risk as it will clear and reset all of the projects files with online copies. The latest version of the repo's files will be downloaded regardless of your current version - so unlike the built-in updater script there are no safety measures to account for any dramatic discrepancies between local and remote versions.

docs/GettingStarted.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
## Cloning and Permissions
2+
It's easy to get up and running. Simply clone the repo, fix permissions, and run.
3+
Make sure you have **all** [dependencies](https://github.com/Coopydood/ultimate-macOS-KVM/blob/main/README.md#requirements) installed before getting started.
4+
5+
***
6+
7+
**⚠ VERSION WARNING**
8+
9+
As of v0.9.0, the main menu file is now `main.py`. This wiki has been updated to reflect this change.
10+
If you are on an older project version (<= v0.8.6), this file will still be named `setup.py`.
11+
***
12+
13+
```
14+
git clone https://github.com/Coopydood/ultimate-macOS-KVM
15+
cd ultimate-macOS-KVM
16+
chmod +x main.py
17+
```
18+
or, do all this with a one-liner:
19+
```
20+
git clone https://github.com/Coopydood/ultimate-macOS-KVM && cd ultimate-macOS-KVM && chmod +x main.py
21+
```
22+
23+
***
24+
25+
## Starting Up
26+
To begin using the project, run the `main.py` file found in the root of the repo directory. It can be run using the following command:
27+
```
28+
./main.py
29+
```
30+
This is your central hub - a macOS-KVM swiss army knife per se. You should use this script to access any other parts of the project, as the other script files **are not intended to be run directly by the user**.
31+
32+
When using the script, make sure you are cd'd into the `ultimate-macOS-KVM` repo directory first. Example:
33+
```
34+
[name@hostname ~]$ cd ultimate-macOS-KVM
35+
[name@hostname ultimate-macOS-KVM]$ ./main.py
36+
```
37+
38+
***
39+
**⚠ WARNING!**
40+
41+
Do *not* use `sudo`. If you're in the habit of running everything with superuser permissions - break that habit before it breaks you.
42+
43+
None of my scripts require `sudo` or root permissions. The only exception to this would be when running a config script *with a physical PCI device passed through using VFIO-PCI*, as this may require superuser permissions as you're dealing with physical devices.

0 commit comments

Comments
 (0)