Nói chung, nếu bạn có thể có được rootfs tarball'd của VM, thì (về lý thuyết) nó sẽ khá đơn giản, mặc dù tôi chưa thử. Thủ thuật chính sẽ nhận được rootfs.tar "đúng rồi". Cân nhắc:
Nó sẽ cần bao gồm tất cả các hệ thống tệp "bình thường" từ VM, nhưng tất nhiên, bạn có thể bỏ qua những thứ như /proc, /sys, / nhà phát triển, vân vân.
Bạn nên bao gồm --xattrs gắn cờ với tar để đảm bảo bạn chọn bất kỳ thuộc tính mở rộng nào. Đây không phải là mặc định.
Khi bạn có một tarball rootfs hợp lệ, việc nhập vào WSL thật dễ dàng:
wsl --nhập Ubuntu2110 <thư mục> <tarball> --version 2
Đối số đầu tiên (tên phân phối) có thể là bất kỳ thứ gì bạn thích, mặc dù tôi khuyên bạn nên tránh Ubuntu vì đây là tên của bản phân phối WSL mặc định và có thể gây ra xung đột.
Tôi có xu hướng thiết lập "thư mục" WSL của mình:
- Một nơi nào đó dễ dàng truy cập từ PowerShell, chẳng hạn như
~\Documents\WSL
- Có
~\Documents\WSL\instance\Ubuntu2110 (và những người khác) cho bản phân phối của tôi
- Có
~\Documents\WSL\images\Ubuntu2110.tar (và những thứ khác) cho hình ảnh rootfs của tôi.
Lớp phần cứng có cơ hội tốt để khác biệt.
Không thực sự là vấn đề bạn có thể nghĩ. Các phiên bản WSL2 thực sự là nhiều "vùng chứa" hơn VM. Ở đó Là một máy ảo đang chạy, nhưng bạn không thể truy cập vào nó. Bản thân VM là thứ xử lý việc nhập và chạy các bản phân phối/phiên bản/bộ chứa. Tất cả các phiên bản WSL2 đều chia sẻ cùng một không gian nhân, phần cứng ảo, mạng, v.v., nhưng mỗi phiên bản đều có không gian tên PID, chroot, v.v. (để tóm tắt lại).
Sự khác biệt giữa WSL và máy ảo của bạn
khởi động hệ thống
Tất nhiên, sự khác biệt lớn nhất mà bạn sẽ tìm thấy là VM thực hiện tất cả cấu hình của nó thông qua Systemd. Điều đó sẽ không xảy ra trên WSL2 vì Systemd không được hỗ trợ. Thay vào đó, WSL sử dụng riêng của mình /trong đó để khởi động khả năng tương tác với hệ thống VM và Windows.
Điều đó có nghĩa là khi bạn khởi động phiên bản WSL2 từ máy ảo đã nhập, gần như không có gì sẽ được chạy.
Bạn sẽ cần bắt đầu từng dịch vụ theo cách thủ công. Hoặc dùng các kỹ thuật khác để bắt đầu tự động.
Các sự cố Systemd khác
Mặc dù bạn có thể bắt đầu nhiều dịch vụ trong Ubuntu mà không cần Systemd, nhưng ngày càng có nhiều dịch vụ dựa vào Systemd. Đó có thể là vấn đề theo WSL. Mặc dù có các giải pháp thay thế để chạy Systemd trong WSL, nhưng hiện tại chúng có xu hướng "hacky".
Ứng dụng GUI
Ngoài ra, hãy nhớ rằng WSL là chủ yếu một môi trường dòng lệnh. Để chạy các ứng dụng GUI, bạn sẽ cần chạy:
- cửa sổ 11
- Máy chủ X của bên thứ ba trong Windows
- Hoặc
xrdp
Môi trường máy tính để bàn
Cuối cùng, môi trường máy tính để bàn có thể còn khó khăn hơn, vì sự kết hợp của các lý do trên và hơn thế nữa:
- Một số yêu cầu Systemd
- Chạy các ứng dụng GUI Linux toàn màn hình trong Windows có thể đưa ra các thách thức về liên kết phím (ví dụ: thay thế+Chuyển hướng sẽ bị Windows chặn và chuyển khỏi DE của bạn).
- WSLg trong Windows 11 sử dụng Weston, cung cấp trình quản lý cửa sổ riêng
