Windows 7 on Zwindler's Reflection

Bug : unable to execute QEMU command ‘cont’ sous KVM et RHEL/CentOS

Sat, 10 Oct 2015 10:30:00 +0000

Cet article est encore un vieil article que je n’ai jamais pris le temps de sortir. Voilà maintenant c’est fait ;-)

Bug unable to execute QEMU command ‘cont’

Aussi rare que cela soit, après ma migration de KVM sur Ubuntu a KVM sur CentOS, je suis tombé sur un bug du Kernel Linux qui affectait directement ma capacité à faire fonctionner des machines virtuelles sous Windows 7 ou Windows 2008 ! Mais toutes les autres fonctionnaient normalement.

Symptôme

Lorsqu’on démarre la VM ou qu’elle démarre seule au boot, elle se met en pause. Si on essaye de la sortir du mode pause on reçoit l’erreur suivante.

Error unpausing domain: internal error unable to execute QEMU command ‘cont’: Resetting the Virtual Machine is required<

L’erreur en elle même n’est pas très explicite. Dans le log de la machine virtuelle en question, on a un message plus long mais guère plus évocateur :

/var/log/libvirt/qemu/[maVM]
kvm: unhandled exit 80000021
kvm_run returned -22
If you’re running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

Bien évidemment, toutes les autres VMs sous Linux fonctionnent parfaitement donc on ne peut pas accuser Qemu de ne pas fonctionner correctement.

Solution

En théorie, j’ai lu à plusieurs endroits que le bug était censé être corrigés sur des patchs des kernels de CentOS 5 ou 6 (toujours présent en 2.6.32-431.3.1.el6.x86_64 par exemple) et même pour Ubuntu.
Dans la pratique, même en mettant l’OS CentOS à jour, impossible de faire fonctionner cette VM.
La seule vrai solution que j’avais trouvé à l’époque était de forcer le passage à un kernel plus récent, à savoir au moins 3.+.

Pour ceux qui se sentiraient un peu perdu, le plus simple est de changer de version de CentOS ou d’Ubuntu. Sur les dernière version le bug n’est plus présent.

Cependant, si vous avez un système en place et qu’une migration n’est pas à l’ordre du jour, voici la marche à suivre pour installer un kernel plus récent. Voici la procédure que j’ai utilisée pour installer un 3.13 sur lequel la VM fonctionne à nouveau (3.11 fonctionne aussi, je ne sais pas avant).

yum install gcc ncurses ncurses-devel
yum update
wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.13.1.tar.gz
tar xzf linux-3.13.1.tar.gz -C /usr/src/
cd /usr/src/linux-3.13.1/
make menuconfig
make
make modules_install install

N’oubliez pas de vérifier que votre kernel est bien choisi en premier dans le boot loader, ce qui n’est souvent pas le cas par défaut (modifier la valeur default dans le grub.conf pour correspondre à la bonne entrée) sinon le problème ne sera pas résolu au reboot.

vi /etc/grub.conf
default=X
[...]
root (hd0,0)
kernel /vmlinuz-3.13.1 ro root=/dev/mapper/vg_root-lv_root rd_LVM_LV=vg_root/lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_MD_UUID=8f43b4fe:e72ed9aa:2da568b5:5f43b223 SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rd_LVM_LV=vg_endeavour/lv_swap rd_NO_DM rhgb quiet
initrd /initramfs-3.13.1.img

Et vous pouvez vérifier que vous êtes sur le bon kernel avec un uname.

reboot
uname -r

Erreur/bug Error starting virt-manager

En bonus track, je voudrais aussi ajouter un petit bug de plus pour la route, sur l’utilisation de l’interface graphique virt-manager cette fois ci.

Pour une raison obscure, lorsque je voulais lancer ma GUI virt-manager, il m’est arrivé une ou deux fois de suivre la procédure décrite sur le blog de nutanix lorsque je recevais l’erreur suivante :

Error starting virt-manager

dbus-uuidgen --get
cat /var/lib/dbus/machine-id
dbus-uuidgen > /var/lib/dbus/machine-id

Installer le pilote ODBC d’Oracle 11g 12c sur Windows 2k8/2k12

Thu, 02 Jul 2015 10:45:02 +0000

