Už jsem to minule nakousnul, mít na stole server s licenčním štítkem od Microsoftu, běžet na něm Linux a přitom potřebovat pro pitomou aplikaci plnohodnotný .NET 4 s WPF, který bohužel nezvládne Mono, ale zároveň taky využít potenciál Apache naplno, to vyloženě svádí k nějakému rozumnému využití této zahozené licence.
Z právního hlediska je možné používat OEM Windows na odpovídajícím počítači i virtualizované, pokud se tedy bude jednat pouze o jednu instanci a skutečně to bude to samé železo. Teorie je v tomto smyslu v pohodě, tak se prostě nahodí nějaký virtuál, napaští se do něj originální product code ze štítku na skříni a bude to, jakýpak s tím zbytečný crcání. Realita je ale bohužel trochu někde jinde.
Po zkoumání možností s pohodlím ovládání a mnoha nepohodlnými licenčními možnostmi VMwaru nakonec jako hypervizor zvítězilo KVM, resp. KVM/QEMU. Pokud by to nebyl produkční server a nebyl už uzpůsobený k mnoha jiným věcem, zřejmě by tam přišel Xen. Proti němu ale pro KVM stačí do běžícího stroje nahodit pár balíků, mít podporu virtualizace v jádře a samozřejmě odpovídající modul. Z hlediska managementu a právě kvůli pohodlí jsem vybral nástroje libvirt, které, doufám, budou schopné případě ošetřit i úplné trubky. Navíc se v tom dobře dělalo vzdáleně, kdy po celonoční kopii instalačního DVDčka stačilo do XQuartz začarovat ssh -X a už to jelo. Protože se v Debianu implicitně dělá su a ne sudo, celkem užitečným hackem hned po přihlášení může být cp .Xauthority /root/. Samotné rozjetí hypervizoru skutečně není potřeba nijak významně prožívat, postačí základní balíky qemu-kvm, libvrit-bin a pak virt-manager, který v tom zběsilém X11 forwardingu na ještě ke všemu pomalé lince obstál ze všech GUI nejlépe.
Instalace předaktivovaných Windows se zdařila, dokonce se povedla i následná změna product key s platnou aktivací a ověřením pravosti, bohužel bootloader při startu hlásil FATAL ERROR: SLIC table pointer isn't what it should be (RSDT). Asi by to vzhledem k tomu povedenému ověření při provozu nevadilo (kdo ví), bohužel bez úderu na klávesu systém nenabíhal, takže sny o automatickém spouštění virtuálu při startu samotného serveru se začaly rozplývat a mizet. Háček spočíval v tom, že KVM nepředalo do QEMU odpovídající tabulky BIOSu.
U toho je potřeba říct si hnedka tři věci. Za prvé, jednotlivé ACPI tabulky BIOSu jsou v /sys/firmware/acpi/tables/ jako 0400 root:root, takže k nim libvirt nemá přístup. Za další, BIOS sám o sobě není ve virtuálu vytvořeném narychlo ve virt-manageru definován. A za třetí, změny XML souborů s nastavením virtuálů se nedají editovat přímo, ale musí se na ně jít přes virsh edit {název-vm} - jako bonus si je to dokonce i zvaliduje.
Jako první je potřeba při editaci doplnit do XML pár uzlů, konkrétně sysinfo do kořene domain a referenci na něj v os. Informace nutné pro uzel bios se dají vyčíst z dmidecode -t 0 a informace pro system zas pomocí dmidecode -t 1. Nakládání s UUID je tady trochu zavádějící, protože musí korespondovat s UUID samotného virtuálního stroje, které bylo vytvořené na začátku tím grafickým managerem a změna neprojde. Jiná políčka taky můžou mít hodnoty To be filled by O.E.M., to pokud to nejsou vyloženě značkové servery.
To nejtěžší je ale explicitní odeslání skutečných ACPI tabulek BIOSu do QEMU, protože oni o něm nevědí. Není potřeba nic složitě patchovat, jak se dá po několika minutách googlování usuzovat, úplně stačí nakopírovat odpovídající tabulky (hlavně SLIC) z /sys/firmware/acpi/tables/ někam, kde bude mít virtuální stroj právo pro jejich čtení, u mě teda /etc/libvirt/acpitables/, kam byly prostě a jednoduše nakopírovány a chmodnuty na 0444.
Jejich samotné předání do QEMU může být oříšek, protože aby bylo možné specifikovat qemu:commandline uzel, potřebuje XML soubor dostat odpovídající namespace, v tomto případě xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'. Pak už by se to mělo nechat s nechybovou hláškou Domain {název-vm} XML configuration edited uložit a správně předat parametry pro QEMU.
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<name>{nazev vm}</name>
<uuid>{vygenerovane cokoliv}</uuid>
...
<sysinfo type='smbios'>
<bios>
<entry name='vendor'>{poskytovatel BIOSu}</entry>
<entry name='version'>{verze BIOSu}</entry>
<entry name='date'>{MM/DD/YYYY}</entry>
<entry name='release'>{release}</entry>
</bios>
<system>
<entry name='manufacturer'>{vyrobce HW}</entry>
<entry name='product'>{nazev HW}</entry>
<entry name='version'>{verze HW}</entry>
<entry name='serial'>{seriove cislo}</entry>
<entry name='uuid'>{UUID nemusi byt asi nutne UUID stroje, ale musi souhlasit s UUID VM}</entry>
<entry name='sku'>{SKU}</entry>
<entry name='family'>{family specifikace}</entry>
</system>
</sysinfo>
...
<os>
...
<smbios mode='sysinfo'/>
</os>
...
<qemu:commandline>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/etc/libvirt/acpitables/MSDM'/>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/etc/libvirt/acpitables/SLIC'/>
</qemu:commandline>
</domain>
Bootloader virtuální OS tak konečně najde, co hledá, a nezasekne se s očekáváním stisku klávesy, zatímco si bude kvůli vlastnímu režimu brát 100 % přiděleného času CPU. No a je to. Perfektně legální virtualizované OEM. Pokud by tu mělo hrát roli ještě UEFI, byla by celá situace o několik úrovní horší, protože by bylo nutné zřejmě ručně vytvořit odpovídající diskové obrazy pro zavádění a podepsat je. A to by byla poněkud vyšší magie, snad to nikdy nebude potřeba… :)