Re: Avonturen met virt-manager en wine
On Wed, Sep 01, 2021 at 04:08:40PM +0200, Paul van der Vlis wrote:
[...]
> Nu hoorde ik dat je Windows 10 ook gewoon als ISO kon downloaden. Een kennis
> had hier wat meer verstand van, en die heeft dat toen gedaan. Omdat ik hier
> vele oudere laptops heb, hebben we gewoon van een willekeurige laptop een
> Windows7 registratie-code afgehaald, en dat bleek te functioneren binnen de
> Windows10 Pro virtuele machine. Ook al was de (virtuele) hardware anders.
Je weet dat dat niet toegestaan is volgens de licentie? Die licentie is
enkel en alleen geldig voor de laptop waar de sticker op plakt.
Bij moderne hardware heb je geen sticker meer, maar zit er een
licentiecode in de ACPI tables (ten minste als je een laptop met Windows
erop koopt). Als dat het geval is, dan heb je onder
/sys/firmware/acpi/tables een bestand "MSDM" en een bestand "SLIC"
staan waarin de relevante gegevens te vinden zijn, en je kan die (mits
wat prullen) doorlussen naar een VM.
Op mijn laptop deed ik dat als volgt:
- dmidecode -t 0
Dat geeft de volgende uitvoer:
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: Dell Inc.
Version: 1.16.3
Release Date: 03/05/2021
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.16
- dmidecode -t 1
Uitvoer:
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: Latitude 5590
Version: Not Specified
Serial Number: D5X3HR2
UUID: 4c4c4544-0035-5810-8033-c4c04f485232
Wake-up Type: Power Switch
SKU Number: 0817
Family: Latitude
- cp /sys/firmware/acpi/tables/MSDM /var/lib/libvirt/images/MSDM.raw
- cp /sys/firmware/acpi/tables/SLIC /var/lib/libvirt/images/SLIC.raw
- Zorg ervoor dat je Windows VM niet draait en dat het bestaat.
- virsh edit <naam van Windows VM>
Dat laatste commando opent een editor, en daar zorg je er dan voor dat
er dit in staat:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<!-- rest van het bestand laten staan, niet aanpassen, en voeg op het einde dit toe: -->
<qemu:commandline>
<qemu:arg value='-smbios'/>
<qemu:arg value='type=0,vendor=Dell Inc.,version=1.16.3,date=03/05/2021,release=1.16'/>
<qemu:arg value='-smbios'/>
<qemu:arg value='type=1,manufacturer=Dell Inc.,product=Latitude 5590,serial=D5X3HR2,uuid=4c4c4544-0035-5810-8033-c4c04f485232,sku=0817,family=Latitude'/>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/var/lib/libvirt/images/SLIC.raw'/>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/var/lib/libvirt/images/MSDM.raw'/>
</qemu:commandline>
</domain>
Pas het tweede en vierde "qemu:arg" aan met de relevante informatie uit
de relevante "dmidecode" commando's.
Proficiat, je bent nu een geldige licentie aan het gebruiken!
(het zou wel handig zijn als virt-manager daar gewoon een vinkje voor
had, maar...)
> Ook die spice-guest-tools deden het prima. We hadden overigens gekozen voor
> de 32-bit versie van Windows10, omdat die veel minder geheugen nodig heeft
> (minimaal 1GB). Dus copy/paste van tekst werkt prima (iets anders heb ik
> niet geprobeerd), de muis gaat vloeiend naar de client, en het herschalen
> van het venster met de virtuele machine gaat prima. Ook kon ik USB-apparaten
> van de host redirecten. Overigens lukte dit niet met een SD-kaart-lezer,
> maar dat bleek geen USB device te zijn.
>
> Waar ik nog wel flinke problemen mee had was met het netwerk. Dat deed het
> in eerste instantie prima, alleen na een reboot van de host-machine niet
> meer. En daardoor wilden de virtuele machines niet meer starten. Na lang
> zoeken vond ik ergens in Virt-manager een optie om het netwerk automatisch
> te starten, als ik me niet vergis in "bewerken | verbinding details". Zonder
> dat starten de VM's niet, zelfs niet als ze geen netwerk kaart hebben.
Je kan ook dat in virsh doen:
net-autostart default
> Wat me nog opviel was dat virt-manager root rechten nodig heeft. Maar je
> kunt er vrij simpel voor zorgen dat hij dat blijvend krijgt door ergens een
> vinkje te zetten. De disks van je virtuele machines komen niet in je
> home-directory maar ergens in /var/lib/libvirt.
Je kan ook je gebruiker aan de juiste groep toevoegen:
sudo adduser wouter libvirt
Nu heeft de gebruiker 'wouter' rechten om de VMs in de "system" libvirtd
te beheren.
Alternatief is het ook perfect mogelijk om een libvirtd in
gebruikerscontext te draaien, maar dan kan je alleen NAT netwerken
gebruiken (naast een aantal andere minimale beperkingen). Als je dat
wilt proberen, dan doe je
Bestand -> Verbinding toevoegen... -> QEMU/KVM gebruikerssessie
VMs in een gebruikerssessie draaien onder de UID van de gebruiker ipv de
"libvirt" UID, en virtuele hard disks worden dan in
$HOME/.local/share/libvirt/images geschreven.
Je kan trouwens ook verbinden met een libvirt op een server op die
manier -- alle communicatie gebeurt dan over SSH.
En als je helemaal gek wilt gaan: je kan ook VMs live migreren tussen
twee libvirt daemons, op voorwaarde dat de twee daemons rechtstreeks met
elkaar kunnen communiceren en de CPU van beide servers voldoende op
elkaar lijkt (of de CPU-opties in de VM op de grootste gemene deler
ingesteld staat).
(live migratie is iets waar ik zelf nog niet mee gespeeld heb, net omdat
het redelijk complex is om juist op te zetten)
> Wat me nog negatief opviel was dat je alleen virtuele harddisks kon aanmaken
> die de volledige grootte hebben.
Nee, dat is niet correct:
root@pc181009:/var/lib/libvirt/images# ls -lh debian.qcow2
-rw------- 1 root root 21G 25 aug 18:33 debian.qcow2
root@pc181009:/var/lib/libvirt/images# du -sh debian.qcow2
2,2G debian.qcow2
Het bestand is een "sparse file": dat lijkt in mijn geval 21G groot te
zijn, maar neemt in werkelijkheid slechts 2.2G in beslag. Als het OS in
de VM ook de relevante trim/discard SCSI en ATA calls gebruikt, dan zal
qemu dat opnieuw vrijgeven (mijn Windows VM doet dat niet en gebruikt
dus de volledige content van de virtuele hard disk, maar mijn Linux VMs
doen het allemaal wel goed).
Je kan verder ook andere storage backends configureren:
rechtermuisknop op "QEMU/KVM" -> Details -> Storage -> op "+" klikken
onderaan links -> Type openklappen. Bij mij zie ik:
dir: Bestandssysteem map
disk: Fysiek schijf apparaat
fs: Pre-geformatteerd blok apparaat
gluster: Gluster Filesystem
iscsi: iSCSI doel
logical: LVM volume group
mpath: Multi-pad apparaat opsommen
netfs: Netwerk geëxporteerde map
rbd: RADOS Block Device/Ceph
scsi: SCSI host adapter
sheepdog: Sheepdog Filesystem
zfs: ZFS Pool
Sommige van die opties (bv Ceph en gluster) zijn interessant voor
clusters en maken live migratie eenvoudiger en sneller (maar dan heb je
wel de serverkant van de relevante software ergens nodig). Anderen zijn
interessant om andere redenen -- ik heb bv op mijn colo server ZFS
staan, en dan is een ZFS pool daarop wel zo handig (maakt dan ZFS
volumes aan en zo).
De meeste daarvan ondersteunen ook sparse storage (dat is zo voor ZFS
bijvoorbeeld), dus het probleem herhaalt zich niet.
> Normaal gebruik ik met Qemu disks die
> "groeien", dus als er meer ruimte nodig is worden ze groter. Dit lukte me in
> eerste instantie niet met virt-manager. Een 20GB harddisk voor een VM is dus
> echt 20GB groot. Het is vast mogelijk om het toch op een of andere manier te
> doen, eventueel buiten virt-manager.
Dat kan inderdaad ook, maar is dus niet nodig.
[...voor de rest geen opmerkingen...]
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Reply to: