Reprise du message précédent :
"ide0", ça dépend de comment était configuré ta vm quand tu as créé ton vmdk.
Bref, RTFM !
Qcow2, c'est un format de fichier, mieux que le raw (enfin, différent). Là, t'a ajouté un disque à ta vm. Ça aurait été mieux de remplacer l'existant. Ce qu'elle en fait du .raw, bah... Tu l'a enlevé de ton fichier de conf ? Si oui, il sert plus à rien, il n'appartiens plus vraiment à la VM. Si non, bah, c'est un des disques de ta vm.
 
Hmm... T'a mis ton .qcow2 dans local ? Tu t'es pas dis qu'il valait mieux le mettre dans local-lvm, à côté du .raw déjà présent ?
 
T'a lu la doc (du format des fichiers de confs, par exemple ), avant de bricoler ?

un manuel ? ca sert à quoi d'abord ?

j'ai mis dans local parce que j'ai suivi un tuto ... m'enfin je me rends compte tout seul de ma connerie. Bosser sur un truc qu'on connais pas à 2h du mat, c'est pas souvent une bonne idée

Du coup en explorant un peu je me rend compte du potentiel de proxmox qui a une debian la dessous. Avoir la main sur l'os, peut s'avérer dangereux, mais ouvre aussi pas mal de possibilités
comme par exemple monter des pool DMZ, routage/firewall sur le proxmox, et openVPN pour ouvrir des pools de VM en VPN..

là sur une machine toute fraiche, je voulais "rapidement" monter quelques VM pour voir, mettre la main dans les entrailles et me faire une idée avant de choisir sur je reste sur cette techno ou pas de virtualisation. Auquel cas je referais un systeme tout propre

c'est du homelab, pas pour de la prod pour l'instant je peux tout casser j'ai mes VM en stock (en ova et vdmk )

Pour vraiment tester le potentiel de l'hyperviseur, ce serais pas mieux de pas utiliser des VM avec des formats de disques inadaptés, des drivers réseaux/disque déjà existants et pas forcément adaptés (virtio/ide, virtio/e1000, ...) ?

si, c'est la prochaine étape
là j'ai fait mon "Hello World!" avec cette VM vmdk
 
maintenant je vais coller mon image au bon endroit et puis tester une install via iso et ova et voir les formats de montage des matériels

Y'a rien pour importer un .ova/autre dans proxmox ? Seriously ?
 
XaT

Rien de natif
Après, tu peux bricoler, mais en natif t'a template de container ou fichier iso.

Il a fallut 2 semaines d'un HFrien pour ajouter le support des OVA (OVF1 avec VMDK) dans XenServer via XO
 
Ça m'étonne que ProxMox ne l'ait pas encore, ça « coûte » pas si cher que ça (à partir du moment où tu sais écrire en Raw sur les disques virtuels, tu peux lire n'importe quel format et le transformer).

vous êtes stressés les gars ... ici c'est le monde debian.

T'es bien placé pour savoir que juste lire le vmdk et le convertir en raw/qcow2 ça fait pas tout. Quid du driver de disque utilisé par la machine originalemenet ? Si c'était de l'ide et que tu remontes le disque en virtio, le grub s'y retrouvera jamais. Idem pour les nic.
Et, plus simplement : si la fonctionnalité n'est toujours pas présente en version 4, dans un outil un peu plus répandu que XO, c'est peut être parceque le besoin n'est pas vraiment remonté par les gens qui paient pour faire tourner la boutique ?
 
Alors oui, pour un lab, c'est carrément plus pratique de pouvoir monter un ova direct. Maintenant, sur un cluster de prod... Non. Pas à mon sens.

 
Je critique pas, ça me surprend réellement c'est tout.
 
Et quand tu importes ce genre du chose, tu prends bien soin de créer une nouvelles machine dans laquelle tu fais qu'injecter le contenu (tu peux paramétrer avant la création d'ailleurs, histoire de t'assurer de pas faire n'importe quoi).
 
Et ce n'est pas « monter » un OVA, c'est carrément une création de machine depuis un OVA.
 
