As the title is speaking for itself, it is quite clear that today, I am going to discuss various methods to open and close firewall ports on ESXi hosts. It is useless to consider whether configuring firewall rules is harmful or not since every admin once in a while meets the necessity of fine-tuning network to distribute access rights. So, you ought to know all the tools at your disposal one way or another.
Last year, my colleague asked me for advice. He couldn’t add an iSCSI target, provided by AWS Storage Gateway, on VMware ESXi cluster. So, initially, this material was intended to serve as a manual. However, since I got a similar question once more just recently, I realized that this topic could be interesting to the others as well, which is why I decided to share this guide, hoping it will be useful.
As an admin, I often have to deal with the necessity to transfer large OVF and ISO files or even move virtual machines (VMs) between ESXi hosts that have poor network performance or disposed in different locations with no network connection whatsoever. If a case like this occurs, a USB flash drive or USB external drive is a way to go. More specifically, you can use a drive in two different ways (by the way, both authors have my most sincere regards and appreciation for presenting these methods in a most coherent and simultaneously simple way). The first one is to copy files from a USB device to a host directly through SSH session without changing drive format as the following article suggests. However, such an approach has some issues, the most tedious one being maximum file size limitations, which certainly limits its use for larger files. You cannot work with the Graphical user interface (GUI) as well. Instead, you gotta use SSH and dive deep into the host data storage system, so you can figure I am a much bigger fan of a second way: creating a VMFS datastore on a USB drive. You can connect it to ESXi hosts and transfer files from one to another (or just store a temporary copy on an external storage device).
Some time ago, I published articles on setting up a home lab using a PC running ESXi and Workstation. We all know that nested virtualization is not an ESXi-only feature; Microsoft Hyper-V also enables us to run VMs inside its VMs. Microsoft’s implementation of this technology is a bit different, but it exists. And, considering that VMware and Microsoft have been competing for a long time, it’s interesting to see what each has to offer for this type of virtualization. In this post, I examine how easy it is to configure a nested virtualization layer inside Hyper-V and vSphere VMs and discuss peculiarities of this process in both environments.
Once engineers came up with the way to virtualize graphics processing units (GPUs), the new era started for machine learning, gaming, modeling, and whatever else IOPS-hungry: all these applications can now go cloud! In this article, I’d like to take a closer look at why GPU virtualization is so promising, who pioneers this tech, and how VMware managed to cover the gap between the virtual and bare-metal GPUs.
It goes without saying that hard disk drives (HDDs) are one of the most common storage medium to date. Data centers, home labs, and PCs have them inside. No wonders, HDDs offer unmatched capacity for moderate costs per GB. Let’s take a closer look at how to choose an HDD. This article is going to be pretty much a long read, but there’s a flow chart in the end that helps to make your choice.
In this post, I’d like to discuss data consistency – an important thing when it comes to backups. If data is consistent, it can be used across your environment, so you can spin up applications faster after restoring from such backup. Actually, it’s why I think this topic to be so important even now.
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?