Docker’da QEMU ile çalıştırılan macOS

 (github.com/sickcodes)
3 puan yazan GN⁺ 2024-08-01 | 1 yorum | WhatsApp'ta paylaş
  • Docker-OSX, Docker konteyneri içinde QEMU + KVM tabanlı macOS çalıştırarak X11 çıktısı, SSH, VNC, iPhone USB entegrasyonu ve iMessage güvenlik araştırmaları için seri numarası üretimi gibi özellikler sunar
  • Çalıştırma yöntemi, /dev/kvm aygıtını, X11 soketini, port yönlendirmeyi ve macOS sürümünü seçmek için SHORTNAME ortam değişkenini Docker’a aktarma yapısına dayanır; Catalina 10.15’ten Tahoe 16’ya kadar örnekler içerir
  • İmaj yapısı amaca göre latest, auto, naked, naked-auto gibi seçeneklere ayrılır; kendi oluşturduğunuz .img dosyasını bağlayabilir veya önceden yapılandırılmış Catalina imajıyla komut satırı işleri çalıştırabilirsiniz
  • Gereksinimler x86_64 KVM destekli host, BIOS’ta sanallaştırmanın etkinleştirilmesi ve en az 20 GB üzeri disk alanıdır; Xcode kullanırken 50 GB, :auto kullanırken en az 50 GB gerekir
  • Yalnızca Linux’ta değil, Windows 11 build 22000+ üzerindeki WSL2 iç içe sanallaştırma ile de çalıştırılabilir; ancak görüntü çıktısı için WSLg, VNC veya bir masaüstü ortamından biri ayarlanmalıdır

Docker konteyneri içinde macOS çalıştırma

  • Docker-OSX, macOS’u Docker konteyneri içinde çalıştıran bir projedir
    • QEMU + KVM üzerinde çalışır
    • X11 yönlendirmesini destekler
    • iPhone USB’nin çalıştığı bir yapılandırma sunar
    • Linux ve Windows’ta macOS güvenlik araştırması yapılabileceğini belirtir
  • Proje OSX-KVM üzerine inşa edilmiştir ve KVM-OpenCore, OpenCorePkg ile birlikte anılır
  • Docker Hub imajı da sunulur: sickcodes/docker-osx

Desteklenen macOS sürümleri ve hızlı çalıştırma yöntemi

  • Quick Start, docker run içinde aşağıdaki öğeleri aktarma yöntemidir
    • --device /dev/kvm
    • SSH için -p 50922:10022
    • X11 için /tmp/.X11-unix volume’u
    • DISPLAY
    • macOS sürümünü seçmek için SHORTNAME
  • README’de yer alan çalıştırma hedefleri şunlardır

    • High Sierra 10.13

    • Mojave 10.14

    • Catalina 10.15

    • Big Sur 11

    • Monterey 12

    • Ventura 13

    • Sonoma 14

    • Sequoia 15

      • Tahoe 16
      • Monterey sonrası örneklerin bir kısmı GENERATE_UNIQUE=true ile MASTER_PLIST_URL değerini birlikte kullanır
      • Sonoma, Sequoia ve Tahoe örnekleri CPU='Haswell-noTSX' ve CPUID_FLAGS değerlerini de içerir

İmaj türleri ve kullanım amaçları

  • Docker-OSX, amaca göre konteyner imajları sunar
    • sickcodes/docker-osx:latest: Hızlıca denemek veya doğrudan macOS imajı oluşturmak için kullanılır
    • sickcodes/docker-osx:auto: Önceden yapılandırılmış Catalina sistemini kullanır; kullanıcı adı user, parola alpine
    • sickcodes/docker-osx:naked: Kullanıcının sahip olduğu .img dosyasını bağlayarak çalıştırır
    • sickcodes/docker-osx:naked-auto: Kullanıcı imajına USERNAME, PASSWORD, OSX_COMMANDS aktararak SSH ve komut çalıştırmayı otomatikleştirir
    • sickcodes/docker-osx:big-sur, :monterey, :ventura, :sonoma, :high-sierra, :mojave: Belirli sürümleri çalıştırmak için
  • naked imajı, mevcut disk imajlarını tekrarlı olarak boot etmek veya konteyneri önceki bir duruma geri döndürme akışına uygundur
  • auto ve naked-auto, komut satırı odaklı işler veya Homebrew tabanlı derlemeler gibi headless işler için kullanılabilir

