QEMU/KVM: Proste przekierowanie urządzenia USB do VM

Cześć!

Gdybyśmy potrzebowali skorzystać bezpośrednio z urządzenia usb hosta (pendrive, karta sieciowa, cokolwiek innego) to możemy bez problemu przekierować takie urządzenie do VMki.

Sprawdzamy identyfikator poleceniem lsusb. Mnie interesuje poniższe urządzenie:

Bus 002 Device 003: ID 05e3:0754 Genesys Logic, Inc. USB3.0 Card Reader

Do maszyny wirtualnej dopisujemy:

-device qemu-xhci,id=xhci \

-device usb-host,vendorid=0x05e3,productid=0x0754

Powyższa sztuczka zadziała tylko z uprawnieniami roota (np sudo). Żeby użytkownikowi przydzielić "prawo" korzystania z urządzenia w VMce to musimy plik /etc/udev/rules.d/99-qemu-usb.rules o poniższej zawartości:

SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", MODE="0666"

Dodatkowo Jeżeli interesuje nas "prawo" do podpinania każdego urządzenia, to zamiast powyższej regułki możemy dodać poniższą:

SUBSYSTEM=="usb", MODE="0666"

Dodatkowo należy wykonać (z roota):

udevadm control --reload

sudo udevadm trigger

Gdyby pojawił się u Was poniższy błąd:

qemu-system-x86_64: warning: dbind: Couldn't connect to accessibility bus: Failed to connect to socket /root/.cache/at-spi/bus_0.0: Permission denied

To wystarczy dodać swojego uzyszkodnika do grupy kvm:

gpasswd -a uzyszkodnik kvm

Przekierowania pci/pcie, o ile się da, pojawiają się w bliżej nieokreślonej przyszłości.

QEMU/KVM: Katalog współdzielony (virtio-9p, sshfs)

 Cześć!

Przydatną funkcją w wirtualizacji jest możliwość współdzielenia dowolnego katalogu hosta z gościem (lub na odwrót). Z natywnych rozwiązań mamy między innymi tftp, smb oraz 9p a zewnętrznych zadziała (prawie) wszystko co działa przez sieć.

Według manuala tftp działa w trybie tylko do odczytu, samba (smb) wymaga oddzielnego serwera na hoście a 9p działa z marszu. Wystarczy odpalić VMkę z poniższą opcją:

-fsdev local,id=nazwa,path=/sciezka/do/katalogu/,security_model=none -device virtio-9p-pci,fsdev=nazwa,mount_tag=nazwa.montowania

Na Linuksie montujemy w taki sposób:

mount -t 9p nazwa.montowania sciezka.montowania

Na Windowsie jest trochę więcej zabawy, bo nie ma aktualnie natywnego sterownika 9p dla Windowsów. Komunikacja po ftp u mnie jeszcze nie ruszyła, ale przecież dane można przesyłać także przez ssh. Do VMki dopisujemy następującą opcję:

-nic user,hostfwd=tcp::1111-:22

Windows ma ustawiony domyślny port. Dostęp z gościa do hosta uważam za mało bezpieczny, szczególnie gdy gościem jest Windows, dlatego sytuację odwróciłem. To nie Windows będzie zapisywał w udostępnionym katalogu a host będzie "pobierał" dane z Windowsa. Konfigurację ssh na Windowsie przedstawiłem w poprzednim wpisie.

No i mamy dostęp do plików, w tym przypadku do całej partycji systemowej:

sshfs -p 1111 Administrator@127.0.0.1:"C:/" punkt.montowania

Powyższe propozycje działają w "czasie rzeczywistym", tzn że zmiany widoczne są natychmiast. 

Są jeszcze trzy inne rozwiązania, ale wymagają wyłączania VMki za każdym razem, gdy chcemy przenieść dane do hosta...:
- pierwszą z nich jest wykorzystanie xorriso do wygenerowania obrazu iso (tryb tylko do odczytu)
- drugą opcją jest przekierowanie pamięci przenośnej po usb (o samym przekierowaniu w następnym wpisie) 
- trzecią z nich jest podpięcie dodatkowego dysku *.img do VMki i jego późniejsze konfigurację i montowanie przez losetup i loop na hoście
... Ale są niepraktyczne, sprawdziłyby się może w starych Windowsach pokroju 95 lub w DOSach.

