În general, dacă puteți obține o rădăcină tarball a VM-ului, ar trebui (teoretic) să fie destul de simplu, deși nu l-am încercat. Principalul truc va fi obținerea rootfs.tar
„doar corect”. Considerații:
Va trebui să includă toate sistemele de fișiere „normale” din VM, dar, desigur, puteți ignora lucruri precum /proc
, /sys
, /dev
, etc.
Ar trebui să includeți --xattrs
marcați în tar pentru a vă asigura că preluați orice atribute extinse. Acesta nu este implicit.
Odată ce aveți un tarball rootfs valid, importarea în WSL este ușor:
wsl --import Ubuntu2110 <director> <tarball> --versiunea 2
Primul argument (numele distribuției) poate fi orice preferi, deși aș recomanda evitarea Ubuntu
deoarece acesta este numele distribuției WSL implicite și ar putea provoca un conflict.
Tind să-mi configurez „directorul” WSL:
- Undeva ușor accesibil din PowerShell, cum ar fi
~\Documente\WSL
- Avea
~\Documents\WSL\instances\Ubuntu2110
(și altele) pentru distribuțiile mele
- Avea
~\Documents\WSL\images\Ubuntu2110.tar
(și altele) pentru imaginile mele rootfs.
Stratul hardware are șanse mari să difere.
Nu chiar problema pe care ați putea crede. Instanțele WSL2 sunt de fapt mai multe „containere” decât VM. Acolo este un VM care rulează, dar nu îl puteți accesa. VM-ul în sine este cel care se ocupă de importul și rularea distribuțiilor/instanțelor/containerelor. Toate instanțele WSL2 partajează același spațiu kernel, hardware virtual, rețea etc., dar fiecare are propriul spațiu de nume PID, chroot etc. (pentru a exagera).
Diferențele dintre WSL și VM-ul dvs
Pornirea sistemului
Cea mai mare diferență pe care o veți găsi este că VM-ul își face toată configurația prin Systemd, desigur. Acest lucru nu se va întâmpla pe WSL2, deoarece Systemd nu este acceptat. În schimb, WSL folosește propriile sale /init
pentru pornirea interoperabilității cu sistemul VM și Windows.
Asta înseamnă că, atunci când porniți instanța WSL2 din VM importată, aproape nimic va rula.
Va trebui să porniți manual fiecare serviciu. Sau folosiți alte tehnici pentru a porni automat.
Alte probleme Systemd
Deși puteți porni multe servicii în Ubuntu fără Systemd, tot mai mulți se bazează pe Systemd. Acestea pot fi problematice sub WSL. Deși există soluții pentru a rula Systemd în WSL, acestea tind să fie „hacky” în prezent.
Aplicații GUI
De asemenea, amintiți-vă că WSL este în primul rând un mediu de linie de comandă. Pentru a rula aplicații GUI, va trebui să rulați fie:
- Windows 11
- Un server X terț în Windows
- Sau
xrdp
Medii desktop
În cele din urmă, mediile desktop pot fi și mai provocatoare, dintr-o combinație a motivelor de mai sus și mai mult:
- Unele necesită Systemd
- Rularea aplicațiilor GUI Linux pe ecran complet în Windows poate prezenta provocări de legare a tastelor (de ex. Alt+Tab va fi interceptat de Windows și se va îndepărta de DE).
- WSLg în Windows 11 utilizează Weston, care oferă propriul manager de ferestre