Başlıca özellikler

  • Docker-OSX’in belirttiği özellikler şunlardır
    • Linux’ta usbfluxd kullanarak iPhone OSX KVM kullanımı
    • macOS Monterey VM çalıştırma
    • Klasör paylaşımı
    • USB passthrough ve hotplug
    • SSH etkinleştirme: localhost:50922
    • VNC etkinleştirme: ./vnc sürümü kullanıldığında localhost:8888
    • serial number generator aracılığıyla iMessage güvenlik araştırması
    • X11 yönlendirmesi
    • Big Sur, özel imajlar ve Xvfb headless modu desteği
    • docker commit ile konteyner çoğaltma imkânı
  • Kubernetes de desteklenir; Helm Chart ve belgelerin helm dizininde olduğu belirtilir

Gereksinimler ve ilk kurulum

  • Minimum gereksinimler şunlardır
    • 20 GB üzeri disk alanı
    • Xcode kullanırken 50 GB
    • :auto kullanırken en az 50 GB
    • BIOS’ta sanallaştırmanın etkinleştirilmesi
    • x86_64 KVM destekli host
  • İlk kurulum, host’a QEMU ve ilgili bağımlılıkları kurduktan sonra libvirtd, virtlogd ve KVM kernel modüllerini etkinleştirme akışıdır
  • Arch, Ubuntu/Debian ve CentOS/RHEL/Fedora için ayrı ayrı paket kurulum komutları sunulur
  • Kullanıcının Docker, KVM ve libvirt gruplarına dahil olması gereken durumlar olabilir; Docker daemon’unun çalışır durumda olduğu da kontrol edilmelidir

Windows’ta çalıştırma koşulları

  • Windows’ta Docker-OSX çalıştırma Windows 11 + WSL2 ortamında mümkündür
    • Windows 11 build 22000+, 21H2 veya üzeri gerekir
    • WSL kurulduktan sonra .wslconfig dosyasına nestedVirtualization=true eklenir
    • WSL dağıtımında kvm-ok ile /dev/kvm ve KVM hızlandırmasının kullanılabilir olup olmadığı kontrol edilir
    • Docker for Windows’ta WSL2 tabanlı engine ve varsayılan WSL dağıtımı entegrasyonu açılmalıdır
  • Ekran çıktısı yöntemleri 3’e ayrılır
    • WSLg: En basit ve önerilen seçenektir, ancak klavye aktarımı veya ikinci fare imlecinin görünmesi gibi sorunlar olabilir
    • VNC: QEMU VNC veya VNC bölümündeki ayarlar kullanılır
    • Desktop Environment: Daha fazla kaynak kullanır ancak tam Linux masaüstü deneyimi sunar

Dosya paylaşımı ve disk yönetimi

  • En kolay ve güvenli paylaşım yöntemi olarak sshfs önerilir
    • Linux/Windows’ta sshfs user@localhost: -p 50922 ~/mnt/osx biçiminde macOS rootfs kullanıcı alanına mount edilir
  • QEMU 9p paylaşımı da mümkündür
    • Host klasörü konteynere /mnt/hostshare olarak aktarılır
    • macOS içinde sudo -S mount_9p hostshare ile mount edilir
  • NFS paylaşımı da açıklanır
    • Host’un /etc/exports dosyasına paylaşım dizini kaydedilir
    • Docker-OSX konteyneri --network host ile başlatılır
    • macOS terminalinde mount_nfs kullanılır
  • Docker disk alanı yetersiz olduğunda /var/lib/docker harici sürücüye, blok depolamaya, NFS’ye vb. taşınıp sembolik bağlantı oluşturulabilir
    • İlgili öğreticilerin yalnızca mevcut Docker imajları ve katmanlarının silinebilmesi riskini kabul ettiğinizde izlenmesi gerektiği belirtilir

iPhone USB ve USB passthrough

  • Masaüstü PC’lerde VFIO tabanlı iPhone USB passthrough yöntemi ayrı bir bağlantıyla açıklanır
  • Dizüstü bilgisayar, PC vb. sistemlerde usbfluxd kullanan ağ tabanlı USB passthrough kullanılabilir
    • Linux’ta iPhone veya iPad USB ile bağlanır
    • usbmuxd, TCP portu 5000 üzerinden dışa açılır
    • macOS guest’inde usbfluxd -f -r 172.17.0.1:5000 biçiminde host’a bağlanılır
    • Xcode gibi uygulamalar kapatılıp yeniden açıldığında cihazın görüneceği belirtilir
  • Genel USB passthrough için QEMU’nun root olarak başlatılması gerektiği belirtilir
    • lsusb -t ile bus ve port kontrol edilir
    • --privileged, /dev/kvm, EXTRA="-device ... usb-host ..." vb. kullanılır
    • VM çalışırken host sistemi ilgili USB aygıtına erişemez