Quand au besoin, ça facilite beaucoup la vie quand tu passes d'une solution à une autre. Ou alors quand un presta (ou autre entité) t'envoie un OVA pour pouvoir le déployer chez toi. C'est relativement courant, et c'est un gros plus de pas te retrouver bloqué. C'est ce qui m'étonne pour ProxMox, qui se veut une solution alternative complète (l'idée est très bien !) : pour moi être compatible avec les standards (de facto ou réels) est un GROS plus en terme d'image et de marché. D'où ma sincère surprise.

c'est clair que pour de la prod, je ne vois pas trop l'intérêt d'importer de l'ova
tu montes tes machines suivant les préco/besoin à partir de zéro.
et tu switche à la migration, c'est plus propre et permet de refaire des tests de charges, upgrade OS ou logicels...
 
mon baptème (suite)
ma VM vmdk installée en local a très bien migré en local-lvm et fonctionne, bien qu'elle fasse un fsck et pleure de ne pas trouver ses /dev/hdax
(vais voir plus tard pour cette vm)
 
par contre là je viens d'installer un linux kali depuis un .iso
bon sang, le boot se gèle tellement c'est lent
j'ai fait un import d'iso dans local. pour créé la vm en montant l'image iso, et utilisant son .raw sur local-lvm (en virtio)
 
install nickelle, sur disque virtuel /dev/vda
 
c'est un ssd pourtant, mais là c'est lent de chez lent

 
de plus un des intérêts est de pouvoir assister, auditer, consulting d'une archi d'un client sans lui péter sa prod, en important des copies de ses VM.
il faut pouvoir travailler avec les différents format que les clients vont envoyer.

Attention, j'attaque personne (et surtout pas toi )
Passer de VMWare à Proxmox, comme l'inverse, c'est prévu par aucun des deux, ça se fait dans la douleur, j'ai pu le constater à nombreuses reprises

Mais pour moi, c'est simple : y'a pas mal d'entreprises qui paient du support pour du Proxmox, je suppose que si y'avait eu un vrai besoin de ces fonctionnalités par ces gens là (et pas M. Kevin avec son proxmox dans son garage), ça aurait été développé.
Parcequ'en soit, y'a pas grand chose à coder : les fonctions de conversions existent déjà dans qemu (avec +/- de joie en fonction des versions de vmdk et des versions de qemu ).

Après, dans l'absolu, la plupart des vrais éditeurs logiciels qui proposent de l'ova... Ils proposent une iso à côté. Voir un package à déployer sur ta RHEL/SUSE préférée. Dans les derniers exemples que j'ai eu sous la main : IBM, RSA, Sophos...

Ton client il a pas d'archi de val isoprod, et il te laisse partir avec des copies de ses VMs de prod ? J'aimerai pas être ton client
Et si tu veux vraiment assiter/auditer/consultinger l'archi de ton client, il te faut le même hyperviseur que lui. Sinon, pour s'assurer que son NSX fonctionne comme il le pense, que son provisionning auto est secure, que ses backups sont cohérents... T'es pas rendu

j'ai pas dit que je partais avec ses  VM ^^

tu travailles pas forcément sur sa virtualisation, mais sur les solutions qui sont hebergées dans les vm.

en pentesting pas exemple, le client il te permet pas d'attaquer son archi, et il peut spécifier qui veut tester ses machines sans toucher à sa virtualisation.

Perso j'ai pas la même expérience, j'ai qu'un petit millier d'users « directs » à travers le monde (bien moins que ProxMox à mon avis), mais c'est ressorti à de nombreuses reprises
 
Dans des cas variés : devs qui veulent bosser en local sur VBOx qui veulent pousser sur l'infra ensuite, presta/fournisseurs ou partie d'un gros groupe qui livre des applis en OVA, échanges divers et variés à plusieurs niveaux.
 
Après j'ai un gros biais US puisque ça représente quasi la moitié de ma clientèle.

Bah l'OVF est sympa pour l'import/provisionning/déploiement de VMs, c'est utile pour scaler j'imagine
Après dans les faits avec QEMU tu peux faire tes scripts pour  
 
Après importer une OVA en 2/2 c'est cool pour déployer une appliance à la va vite. C'est ça aussi l'avantage de l'appliance virtuelle
 
I guess
 
XaT

vous me conseillez d'utiliser/installer les services proxmox : firewall, dhcp, openvpn
 
ou bien d'installer un pfsense qui sera entre mon WAN et les LAN des VM ?

Perso j'ai un utm sophos qui fait ça, je voulais tester. J'ai pas eu l'occasion d'expérimenter les services intégrés. Ni les switchs OVS. Si tu a des retours dessus, hésite pas

des retours.. hum non, y'a (quelques ?) années je baignais dans les firewall et autre loadbalancing.
Aujourd'hui je suis à la rue sur ce qui se fait  
 elles sont bien périmées depuis plus de 15 ans mes certifs
 
ca a l'air bien ton all in one
 
 
 
EDIT: j'ai essayé les cas IDE / virtio en disque... fichtre la différence sur les VM winchose (sans/avec drivers !)

Perso j'ai préfèré utiliser une machine dédié pour le firewall/dhcp/load balancing sous Zer0shell

Un UBNT ERL §§§
 
XaT

oki j'ai l'embarras du choix
 
vais rester sur une solution en virtualisation (c'est un homelab)
du coup vais réfléchir aux options zer0shell/proxmox modules/pfsense
 
avant de partir à l'arrache, vais devoir poser mon organisation sur papier ^^

J'ai finalement acheté un petit switch GB 5 ports et des adaptateurs USB3/GB pour mes NUCs. J'y ai connecté mes deux NAS et les NUC et configuré un réseau "privé" (non rooté) dédié à DRBD.
 
Alors que j'étais arrivé au point 5 de ma procédure d'installation il fallait que je choisisse mon type de filesystem et je suis tombé sur cette doc: https://pve.proxmox.com/wiki/DRBD9
 
Du coup j'ai "rollback" jusqu'au point 1 et j'ai suivi la doc. Je suis en train de redémarrer mes VMs en mode "cache=write-through" pour migrer ensuite les disques de NFS/qcow2 à DRBD/raw (ces deux points, raw et cache, étant des prérequis pour utiliser DRBD) ...
 
So far so good:
 

 
Faut que je trouve un (encore plus) petit NUC pour remplacer le 3ème nœud VM par un nœud physique "pour le quorum" et ça sera impeccable !

un moyen de migrer un kvm d'un proxmox à un autre proxmox ? (Genre sans faire un rsync du qcow2 à la main)

Les avoir dans le même cluster. Faire un backup, scp backup, restaurer le backup.

 
J'ai pas de cluster mais 2 proxmox distincts.
 
Ni de share (NFS, iSCSI) pour les images.

Alors backup, transfert le backup et restaure .

 
S'ils sont dans le même cluster, tu peux pas juste faire une migration ?

ok c'est bien ce que je pensais

Si. Mes deux phrases, c'était deux choix possibles. Mais comme je sais pas m'exprimer, c'est pas compréhensible

Yop les gens, je débarque
 
Pris par une motivation insoupçonné, j'ai réinstall mon serveur@home ce weekend
 
Debian 8 à jour avec presque rien (un bureau, ssh) + install de proxmox VE.
j'ai un peu galéré avec le réseau, mais maintenant ça marche (presque) correctement
 
J'ai mon eth0 en manual, et le vmbr0 avec l'IP de l'host.
Jusque là tout va bien mais:
- mes VM accède bien à l'extérieur, net etc, j'accède au VMs depuis mon lan.
- Mon host répond au ping
- L'host arrive à pinger les VM/container
 
Mais depuis l'host je n'arrive pas à sortir sur mon réseau local, ni sur le net    
 
Je n'ai aucune règle iptables ni rien, je loupe un truc ?
 
(sinon je lis le topic, j'ai repris à la page 35 )

Tu as bien une ligne "gateway xxx.xxx.xxx.xxx" dans la déclaration de vmbr0 dans /etc/network/interfaces ?

 
Oh putain j'ai honte  
 
on va essayer avec la gateway, y a des chances que ça marche mieux en effet
 

Tu peux aussi configurer un serveur dns, c'est pas mal

 
Par curiosité, t'as installé sur une debian au lieu de la distrib proxmox ? (qui est aussi basée sur Debian je crois). Si oui, pourquoi au lien de la distrib direct ?
 
C'est pas pour critiquer mais juste pour comprendre

 
J'ai fais un raid5 logiciel de 4 disques puis des volumes LVM;
Puis pour avoir une interface graphique.
 
Mais je t'avoue ne pas avoir essayé l'ISO 'tout fait' pour voir si c'était possible avec

Le raid logiciel ne peut pas être configuré via l'iso d'installation de Proxmox (hors zfs) donc passer par une debian puis installation de proxmox est la bonne solution.

 
OK ça me va      

snipereyes: t'as du ssh dessus hein et c'est une debian en dessous donc tu peux recréer ton raid5 + lvm sans aucun soucis après même avec l'installeur de proxmox.

Sauf si tu veux mettre l'os sur le raid5

Tien ça me fait penser que j'tenterais bien de mettre l'os-hyperviseur sur du iPXE
 
XaT