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,2G debian.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}
Reply to: