This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DTs48kyBtANE01Gwm126mzdh7IIiws4Dl
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Je vais aller regarder, mais je n'ai pas de snapshot configuré... Enfin, normalement.

JB


--DTs48kyBtANE01Gwm126mzdh7IIiws4Dl--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZy86/gAKCRDFW/s/mMLX CMNLAQCLJicHGtdQYzEBHNs27VAfe3M6dRrO8OMELMUrtZYrKgEApTNpYmDty6Fn yGXq8jUjowD6TgaTvuA4Pq1oAzONEg4=
=pcec
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nCokz3kt3a88BGFgcjXN8SwzHVAfhKV1F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour à tous,

Depuis ce matin, j'essaie désespérément de lancer une machine virtuelle
Windows 10 sur une installation KVM. Je précise que cette installation fonctionnait parfaitement jusqu'à récemment (je ne l'utilise pas tous
les jours).

Les images sont sur un disque NFS.

Dans virt-manager, j'ai actuellement trois machines virtuelles. Une NetBSD 10, une Windows 7 pro et une Windows 10. Les deux premières fonctionnent parfaitement. Les paramètres de la troisième me semblent corrects, sauf que lorsque je lance la machine, la charge sur le serveur
NFS monte en flèche (typiquement, nfs possède 512 threads, la charge
monte à 512 durant plusieurs heures et y reste !), la machine hôte ne
répond quasiment plus (même la souris a du mal à bouger) et je n'arrive jamais à quelque chose d'utilisable. Les paramètres principaux pour la machine sont les suivants :
- 8 Go de ram (sur les 32 de l'hôte) ;
- 4 VCPU (sur les 20 CPU de l'hôte).

Le reste des paramètres est identique à ceux de la machine Windows 7.

Quelqu'un a-t-il déjà vu un tel comportement ?

Bien cordialement,

JB


--nCokz3kt3a88BGFgcjXN8SwzHVAfhKV1F--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZyzm5gAKCRDFW/s/mMLX CKvcAQDy5jydAgSvLH5T4bNiIG3b12J/fDFhei05ky+UKn0dIAEAzYjHNIVy0ljA vbtVmtXM9qqmarBifksjWQuexLo2oQQ=
=ztJ0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour

Le 07/11/2024 à 19:19, didier gaumet a écrit :

Le 07/11/2024 à 17:12, BERTRAND Joël a écrit :

    Bonjour à tous,

    Depuis ce matin, j'essaie désespérément de lancer une machine
virtuelle
Windows 10 sur une installation KVM. Je précise que cette installation
fonctionnait parfaitement jusqu'à récemment (je ne l'utilise pas tous
les jours).

[...]
L'une des possibilités (parmi bien d'autres) serait une mise-à-jour
Windows qui a mal tourné et rend le démarrage normal de Windows
impossible. Auquel cas peut-être que tu gardes la main lors du tout
début du démarrage et tu peux alors appuyer sur une ou des touche(s)
de fonction pour démarre en mode sans échec,

[...]

ou alors monté le fichier disque dans une autre VM comme second disque
et analyser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --urp1NKyNLqmsvv6cM2GdYALSowaqG0FNU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

didier gaumet a écrit :

Le 07/11/2024 à 17:12, BERTRAND Joël a écrit :

    Bonjour à tous,

    Depuis ce matin, j'essaie désespérément de lancer une machine
virtuelle
Windows 10 sur une installation KVM. Je précise que cette installation
fonctionnait parfaitement jusqu'à récemment (je ne l'utilise pas tous
les jours).

[...]
L'une des possibilités (parmi bien d'autres) serait une mise-à-jour
Windows qui a mal tourné et rend le démarrage normal de Windows
impossible. Auquel cas peut-être que tu gardes la main lors du tout
début du démarrage et tu peux alors appuyer sur une ou des touche(s) de fonction pour démarre en mode sans échec, avec ou sans le réseau, voire avec ou sans des périphériques (j'ai vraiment pas souvent utilisé le
mode sans échec et la dernière fois remonte à plusieurs années): https://stackoverflow.com/questions/41842509/libvirt-kvm-qemu-is-it-possible-to-boot-a-windows-guest-into-safe-mode