Windows Server: SSH Server

Cześć!

Systemy Windows od jakiegoś czasu mają zintegrowaną obsługę serwera ssh. W uproszczeniu ssh to protokół sieciowy używany głównie do zdalnego zarządzania innymi komputerami.

Poniżej przedstawię bardzo szybką konfigurację ssh na przykładzie Windows Server 2025 (na innych wersjach zapewne wygląda to bardzo podobnie) w wersji "klikalnej" (za wersję tekstową może kiedyś się zabiorę). Najpierw włączamy funkcję w "menedżera serwera":

Następnie przechodzimy do "usług". Uruchamianie powinno być ustawione na auto.

Plik konfiguracyjny znajduje się w:

C:\ProgramData\ssh\sshd_config

Przed zmianą konfiguracji wypadałoby wcześniej zatrzymać usługę. Gdyby komuś była potrzebna możliwość logowania się na konto Administrator bez hasła, to szukamy następujących linijek:

PasswordAuthentication yes

PermitEmptyPasswords yes

PermitRootLogin yes

Pierwsza linijka umożliwia logowania się z hasłem w ogóle. Druga opcja umożliwia zalogowania się bez hasła, ale technicznie jest to równoznaczne z logowaniem się z "pustym hasłem" więc bez pierwszej opcji nie zadziała. Trzecia to możliwość logowania się na konto Administratora.

Dodatkowo:

gpedit.msc 

|-Computer Configuration 

 |-Windows Setting

  |-Security Settings

   |-Local Policies

    |-Security Options

     |-Accounts: Limit local account use of blank passwords to console logon only

Reguły Firewalla (wybrałem opcję z portem):

Usługę z powrotem włączamy.

Jako że u mnie Server 2025 działa w maszynie wirtualnej z przekierowaniem portu (1111 do 22), to sprawdzamy połączenie:

ssh -p 1111 Administrator@127.0.0.1

W miejscu 127.0.0.1 wpisujemy swoje IP lub nazwę PCta o ile taką ustawiliśmy.

I to wszystko.

QEMU/KVM: Wirtualny router z wykorzystaniem OpenWRT

Cześć!

Od kilku dni zastanawiałem się, czy jest możliwość połączenia kilku maszyn wirtualnych w jedną sieć 'bez sieci' (czyli stricte bez kabla i mostu na hoście). Docelowo zależało mi na działaniu bez uprawień root'a i bez ingerencji w konfigurację hosta.

Możliwości są dwie. Natywnie qemu/kvm umożliwia nam zestawienie wirtualnego połączenia dwóch maszyn (stream, mcast, socket itd) i tym dzisiaj nie będziemy się zajmować. Nas interesuje wirtualna sieć z wykorzystaniem vde_switch.

Na hoście (Debian) instalujemy:

apt install vdeplug vdens vde2-cryptcab vde2 vde-wirefilter vde-switch

Uruchamiamy przełącznik:

vde_switch

Domyślnym katalogiem "gniazd" jest /tmp/vde.ctl/ (można zmienić, zapraszam do manuala).

Do VMki dodajemy:

-netdev user,id=wan -device e1000,netdev=wan,mac=52:54:00:00:00:01 \

-netdev vde,id=lan,sock=/tmp/vde.ctl/ -device e1000,netdev=lan,mac=52:54:00:00:00:02

Koniecznie w takiej kolejności, żeby zachować kolejność nazewnictwa. wan powinien zostać nazwany jako eth0 a lan jako eth1.

OpenWRT ma bardzo małe wymagania sprzętowe, więc na obecnych komputerach nie powinniśmy odczuć jego działania. Jak ogarniemy sobie obraz (u mnie zadziałał obraz generic combined) to wystarczy uruchomić VMkę, wejść do konsoli enterem (domyślnie ustawione jest puste hasło) i wykonać następne polecenia:

uci set network.wan=interface

