ldelloca's Posts

Ciao, stavo pensando esattamente lo stesso, ovvero di verificare dal file vmx quale fosse il vmdk che viene ad oggi utilizzato. Se effettivamente il disco è il vmdk originale, si può pensare di rimuovere totalmente le snapshots. Il disco 2 invece è a posto? PS: invece di usare il datastore browser, usa una sessione ssh, così puoi vedere i descriptor files e i flat files. Oltre che da riga di comando è possibile cancellare velocemente i delta disks "persi", ed è un metodo tutto sommato "sicuro" perchè se il file è in uso (ovvero la VM sta usando la snapshot) il sistema ti dovrebbe impedire di cancellarlo. Se si cancella senza errori, il motivo è che non è in uso dalla VM. In questo caso quindi meglio tenerla accesa per mettere i file corretti in lock. Luca

Ciao, ESXi (e anche Veeam) vuol farti creare una nuova snapshot prima di consolidare le altre perchè la VM è accesa, e la nuova snapshot serve a raccogliere le nuove scritture mentre le altre snapshot vengono cancellate. Questa "helper snapshot" non è necessaria se la VM è spenta. Proverei quindi a fare il commit delle snapshots con la virtual machine spenta, in questa condizione potresti adottare i comandi descritti in: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026380 Ciao, Luca

Ciao, dalla lista hai 29 snapshot, più la macchina base fanno 30 restore points. Veeam non ti fa fare la snapshot aggiuntiva, ma la console di vSphere dovrebbe fartelo fare comunque, dato che il limite è 32. Dubbio, per caso ti compare nel menu di vCenter l'opzione "consolidate"? Luca

Sì è strano ma assolutamente noto e documentato, ogni tanto per diversi motivi può capitare che ci siano queste snapshot "dimenticate". VMware ha una procedura apposita per consolidarle: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002310 Ciao, Luca

Ciao, ci sono 29 snapshots di questa VM. Il limite di vSphere è 32, ma Veeam si ferma a 28 perchè ne servono altre come helper per alcune operazioni che compie. Quindi anche se non hai postato l'errore credo proprio che sia questo il motivo. Devi rimuovere alcune snapshots, oltre che sono vecchie di due anni quindi non vedo assolutamente il motivo di tenerle in giro, creano solo problemi. se servivano come punti di ripristino, immagino che dopo 2 anni se nessuno abbia richiesto di tornare a uno stadio precedente, le si possano anche cancellare... Luca

Mi verrebbe da dire che se parte da sda dovrebbe finire di partire e “semplicemente” indicare che sdb è corrotto. Non l’ho mai fatto, ma staccare sdb e far partire il raid volutamente in degraded mode? Non saprei però sinceramente, ripeto non ho mai usato md, sempre raid hardware...

Il master disk parte anche senza l’altro disco in realtà, non c’è bisogno di fare nulla… Potrebbe essere che GRUB non è installato su sdb, però prima mi "farei un giro” sul server facendo boot da un liveCD stile knoppix o simile innanzitutto per vedere che il contenuto sia integro, nel caso farne una copia su disco esterno, e poi lavorare sul server. Se manca grub su sdb puoi seguire questo post ad esempio: https://urldefense.proofpoint.com/v2/url?u=http-3A__serverfault.com_questions_612529_linux-2Draid-2D1-2Dhow-2Dto-2Dmake-2Da-2Dsecondary-2Dhd-2Dboot&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=WqnSQ812JDCBQNRS86muKhKGgk7sUIatqznZcqYQ0mU&m=rwcpu0qTDJFNyAbsyZmiZIa62hzEyj0UL7flImBuMQQ&s=VOkWsXtTndNrajk5CPJmh8ta8IudTGbDQH3UCeU0VwM&e= Ma come sempre, leggi bene i comandi e controlla che corrispondano alla tua situazione. Luca.

