Hi, guys, I finally managed to finish an article on deploying VMware vSAN on the nested ESXi hosts. Some had difficulties with setting up the networking for this scenario, so here’s a guide on this matter from me!
Today, I’d like to share some of cool ESXCLI commands for performing a good part of IT related routines. Sure, vSphere Client has a wonderful GUI allowing for carrying out most of daily tasks… but CLI is much more powerful tool once you master it! So, that’s actually why I share my “Swiss Army knife” commands here.
Having a disaster recovery site is a must for any company. That’s why I wrote an article some time ago on how to set up Site Recovery Manager (SRM) so that it allows for creating a disaster recovery site. Today, I describe how you can actually create that site and migrate your VMs from the main site there.
Remember Blade Runner 2049, when people lost all their valuable data in The Blackout? Thanks to the 3-2-1 backup rule developed by Veeam, a disaster like that will never come true. I decided to write an article discussing this strategy in detail to make sure that guys new to IT will keep their data safe.
VMware vCenter Site Recovery Manager has been introduced back in 2011. It is a VMware vCenter plug-in for disaster recovery site configuration and management. It also allows migrating to that site at the moment of need or during planned migrations. In other words, SRM ensures shortest services downtime if something goes wrong at your main site. Please, don’t count on that thing that much since there will be insignificant time losses anyway.
An ability to back up and restore vCenter Server Appliance (vCSA) configurations appeared back in vCSA 6.5. I guess that many have already used it. If you were unlucky to restore from that backup, you know that this procedure is not that straightforward. Bad news: In vCSA 6.7 Update 1 configuration restore process is still like that. In today’s article, I take a closer look at how you back up and restore VMware vCSA 6.7 configuration.
19 September 2018, VMware announced the end General availability for vSphere 5.5 – their probably most installed vSphere versions to date. But, wait, why write about it in January 2019? You see, some being misled by a title starting with “End”, think that it might be the end for the solution… WRONG! To overcome this fallacy, I decided to write an article that sheds light on VMware Lifecycle Policy and proves that End of General Availability is not the end!
Quick Boot is another cool feature introduced in vSphere 6.7. Why does it deserve own article? Because, with this feature in place, rebooting ESXi won’t lead to restarting a server itself. By optimizing the reboot path, Quick Boot enables to avoid time-consuming firmware and device initialization processes. Looks really handy when all you need is just applying small changes or doing some update quickly, doesn’t it? In this article, I discuss how to quick boot a server and share my experience of using that feature. How fast will ESXi reboot with that feature in place?
Some time ago, there was a post about new cool features brought to VMware vSphere 6.7 with Update 1. I forgot to mention one thing that appeared in VMware vSphere even before the update – PMEM support for your VMs. Well, I think it won’t be enough to write something like “Wow, it is good to see PMEM support in vSphere… it is very fast”. This innovation needs own article shedding light on what PMEM is and how fast your VMs can actually run on it. Unfortunately, I have no NVDIMM devices in my lab yet… but I still can simulate one using some host RAM!
Building a virtualized environment with VMware Workstation is a bit different from the scenario discussed before. Today, I use VMware Workstation 15 Pro – a virtualization platform that supports hypervisor virtualization and allows administrating small VMware infrastructures. Yes, Workstation is a vCenter-like platform, but it has rather limited functionality. Anyway, it allows building a vSphere lab for free! This being said, the solution is good for this article.