uci set network.wan.device='eth0'

uci set network.wan.proto='dhcp'

uci set network.lan=interface

uci set network.lan.device='eth1'

uci set network.lan.proto='static'

uci set network.lan.ipaddr='192.168.10.1'

uci set network.lan.netmask='255.255.255.0'

uci commit network

/etc/init.d/network restart

uci set dhcp.lan=dhcp

uci set dhcp.lan.interface='lan'

uci set dhcp.lan.start='100'

uci set dhcp.lan.limit='150'

uci set dhcp.lan.leasetime='12h'

uci commit dhcp

/etc/init.d/dnsmasq restart

uci commit

reboot

I tyle. Kolejne VMki należy odpalać z poniższą linijką:

-netdev vde,id=lan,sock=/tmp/vde.ctl/ -device e1000,netdev=lan,mac=52:54:00:00:00:xx

Należy tylko pamiętać o zmianach mac (xx) i ruszy z marszu.

W przyszłości w miejsce OpenWRT wleci Debian lub VyOS.

Info od AI to 15% sukcesu ;D reszta własny zamysł i wykonanie.

QEMU/KVM: Instalacja Windowsa bez TPM

Cześć!

Ostatnio "walczyłem" z emulacją TPM dla VM'ek qemu/kvm. Teraz pokażę 2 sposoby, jak zainstalować Windowsa bez emulacji TPMa.

Pierwszym z nich jest edycja rejestru w "locie", tzn w trakcie instalacji systemu. Na pierwszym ekranie korzystamy ze skrótu:

Shift + F10

W ten sposób uruchomimy cmd.exe (wiersz poleceń). Wpisujemy:

regedit

Przechodzimy do:

HKEY_LOCAL_MACHINE\SYSTEM\Setup

Tworzymy nowy klucz o następującej nazwie:

LabConfig

I tworzymy nowe wpisy DWORD 32.

BypassTPMCheck

BypassSecureBootCheck

BypassRAMCheck

Każdy kolejny wpis musi mieć wartość 1. I to wszystko.

Drugim sposobem jest edycja obrazu iso. Najpierw dociągamy (w Debianie) następujące paczki:

apt install wimtools chntpw xorriso

Obraz iso teoretycznie możemy zamontować z opcją loop, ale domyślnie zamontuje się w trybie tylko do odczytu. Ja, zamiast montowania, traktuję iso po prostu jak archiwum i rozpakowuję jakimkolwiek archiwerem (np 7zip).

Tworzymy dwa foldery:

mkdir obraz wim

Do folderu obraz należy wypakować iso. Do katalogu wim montujemy boot.wim:

wimlib-imagex mountrw obraz/sources/boot.wim 2 wim

"2" oznacza Microsoft Windows Setup. Zapraszam do manuala wimlib-imagex.

Następnie wykonujemy polecenie:

chntpw -e /dev/shm/win11vm.wim/Windows/System32/config/SYSTEM

Teraz kolejno wpisujemy poniższe polecenia (każde kolejne zatwierdzamy enterem):

cd Setup

nk LabConfig

cd LabConfig

nv 4 BypassTPMCheck

nv 4 BypassSecureBootCheck

nv 4 BypassRAMCheck

ed BypassTPMCheck

1

ed BypassSecureBootCheck

1

ed BypassRAMCheck

1

q

y

Zapisujemy zmiany:

wimlib-imagex unmount wim --commit

W celu utworzeniu obrazu wykonujemy:

xorriso \

 -as mkisofs \

 -iso-level 3 \

 -o obraz.bez.tpm.iso \

 -full-iso9660-filenames \

 -volid "obraz.bez.tpm" \

 -eltorito-boot boot/etfsboot.com \

 -no-emul-boot \

 -boot-load-size 8 \

 -boot-info-table \

 -eltorito-alt-boot \

 -e efi/microsoft/boot/efisys.bin \

 -no-emul-boot \

 -isohybrid-gpt-basdat obraz

I to wszystko.

Windows Server 2025 na dzień 2 kwietnia 2026 nie wymaga TPMa do działania (o ile nie potrzebujemy szyfrowania itd).