Hyper-V checkpoints are a double-edged technology. Used appropriately, they can be a quick and simple solution to any number of problems. Used inappropriately, they can cause an entire deployment to be brought to a catastrophic halt. To make it worse, many people are not entirely clear on just what a checkpoint truly is. This guide is meant to help you correctly Implement Hyper-V Checkpoints.
Eric Siron shares his experience of providing data redundancy for small businesses by offering 8 Best Practices for Small Business Backup using Hyper-V.
In part one of this series, we talked about Hyper-V’s key-value data exchange feature and got an idea for how it works. In this post, I’m going to provide you with some PowerShell modules that are intended to alleviate most of the pain of using Key-Value Pair Data Exchange. Once you’ve implemented these modules on your systems, you’ll be able to pass data back and forth from guests to hosts.
You’d be hard-pressed to find any feature of Hyper-V that’s been around as long as Data Exchange yet received so little attention. That’s not surprising, since it’s fairly difficult to use at all, much less effectively. My goal with this post is to introduce you to this feature along with a few methods that make using it easier. At the worst, you’ll get a decent understanding of what it does. If you’re lucky, you’ll come up with a use for it.
It is possible to connect the host’s physical optical drive directly to a virtual machine for the purpose of loading operating systems and software, but, unless the host is right next to you, it’s not very practical. The obvious solution is to use images of the necessary discs. Hyper-V makes some of that easy, but using it across a network connection can be somewhat more difficult. This post will examine your options.
Back on the 10th of Dec. some of you may recall that Thomas Maurer and I did a webinar on Scripting and Automation in Hyper-V. We had a number of questions throughout the webinar that we were not able to get to due to time constraints, but I’ve compiled a list of some of the most ask about questions below and what their answers are.
There are currently a lot of emerging technologies in the marketplace right now, and there are few that are more popular than the concept of nested virtualization. This capability has been a possibility in the vSphere ESXi stack for some time, but until recently, Microsoft had shown little interest in providing this same functionality. It could be, this was due to the fact that the only real use cases were lab environments and training. This has changed recently with the advent of cloud and container technologies as we continue to abstract more and more layers of our IT infrastructure.
It’s not difficult to find all sorts of lists and discussions of best practices for Hyper-V, however best practices lists are a bit tougher to find for failover clustering. What I’m going to do in this article is focus in on the overlapping portion of the Hyper-V/Failover Cluster Venn diagram, resulting in my 19 best practices for a Hyper-V Cluster.
My standing recommendation on allocating virtual machine resources is to start small. It’s very easy to grow almost all virtual resources with very little, and sometimes no impact. Taking resources away, on the other hand, can be trickier. The most difficult resource to remove from a virtual machine is drive space. If it’s just a matter of removing a disk, that’s usually not so bad. Making a virtual disk smaller is somewhat trickier.
Creating and managing VDI are not trivial tasks in Hyper-V (or any other hypervisor) and can end in disaster if not properly planned. My goal with this article is to reach you during the contemplation phase where you’re trying to determine if VDI is worth tackling.
Here are 7 things to think about before even starting a pilot project.
Replica is one of the many compelling features of Hyper-V. It allows you to create a comprehensive disaster recovery system with very little effort. It’s simple to design and deploy. What’s not always so easy about Hyper-V Replica is understanding many of its constituent components and some of the operations. In this article, the focus will be on the Replica Broker.
Most titles like that requires some clarification. I would hope that, to anyone that has read even a little of my work, it’s obvious that I’m not anti-Microsoft. The vast majority of technologies that I work with at my regular job are from Microsoft. However, I strongly believe that my pragmatism must always be tempered by my realism, and the realist in me insists that regardless of how much I depend on something, I must always remain aware of its flaws. So, in this post I’m going to talk about the larger things I believe that Microsoft should truly be doing differently with Hyper-V. In simple terms, these mainly boil down to backward compatibility.
If you’re administrating a Hyper-V cluster that is a few years in age and you’re thinking of expanding, you might be at the point where it is no longer feasible to purchase a new host with hardware that matches your existing hosts. However, if the CPU on the newer host is of a different version or generation, live migration or restoring a saved state VM between the new and old host will fail. Luckily, Hyper-V comes with a feature called CPU compatibility mode that will allow these functions to continue between CPU generations.
Are there any bumper stickers or t-shirts out there that say, “I was using Hyper-V before using Hyper-V was cool?” If there are, I think I need one. I built my first production system on Hyper-V 2008 R2 not long after it debuted. So, I missed the early-adopter crowd by a couple of years but I’ve definitely been in this for a while. The only problem with sticking with a tech as it grows from infancy is that sometimes things change and you miss out. One of the things that changed on me was the way that time synchronization works between Hyper-V and its guests.
When creating a Hyper-V checkpoint, it is crucial to know where the checkpoint files are being saved, especially since checkpoint files can fill up storage. When trying to find where the checkpoint files are being stored in your Hyper-V environment, it is important to understand what types of files are generated when creating a checkpoint. This is because components of the checkpoint are stored in two separate locations. The AVHDX file is stored with the VHD storage and the checkpoint configuration files are stored with the VM’s active configuration files.