Headless, VNC, SPICE, uzaktan çalıştırma

  • Headless çalıştırma, docker run içinde X11 ile ilgili iki satırın kaldırılması yöntemidir
    • /tmp/.X11-unix volume’unu kaldırma
    • DISPLAY ortam değişkenini kaldırma
  • Özel imaj tabanlı headless konteynerlerin CI/CD pipeline’ları için yararlı olduğu belirtilir
  • VNC yalnızca yerel kullanım için kullanılabilir, ancak README TLS/HTTPS şifrelemesinin hiç olmadığını açıkça belirtir
    • SSH tüneli kullanılıp dış port kapatılırsa güvenli hale geleceği belirtilir
  • SPICE de kullanılabilir
    • remote-viewer spice://localhost:3001 ile bağlanılır
    • Örnekteki -disable-ticketing, kimlik doğrulamasız VM erişimine izin verdiği için SPICE kılavuzundaki kimlik doğrulama ayarlarına bakılması gerektiği belirtilir

Seri numarası ve iMessage/iCloud araştırması

  • iMessage veya iCloud kullanımı için değiştirilmesi gereken değerler olarak şunlar sunulur
    • SERIAL
    • BOARD_SERIAL
    • UUID
    • MAC_ADDRESS
    • ROM değerinin iki nokta üst üste işaretleri kaldırılmış küçük harfli MAC adresi olduğu açıklanır
  • Docker-OSX iki yöntem sunar
    • GENERATE_UNIQUE=true: Runtime sırasında benzersiz değerler oluşturur
    • GENERATE_SPECIFIC=true: Belirtilen değerleri kullanır
  • ./custom/generate-unique-machine-values.sh, seri numarası, MAC adresi, CSV/TSV çıktısı ve boot disk imajı oluşturabilir
  • macOS içinde seri numarası ioreg -l | grep IOPlatformSerialNumber ile kontrol edilebilir

Performans, çözünürlük ve ağ ayarları

  • osx-optimizer kullanılarak konteynerin daha hızlı hale getirilebileceği belirtilir
    • GUI giriş ekranını atlama
    • Spotlight indekslemeyi devre dışı bırakma
    • Ağır giriş ekranı arka planını devre dışı bırakma
    • Güncellemeleri devre dışı bırakma
  • Çözünürlük WIDTH ve HEIGHT ortam değişkenleriyle değiştirilebilir
    • GENERATE_UNIQUE=true veya GENERATE_SPECIFIC=true ile birlikte kullanılmalıdır
    • Yeni boot bölümü oluşturmak için açılış yaklaşık 30 saniye daha uzun sürer
    • Hatalı çözünürlük varsayılan olarak 800x600 olur
  • Ağ adaptörü ortam değişkeniyle değiştirilebilir
    • Hızlı internet bağlantısı: NETWORKING=vmxnet3
    • Yavaş internet bağlantısı: NETWORKING=e1000-82545em
  • Uzaktan kurulumda IPv4 forwarding açılırsa performans iyileşebilir, ancak konteynerde VPN kullanılsa bile host IP’sinin sızabileceği belirtilir

Sorun giderme ve sınırlamalar

  • Docker daemon’u çalışmıyorsa docker: unknown server OS: . hatası oluşabilir
    • sudo dockerd
    • sudo systemctl --start dockerd
    • sudo systemctl --enable --now dockerd
  • RAM, fiziksel makineden daha fazla atanamaz
    • Varsayılan değer -e RAM=3
    • Fazla atama durumunda cannot set up guest memory 'pc.ram': Cannot allocate memory hatası oluşabilir
  • ALSA ile ilgili hatalar konteyner başlatılırken veya boot sırasında görülebilir; boot ve işlevler normalse endişelenmeye gerek olmadığı belirtilir
  • TODO içinde aşağıdaki maddeler kalmıştır
    • Güvenlik araştırmacıları için belgeler
    • GPU hızlandırma
    • virt-manager desteği