non credo le due cose sono collegate, visto che rsync (o scp, o altro) copiava solamente da sorgente. Non so alla fine cosa hai usato, la stringa come detto era un suggerimento, spero ti sia guardato un pò il comando e le opzioni prima di lanciarlo... Scusa, ma se il server vecchio era pericolante, perchè l'hai riavviato? Motivo? In ogni caso il software raid pare avere qualche problema, i dischi sono entrambi visibili da bios e da console? Prova a leggere qui, non ho mai usato estesamente il raid software di md: https://www.centos.org/forums/viewtopic.php?t=16335#p77460 Potrebbe essere che md ha invertito i due dischi del raid1?

Se come spero almeno la password di root è disponibile, io costruirei sinceramente una nuova virtual machine con lo stesso OS, e poi con rsync copierei tutte le varie folder nel nuovo sistema. Sul nuovo server poi esegui un comando tipo: rsync -aHxv root@1.2.3.4:/* /mount --exclude=/dev --exclude=/proc --exclude=/sys --exclude=/tmp --exclude=/net Dove 1.2.3.4 è l'IP del server fisico attuale. Se c'è qualche applicativo che gira come daemon e tiene aperti databases o simili, magari meglio fermarli prima di iniziare la copia per essere sicuri che i database siano consistenti. Ci sarà inoltre da lavorare un minimo sulle configurazioni di rete, udev troverà una scheda di rete con mac address differente quindi dovrai riconfigurare la scheda nuova. In questo modo puoi fare tutte le prove che servono per essere sicuro che il nuovo server sia funzionante prima di spegnere quello vecchio. E anche fosse, quello vecchio lo tieni in vita prima di dismetterlo, basta staccargli la scheda di rete per provare quello nuovo. Luca.

Domanda banale, ma il server fujitsu è nella hcl di VMware? Se si, dovrebbe avere i moduli di controllo hardware, oppure sul sito fujitsu puoi trovare i moduli vib per controllare l'hardware, non ho mai usato questa marca quindi non so che tipo supporto offrano per ESXi. Luca

Scusa ma continuo a non capire: se sai di quanti iops di picco hai bisogno, invece di fare i conti tra dischi sata sas e ssd, già sai che fondamentalmente avrai bisogno di tiering su SSD, altrimenti coi soli dischi meccanici andrai a dover disegnare uno storage gigantesco solo per avere questi numeri. Se hai già una lista di possibili fornitori, meglio a questo punto sottoporre a loro le richieste (tot iops di picco, tot spazio disco, connettività di tipo X, e il budget) e vedere cosa loro configurano per te. Luca.

sono d’accordo con tinto. La scelta migliore, per ora, è installare un tool di monitoring (Veeam One, vFoglight, VMturbo…) a tracciare per bene per diverse settimane l’attività storage di tutte le VM, in modo da avere innanzitutto una visione chiara e dei numeri precisi sul carico di lavoro attuale. Poi, con questi, è possibile fare delle scelte più ponderate. Adesso stiamo parlando di tot iops “al chilo”, e si rischia solo di buttare via i soldi. PS: oltretutto 30.000 iops possono benissimo girare su rete a 1Gb, dipende per esempio dal block size medio. Ma anche questa è un’informazione che si può ottenere solo dai logs.

Ciao, non ho mai usato RHEL ma sempre CentOS. Ho googlato velocemente anche io, magari questo ti può dare qualche spunto? https://urldefense.proofpoint.com/v1/url?u=http://tcwd.net/vblog/2014/05/24/rhel-virtual-datacenter-licensing-on-esxi-explained/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=FGyPC8ZSvBkKihkoeKgCmjuZI2qYJ8xvSchS1aM1v%2Fc%3D%0A&m=T%2B4r5wayEnrpPVo1igyiVsBJES2r3csuSQ%2F9XqyhU74%3D%0A&s=a00387b726371ed480d27c844c1324fd45629dcef27aa7468d61f048ca4082ab Ciao,  Luca.