As many guys working in IT, I have my own lab. I usually prefer to use my own lab as the degree of freedom I can experience cannot be compared with a corporate lab. It often happens that some specific configurations (one for all, my vCloud Director environment) are better looking in my own lab than any other place, and so I also use my lab to show those technologies to partners and customers. This is easy when I’m at home, but I may be in an hotel room, in a conference room at the customer’s site, or another different place, and in many of these situations it may happen (and it happened enough times to justify this little project) that the connections to my lab are blocked by a firewall or another device. I have two ways to connect to my lab: an RDP to a jumpbox machine, published on a different port that the usual TCP/3389, and an ipsec vpn concentrator. In one case, none of them was possible at a customer, so we ended up with a colleague of mine tethering from his phone. I decided it was time to develop a better solution that was able to work in almost any situation. And my solution involves the always amazing SSH.
During my tests with keepalived as a balancer for a linux cluster, I was searching for a way to quickly simulate a node failure and to check keepalived was correctly failing over to the other node. Here is a quick and smart way to do it!
If you are facing the error “Failed to set locale, defaulting to C” when running yum on CentOS, here’s a quick solution to fix this warning.
One of the biggest misconceptions about Veeam Backup & Replication, often fueled by competitors, is that it requires the complete server installation in order to run restores. So, this becomes a Single Point of Failure, just like many other solutions from competitors. This is completely untrue: there are two main features in Veeam that make restores possible even without the server installation.
It’s now common knowledge the vSphere Web Client is the main and preferred client VMware want us to use. Apart the resistance of users to adopt new tools, there are also two clear situations where you still need the Windows Client: the configuration of an ESXi server not connected to vCenter, and Update Manager. In […]
E’ oramai appurato che il Web Client di vSphere è il client principale che VMware vuole farci usare. Oltre alla resistenza al cambiamento opposto da molti utenti, esistono ancora due oggettive situazioni in cui il client installabile su Windows risulta necessario: la configurazione di un server ESXi non connesso a vCenter, e l’uso di Update […]
Abbiamo parlato ieri della gestione dell’orologio in una VM Windows. Vediamo oggi come fare la stessa cosa con una VM Linux. Innanzitutto, attenzione al kernel che usate: se avete una VM multiprocessore, USATE i kernel SMP. Kernel non corretti sono la primissima causa del “time drift”. Secondo, è possibile passare al kernel alcuni parametri, che […]
Una delle funzioni più “cool” di vsphere, anche se meno note, è la possibilità di aggiungere a caldo ram a quei sistemi operativi che supportano questa funzione. In questo modo si può togliere d’impaccio un server sovraccarico azzerando completamente il downtime necessario al reboot. Tra i sistemi che supportano questa funzione c’è ovviamente linux. Potrebbe […]