Re: Avonturen met virt-manager en wine
Paul van der Vlis schreef op di 14-09-2021 om 15:53 [+0200]: > Op 14-09-2021 om 15:50 schreef Paul van der Vlis: > > Ik had altijd begrepen dat ze alleen groeiden, en nooit kleiner > > werden. > > Dat je daarvoor een conversie moet doen die veel ruimte kost. Ik > > zit hiermee bijvoorbeeld met mijn mailserver, daar wordt veel > > gewist. > > Dit staat er in mijn aantekeningen, om te verkleinen: > qemu-img convert -p -O qcow2 kvm52.qcow2 kvm52-klein.qcow2 > > Maar dan heb je dus tijdelijk veel ruimte nodig. > > Misschien dat trim het ook zelf kan... Windows-VM's doen voor zover ik gevonden heb geen discard/trim op schijven die via de "virtio" bus zijn aangesloten. In elk geval niet automatisch. Als je de disks via een (Virtio) SCSI controller op de VM aansluit gebeurt dit wél. De .qcow2 files op de host worden na zo'n discard ook kleiner. (dit werkt ook als je "sparse volumes" in LVM gebruikt in plaats van qcow-bestanden) -Martijn
Re: Avonturen met virt-manager en wine
Op 14-09-2021 om 15:50 schreef Paul van der Vlis: Ik had altijd begrepen dat ze alleen groeiden, en nooit kleiner werden. Dat je daarvoor een conversie moet doen die veel ruimte kost. Ik zit hiermee bijvoorbeeld met mijn mailserver, daar wordt veel gewist. Dit staat er in mijn aantekeningen, om te verkleinen: qemu-img convert -p -O qcow2 kvm52.qcow2 kvm52-klein.qcow2 Maar dan heb je dus tijdelijk veel ruimte nodig. Misschien dat trim het ook zelf kan... Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Avonturen met virt-manager en wine
Hallo Wouter en anderen,
Op 14-09-2021 om 13:55 schreef Wouter Verhelst:
Hoi Paul,
Persoonlijk werk ik liever met system VMs (en zelfs virsh geeft je een
warning als je user context VMs probeert aan te maken), maar de keuze is
er dus.
Op een server is dat inderdaad beter, maar ik was hier bezig in een
desktop context. Windows applicaties draaien onder Linux.
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,2Gdebian.qcow2
Wat raar zeg, blijkbaar geeft ls -lh dus niet altijd de juiste waarde??
Toch wel, maar wat het je toont is niet wat jij denkt dat het is ;-)
>
"ls -l" geeft je de apparent size; "ls -s" geeft je de hoeveelheid
blocks die in gebruik zijn. De twee zijn niet dezelfde waarde
Is hier misschien iets aan veranderd?
Nee hoor; sparse files bestaan al *heel* lang. Wikipedia legt redelijk
goed uit hoe ze functioneren:
https://en.wikipedia.org/wiki/Sparse_file
Ik dacht dat ik op de server wel de gebruikte ruimte kreeg met "ls -lh",
maar misschien moet ik dit beter controleren.
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).
Gut, bij mij doen de Linux VM's dat niet. Ik moet wellicht de host
upgraden.
Het kan ook gewoon config binnen de VM zijn hoor. Kijk na of je
trim/discard aan hebt staan op je mounted filesystems.
Alternatief heb ik misschien een foutje gemaakt en doet qemu helemaal
geen fallocate() om het bestand terug sparse te maken, maar worden
alleen sparse files aangemaakt bij het aanmaken van de VM. Deze VM is
nog niet zó geweldig veel gebruikt, dus het kan zijn dat dat de reden is
dat het bestand nog niet helemaal gealloceerd is...
Ik had altijd begrepen dat ze alleen groeiden, en nooit kleiner werden.
Dat je daarvoor een conversie moet doen die veel ruimte kost. Ik zit
hiermee bijvoorbeeld met mijn mailserver, daar wordt veel gewist.
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
Interessant, vooral die "dir" kende ik nog niet.
Eh, dat is de default, en is waarschijnlijk ook degene die je gebruikt ;-)
("dir" maakt gewoon .qcow2-bestanden aan in een directory ergens op het
bestandssysteem)
Ah. Ik dacht even dat je de gegevens ook gewoon direct in een directory
kon zetten, zoals bij een chroot. Maar dus niet.
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Re: Avonturen met virt-manager en wine
Hoi Paul,
On Sat, Sep 11, 2021 at 10:38:01PM +0200, Paul van der Vlis wrote:
> Op 08-09-2021 om 17:44 schreef Wouter Verhelst:
[...]
> > Je weet dat dat niet toegestaan is volgens de licentie?
>
> Nee, wist ik niet precies. Maar was te verwachten.
Tjah :)
[...]
> > > 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.
>
> Bij nader inzien had ik dat waarschijnlijk ook gedaan.
>
> > 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.
>
> Aha. Zal ik in mijn gedachten houden. Wellicht beter inderdaad.
Goh. In sommige situaties is dat handiger, ja, maar zeker niet altijd;
vooral als je geen systemd gebruikt is dat geen goed idee (want dan
worden je VMs niet correct afgesloten bij het afsluiten van het
systeem). Ook is een VM in user context niet direct beschikbaar van
buiten het virtuele netwerk (zelfs niet vanop de host), omwille van
NAT-only netwerken en zo.
Persoonlijk werk ik liever met system VMs (en zelfs virsh geeft je een
warning als je user context VMs probeert aan te maken), maar de keuze is
er dus.
[...]
> > > 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,2Gdebian.qcow2
>
> Wat raar zeg, blijkbaar geeft ls -lh dus niet altijd de juiste waarde??
Toch wel, maar wat het je toont is niet wat jij denkt dat het is ;-)
"ls -l" geeft je de apparent size; "ls -s" geeft je de hoeveelheid
blocks die in gebruik zijn. De twee zijn niet dezelfde waarde
> Is hier misschien iets aan veranderd?
Nee hoor; sparse files bestaan al *heel* lang. Wikipedia legt redelijk
goed uit hoe ze functioneren:
https://en.wikipedia.org/wiki/Sparse_file
> > 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).
>
> Gut, bij mij doen de Linux VM's dat niet. Ik moet wellicht de host
> upgraden.
Het kan ook gewoon config binnen de VM zijn hoor. Kijk na of je
trim/discard aan hebt staan op je mounted filesystems.
Alternatief heb ik misschien een foutje gemaakt en doet qemu helemaal
geen fallocate() om het bestand terug sparse te maken, maar worden
alleen sparse files aangemaakt bij het aanmaken van de VM. Deze VM is
nog niet zó geweldig veel gebruikt, dus het kan zijn dat dat de reden is
dat het bestand nog niet helemaal gealloceerd is...
> > 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
>
> Interessant, vooral die "dir" kende ik nog niet.
Eh, dat is de default, en is waarschijnlijk ook degene die je gebruikt ;-)
("dir" maakt gewoon .qcow2-bestanden aan in een directory ergens op het
bestandssysteem)
Groeten,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Avonturen met virt-manager en wine
Op 08-09-2021 om 17:44 schreef Wouter Verhelst: 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? Nee, wist ik niet precies. Maar was te verwachten. 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 0x, DMI type 0, 26 bytes BIOS Information Vendor: Dell Inc. Version: 1.16.3 Release Date: 03/05/2021 Address: 0xF 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 Dat laatste commando opent een editor, en daar zorg je er dan voor dat er dit in staat: 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! Bedankt! (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 Oh kijk! 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 wo
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 0x, DMI type 0, 26 bytes BIOS Information Vendor: Dell Inc. Version: 1.16.3 Release Date: 03/05/2021 Address: 0xF 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 Dat laatste commando opent een editor, en daar zorg je er dan voor dat er dit in staat: 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. Al
Avonturen met virt-manager en wine
Hallo, Ik heb niet zoveel ervaring met het draaien van Windows programma's onder Linux, maar ik heb een klant die dat graag wou. Wat hier onder staat gaat over Debian 11. In het verleden heb ik wat matige ervaringen gehad met Wine, daarom ben ik wat kritisch tegenover dat programma. Bij mijn klant had ik daarom aangeraden om maar een virtuele machine te gebruiken. In het verleden heb ik voor klanten wel Virtualbox geïnstalleerd, maar dat zit niet meer in Debian en daarom gebruik ik het liever niet. Een punt was in het verleden ook, dat als er een nieuw kernel kwam, dan moest je de modules opnieuw compileren. Bij zoiets kan natuurlijk iets fout gaan. Ik weet eigenlijk niet zeker of dit nog steeds zo is. Maar goed, ik dus maar eens virt-manager geprobeerd. Gewoon simpel te installeren met "apt install virt-manager", en dan neemt hij meteen ook Qemu, KVM, en dergelijke mee. Klant had me Windows XP meegeleverd. Dat installeerde prima en heeft als voordeel dat het erg weinig geheugen gebruikt. Echter, om het prettig te laten functioneren heb je binnen Windows iets nodig wat "spice guest tools" heet. En dat bleek niet te werken in XP. Je hebt die spice tools nodig voor dingen als copy/paste tussen host en client, maar ook om de muis soepel te switchen tussen beide systemen, en voor een betere grafische driver. Na het installeren van die tools had ik nog maar 4 kleuren, het zag er niet uit. Later las ik dat XP niet meer gesupport werd. Hier zijn die tools te downloaden: https://www.spice-space.org/download.html Ik vond ze niet in Debian, terwijl ik de "virtualbox-guest-additions-iso" hier wel vind (in non-free). Dat XP niet goed functioneerde was een flinke tegenvaller. Daarom ben ik ook aan de slag gegaan met Wine. Eigenlijk ging dat vrij goed en soepel, alleen kreeg ik OLE foutmeldingen tijdens de installatie. Mocht iemand weten wat ik daar tegen kan doen, dan hoor ik dat graag. Daarna functioneerde het programma, maar was het niet mogelijk om bijvoorbeeld een foto te verplaatsen met "drag en drop" in de applicatie. Gewone copy/paste deed het wel. Maar een punt bij Wine vind ik altijd, dat je nooit zeker weet of het blijft functioneren, of dat je toch later nog dingen vind die niet functioneren. Ik vond het dus wat onzeker, zeker omdat de klant ver weg woont. 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. 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. 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. Wat me nog negatief opviel was dat je alleen virtuele harddisks kon aanmaken die de volledige grootte hebben. 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. De klant wou niet dat Windows bij het internet kon. Wat ik gedaan heb is na installatie de virtuele netwerkkabel verwijderd, dat is ook simpel aan en uit te zetten in de eigenschappen van de virtuele machine (bij de netwerk kaart). De netwerk kaart verwijderen had vast ook gekund. Waar ik ook naar gekeken heb is een soort gedeelde map tussen client en host, maar dat is me niet gelukt. Nu ja, via een USB-stick. Omdat de klant geen netwerk wou heb ik geen Samba geprobeerd, dat had het waarschijnlijk wel gedaan. Wat ik wel geprobeerd heb is iets wat in die Spice-guest-tools zit en wat "Spice Webdav deamon" heet, dit zou
