Bonjour !
Voilà des années que je possède un serveur Linux, un PC fixe avec OS X (hackintosh) et un PC portable professionnel avec Windows 7. Et voilà autant d'années que je ramène systématiquement mon PC portable professionnel à mon domicile au cas où j'aurais besoin d'un Windows pour tester une nouveauté, utiliser un logiciel qui n'est disponible que sur Windows, etc.
J'aimerais finalement mettre en œuvre la solution qui coule de source : virtualiser Windows. Et tant qu'à faire, ne pas le virtualiser sur mon PC fixe, mais sur mon serveur Linux, qui sert essentiellement de serveur de stockage et passe donc pas mal de temps à se tourner les pouces.
Mon idéal serait une solution comme celle que propose Qnap sur ses NAS : http://www.qnap.com/event/station/fr/virtualization.php
On crée une ou plusieurs machines virtuelles depuis une interface d'administration Web, on les démarre par ce biais, puis on peut les contrôler depuis le navigateur ou via VNC.
En somme, plus ou moins l'équivalent d'un VMware ESXi mais au-dessus d'un système d'exploitation existant. (De ce que j'en ai compris, car je ne l'ai jamais utilisé.)
Si ce dont je rêve n'existe pas ou est trop compliqué à mettre en place, j'aimerais une solution la plus légère et la plus simple possible. Une solution avec laquelle on définirait une machine virtuelle avec un fichier de configuration, on la démarrerait sous la forme d'un service et on la contrôlerait via un client VNC.
Est-ce que tout cela existe ? :)
Merci d'avance pour vos retours.
# kvm et des interfaces pour le gerer
Posté par NeoX . Évalué à 5.
ce que tu cherches c'est KVM pour faire la virtualisation.
pour l'interface, tu peux ne rien installer,
installer libvirt et ses outils graphiques locaux pour gerer ce serveur distant
installer proxmox, sur le serveur, pour avoir une interface web pour gerer les machines virtuelles
et plutot que VNC, autant utiliser ce qui est fournit par windows, le protocole RDP
[^] # Re: kvm et des interfaces pour le gerer
Posté par Romano2K . Évalué à 2.
Merci pour ta réponse, qui en soulève quelques autres. :)
C'est noté pour KVM. J'ai vu qu'il est souvent conseillé, mais il n'est pas proposé sous forme de paquet dans les dépôts officiels d'Arch Linux. Ou alors je n'ai pas bien compris comment ça fonctionne ? Car j'ai déjà vérifié, lsmod renvoie bien les modules kvm et kvm_amd. (Mon serveur est un HP MicroServer N40L.)
En tout cas, pour libvirt, ça ne peut fonctionner que d'un poste client Linux, non ? J'ai été voir le site internet, il n'y a pas l'air d'y avoir de version Windows ou OS X de virt-manager.
Quant à Proxmox, il a bien l'air de répondre à mes besoins en effet. Sur le site internet, je crois comprendre qu'il y a une version OS, comparable à ESXi, et une version qu'on peut installer par-dessus un OS existant, c'est bien ça ? Mais là encore, pas de paquet sur Arch, ni dans les dépôts officiels, ni dans les dépôts AUR. C'est un logiciel peu utilisé ?
[^] # Re: kvm et des interfaces pour le gerer
Posté par Adminrezo (site web personnel) . Évalué à 1.
Tu peux faire du Qemu/kvm avec arch :
https://wiki.archlinux.org/index.php/QEMU
Au niveau performance c'est excellent. Pas besoin de s'installer jn proxmox pour ça.
Sinon pour un accès depuis Windows, je pense que tu peux utiliser VirtViewer ou au pire Vnc (dans les paramètres de la Vm, remplacer Spice par Vnc). Pour MacOs je n'en sais rien.
[^] # Re: kvm et des interfaces pour le gerer
Posté par Romano2K . Évalué à 1.
Je commence à comprendre. Il est écrit sur Wikipédia que "lorsqu'on parle de KVM, on parle généralement de l'ensemble : la version modifiée de QEMU et le module kvm." Je pensais que KVM était un logiciel à part entière.
Avec Qemu, je peux donc configurer une VM pour qu'elle "exporte" l'écran via VNC et procéder à l'installation de l'OS d'un autre ordinateur que le "host" ?
Concernant Proxmox, c'est la partie interface d'administration HTML qui m'intéresse. Avec la réponse de NeoX à ma question qui parle d'un OS existant, j'ai compris qu'on pouvait l'installer sous forme d'un logiciel. J'ai mal compris ? C'est forcément un OS entier ?
Mon serveur n'est pas très puissant, donc j'aimerais pouvoir suspendre et reprendre les VM facilement, quand j'ai besoin de m'y connecter de n'importe où. Ce serait vraiment bien si j'avais une GUI pour ça. Et si elle permettait aussi de créer les VM avec une interface user friendly, ça mangerait pas de pain. ;-)
[^] # Re: kvm et des interfaces pour le gerer
Posté par NeoX . Évalué à 2.
Helas je crois que promox n'existe que dans 2 versions :
donc pas simple de l'ajouter à ton serveur sous ARCH,
sauf à decompresser les paquets debian, pour les installer à la main ensuite (avec tout le bricolage qu'il va falloir faire pour adapter)
Sinon tu peux installer et utiliser virtualbox,
pour l'interface graphique, tu fais un export DISPLAY vers ton portable,
sinon tu l'utilises en ligne de commande, c'est moins sexy mais tout a fait faisable.
[^] # Re: kvm et des interfaces pour le gerer
Posté par ptit_poulet . Évalué à 2.
Pour VirtualBox tu peux utiliser phpVirtualBox, ce qui te permet de tout gérer depuis ton navigateur ;)
[^] # Re: kvm et des interfaces pour le gerer
Posté par Romano2K . Évalué à 1. Dernière modification le 03 octobre 2015 à 22:30.
Je n'ai pas trouvé la version paquet en navigant sur le site de Proxmox. J'ai finit par chercher avec un moteur de recherche et à trouver ceci : https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Wheezy
Ça a l'air un peu lourd à mettre en place. Mais je suis en période de reflexion sur mes serveurs, VPS, dédiés, etc., alors je vais peut-être l'essayer sur ma Dedibox Kidéchire, même si elle n'est sans doute pas assez puissante pour faire tourner Windows dignement.
En tout cas je n'aurai pas les capacités, ou du moins pas le courage, pour essayer de le porter sur Arch. Vous l'aurez compris, je suis capable d'installer des paquets et de les configurer, mais pas tellement plus. Je n'installe un logiciel à partir des sources que si je n'ai pas trouvé de logiciel équivalent disponible sous forme de paquet.
Dans mon esprit, la notion d'"export DISPLAY" est propre à l'univers Linux/UNIX, je me trompe ? Je peux récupérer un tel export sur un client Windows, Android, iOS… ?
En tout cas grace à phpVirtualBox, je découvre que ce logiciel peut fonctionner en headless. Et phpVirtualBox a l'air de bien correspondre à mes besoins.
Pour le moment je suis en train d'essayer QEMU sur ma Dédibox Kidéchire, avec une installation d'Ubuntu, pour me familiariser avec le concept. Je verrai juste après pour VirtualBox.
[^] # Re: kvm et des interfaces pour le gerer
Posté par NeoX . Évalué à 2.
l'idée c'etait de lancer virtualbox avec son interface graphique depuis ton serveur,
avec un affichage sur ton portable (linux, windows, osx)
il faut juste avoir une couche X11 sur la machine qui recoit l'affichage :
[^] # Re: kvm et des interfaces pour le gerer
Posté par benja . Évalué à 1. Dernière modification le 04 octobre 2015 à 02:15.
Une autre solution, qui à mon avis est plus pratique et plus performante, c'est d'utiliser libvirt (kvm) avec spice.
Rapidement en passant sur de nombreux détails, il suffit:
- de lancer libvirtd sur le serveur
- sur un client linux, se connecter au serveur avec virt-manager en ajoutant une connection ssh
- créer la machine virtuelle à partir de virt-manager, il conviendra à priori de copier le média d'installation sur le serveur
- éventuellement d'installer les drivers spices/virt-io pour windows
- ensuite il est possible d'utiliser un client spice directement sans passer par virt-manager, i.e. il existe aussi un client windows et android (je crois).
note: il est possible d'installer windows, du moins au temps de xp ça marchait, sur un périphérique disque de type "virtio" en attachant une disquette qui contient le pilote ad-hoc au moment de l'installation
note: les pilotes windows spice (pour une meilleur accélération graphique) et virtio sont trouvable via le site de spice.
note: il est conseillé d'attribuer toute une partition (ou un "logical volume" lvm) en tant que disque virtuel, c'est plus performant que d'utiliser un fichier d'image. Au moment de la création avec virt-manager, il suffit de choisir "parcourir localement" et tapper soit même /dev/sdaXX ou /dev/MonVolumeGroup/MonLV…)
spice donne un résultat bien plus satisfaisant que vnc et/ou forward X. De plus cela supporte la redirection du son et de certains périphériques USB, entre autre…
[^] # Re: kvm et des interfaces pour le gerer
Posté par benja . Évalué à 1. Dernière modification le 04 octobre 2015 à 02:30.
Encore une autre solution assez efficace est d'utiliser rdesktop. Il y a pas mal de client libre dont certains qui permettent de partager un dossier local. Du coup le choix de la solution de virtualisation n'est plus limitée à kvm/qemu (qui est la seule à proposer spice). Pas sûr que l'on puisse partager de l'usb avec rdesktop, mais bon si c'est pour faire du mass-storage, autant partager un dossier via rdesktop…
note: spice permet aussi de partager le copier/coller, pour cela il faut aussi installer les pilotes windows.
[^] # Re: kvm et des interfaces pour le gerer
Posté par benja . Évalué à 1.
BTW est-ce que quelqu'un a réussi a partager un lecteur smartcard via spice/celt ? J'avais essayé en recompilant les paquets qui vont bien sur une debian (en gros tout ce qui a à voir avec la libcelt iirc), mais ça n'a jamais foncionné plus loin que la détection du lecteur par windows. Le lecteur sur l'hôte étant un ACR38.
[^] # Re: kvm et des interfaces pour le gerer
Posté par Romano2K . Évalué à 1.
Bonjour, et merci pour ton/tes message(s) détaillé(s).
Ta solution libvirt est intéressante, mais elle implique de maintenir un Linux graphique opérationnel quelque part, ce qui ne me parait pas idéal (à moi, pas en général). Je pourrais virtualiser temporairement un Linux graphique sur un de mes PC OS X ou Windows, le temps d'installer sur mon serveur une machine virtuelle Linux graphique qui me servirait ensuite à accéder à virt-manager. Mais c'est un peu tiré par les cheveux ! :)
C'est vraiment dommage que virt-manager n'ait pas été porté sur OS X ou Windows. (Du moins sans méthodes à la cygwin.)
En tout cas SPICE a l'air intéressant. Le problème c'est qu'il manque un client iOS. Mais si on peut faire fonctionner SPICE et VNC en parallèle sur le même écran virtuel, je le ferais bien.
Enfin, merci pour les conseils sur le stockage du disque virtuel. C'est bon à savoir, et même si les performances m'importent assez peu pour ce que je veux faire, ça ne mange pas de pain. D'autant que j'utilise déjà LVM sur ce serveur de stockage, donc quitte à réserver 30 Go à ce Windows virtuel, autant les réserver en rapide.
Cela étant, je vais d'abord donner sa chance à VirtualBox, même s'il semble avoir besoin de modules de kernel spécifiques, car avec phpVirtualBox ça reste la solution qui me plait le plus, sur le papier. En attendant que Proxmox soit un jour proposé sous forme de logiciel pour toutes sortes de distributions ! :)
# Je fais ça ici ....
Posté par totof2000 . Évalué à 2.
Mais pas avec Linux, mais avec NetBSD.
J'utilise Xen (qui est dispo également sous Linux), et un client VNC pour mes VMs Windows.
Comme le disait qqn ici, je pourrais utiliser RDP, mais il me semble que RDP ne permette pas d'accédes aux messages de démarrage : il ne te donne la main que lorsque Windows est démarré.
[^] # Re: Je fais ça ici ....
Posté par Romano2K . Évalué à 1.
Je vais jeter un œil à Xen, merci.
Pour VNC vs RDP, je n'ai pas réagi plus tôt, mais c'est clair qu'il faut VNC ou un protocole semblable au moins pour l'installation, puisqu'effectivement RDP ne fonctionne qu'une fois qu'il a été activé et que l'OS a démarré.
J'utilisé Remotix sur iOS et sur OS X, une solution qui est compatible avec les deux, donc j'utiliserai sans doute RDP lorsque tout fonctionnera.
# Openmediavault
Posté par ptit_poulet . Évalué à 1.
Bonjour,
As-tu regardé du côté d'Openmediavault. Je l'utilise depuis plusieurs années sans aucun soucis et ça combine exactement tout ce que tu veux faire : nas, virtualisation (virtualbox, docker), hébergement, ftp, partage….
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.