Lorsqu’un progiciel installé sur un serveur Windows nécessite une connexion à une base Oracle, il n’est pas toujours nécessaire d’installer un client Oracle (même Runtime). Des fois, c’est simplement le pilote ODBC qui est nécessaire.

Seulement, pour ceux qui comme moi ne sont ni à l’aise avec Windows 2012, ni à l’aise avec ce genre de considérations, j’ai trouvé que c’était un peu nébuleux.

Voici la page où on peut télécharger tous les bouts de clients Oracle pour Windows qu’on veut ici.

Quoi faire avec? A vous de le savoir (ou alors, il faut trouver la bonne doc, ce qui n’a pas été mon cas pour l’instant) ! [Edit]En fait c’est écrit touuuuuut en bas de la page, après la longue liste de téléchargements[/Edit]

Il ne faut pas se contenter de télécharger l’archive, qui est insuffisante en soit, il faut aussi récupérer l’archive « basic », qui contient grosso modo le cœur du pilote ODBC. Dans mon cas il me fallait un pilote en version Oracle 11.2, mais le principe reste le même pour d’autres versions.

instantclient-basic-windows.x64-11.2.0.4.0.zip
instantclient-odbc-windows.x64-11.2.0.4.0.zip

Dézipppez dans le MÊME dossier les deux archives. Dans mon cas, je les ai mis dans C:\Program Files\instantclient_11_2

Enfin, lancez un shell PowerShell en tant qu’administrateur, puis, dans le dossier en question, exécutez la commande odbc_install (.exe).

Pour finir, avant que le pilote soit totalement opérationnel, il faut aussi modifier la variable d’environnement globale de Windows « Path » pour y ajouter le chemin vers le pilote ODBC.

Une fois toutes ces opérations réalisées, le pilote ODBC devrait être visible dans l’administrateur de sources de données, via le binaire « C:\Windows\SysWOW64\odbcad32.exe »

Quelques infos trouvées sur les sites suivants :

« la Connexion Bureau à Distance ne peut pas vérifier l’identité » depuis un Mac/OSX vers Windows 2008+

Fri, 05 Jun 2015 13:36:49 +0000

On ne peut pas dire que je sois un grand partisan d’Apple, mais il arrive parfois que des VIPs souhaitent se connecter sur les serveurs Windows en bureau à distance (RDP). Et quand on n’y connait rien car on n’en utilise pas, c’est parfois un peu déroutant.

Ici, le mac refusait de se connecter au serveur Windows 2008, qui autorisait pourtant les connexions RDP. En fait, le souci se situait au niveau de l’acceptation du certificat délivré par le serveur 2008r2 (qui venait d’être migré depuis un 2003, qui ne dispose pas de cette sécurité).

Symptôme

Le message d’erreur suivant apparait suite à l’authentification sur la mire d’un serveur Windows 2008 ou plus sur un Mac. Le serveur répond bien au ping (puisqu’on a la mire). On s’est assuré que le mot de passe entré est correct.

Résolution

Comme je l’ai dis en introduction, il s’agit ici d’un défaut du client RDP sur OSX qui gère mal les authentifications avancées de Windows 7 et 2008R2 et plus. Pour résoudre ce problème, il y a plusieurs manipulations à effectuer.

Suppression des entrées dans le trousseau

La première chose à faire est d’abord de supprimer toutes les entrées correspondantes aux connexions RDP dans le trousseau de compte Mac

Ouvrir le finder
Aller dans Applications
Aller dans le dossier Utilitaires
Ouvrir trousseaux d’accès
Supprimer les lignes avec « remote desktop connection »

ATTENTION : faire un clic droit sur la ligne pour supprimer et ne pas utiliser le menu dans le haut. Sinon il y a risque de supprimer tous les enregistrements.

Lors de la prochaine connexion, ne pas cocher d’ajouter les informations au trousseau.

Modification du .rdp

Si le problème persiste, il est probable que les informations de connexion soient contenues dans le RDP. Lorsque l’authentification échoue, ouvrir les préférences du fichier RDP en cliquant sur CBD en haut à gauche, puis sur Préférences

Dans l’onglet Session, vider la case Domaine et décocher les cases

Dans l’onglet Sécurité, cocher la case Toujours se connecter

Quitter les préférences et enregistrer quand le Mac le demande pour mettre à jour le .rdp