Posté(e) le 7 septembre 201113 a Bonjour, Je me pose une question qui risque de paraître bizarre: est-il possible dans un environnement Linux server (sans bureau graphique donc) de virtualiser par exemple un Windows et d'avoir l'affichage de cette virtualisation sur une autre machine équipée elle d'un environnement graphique? En fait, je voudrais que mon NAS supporte la virtualisation d'un Windows, sur lequel je me connecterais en RDP pour faire du dev. Mais mon NAS devrait être en mode serveur uniquement, donc en ligne de commande. A première vue, je dirais que c'est pas possible... Merci d'avance!
Posté(e) le 7 septembre 201113 a Si, c'est tout à fait possible ! Mais les détails dépendent de ta solution de virtualisation si tu veux afficher la console locale. Concernant RDP, il s'agit d'un service réseau, donc à partir du moment où la machine virtuelle est accessible via le réseau et que RDP est activé, tu peux t'y connecter.
Posté(e) le 7 septembre 201113 a Bonjour, C'est possible avec VirtualBox en tout cas. (Même si je n'ai jamais essayé) Regarde Virtual Box Manual Ch.7 Remote virtual machines Il y a un paragraphe Step by step: creating a virtual machine on a headless server. Apparemment, on peut même avoir l'accès dans la machine virtuelle distante au périphériques USB locaux. Note: dans ce cas, c'est VirtualBox qui gère le RDP, pas la machine virtuelle. Si c'est la machine virtuelle qui fait tourner un service RDP (comme propose AHP_Nils), ça doit marcher aussi.
Posté(e) le 7 septembre 201113 a Auteur C'est génial!! Merci beaucoup à vous. Je reviendrais ici si j'ai un souci... Sinon, je passerais le sujet à [RESOLU]
Posté(e) le 7 septembre 201113 a Bonsoir, C'est également possible avec QEMU/KVM. Je ne l'ai pas fait avec un Windows, mais avec une distribution Linux avec interface graphique virtualisée sur une Debian sans aucun morceau d'X.org à l'intérieur. Pour se connecter graphiquement via VNC à la machine invitée, tu n'échapperas pas par contre à une émulation ultra-basique de la sortie graphique (j'ai du activé le framebuffer comme option au boot), au moins pour installer la machine (à moins que tu l'aies déjà installé ailleurs et juste copié sur le serveur). Pour RDP, même réponse que AHP_Nils.
Posté(e) le 8 septembre 201113 a (à moins que tu l'aies déjà installé ailleurs et juste copié sur le serveur). Je pense d'ailleurs que ça sera le plus simple et le moins casse-pieds.
Posté(e) le 8 septembre 201113 a Auteur J'avais l'idée suivante: - faire la conf de la VM et installation de l'OS (Windows & Ubuntu Desktop) dans la VM sur ma machine perso sous Windows - transférer la conf sous Linux - démarrer la VM dans mon NAS (Ubuntu server) - me connecter sur la VM à partir de ma machine perso
Posté(e) le 8 septembre 201113 a Cela me semble jouable, au moins avec VirtualBox. La configuration de chaque machine virtuelle est située dans un fichier xml au nom de celle-ci. En modifiant éventuellement les chemins dans ce fichier, tu devrais pouvoir installer ta VM sur ton Windows, puis la "mettre en production" sur ton Linux.
Posté(e) le 9 septembre 201113 a Faisable également avec QEMU/KVM : il te suffira juste de faire un dump XML de la configuration de ta machine virtuelle pour la recharger sur le serveur. (en même temps heureusement que de tels logiciels - Virtualbox, KVM... - permettent de faire ça... c'est quand même la base ! ;-)) Edit : dump utile uniquement si tu utilises un client "haut niveau" (type virsh) pour administrer tes VM. Avec la commande kvm directement, pas besoin.
Posté(e) le 10 septembre 201113 a Depuis Virtualbox 4, chaque VM a son propre dossier avec son fichier de conf, ses snapshots, et les disques durs créés à l'occasion. La seule chose que j'ai eu personnellement à modifier en transférant une VM de windows à Linux, c'est la définition de la carte réseau sur laquelle je bridge (je n'ai pas utilisé virtio, qui évite de passer par la modif). Sinon ça roule d'enfer. Faudra quand même un jour que je me mette à KVM histoire de voir les différences.
Posté(e) le 11 septembre 201113 a Pourquoi installer sur une machine avec interface graphique ? De la même manière que tu te connecteras à distance en VNC ou RDP à la machine, tu peux en faire de même à l'installation avec la sortie VNC de Qemu.
Posté(e) le 12 septembre 201113 a Pourquoi installer sur une machine avec interface graphique ? Justement, il veut s'en passer
Posté(e) le 12 septembre 201113 a L'installation en graphique ne se fera que sur une machine Windows (dans le cas de Virtualbox--faisable aussi sous linux, et avec KVM d'ailleurs), cette méthode étant quand même infiniment plus "user-friendly" qu'en ligne de commande. Ensuite elle est transférée sur un serveur et lancée avec un support RDP/VNC qui permettra de s'y connecter à distance. La seule interface graphique au final, c'est celle de la VM.
Posté(e) le 12 septembre 201113 a Il est tout autant "ami de l'utilisateur" de réaliser cette installation sur le serveur distant, et cela sans besoin de ligne de commande ! En effet grâce à libvirt couplé à virt-manager, il est possible de piloter son serveur de virtualisation à distance de la même manière que sa machine locale. Cela permet d'installer et d'administrer ses machines virtuelles à l'aide d'une interface graphique. Cette méthode évite de devoir transférer la machine virtuelle, et me semble tout aussi simple.
Posté(e) le 13 septembre 201113 a Et nécessite un linux en client, ce qui n'est pas forcément possible :)
Posté(e) le 13 septembre 201113 a Auteur La machine qui hébergera les VMs sera sous Linux. La machine cliente qui se connectera aux VMs sera sous Windows Seven. Je suis loin d'être fluent en Linux et les outils/libs qui tournent autour, alors "[...] grâce à libvirt couplé à virt-manager [...]", ça ressemble presque à du chinois pour moi C'est pourquoi j'opte pour la solution simple: création des VMs et installation des OS dans les VMs sous Windows (sous VirtualBox, car j'ai déjà manipulé la chose) avec transfert sous Linux. Je pense que la simple reconfiguration du réseau pour la VM soit contactable va me donner des sueurs alors, aller au-delà...
Posté(e) le 13 septembre 201113 a Bonjour, voici la solution que je te propose avec Virtualbox (j'ai déjà testé ça marche) : 1- installer ta VM de dev sur ton poste avec Virtualbox installé. Ne pas oublier d'activer TSE dans la VM. 2- installer Virtualbox sur ton linux 3- transférer la VM sur le linux 4- utiliser la commande VBoxManage registervm pour enregistrer la VM dans l'inventaire de virtualbox 5- utiliser la commande VBoxHeadless -startvm vmdev --vrdp off & pour lancer le démarrage de la VM sur la linux 6- commencer les tests. Attention au réseau, par défaut, sur Virtualbox les VM sont en mode NAT avec la machine hôte. Donc si tu veux conserver ce mode, il faudra jouer avec la commande VBoxManage modifyvm --natpf<1-N> [<name>],tcp|udp,[<hostip>],<hostport>,[<guestip>], <guestport> Celle-ci te permettra de faire la redirection du port 3389 (TSE) vers ta machine virtuelle. Voilà !
Posté(e) le 13 septembre 201113 a Pas besoin de se faire peur à modifier la config à la main, le fait est qu'on peut normalement utiliser la carte réseau virtuelle "virtio", qui est censée être disponible sous tous les systèmes. Comme ça, même lors d'un transfert, pas de problème. Mais ceci dit, c'est de la théorie pour ma part, je n'ai pas essayé (faudrait que je m'y recolle un peu, et j'en reparle après ). Dernière précision : pour pouvoir profiter du mode RDP "générique" fourni par Virtualbox, il faut obligatoirement avoir installé l'Extension pack, sinon ça marchera pas
Posté(e) le 13 septembre 201113 a c'est aussi possible avec xen. Cela fonctionne sur ma debian squeeze, avec un windows serveur 2008 R2 avec activation du TSE dessus. Attention, si la machine se vautre, on a pas accès au menu du démarrage ( mode sans échec et autre ) et la cela devient parfois diificile de pouvoir se dépanner quand on ne sait pas pourquoi la machine virtuelle ne démarre pas.... Sinon tu peux aussi mettre un linux avec interface graphique, et y accèder à distance en xdmcp par exemple. c'est ce que je fais.
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.