Tóm tắt nhanh
- LSW cài Windows vào máy ảo, đưa từng cửa sổ ứng dụng ra desktop Linux và cho phép sử dụng GPU của máy chủ.
- Cấu hình được dự án thử nghiệm gồm Linux x86-64 có KVM, desktop Wayland/KDE Plasma và GPU có trình điều khiển Vulkan.
- Người dùng Arch có thể cài gói lsw-bin từ AUR, sau đó dùng LSW Manager để cài Windows và mở ứng dụng.
- Đây vẫn là bản alpha: ứng dụng mở được chưa đồng nghĩa làm việc ổn định, còn RAM cấp cho máy ảo sẽ làm giảm phần dành cho Linux.
LSW đưa ứng dụng Windows lên desktop Linux theo cách khác Wine: giữ một hệ điều hành Windows thật trong máy ảo, nhưng chia sẻ GPU máy chủ thay vì bắt người dùng dành riêng một card đồ họa cho nó. Điểm đáng quan tâm là khả năng dùng phần mềm đồ họa cùng các ứng dụng Linux mà không phải liên tục chuyển hệ điều hành; đổi lại, người dùng vẫn phải nuôi cả Windows bên dưới.
Với người đang muốn chuyển máy làm việc sang Linux nhưng còn phụ thuộc Photoshop, Affinity hoặc Microsoft 365, đây là một hướng thử có cơ sở kỹ thuật rõ ràng. Tuy nhiên, trạng thái alpha và các lỗi đã xuất hiện khiến LSW phù hợp với một môi trường thử nghiệm hơn là nơi duy nhất lưu công việc đang làm dở.
LSW giữ Windows thật, còn GPU được chia sẻ với Linux
Khác biệt quan trọng nhất nằm ở nơi ứng dụng thực sự chạy. Wine cung cấp lớp tương thích để phần mềm Windows hoạt động mà không cần cài cả hệ điều hành Windows; LSW thì cài Windows vào máy ảo, nên ứng dụng vẫn làm việc với môi trường Windows bên trong. Cửa sổ hiện trên Linux không có nghĩa phần mềm đã trở thành ứng dụng Linux nguyên bản.
Kiến trúc này chia công việc thành các phần tương đối rõ. LSW Manager quản lý cài đặt và vận hành máy ảo thông qua libvirt, còn dịch vụ phía Windows thực hiện tác vụ trong hệ điều hành khách. Thành phần remotewin phụ trách đưa cửa sổ ra desktop: mỗi ứng dụng có một tiến trình tương ứng trên máy chủ, quản lý hình ảnh, thao tác nhập liệu, menu và nhận diện trên thanh tác vụ. Vì vậy, người dùng có thể tương tác với từng ứng dụng thay vì luôn nhìn vào một màn hình Windows nằm trong khung máy ảo.
Phần đồ họa do accel-virt xử lý. Trình điều khiển WDDM avgpu.sys cùng các trình điều khiển ở không gian người dùng trong Windows chuyển lệnh qua thiết bị QEMU đã được chỉnh sửa; Linux thực thi công việc đó trên GPU của mình thông qua Vulkan, EGL hoặc OpenCL. Với Direct3D, hệ thống còn sử dụng DXVK và vkd3d-proton. Nói LSW không phải Wine là đúng, nhưng hiểu thành toàn bộ đường xử lý đồ họa không có bước chuyển đổi nào thì lại sai.
Cách chia sẻ này khác việc gán trực tiếp một GPU cho máy ảo bằng PCIe passthrough. GPU vẫn phục vụ desktop Linux, trong khi Windows gửi công việc qua lớp trình điều khiển riêng; không cần mặc định chuẩn bị một card thứ hai chỉ để dành cho hệ điều hành khách. Đổi lại, tốc độ và tính tương thích vẫn phụ thuộc GPU, driver, API mà ứng dụng sử dụng và chất lượng triển khai của LSW.
Theo tài liệu dự án, Direct3D 11 hỗ trợ đến feature level 12_1, Vulkan ở mức 1.3 và OpenGL đến 4.6; Direct3D 12 phụ thuộc khả năng mà vkd3d-proton cung cấp trên GPU máy chủ. OpenCL được liệt kê ở mức 3.0, nhưng máy chủ cần có driver OpenCL tương ứng. Đây là phạm vi API được công bố, không phải cam kết rằng mọi phần mềm dùng các API ấy đều hoạt động hoàn chỉnh.
Đường truyền hình ảnh cũng có điều kiện: ở cấu hình cho phép, khung hình của cửa sổ được giữ trên GPU thay vì sao chép ngược qua máy ảo; nếu không, hình ảnh phải đi qua mạng của hệ điều hành khách dưới dạng điểm ảnh. Vì vậy, không nên lấy việc Windows nhận tên GPU trong Device Manager làm bằng chứng rằng hiệu năng đã ngang cài Windows trực tiếp.
Cài trên Arch và KDE trước, rồi mới tính đến cấu hình khác
Lộ trình ít biến số nhất là bắt đầu từ cấu hình mà dự án đã thử, thay vì đồng thời đổi bản phân phối, desktop và driver. Tài liệu LSW yêu cầu Linux x86-64 có KVM, tài khoản người dùng mở được /dev/kvm, desktop Wayland và driver Vulkan cho GPU. Cơ chế đặt cửa sổ sử dụng KWin, còn KDE Plasma là môi trường được kiểm thử; chỉ có Wayland chưa đủ để suy ra mọi compositor đều được hỗ trợ tương đương.
Theo dự án, GPU AMD, Intel và NVIDIA đều đã được thử nghiệm, nhưng điều đó không bao phủ mọi mẫu card hay phiên bản driver. Máy ảo chạy trong phiên libvirt của người dùng qua qemu:///session, không yêu cầu dịch vụ libvirtd hệ thống hoặc mặc định thêm tài khoản vào nhóm libvirt. Khi gặp lỗi quyền truy cập KVM, nên kiểm tra đúng điều kiện được tài liệu nêu thay vì tùy tiện mở rộng quyền quản trị.
Bước 1: cài gói LSW. Trên Arch hoặc bản phân phối tương thích, nếu đã có yay, lệnh cài được dự án hướng dẫn là:
yay -S lsw-binAUR là nơi phân phối gói do cộng đồng quản lý, vì thế cần xem thông tin và nội dung gói trước khi chấp nhận cài. README còn nêu lựa chọn tải gói lsw-<version>-x86_64.tar.zst từ GitHub Releases cho bản phân phối khác, nhưng gói được dựng theo thư viện của Arch nên có thể đòi hỏi phiên bản thư viện tương ứng. Không nên coi tarball này là bản cài dùng chung chắc chắn cho mọi hệ Linux.
Bước 2: chuẩn bị Windows rồi mở trình quản lý. Khởi chạy LSW Manager từ menu ứng dụng hoặc dùng lệnh:
lsw-managerTrong trình hướng dẫn, chấp nhận giấy phép Windows, chọn nguồn cài đặt, kích thước máy ảo và tài khoản Windows. Dự án yêu cầu Windows 11 24H2, build 26100 trở lên vì driver GPU cần WDDM 3.2. Nên chuẩn bị sẵn ISO hợp lệ: README có tùy chọn tải Windows, nhưng bản dùng thử được mô tả trên XDA từng gặp lỗi ở chức năng tải này, nên tình trạng thực tế có thể khác giữa các bản phát hành.
Quá trình cài đặt tự động tạo tài khoản Windows và thiết lập các thành phần cần thiết. Nếu trình hướng dẫn có tùy chọn lược bỏ ứng dụng hoặc thành phần Windows, đừng chọn mức mạnh nhất chỉ để giảm dung lượng. Việc bỏ cả Windows Update hay WebView2 có thể ảnh hưởng những phần mềm cần chúng; ở lượt cài đầu, giữ môi trường dễ kiểm tra lỗi thường có ích hơn một bản Windows gọn tối đa.
Bước 3: chia tài nguyên để Linux vẫn còn chỗ làm việc. Chọn CPU, RAM và dung lượng đĩa theo nhu cầu ứng dụng, nhưng tính cả phần mà desktop Linux đang sử dụng. Trong bản thử được XDA mô tả, đĩa tăng dần tới giới hạn đã đặt, còn RAM được giữ cho máy ảo suốt thời gian nó chạy. Việc đóng một cửa sổ ứng dụng vì thế chưa chắc đã trả lại bộ nhớ cho máy chủ nếu Windows bên dưới vẫn hoạt động.
Bước 4: cài và mở ứng dụng từ LSW Manager. Sau khi Windows hoàn tất thiết lập, có thể khởi chạy phần mềm qua trình quản lý; tính năng Run on VM nhận chương trình, bộ cài hoặc script cục bộ rồi chép vào Windows để thực thi. Chỉ dùng bộ cài đáng tin cậy, tương tự cách làm trên một máy Windows thông thường.
Với dữ liệu làm việc, README mô tả tính năng chia sẻ thư mục máy chủ thành ổ đĩa trong Windows, dùng virtio-fs và các thành phần tương ứng ở hệ điều hành khách. Máy chủ có thể cần virtiofsd. Nên thử trước bằng một thư mục chứa bản sao dữ liệu và kiểm tra đường đọc, ghi, mở lại tệp; việc cửa sổ ứng dụng hiện tốt không xác nhận rằng mọi chức năng chia sẻ đã sẵn sàng ở phiên bản đang cài.
Chỉ chuyển công việc sang LSW sau khi thử đủ một quy trình
Tiêu chí đáng dùng nhất là hoàn thành công việc với tệp thật, không phải chụp được một màn hình ứng dụng đang mở. Với phần mềm xử lý ảnh, cần kiểm tra từ mở tệp, chỉnh sửa, xem trước cho đến lưu và xuất kết quả; người dùng văn phòng cũng nên thử đúng loại tài liệu cùng những tính năng mình phụ thuộc. Một lỗi ở bước cuối vẫn có thể làm mất toàn bộ lợi ích của việc cài đặt dễ dàng.
Các ứng dụng như Affinity, Photoshop, Lightroom và Microsoft 365 đã có ghi nhận chạy được trong bài dùng thử, nhưng chưa có bộ benchmark kiểm soát để quy thành mức hiệu năng chung. Ngay với chỉnh ảnh RAW, thao tác xem trước và chuyển không gian làm việc vẫn có độ trễ; việc phần mềm nhận GPU không loại bỏ chi phí ảo hóa hoặc mọi nút thắt khác.
DaVinci Resolve cho thấy rõ sự khác nhau giữa khởi chạy và sử dụng được: bản Windows có thể cài, mở giao diện nhưng phát video bị nhấp nháy trong lần thử được công bố. Với ứng dụng vốn có bản Linux, thử bản đó trước sẽ bớt một lớp phức tạp. Còn trường hợp Autodesk Fusion, không nên quy toàn bộ chênh lệch tốc độ cho LSW khi lượng RAM được cấp cho máy ảo và lượng RAM có trên Windows chạy trực tiếp không giống nhau.
LSW cũng chưa phải lý do để bỏ Proton khi chơi game. Có trò chạy được và có trò không khởi chạy trong những lần thử ban đầu, chưa đủ cơ sở khẳng định độ tương thích rộng. Riêng anti-cheat, việc giữ Windows thật trong máy ảo không tự chứng minh cơ chế kiểm tra của trò chơi sẽ chấp nhận môi trường đó.
Một giới hạn khác cần cân nhắc là driver Windows hiện được ký thử nghiệm. Theo README, hệ điều hành khách phải bật test signing và dùng UEFI không nạp khóa Secure Boot. Đây là điều kiện của máy ảo Windows trong LSW, không phải chỉ dẫn tắt Secure Boot trên toàn bộ máy Linux; không nên thay đổi thiết lập bảo mật của máy chủ chỉ vì thấy yêu cầu này.
Dự án công bố giấy phép Apache-2.0 cho LSW, nhưng hai submodule accel-virt và remotewin vẫn ở trạng thái riêng tư tại thời điểm tài liệu được ghi nhận. Vì vậy, tải kho công khai chưa đủ để tự dựng toàn bộ hệ thống; README hướng người chưa có quyền truy cập sang gói AUR hoặc tarball phát hành. Điều này đáng lưu ý nếu khả năng tự kiểm tra và tự dựng toàn bộ mã nguồn là điều kiện bắt buộc của môi trường làm việc.
Với người dùng tại Việt Nam đang cân nhắc chuyển sang Linux để làm thiết kế hoặc văn phòng, cách hợp lý là giữ nguyên hệ thống đang dùng, thử LSW với bản sao công việc rồi mới quyết định. LSW không thay thế quyền sử dụng Windows hay giấy phép của ứng dụng bên trong. Chỉ khi các bước cần thiết đều ổn định trên đúng máy, đúng phiên bản phần mềm và đúng bộ tệp của mình, việc giảm phụ thuộc vào một phân vùng Windows riêng mới có cơ sở.
Khi báo lỗi, dự án yêu cầu nêu bản phân phối, GPU và phiên bản LSW, đồng thời cung cấp log của trình quản lý; lỗi thư mục chia sẻ còn có log riêng trong Windows. Ghi lại cấu hình đã chạy tốt trước khi cập nhật sẽ hữu ích, bởi chính dự án cảnh báo những bản phát hành sớm có thể làm hỏng chức năng từng hoạt động.
Nguồn tham khảo: Tài liệu và mã nguồn LSW trên GitHub; Bài dùng thử LSW của XDA Developers.
