Le topic de Windows 10 - Page 29

Godzil (./833) :
Ne pas donner ce types d'informations a l'OS virtualisé c'est au contraire risquer encore plus de problemes.

Lesquels ? Je ne vois aucun problème à ce que l'OS virtualisé continue de travailler tant que l'OS réel gère.

Mettons qu'il y ait une rupture de courant, avec niveau de batterie critique. Il faut que l'OS hôte donne à temps les informations nécessaires pour que l'OS virtualisé puisse exécuter les éventuels scripts et éteindre proprement le système avant rupture de courant... l'OS hôte aura beau s'éteindre proprement, si l'invité n'a pas le temps ou les informations adéquates relatives à la situation, ça peut être un vrai danger pour les données et/ou la continuité de service) (et si on investit dans des alimentations secourues, c'est pas pour que les OS n'en aient rien à faire )

Il y a aussi le fait que l'OS Hote n'a aucun control sur ce que fait le virtualisé.

Exemple, Windows 10 a un mode ou il cherche a consommer moins si la batterie est faible (et ca a un veritable impact sur la consommation, ca peux doubler l'autonomie)
Mais ce mode n'est activé automatiquement QUE si il a les informations de batteries. Idem en cas de batterie faible, (ou meme juste etre sur batterie) certasin services moins utiles peuvent etre coupé (indexation par exemple) alors que sur une machine branché sur secteur ils tourneront.

Nil (./842) :
Mettons qu'il y ait une rupture de courant, avec niveau de batterie critique. Il faut que l'OS hôte donne à temps les informations nécessaires pour que l'OS virtualisé puisse exécuter les éventuels scripts et éteindre proprement le système avant rupture de courant... l'OS hôte aura beau s'éteindre proprement, si l'invité n'a pas le temps ou les informations adéquates relatives à la situation, ça peut être un vrai danger pour les données et/ou la continuité de service) (et si on investit dans des alimentations secourues, c'est pas pour que les OS n'en aient rien à faire )

Mais çà c'est le virtualiseur qui doit s'en occuper, pas la machine hote... Il fait un snapshot, arrête la virtualisation et puis basta : pas de pertes de données !

Godzil (./843) :
Exemple, Windows 10 a un mode ou il cherche a consommer moins si la batterie est faible (et ca a un veritable impact sur la consommation, ca peux doubler l'autonomie)Mais ce mode n'est activé automatiquement QUE si il a les informations de batteries. Idem en cas de batterie faible, (ou meme juste etre sur batterie) certasin services moins utiles peuvent etre coupé (indexation par exemple) alors que sur une machine branché sur secteur ils tourneront.

Là pourquoi pas. Mais passer en mode économie d'énergie et normalement indépendant d'avoir une batterie ou une batterie faible.

PpHd (./844) :
Mais çà c'est le virtualiseur qui doit s'en occuper, pas la machine hote... Il fait un snapshot, arrête la virtualisation et puis basta : pas de pertes de données !

Un snapshot ne permet pas tout (en particulier, en cas de problème électrique, on peut avoir besoin de lancer un service réseau distant, de fermer proprement des sockets, d'envoyer des messages d'avertissement... tu peux, pour ce dernier point, arguer que c'est au virtualiseur de le faire, sauf que ce ne sont pas les mêmes équipes qui gèrent la virtualisation et les OS virtualisés, donc ça n'est pas gérable. Faire un snapshot, ça peut (éventuellement) être une solution pour de la virtualisation de poste de travail, mais pour des serveurs, pas vraiment...

PpHd (./844) :
Mais passer en mode économie d'énergie et normalement indépendant d'avoir une batterie ou une batterie faible.

Ca fait au moins 10 ans que les portables viennent avec des outils permettant de basculer automatiquement d'un mode à l'autre en fonction du niveau de batterie, afin de permettre d'en allonger la durée (je l'avais sur un Lenovo d'entrée de gamme datant de 2009).

Nil (./845) :
Un snapshot ne permet pas tout (en particulier, en cas de problème électrique, on peut avoir besoin de lancer un service réseau distant, de fermer proprement des sockets, d'envoyer des messages d'avertissement... tu peux, pour ce dernier point, arguer que c'est au virtualiseur de le faire, sauf que ce ne sont pas les mêmes équipes qui gèrent la virtualisation et les OS virtualisés, donc ça n'est pas gérable. Faire un snapshot, ça peut (éventuellement) être une solution pour de la virtualisation de poste de travail, mais pour des serveurs, pas vraiment...

Pour les serveurs ca ne fonctionne pas pareil. Normalement les onduleurs envoient un message par le système de monitoring (souvent un trap SNMP) pour informer les services de l'arrêt. Et là que ca soit virtualisé ou réel, cela ne change rien vu que le virtualiseur n'intervient pas (encore).

Ca fait au moins 10 ans que les portables viennent avec des outils permettant de basculer automatiquement d'un mode à l'autre en fonction du niveau de batterie, afin de permettre d'en allonger la durée (je l'avais sur un Lenovo d'entrée de gamme datant de 2009).

Ce que je voulais dire est que l'on pouvait demander manuellement le mode économie d'énergie.

J'utilise évidemment KVM. L'interface QEMU reste la même, c'est juste que c'est plus rapide en virtualisation matérielle qu'en virtualisation logicielle. (La virtualisation logicielle ralentit d'un facteur 50 environ.) Mais ça fait longtemps que QEMU-KVM a été intégré à QEMU.

J'ai pas lu le reste des commz mais non Windows quand il est au-dessous du niveau de batterie "critique" (5% par défaut) il exécute la commande mettre en veille prolongée. S'il n'y a pas de support pour la veille prolongée (et Parallels dans le cas de Bootcamp désactive par défaut parce que c'est très risqué de rebooter sous un Windows en hibernation depuis la VM) alors il s'éteint. Il s'éteint proprement MAIS ne demande pas comme habituellement si on veut enregistrer. C'est un comportement "normal" qui n'a ni à voir avec la VM ou l'hôte.
Parallels, vmware et sûrement d'autres donnent à l'invité toute les informations de batterie.

Ha mais tu virtualise ta partition bootcamp? Bah forcement

PpHd (./846) :
Pour les serveurs ca ne fonctionne pas pareil. Normalement les onduleurs envoient un message par le système de monitoring (souvent un trap SNMP) pour informer les services de l'arrêt. Et là que ca soit virtualisé ou réel, cela ne change rien vu que le virtualiseur n'intervient pas (encore).

Tout ne passe pas par SNMP, il peut y avoir des secours d'alimentation qui utilisent du port série, de l'USB ou encore du spécifique (série sur RJ45, par exemple).

Depuis quelques jours, j'ai un BSOD systématique au boot d'une VM VirtualBox :/

C'est le prix à payer quand on utilise un système gratuit développé par des amateurs

...ah zut, c'est le topic Windows 10, pas le topic Linux ?

Bof, je n'ai jamais eu le moindre plantage ou bug sous PedroM

https://social.technet.microsoft.com/Forums/windows/en-US/ab5f8dc5-69a5-406f-8573-b756782a860d/rdp-files-wont-open-remote-desktop-after-win10-anniversary-update?forum=win10itpronetworking&prof=required
(regardez le bug et sa solution)

Mais... comment ils font pour avoir des bugs pareils ?!

Si encore il y avais une potentielle logique entre les deux mais la je ne vois pas o_o

Bah je comprends le lien entre les deux (remote desktop va faire du scaling, peut-être qu'il y a un souci avec le scaling rescalé ?), mais pas que ça ne tente même pas d'établir la connexion...

-

Nil: Heu non le scalling n'a aucun rapport avec l'ouverture d'un fichier, ils ne parle pas de "ça ne se connecte pas" mais de "le fichier .rdp sauvegarde ne s'ouvre pas, mais si on lance la connexion a la main ça marche"

Orion_ > d'après ceux qui ont testé, malheureusement c'est très bugué...

Bon bah j'ai testé ReactOS - notre client VPN ne fonctionne plus sous Windows 10, et même les méchants hacks pour le faire marcher ne passent pas sous l'Anniversary Update et je me demandais si ça pourrait passer sous ReactOS dans une VM. Bah c'est à la fois pas mal et encore très limité/buggé (et, évidemment, vu que la pile réseau semble être ultra limitée, ça ne fonctionne pas).

-

(*une alternative à windows xp)

T'as BSD Orion, ou sinon tu peux contribuer.
Ou encore, tu te fais des VM, ça permet d'avoir les deux, suivant tes besoin. C'est mon choix et même si c'est pas idéal, c'est pas mal pour avoir les avantages des deux.

Ps -> Pour utiliser VirtualBox sous Win 10, il faut désinstaller HyperV

-

"Tout", c'est mal barré... y'a plein de trucs sous Windows qui sont mal/pas documentés, et des tas de programmes bugués qui ne fonctionnent que par coup de pot (ou que MS a implémenté des workarounds exprès pour eux).

-

Le système en lui-même n'est pas stable à 100%, de ce que j'ai pu voir. Du coup ça paraît difficilement utilisable dans un environnement pro ou assimilé.

On en avait déjà parlé, mais un petit rappel ne fait pas de mal :
http://www.pcworld.com/article/3112663/software/microsoft-made-em-do-it-the-latest-kaby-lake-zen-chips-will-support-only-windows-10.html