En fait, ça démarre. Mais le fonctionnement est erratique. Si je laisse
le truc assez longtemps, j'arrive à l'écran de connexion. Je peux même ouvrir un session (qui peut s'ouvrir correctement ou pas), mais tout est
d'une lenteur abominable en surchargeant le réseau local et le serveur
NFS. Ce que je n'avais pas auparavant.

JB


--urp1NKyNLqmsvv6cM2GdYALSowaqG0FNU--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZy0++QAKCRDFW/s/mMLX CCRSAP4kx8dzmMv0YSU0yGT1O7ERhc9IoUxY7EQZJuC8yqylUwEA+QBsg06YpBb5 G8n7S6CrVhPo6fmegD3NjaQuAzchbAE=
=5npS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bAca1rYYiGcR4zr7qVtboAhwdCioPPacH
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

didier gaumet a écrit :

Le 07/11/2024 à 23:28, BERTRAND Joël a écrit :

    En fait, ça démarre. Mais le fonctionnement est erratique. Si je >> laisse
le truc assez longtemps, j'arrive à l'écran de connexion. Je peux même
ouvrir un session (qui peut s'ouvrir correctement ou pas), mais tout est
d'une lenteur abominable en surchargeant le réseau local et le serveur
NFS. Ce que je n'avais pas auparavant.

au feeling, comme ça, ça ressemble plus à un problème dans l'invité Windows que dans l'environnement de l'hôte Debian...

Bonjour,

Pas certain du tout :

hilbert:[~/.local/share/libvirt/images] > ls -lh
-rw------- 1 bertrand users 21G 7 janv. 2023 netbsd10.0.qcow2
-rw-r--r-- 1 bertrand users 33G 7 nov. 16:50 Virtual10-disk001.qcow2 -rw------- 1 bertrand users 129G 7 nov. 16:42 win10.qcow2

Le disque utilisé par la VM est Virtual10-disk001.qcow2 (j'ai vérifié
dans la configuration de la VM). Or je viens de m'apercevoir qu'un autre
disque est créé par je ne sais qui et que ce disque fait... 128 Go !
Sans doute plus il faudrait que je laisse la VM aller jusqu'au bout.

Pour mémoire, la taille de Virtual10-disk001.qcow2 est de 128 Go :

hilbert:[~/.local/share/libvirt/images] > file Virtual10-disk001.qcow2 Virtual10-disk001.qcow2: QEMU QCOW Image (v2), 137438953472 bytes (v2), 137438953472 bytes
hilbert:[~/.local/share/libvirt/images] > file win10.qcow2
win10.qcow2: QEMU QCOW Image (v3), 137438953472 bytes (v3), 137438953472
bytes

et c'est bien la VM qui crée un autre fichier (au nom de la VM) et qui
sature le serveur NFS. Précédemment, ce n'était pas le cas.

Bien cordialement,

JB



--bAca1rYYiGcR4zr7qVtboAhwdCioPPacH--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZy2/rgAKCRDFW/s/mMLX CG6dAP9MJT0HBIoeK7r5sid1Azz1URE9bad3JYlJXqB4lafPeQD9ErOruHSVvKVz b2ewRihfz4j0aS3YZgkLWOLClUgpCg4=
=GKMV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L7zJvr88PYLf9pqiZjIZUpmjRb58MGoxD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

didier gaumet a écrit :

Le 08/11/2024 à 08:37, BERTRAND Joël a écrit :

    Bonjour,

    Pas certain du tout :

hilbert:[~/.local/share/libvirt/images] > ls -lh
-rw------- 1 bertrand users  21G  7 janv.  2023  netbsd10.0.qcow2
-rw-r--r-- 1 bertrand users  33G  7 nov.  16:50  Virtual10-disk001.qcow2 >> -rw------- 1 bertrand users 129G  7 nov.  16:42  win10.qcow2

    Le disque utilisé par la VM est Virtual10-disk001.qcow2 (j'ai vérifié
dans la configuration de la VM). Or je viens de m'apercevoir qu'un autre
disque est créé par je ne sais qui et que ce disque fait... 128 Go !
Sans doute plus il faudrait que je laisse la VM aller jusqu'au bout.

    Pour mémoire, la taille de Virtual10-disk001.qcow2 est de 128 Go : >>
hilbert:[~/.local/share/libvirt/images] > file Virtual10-disk001.qcow2
Virtual10-disk001.qcow2: QEMU QCOW Image (v2), 137438953472 bytes (v2),
137438953472 bytes
hilbert:[~/.local/share/libvirt/images] > file win10.qcow2
win10.qcow2: QEMU QCOW Image (v3), 137438953472 bytes (v3), 137438953472
bytes

et c'est bien la VM qui crée un autre fichier (au nom de la VM) et qui
sature le serveur NFS. Précédemment, ce n'était pas le cas.

    Bien cordialement,

    JB

Je suis loin de bien connaître kvm/qemu donc ce que j'avance est à
prendre avec des pincettes,

mais je suis resté sur l'impression qu'avec les options standard, l'occupation d'une image qemu sur un disque réel est dynamique, ce qui suggérerait que ton disque Windows est plein (128Go alloués, 128Go occupés) et il semblerait que dans ce cas (supposition, j'y connais rien
et je n'ai jamais entendu parler d'un tel comportement), qemu crée une
image temporaire pour éviter de planter la machine? (la dernière partie
est vraiment une pure hypothèse sans rien pour la soutenir)

Pas possible que le disque soit plein (il n'y a que W10 avec un logiciel de quelques Mo permettant de programmer un chip USB/RS232).

tu pourrais simplement essayer de forcer l'extinction de la VM Windows, porter la taille de l'image à 200G et redémarrer la machine: peut-être
que Windows se lancerait normalement (modulo une vérification NTFS au départ, probablement)?

Je ne peux pas forcer l'arrêt de la machine. La charge (côté client) l'interdit. Plus rien ne répond.


--L7zJvr88PYLf9pqiZjIZUpmjRb58MGoxD--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZy3aLgAKCRDFW/s/mMLX CKdhAPwLoOPxrvJpBM6zwEboEdFLOxX7xoLNw1vPnR5Z8Hh5SgD7Bbwwve/ZlSDt Wm5DsCz8jXsdhfvqd3USB8dCwhQ4AwM=
=9QA8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Le 08/11/2024 à 10:30, BERTRAND Joël a écrit :
[...]

Je ne peux pas forcer l'arrêt de la machine. La charge (côté client) l'interdit. Plus rien ne répond.

sudo virsh && destroy <domaine> (voire reset <domaine>)

Tu peux ensuite attacher le disque de cette machine à la VM W7 à fin d'analyse. Aussi, dans virsh, executer perf sur ce domaine


<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 08/11/2024 à 10:30, BERTRAND Joël a
écrit :</div>
<div class="moz-cite-prefix">[...]<br>
</div>
<blockquote type="cite"
cite="mid:21dc0708-9a54-5fab-03dd-df6df05f8e0e@systella.fr"><span
style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap=""> Je ne peux pas forcer l'arrêt de la machine. La charge (côté client)
l'interdit. Plus rien ne répond.</pre>
</blockquote>
<span style="white-space: pre-wrap">sudo virsh &amp;&amp; destroy &lt;domaine&gt; (voire reset &lt;domaine&gt;)
</span>
<p>Tu peux ensuite attacher le disque de cette machine à la VM W7 à
fin d'analyse. Aussi, dans virsh, executer perf sur ce domaine</p>
<p><br>
</p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6x2rZHyOqhR2AaJ5UfUFoCmOBxKohWdSg
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

didier gaumet a écrit :

Apparemment je me trompe: un ls sur une image qcow2 montre l'espace
alloué (virtual size), pas réellement occupé (disk size):

didier@hp-notebook14:~$ sudo qemu-img info /home/machines_virtuelles/win10.qcow2image: /home/machines_virtuelles/win10.qcow2
file format: qcow2
virtual size: 50 GiB (53687091200 bytes)
disk size: 23.9 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: true
    refcount bits: 16
    corrupt: false
    extended l2: false

didier@hp-notebook14:~$ ls -al /home/machines_virtuelles
total 41245288
drwxrwxr-x 2 libvirt-qemu libvirt        4096  7 nov.  13:39 . drwxr-xr-x 5 root         root           4096 15 août  14:43 ..
-rw------- 1 root         root    53695545344 18 août  22:14 debian.qcow2
-rw------- 1 root         root    53695545344  7 nov.  14:35 opensuse_leap.qcow2
-rw------- 1 root         root    53695545344 17 août  22:54 win10.qcow2

tu peux peut-être tenter (si la commande veut bien répondre),
- un qemu-img info pour avoir la taille réellement occupée

hilbert:[~/.local/share/libvirt/images] > qemu-img info
Virtual10-disk001.qcow2
image: Virtual10-disk001.qcow2
file format: qcow2
virtual size: 128 GiB (137438953472 bytes)
disk size: 32.8 GiB
cluster_size: 65536
Format specific information:
compat: 0.10
compression type: zlib
refcount bits: 16
Child node '/file':
filename: Virtual10-disk001.qcow2
protocol type: file
file length: 32.8 GiB (35205677056 bytes)
disk size: 32.8 GiB
hilbert:[~/.local/share/libvirt/images] >

- un qemu-check pour vérifier sir l'image est corrompue
- éventuellement un qemu-img resize pour agrandir ton image qcow2 sans arrêter ta machine virtuelle, même si ça me semble douteux que le changement de taille soit pris en compte immédiatement plutôt qu'au prochain démarrage de la VM.

En tout cas bon courage :-)

PS: si je comprends à peu près (c'est incertain), si l'option
data_file_raw a été choisie, qemu crée une image supplémentaire avec les entrées-sorties sur l'image principale, ce qui explique tes deux images
qcow pour une seule machine virtuelle.
cf doc qemu:
https://www.qemu.org/docs/master/tools/qemu-img.html#notes

Je ne vois pas comment voir l'état de ce paramètre :-(

JB


--6x2rZHyOqhR2AaJ5UfUFoCmOBxKohWdSg--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQj8MW8iOsC2RXEznnFW/s/mMLXCAUCZy3oVwAKCRDFW/s/mMLX CLiTAQCs+qPOCeRrylTNaB+jyn0CRkoemk5NCOgeU3TmvsQueQD8CHzZ5XMey0Uk xDvumfslB/SwSJIYteOCUp+98XcnygE=
=ZRDZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

BERTRAND Joël, on 2024-11-08:

didier gaumet a écrit :

Le 07/11/2024 à 23:28, BERTRAND Joël a écrit :

    En fait, ça démarre. Mais le fonctionnement est erratique. Si je >>> laisse
le truc assez longtemps, j'arrive à l'écran de connexion. Je peux même >>> ouvrir un session (qui peut s'ouvrir correctement ou pas), mais tout est >>> d'une lenteur abominable en surchargeant le réseau local et le serveur
NFS. Ce que je n'avais pas auparavant.

au feeling, comme ça, ça ressemble plus à un problème dans l'invité
Windows que dans l'environnement de l'hôte Debian...

Bonjour,

Pas certain du tout :

hilbert:[~/.local/share/libvirt/images] > ls -lh
-rw------- 1 bertrand users 21G 7 janv. 2023 netbsd10.0.qcow2
-rw-r--r-- 1 bertrand users 33G 7 nov. 16:50 Virtual10-disk001.qcow2 -rw------- 1 bertrand users 129G 7 nov. 16:42 win10.qcow2

Le disque utilisé par la VM est Virtual10-disk001.qcow2 (j'ai vérifié
dans la configuration de la VM). Or je viens de m'apercevoir qu'un autre disque est créé par je ne sais qui et que ce disque fait... 128 Go !
Sans doute plus il faudrait que je laisse la VM aller jusqu'au bout.

Pour mémoire, la taille de Virtual10-disk001.qcow2 est de 128 Go :

hilbert:[~/.local/share/libvirt/images] > file Virtual10-disk001.qcow2 Virtual10-disk001.qcow2: QEMU QCOW Image (v2), 137438953472 bytes (v2), 137438953472 bytes
hilbert:[~/.local/share/libvirt/images] > file win10.qcow2
win10.qcow2: QEMU QCOW Image (v3), 137438953472 bytes (v3), 137438953472 bytes

et c'est bien la VM qui crée un autre fichier (au nom de la VM) et qui sature le serveur NFS. Précédemment, ce n'était pas le cas.

Je vais probablement raconter des bêtises parce que je n'ai
suivi la conversation que d'un œil distrait, et ce détail
d'implémentation de la libvirt n'est pas particulièrement ma
spécialité, mais… est-ce qu'il n'y aurait pas un snapshot de la
machine Windows 10 en place à l'instant t ?

Je ne sais pas si ça expliquerait les lenteurs (à moins d'une
incohérence dans la stratégie de cache disque en cas de
snapshot), mais ça expliquerait peut-être le fichier auxiliaire,
pour enregistrer les différences entre la prise de vue et l'état
courant du disque.

En espérant néanmoins que ça aide,
sinon je retourne me cacher, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/1, please excuse my verbosity
`- on air: Banco del Mutuo Soccorso - Dopo... Niente E' P…

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmcueK8ACgkQeTz2fo8N Edrhfg/9GteSEIl2VekgyXlW0+6Dwi6T+YG47y8aPvZ/nHcZS26DYfIPb5dhhb+7 ZsjcfPNH1jKwWoqBJWVWrDgeojTYNmNOfrPzIaERWtg7iSVFIryEbUI3Fi2GgMhJ uTvcqjbFmszAPGAAYzIyNnHde39hRkNKHKHxhsr3V5f4AEip/1dtLEDKS3DS9DLo /kRXtj3WJARpMv2bKjDXDSTAbOXacbjvo+qsl1AtuBrTWOUMztdTtfYYzRfDoRPx wu+H+xss2dNonJkiLlvAyWneGc3aPy3xlfFO6rcieObAm90+xHfPvqvKEpE4UWhb il18KE7cgHswWl9kpJG1Be1aY3E0Gd3RF38GD9EcYooyCZEC6qXOfFxnP/Rq5hbB +HjykJKLkh65EpHZmqUsOy7AV1/cKWj9hwo7WlobF9w36+Oq8crimkKHJL+XSK/B UoEV7aSIDmIBWRvXB6yI4ewRK4uD+TB75UKNDXBM7geUcviwgEUoHFH+iKkKhPhA GptT7wzV6dgULIeqGwZ2BWTv91WXmaltBpdcfSSSA+j2CKNC6Mo279SmpcXG7g3T TyWW25cI/ON+onVNMiqdVPNSY0O1hKRxdYPs7R8ZTDrbWDXN6H87f4nCVuNRmVNu yHDcPhiKKRd3uNvp