Reprise du message précédent :
J'ai l'impression que ces boitiers ne sont plus commercialisés.  
Ils ont maintenant une offre SaaS avec Trustlane. A voir.

 
Prisma access, 2022 mon gars.

 
Et Gloubi protect ?  

Gloubi derrière l'user, chaque click sur un lien louche, ouverture de mail douteux, c'est une grosse tatane dans la gueule Bon c'est un peu cher, mais efficace

 
C'est le problème avec les radiateurs ; ils sont souvent chaud  
 

 
Y a l'option barre à mine qui résout définitivement le problème   ²

Barre à mine sur le PC ou l'user? Sur le PC, ca a l'avantage de faire tourner la filiale vente de matériel. Sur l'user, c'est de suite peu probable que l'user renouvelle le contrat

Si ya des experts VMware dans la salle : existe il un call d'API qui permet d'exporter un snapshot directement ? (sans avoir à accéder au datastore à côté).

J'ai peut-être pas compris la réponse mais c'est quoi exporter un snapshot sans accéder au datastore ?

 
en passant seulement par la couche applicative sans accès au stockage peut être ?  

Mais snapshot c'est pas le delta de la vm uniquement?

Typiquement avec XCP-ng, via XO, je déclenche le snapshot, puis je demande à XCP-ng de me filer une URL du disque que je veux récupérer, qui va être un handler HTTP exposé par l'hôte, que je vais aller récupérer directement (le contenu du disque). Dans ce cas, je récupère l'intégralité du contenu du disque (un full quoi). Je peux aussi lui demander le diff entre 2 snapshots et il me sert un handler HTTP qu'avec les blocks changés. J'ai 0 besoin d'accéder au datastore directement, tout passe par l'hôte et son API.

J'ai besoin du full et d'un delta aussi. J'imaginais que c'était pareil avec VMware ? Ou alors la façon de faire c'est de lire les fichiers sur le datastore directement ?

Je m'auto répond : visiblement, tous les fichiers du datastore sont disponibles directement via une requête HTTP, y compris les fichiers delta.
 
Exemple concret :
 

 
Avec le chemin, le nom du DC et du datastore et bien entendu le nom du fichier dans le datastore.

Mais le fichier snapshot, il grossit au fur et à mesure.  
 
comment tu vas le recuperer sans qu'il soit corrompu?

VM arrêté  
ou sinon ça store sur le snapshot et pas sur le vmdk de base ?

L'idée c'est :

1. d'exporter le full une première fois pendant que la VM tourne (le principe d'un snap c'est qu'il fournit une image fixe de la VM à un moment). Et l'importer chez nous
2. puis stopper la VM, refaire un snap pour récupérer le delta depuis le premier snap. Fusionner le delta dans XCP-ng
3. Démarrer sur XCP-ng

Comme ça, tu réduis le downtime au maximum quand tu migres de VMware à XCP-ng

C'est le même principe que la « warm migration » qu'on fait chez nous : https://xen-orchestra.com/blog/warm [...] orchestra/

ah ok tu exportes le vmdk d'avant le snapshot (le gros fichier ^^ ) pas le fichier snapshot vmdk000000x.
un second snap pour récupérer le fichiers vmdk00000x que tu avais fait avant.
et de remettre en place les 2 fichiers la full

mais tu ne dois  pas modifier le fichiers VMX  ? car la vm va s'attendre à faire tourner le second snap non ?

Sur XCP-ng, quand tu snap, ça crée une « base copy » qui est le parent en read only au moment du snap, et le disque actif c'est du copy on write sur un nouveau disque (qui écrit les blocs nouveaux ou changés par rapport à la base copy). Donc tu peux exporter le full qui est en fait un pointeur vers la « base copy » sans problème (j'imagine c'est ça dont tu parle, le fichier d'avant le snapshot dans VMware).

Nous on va envoyer le full, puis les blocs changés depuis le premier snap (VM à l'arrêt) et merger ce diff dans la destination, puis booter la destination côté XCP-ng.

Je sais pas ce qu'est le fichier VMX par contre.

edit : note qu'on réplique d'abord pendant que la VM tourne (le plus long), et qu'on arrête ensuite le moins longtemps possible car on ajoute que les blocs écrits depuis la première synchro « full ».

Sauf que si tu migres du Linux, faut pas oublier d'installer un kernel xen avant la migration, non ?

 
Euh... non
 
Avec Xen ça fait un bail que les VMs n'ont pas besoin d'être modifiées pour tourner (mode HVM). Même les drivers paravirtualisés sont inclus dans Linux depuis 15 ans environ
 
Les trucs à faire c'est de virer les tools VMware en amont je pense, et probablement ta conf réseau avec les devices name qui vont changer. Mais rien de bien compliqué.

 
Meuh non, ça s'appelle de la remédiation sur des vulnérabilités : on a éliminé une faille de sécu, le client est content !  

 
J’ai déjà mis une claque sur la tête d’un collègue qui a reçu un mail avec une PJ, et qui a fait « oh, un truc louche en pdf je fais quoi ? » et qui a double cliqué sur le doc avait que j’aie eu le temps de répondre.

Effectivement vu comme ça

Pas quelqu'un du domaine d'activité de ta boîte j'espère

 
Je te confirme que désinstaller les tools vmWare c'est vraiment un passage obligé avant tout export.
Sinon une fois sorti de vmware c'est une chianlie a supprimer. Ça ne se désinstalle pas proprement.
Et vmWare n'aide pas du tout a résoudre ce fait (forcément).

tu parlerais pas de windows toi ? ;o

 
 
Sisi, un RSSI…

Ah oui c'est pas sérieux

Du coup que je trouve que la claque est trop gentille  

 
Du coup dégradé dans la foulée à 'technicien de surface en charge du remplacement des toners des 900 MFP de la GloubiCorp'

Trankil la novlangue chez les informaticiens ? Respectez-vous, boudiou.

 
Du coup:  
https://www.youtube.com/watch?v=P2ZOpwlLYVA
 

Tranquille ouais

On arrêtera la novlangue quand les juristes abandonneront le latin

 
Et quand les commerciaux arrêteront le bullshit.

 
du coup tu proposes quoi ?

 
A l'époque c'était la "gloubi et ce type corp", je pouvais pas le dégrader par contre je l'ai pourri et je l'ai obligé à reset son Mac, rien que pour la forme.

Bouge pas, je prends une photo dans le bureau d'à côté.

Voilà

Du coup, pourquoi faire compliqué alors qu'on peut faire simple ? typical french