ghost82

No, I'm currently running my primary mac os vm on another linux host and manually generated the xml; macinabox was useful to start, but I have too many mods now. I'm currently using smbios data of imacpro1,1. Serial number must be correct as far as the smbios model you set, but apple should not be able to validate when you bought the device.

As far as findmy and the black screen I'm quite sure it depends on gpu rendering. On my vm everything is fine (I'm on Monterey and cannot upgrade because of my cpus), I'm passing through a 6900xt gpu and enabled unfairgva in opencore because also TV app showed a black screen. Now everything is fine.

As far as the location map: my though is that the black screen could be because of gpu rendering requirement: are you connecting via vnc?This could explain the black screen. As far as the not able to get location, I know location can be found only with wifi protocol, not with ethernet. No wifi, no location, and maybe external wifi (a usb wifi dongle for example) wont work at all to get the location because of how it works in mac os in general, but only a proper wifi pcie module passed to the vm from the host. As far as imessage I have no idea, I don't use it at all, can you check both devices are connected to apple account?To be sure, logout, login again and retest. And also does your en0 connection is seen as built-in?Check in ioreg explorer or with hackintool See following image, both en0 and en1 builtin:

Mac address change is not a must, but recommended. En0 must be built-in. Your issue was that from the apple side you login multiple times (too many) to your account with different devices. In real, you changed only the configuration of the vm, but each change resulted in a new device seen from the apple side, so they locked the account. Glad that you solved the issue.

First of all, logging into an apple account from a mac os virtual machine is not illegal and is not against apple terms and conditions; what you can't do is virtualizing a mac in a host which is not a mac. Note that qemu is available also for mac os hosts. I'm using my apple account in a qemu vm (other than my real macbook pro) from more than 6 years now and, apart being banned/flagged at the beginning (which required calling an operator), because basically I didn't know what I were doing, I never had a single issue after that. If you want to log with an apple account, first you need to setup your hardware such that the en0 is seen as built in, you should use a mac address belonging to apple hardware, choose proper smbios data, serial number. Do not change serial number or other smbios data once you are logged in, because apple will see logins, coming from different devices, and for "security reasons" it will flag your account. If you want to experiment with a mac os vm do it offline, Once you know what you're doing freeze the configuration and go online. Once you know what you're doing, call apple and give them the code (if you have one) to unlock the account; it could be that the operator has no idea of what you're saying and doesn't even know what is the code you have to unlock the account; if this is the case call again to speak to another operator untill you find one that knows what you're talking about..I had to call 3 times to find a smart operator that unlocked my account in less than 10 seconds.. Do not tell them you are virualizing a mac on a non apple hardware, you can say you are virtualizing it on a mac host, so..??They have to unlock your account.

If an older backup works, just replace the img file with the newer one and it should boot.

Hello @The Transplant I never used the backup plugin, so I'm sorry but I don't know how this plugin works. Anyway... An img file is the disk file. The xml file contains the emulated hardware and layout of the virtual pc. The edk2 ovmf code fd file is the bios of your virtual pc. The edk2 ovmf vars fd file is the nvram of your virtual pc. You need these 4 things to boot a qemu vm. You should be able to boot the img by recreating the other 3 files; you can copy the ovmf code fd file from another vm (it's the bios, the bios is the same for every vm), and you also can use the ovmf vars fd file copied (better) from the same vm (the vars file can contain nvram variables, such as boot order). As far as the xml you can create a new vm, so to generate a new xml and change the relevant part of this new xml to point to your img disk file, and fd files; if hardware layout is different than the old xml (for example, you add a new usb virtual controller which was not there in the original vm), windows should be smart enough to not hang. Obviously you need to know if your original vm was a uefi or bios vm, q35 or i 440fx, so you can create the new vm accordingly, using ovmf or seabios nad q35 or i440fx virtual chipsets. Correct, it doesn't matter, unraid applies a prefix with the uid of the vm to the filename. Either edit the path to point to that of where the img is, or move the img to that path. This file should contain some nvram variables, but it shouldn't matter, make sure to check the xml to point to this file. If it doesn't boot you may need to enter the ovmf bios screen (by pressing esc key on vm boot repeatedly) and change the boot order.

Do not take it bad, but it must be something else..both unraid and proxmox use qemu to do virtualization and the host os cannot make such a difference.

These are warnings and that features are simply ignored because your native cpu doesn't support them. You don't need that file, that is for emulated nvram, and you will not emulate it. This is the issue, if you use the configurator with an older or newer version of opencore it will mess your configuration file. What is not working is opencore because it's not configured properly/wrongly or because the image you are using is too old for the os you're trying to boot. I suggest to not copy the efi folder to the macos disk, but let it stay alone in its own disk and configure the vm boot from it, so that the original efi in the macos disk will be simply ignored, otherwise if you mess things with the efi it will be more difficult to mount that partition.

Yes I agree 100%, but stupid software houses don't understand this; instead of programming some serious anticheating software they only check if you're running the game in a vm.

/lib64/ld-linux-x86-64.so.2 /boot/config/unraider 😒👎

the "do not use a rom" should be changed to "use a rom only when needed", when the gpu you are passing through is the primary gpu, flagged as boot vga by the host.

As you can see network types are "PCNet32"; most probably the os has few drivers for network adapters, maybe only that one. You can try to manually edit your xml and put 'pcnet' as model type for network, instead of 'e1000' or whatever it is. <model type='pcnet'/>

From your xml you are using legacy bios boot (seabios). The issue could be related to legacy bios vs the gpu you are passing through (the 3060 is a recent gpu with uefi support), not able to display legacy boot. You should convert your vm to uefi bios (ovmf): this means convert the installed vm to uefi and also modify the xml template to boot with uefi-ovmf bios). -- To confirm the culprit you can temporary switch from gpu passthrough to vnc, and I'm quite sure that with vnc you will see the verbose boot.

no idea, maybe you don't have any virtio driver installed in your linux vm, maybe they are part of kvm and need to install it to have virtio drivers...frankly speaking for everyday use you wont notice any difference between sata and virtio. qemu agent has nothing to do with virtio.