Lisans ve bildirimler

  • Docker-OSX, GPL v3+ ile lisanslanmıştır
  • Docker-OSX’in özel mülk yazılım oluşturmaya yönelik bir araç olarak kullanılmasına izin verildiği açıkça belirtilir
  • Apple güvenlik araştırmaları ve Apple Bug Bounty Program ile ilgili bildirimler içerir; Hackintosh, OSX-KVM ve Docker-OSX’in hukuki meseleleri hakkında ayrı bir yazıya bağlantı verir
  • Projede anılan ürün adları, logolar, markalar ve ticari markaların ilgili sahiplerinin mülkü olduğu; bu marka sahiplerinin depo ile bağlantılı olmadığı veya onu desteklemediği/onaylamadığı belirtilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-01
Hacker News yorumları

  • Projeyi gerçekten kullanmak isteyenler için önemli ama neden bu kadar çok Dockerfile benzeri build tarifinin build sırasında internetten rastgele şeyler indirdiğini anlamıyorum
    Bu projenin Dockerfile’ı da build anında 2 Git deposu ve 1 script getiriyor
    İnternet erişimi kapalı sandbox build sunucusunda başarısız olması bir yana, güvenliği az da olsa önemseyen herkesin kullanmadan önce tüm build tarifini denetlemesi gerekiyor
    README, requirements.txt, package.json gibi build tanımlarında yazan bağımlılıkları incelemek artık yetmiyor; son dönemdeki kritik altyapı arızaları ve tedarik zinciri saldırılarının artışı düşünüldüğünde bu çok endişe verici bir gidişat

    • Projelerin build dosyalarını internetten çekmesinden gerçekten nefret ediyorum. Genelde beklenmedik şekilde oluyor; yalnızca güvenlik sorunu değil, üzerine bağımlı olan yazılımı paketlemeyi de çok daha zorlaştırıyor
      Sürüm sorunları çıkması, internetin olmaması ya da en kötüsü bağımlılığın artık sunulmaması gibi tatsız sürprizler doğuruyor. Kendi kendine yeten dağıtım varsayılan olmalı
    • Cevap değişim churn’ü. DevOps alanında değişim o kadar yoğun ki artık kimsenin “doğru yöntemi” çözmeye vakti yok
    • Doğru yön, Red Hat, SUSE, Canonical gibi büyük açık kaynak oyuncularının build’i güvenli hâle getirmesini beklemek
      Fedora ve openSUSE genelde dağıtım paketleri ve konteyner imajları dahil olmak üzere, depodaki paketlerle build edilme ya da build sırasında yalnızca açıkça eklenmiş ikilileri kullanma yönünde politikalara sahip
      Bu yüzden dnf/zypper install ile kurabiliyorsanız veya üreticinin konteyner registry’sinden çekebiliyorsanız çıktıya güvenebilirsiniz
      En yeni bleeding edge’e ihtiyacınız varsa internetten rastgele şeyler alma riskini kabul etmeniz gerekir
      Rastgele bir açık kaynak geliştiricisinin çevrimdışı hazır, güvenilir build çıktıları üretmesi zor; böyle bir altyapısı da yok. Red Hat veya SUSE gibi şirketlerin var olma nedeni de bu
      Milyarlarca dolarlık şirketler, birilerinin tesisat işini yapıp internetteki rastgele çıktıları güvenilir, tekrarlanabilir ve imzalı çıktılara dönüştürmesi; CVE’leri takip edip düzenli güncellemesi için ödeme yapmaya istekli
    • Tek bir web sayfası göstermek için JavaScript’in on binlerce bağımlılık çekmesinden farkı ne, bilmiyorum
      80’lerde Lego blokları gibi takılıp çıkarılan modüler, yeniden kullanılabilir yazılım bileşenleri hayal edilirdi; o zaman buna CASE deniyordu. Şimdi bu gerçekleşmiş sayılır ama elbette bir bedeli var
    • Muhtemelen başlıca neden, konfigürasyon düzenini ayrı Git depolarıyla korumak istemeleri
      Dockerfile içinde clone etmezseniz, build öncesinde “clone ederken --recursive kullanın veya git submodule init ile diğer depoyu mevcut çalışma dizinine getirin” gibi talimatlar gerekir

  • GPU hızlandırmanın tek olası yolu, PCI passthrough ile desteklenen bir dGPU aktarmak. AMD RX 6xxx ve üstü macOS 14.x’te mümkün, ancak modern Nvidia için şans yok
    Intel iGPU Comet Lake’e kadar, bazı Ice Lake modellerine kadar çalışıyor; daha yenileri çalışmıyor
    Apple Silicon build’i macOS’un yakın vadede emüle edilmesi zor görünüyor; ARM Darwin’i boot etmeye yönelik az da olsa erken çalışmalar var
    Ayrıca AMD’de Intel VT-x olmadığı için AMD host’larda sanallaştırma bozuluyor; ancak eski VirtualBox kullanan tuhaf bir hack ile Docker’ı emülasyon üzerinden bir ölçüde çalıştırmak mümkün

    • Teorik olarak biri, Windows ve Linux’ta olduğu gibi libvirt/kvm/qemu 3D hızlandırma için bir görüntü sürücüsü yazabilir. O zaman performans en iyi seviyede olmasa da neredeyse her GPU’da GPU performansından yararlanılabilir
      AMD’nin kendi VT-x alternatifi olan AMD-V var, bu yüzden sorunsuz çalışması gerekir. Ancak macOS’u AMD CPU’da boot ettirmede başka engeller var; genelde kext yükleme veya başka hilelerle çözülüyor
      Docker ile tüm bir işletim sistemi çalıştırmanın anlamını pek anlayamıyorum. OVA ya da tercih edilen sanallaştırma formatıyla dağıtılabilir. qcow2 ve VM’i başlatmak için bir bash script’i muhtemelen yeterli olur
    • “AMD’de Intel VT-x olmadığı için AMD host’larda sanallaştırma bozuluyor” kısmı AMD-V ile olmuyor mu?

  • İlgili yazılar:
    Docker-OSX: Run macOS VM in a Docker - https://news.ycombinator.com/item?id=34374710 - Ocak 2023, 110 yorum
    macOS in QEMU in Docker - https://news.ycombinator.com/item?id=23419101 - Haziran 2020, 186 yorum

  • Birkaç ay önce deneme amaçlı kurmuştum ve oldukça iyi çalışmıştı. Ancak iMessage’ın çalışması için uygulamanın donanım ID’sini Apple’a gönderdiğini ve bu projenin sahte değerler kullandığını öğrendim
    O noktadan itibaren “bu pek olmayacak gibi” kaydırağına binmiş oldum; sahte değerlerin Apple tarafından işaretlenebileceğini ve bunun sonucunda iCloud ID’sinin potansiyel spammer olarak işaretlenip diğer cihazlara erişimin kısıtlanabileceğini öğrendim
    Tek seçenek, muğlak şekilde linklenmiş donanım ID oluşturma script’i ile değerleri sürekli deneyip “çalışan” bir değer bulmak; fakat bunun gerçekten iyi eşleştiğine ve iCloud itibarına zarar vermediğine dair net bir sinyal yok
    Bunun dışında gerçekten iyi çalışıyordu ve sıkışık durumlarda çok kullanışlı

    • “Çalışana kadar HWID’yi sürekli değiştirme” yöntemi Hackintosh’ta iMessage’ı çalıştırmak için de yaygındı. Çalışıp çalışmadığını checkcoverage.apple.com üzerinden kontrol edebiliyordunuz
      Kısa süre sonra eski ama gerçek bir Mac’in Serial’ını kopyalamanın daha kolay olduğunu fark ettim
      Ancak bu araç, kişisel bilgisayar gibi kullanmaktan çok, tescilli macOS framework’lerine bağımlı build script’leri gibi işler için daha yararlı görünüyor
    • Güvenlik araştırmaları için genelde birincil iCloud hesabını veya başka ana hesapları kullanmamak daha iyidir

  • Sadece iOS için derleme yapılıp yapılamayacağını denemek istiyorum. Örneğin Unity, React Native gibi şeyler
    Derleme 5 kat daha uzun sürse bile özgürlük açısından oldukça güzel olabilir

    • Çapraz derleme muhtemelen daha iyi bir yaklaşım: https://github.com/tpoechtrager/osxcross
      Godot’nun iOS hedefli derleme yapma biçimi de bu yönde: https://github.com/godotengine/build-containers/blob/main/Do...
      Araçların önceden kurulu olduğu bir Docker imajı da var, ancak iOS’u hedeflemek için biraz değişiklik gerekiyor: https://github.com/shepherdjerred/macos-cross-compiler
      RStudio’da, şimdiki Posit’te çalışırken Linux host üzerinden x86_64/aarch64 macOS hedefli C/C++/Fortran/Rust çapraz derleme üzerinde çalışmıştım
      Posit Package Manager’dan (https://p3m.dev/client/) native kod içeren R paketleri indirirseniz, bunlar bu yöntemle çapraz derlenmiştir :)
    • Kendim denedim. USB portunu bir şekilde Docker’ın ötesine paylaşmam gerekti; depodaki talimatlara göre neredeyse kara büyü gibiydi ama iOS uygulamasını derledikten sonra iPhone’da çalıştırabildim
    • Windows makine üzerindeki bu ortamda native Swift modülleri olan React Native iOS derleyip simülatörde çalıştırmak mümkün olursa etkileyici olur

  • Daha önce Sick Codes ile bu ürün yaklaşımı hakkında röportaj yapmıştım: https://www.vice.com/en/article/akdmb8/open-source-app-lets-...
    Benzer bir işi Proxmox ev sunucusunda yapan OSX-PROXMOX da var: https://github.com/luchina-gabriel/OSX-PROXMOX
    Kişisel olarak HP Z420 Xeon’da ikincisini kullanıyorum; özellikle GPU passthrough eklenince çok kararlı

  • Ev sunucusunda iCloud senkronizasyonu çalıştırabilsem iyi olurdu. Şu anda iCloud’u ev sunucusuna/NAS’a fiziksel olarak yedeklemenin iyi bir yolu yok ve yalnızca Windows/Apple’da çalışıyor

    • Bu, veriyi senkronize ettikten sonra yerelde saklamaya veya başka bir yere yedeklemeye yardımcı olabilir:
      https://github.com/steilerDev/icloud-photos-sync
      https://github.com/icloud-photos-downloader/icloud_photos_do...
    • OSX-Docker ve OSXPhotos kullanan bir çözüm üzerinde çalışıyorum. Epey yaklaştım ama iCloud’daki tüm bilgileri yedeklerken metadata değişikliklerini de dahil etmek istiyordum
      Meğer iCloud orijinal fotoğrafları güncellemiyormuş. Anlaşılır bir şey ama yedekleme yaparken bu değişikliklerin de içinde olmasını bekleyen biri için pek işe yaramıyor
    • Bunun o soruna nasıl yardımcı olduğunu merak ediyorum. Bağlı bir Mac/PC’deki iCloud klasörünü NAS’a rsync etmekle karşılaştırıldığında neyi farklı yapmayı sağlıyor?

  • MacOS imajlarının yeniden dağıtımına lisans açısından izin verilip verilmediğini merak ediyorum. Yoksa bu proje Docker Hub’da korsan kopyaları açıkça mı dağıtıyor?

    • Emin değilim ama Corellium iOS instance’larını sanallaştırmıştı; Apple tarafından dava edildi ve sonra uzlaştılar
    • Bu açıkça yasa dışı

  • Intel desteği çıkarılmış daha yeni MacOS sürümleri gelirse ilerlemenin durup durmayacağını merak ediyorum
    Bu container içinde Docker çalıştırıp MacOS içinde MacOS çalıştırabilir miyiz? ;)

    • Teoride qemu’yu her zaman tam emülasyon modunda çalıştırabilirsiniz
    • Desteklenen herhangi bir VM programında zaten bunu yapabilirsiniz

  • “USB passthrough” ifadesinin gerçekte olsa olsa “Ethernet üzerinden USB proxy” olduğu durumlarda kullanılmasından gerçekten nefret ediyorum
    Bu passthrough değil. Normal passthrough’da olmayan, hatta gelişmiş passthrough’da bile olmayabilecek birçok dezavantaj getiriyor

    • QEMU USB passthrough gerçekten USB passthrough’dur. USB passthrough’daki sorunlar USB denetleyicisinin kendisinden ve cihaz enumerasyon biçiminden kaynaklanır; daha iyi tek çözüm USB denetleyicisinin tamamını PCIe passthrough ile aktarmaktır
      Ama o yöntemin de başka sorunları var. Aktarılan donanımı çok olan büyük ölçekli VM test çiftlikleri çalıştırma deneyimime dayanarak söylüyorum
      Yine de “Ethernet üzerinden USB proxy” de gerçek passthrough’dur; sadece VirtIO’ya göre daha yüksek gecikmeye sahip bir passthrough’dur