Using Snapshots in Hyper-V
Snapshots: tricky about simple
Surely, many are familiar with the rather useful feature of many virtualization products — snapshots, in the common people snapshots. A snapshot of a virtual machine is like being saved in a game: in case it’s badly done somewhere (Barmina’s patch, for example), you can go back and repeat everything again. In this article I will try to tell in more or less detail about the work of snapshots and about some of the nuances of their application. The article focuses on Microsoft Hyper-V, but with some stretch the article’s material is applicable to other virtualization systems (in particular, VMWare).
Before continuing - let's remember what components the virtual machine consists of:
The configuration file is the basis of the virtual machine; it stores all settings related to the virtual machine. It is an XML file that has, strangely enough, an XML extension. In VirtualPC / Virtual Server, this file had a VMC extension.
Virtual disk file Usually, virtual machines use special image files with a .vhd extension as a hard disk. This format, originally developed by Connectix, after its acquisition by Microsoft, was used in virtualization products, and not only in them: in particular, they are used in Microsoft Software iSCSI Target, and in Windows 7 and Windows Server 2008 R2 with VHD disks You can work at the OS level, right up to booting the OS itself from them.
Differential disks are the basis of snapshot technology. When creating a snapshot, the recording into the VHD file is terminated, and all subsequent changes are recorded in a separate file with the VHD extension.
Save State is one of the useful functions of the virtualization system. When you save the state, all the contents of the virtual machine memory, processor registers, etc. saved to special files, and virtualka goes to the "Off" state. After that, you can do anything, until the host machine is restarted, and then start the virtual machine again - and it will work, as if nothing had happened, in exactly the same state as it was before it was saved. The function Hibernate in Microsoft Windows works in approximately the same way with the only difference - state saving occurs at the level of the virtual machine itself, and not at the guest OS level. In VirtualPC and Virtual Server, a file with the VSV extension was used to save the contents of the memory, while in Hyper-V there were as many as two - BIN and VSV.
Export file If you need to clone a Hyper-V virtual machine, or move it to another host, you must perform an export and then import operation. When exporting, the XML configuration file is converted to a file with the EXP extension. In VirtualPC and Virtual Server, it’s enough just to copy the files of the virtual machine, and in Hyper-V they invented import / export - as they say, for security purposes.
There are two types of snapshots: online and offline. On-line is called snapshot made on a virtual machine with a running guest OS. Accordingly, if the virtual machine was in the “off” state, then the snapshot will be called offline. For the user, there is absolutely no difference between online and offline snapshots. They differ only in the file composition, because when creating a snapshot on a running virtual machine, the Save State operation occurs, and the Save State data is included in the snapshot
Online snapshot:
')
As already mentioned, virtual machine snapshots are the same as saving in the game. And their only purpose is to provide a point of return in case of possible errors. Snapshots are not a backup, and they cannot be used for disaster recovery. Using snapshots in a production-based environment is not recommended, because it can lead to a drop in performance, why this is so - it will be clear further from the article. If you need to frequently create backup copies to protect against user errors - you need to use other tools, for example - incremental backups or transaction logs, if we are talking about databases.
In addition, you need to remember that you can and need to manage snapshots only through standard Hyper-V tools (MMC Hyper-V Manager snap-in, WMI providers, PowerShell cmdlets) and third-party software using such tools — for example, Microsoft SystemCenter Virtual Machine Manager.
So, what happens when creating snapshots?
For simplicity, we will present a virtual machine with one hard disk (see figure). We have just installed an operating system on it, and before moving on - we want to snapshot. When you select Create Snapshot, the current configuration of the virtual machine is saved in a separate file (Copy of Configuration 1), and an AVHD file is created (AVHD Differential Disk 1). In this case, changes are made to the virtual machine configuration itself, and from that moment only a read is made from the VHD file, and the entire write is made only to the AVHD file (green arrow). The virtual machine disk already consists of two files: VHD and AVHD. We got the first snapshot, which for convenience can be called “OS Installed” (by default snapshots are given the name from the name of the virtual machine with the addition of the date and time of creation).
Now, let's say that we did something (for example, installed the application) and take another snapshot. Just as before, the configuration is saved in a separate file, a new AVHD is created, and the recording is redirected to it already (yellow arrow). The virtual disk consists already of three files: VHD and two AVHD. For simplicity, the resulting snapshot can be called “Apps Installed”.
Suppose we created one or more snapshots. What can you do with them now? The choice here, in principle, is not too rich: snapshots can either be applied (Apply) or deleted (Delete). In fact, this means:
This must be clearly understood for yourself, so that later you do not “break the fire of wood”. As one expert said, “Delete means, Apply means Delete,” and it would be even better to say in Mayakovsky’s style: “We say Delete” - we mean “Apply”, we say “Apply” - we mean “Delete”.
Let's see how this happens.
We want to roll back to the time of the installation of applications. To do this, select Snapshot "Apps Installed" ("Snapshot 2") and make "Apply". As soon as we do this, the current configuration of the virtual machine is replaced by a copy of the snapshot (i.e., the Configuration will be overwritten from the Copy of Configuration 2). After that, AVHD with the changes made before the “rollback” (“Differential disk AVHD 2”) is deleted, and a new AVHD is created, to which the recording is immediately redirected.
Now, let's say we finished our experiments, and before entering the virtual machine into production, we want to delete all our snapshots. If we remove the Apps Installed snapshot, the following will happen:
When you roll back to the OS Installed snapshot, the AVHD currently in effect (as part of the Apps Installed snapshot) is removed, a new configuration copy and a new AVHD (AVHD Differential Disk 3) are created, which in our case refers to VHD itself. Further, if we, for example, create another snapshot (for simplicity, call it “New Snapshot”), then the new AVHD will be created on the basis of the “Differential disk AVHD 3”). There may be more such branches - for example, from the OS Installed snapshot there can be three or more branches. Delete / Apply operations on branching occur in the same way as described, but with some nuances. For example, if we now want to remove the OS Installed snapshot, it will disappear from the list and a copy of the configuration will be deleted, but merging will not occur after the virtual machine is stopped. Why? And everything is very simple: since not one but only two AVHDs are formed from our VHD - you cannot overwrite the VHD itself: if AVHD1 is used for rewriting, then AVHD3, and accordingly - all that is based on it possible rollback will not work for them.
Here is another "exception to the rule": let's say we remove the Apps Installed snapshot. As we can see, he does not have his AVHD. Therefore, the previous AVHD1 will be deleted.
If we want to return to the Apps Installed snapshot, a new AVHD will be created based on AVHD1 (well, that is, a new AVHD2, roughly speaking), and the currently active AVHD4 will be deleted.
First of all, as I said before, you need to remember about “Delete means, Apply, means Delete”, and think before pressing the button, so as not to lose anything.
Secondly, if the virtual machine contains online snapshots, it is extremely not recommended to export and transfer it to another server. The fact is that the online snapshot contains the state of the processor registers and the contents of the memory, and using such a snapshot in another hardware environment can lead to the crash of the guest OS.
Thirdly, as already mentioned, snapshots are not recommended for use in a production environment. Surely, you know that for production it is recommended to use virtual disks of a fixed size - in order to get rid of the fragmentation of the VHD file. Creating snapshots, we artificially divide our virtual disk into separate files - VHD and AVHD set. On high-load systems, this can lead to some performance degradation. In addition, when you remove snapshots, a merge operation takes place, which can also affect the overall system performance, and, moreover, can increase the idle time when the virtual machine reboots. For example, if you deleted one or several snapshots on a virtual machine, and then you had to restart it (for example, when installing updates), the OS will not start loading until the merge operation is completed completely. Therefore, snapshots can be used before putting into production, to save time during software installation and initial setup. After that, all snapshots need to be removed, wait until the end of the merge, and only then enter into production.
Another small point: in the Hyper-V settings, you can set a separate path for placing virtual machine files and a path for placing VHD. By default, both are stored on the C: drive. If you plan to use a high-speed RAID array for VHD storage, for example, you need to store not only VHDs on it, but also virtual machine files. The fact is that when creating snapshots, AVHD files will be stored in the exact location that was chosen to store virtual machines. And it may happen that the VHD itself will be stored on a separate disk array, and the AVHD heap will be on the C: drive, which is not good.
On this I will finish this post, and without that already big. I apologize for some confusion, the topic with seeming simplicity is a bit non-trivial to explain. For a better understanding, I advise you to watch a screencast, with an animated presentation and demonstration: www.techdays.ru/videos/1490.html
If haboobschestvennost will not mind - I can give links to my other screencasts and articles about Hyper-V, so as not to cross-post and not copy-paste. I hope someone interested my article, in any case - thanks in advance.
Surely, many are familiar with the rather useful feature of many virtualization products — snapshots, in the common people snapshots. A snapshot of a virtual machine is like being saved in a game: in case it’s badly done somewhere (Barmina’s patch, for example), you can go back and repeat everything again. In this article I will try to tell in more or less detail about the work of snapshots and about some of the nuances of their application. The article focuses on Microsoft Hyper-V, but with some stretch the article’s material is applicable to other virtualization systems (in particular, VMWare).
Before continuing - let's remember what components the virtual machine consists of:
The configuration file is the basis of the virtual machine; it stores all settings related to the virtual machine. It is an XML file that has, strangely enough, an XML extension. In VirtualPC / Virtual Server, this file had a VMC extension.
Virtual disk file Usually, virtual machines use special image files with a .vhd extension as a hard disk. This format, originally developed by Connectix, after its acquisition by Microsoft, was used in virtualization products, and not only in them: in particular, they are used in Microsoft Software iSCSI Target, and in Windows 7 and Windows Server 2008 R2 with VHD disks You can work at the OS level, right up to booting the OS itself from them.
Differential disks are the basis of snapshot technology. When creating a snapshot, the recording into the VHD file is terminated, and all subsequent changes are recorded in a separate file with the VHD extension.
Save State is one of the useful functions of the virtualization system. When you save the state, all the contents of the virtual machine memory, processor registers, etc. saved to special files, and virtualka goes to the "Off" state. After that, you can do anything, until the host machine is restarted, and then start the virtual machine again - and it will work, as if nothing had happened, in exactly the same state as it was before it was saved. The function Hibernate in Microsoft Windows works in approximately the same way with the only difference - state saving occurs at the level of the virtual machine itself, and not at the guest OS level. In VirtualPC and Virtual Server, a file with the VSV extension was used to save the contents of the memory, while in Hyper-V there were as many as two - BIN and VSV.
Export file If you need to clone a Hyper-V virtual machine, or move it to another host, you must perform an export and then import operation. When exporting, the XML configuration file is converted to a file with the EXP extension. In VirtualPC and Virtual Server, it’s enough just to copy the files of the virtual machine, and in Hyper-V they invented import / export - as they say, for security purposes.
There are two types of snapshots: online and offline. On-line is called snapshot made on a virtual machine with a running guest OS. Accordingly, if the virtual machine was in the “off” state, then the snapshot will be called offline. For the user, there is absolutely no difference between online and offline snapshots. They differ only in the file composition, because when creating a snapshot on a running virtual machine, the Save State operation occurs, and the Save State data is included in the snapshot
Online snapshot:
- Copy configuration file
- Differential AVHD Disk
- Files Save State - BIN + VSV
- Copy configuration file
- Differential AVHD Disk
What can and cannot do with snapshots?
')
As already mentioned, virtual machine snapshots are the same as saving in the game. And their only purpose is to provide a point of return in case of possible errors. Snapshots are not a backup, and they cannot be used for disaster recovery. Using snapshots in a production-based environment is not recommended, because it can lead to a drop in performance, why this is so - it will be clear further from the article. If you need to frequently create backup copies to protect against user errors - you need to use other tools, for example - incremental backups or transaction logs, if we are talking about databases.
In addition, you need to remember that you can and need to manage snapshots only through standard Hyper-V tools (MMC Hyper-V Manager snap-in, WMI providers, PowerShell cmdlets) and third-party software using such tools — for example, Microsoft SystemCenter Virtual Machine Manager.
So, what happens when creating snapshots?
For simplicity, we will present a virtual machine with one hard disk (see figure). We have just installed an operating system on it, and before moving on - we want to snapshot. When you select Create Snapshot, the current configuration of the virtual machine is saved in a separate file (Copy of Configuration 1), and an AVHD file is created (AVHD Differential Disk 1). In this case, changes are made to the virtual machine configuration itself, and from that moment only a read is made from the VHD file, and the entire write is made only to the AVHD file (green arrow). The virtual machine disk already consists of two files: VHD and AVHD. We got the first snapshot, which for convenience can be called “OS Installed” (by default snapshots are given the name from the name of the virtual machine with the addition of the date and time of creation).
Now, let's say that we did something (for example, installed the application) and take another snapshot. Just as before, the configuration is saved in a separate file, a new AVHD is created, and the recording is redirected to it already (yellow arrow). The virtual disk consists already of three files: VHD and two AVHD. For simplicity, the resulting snapshot can be called “Apps Installed”.
Suppose we created one or more snapshots. What can you do with them now? The choice here, in principle, is not too rich: snapshots can either be applied (Apply) or deleted (Delete). In fact, this means:
- Apply - return to the point where the snapshot was created, while all changes that have occurred since the snapshot was created and so far will be lost.
- Delete - the return point will be deleted, and all changes made will be saved forever.
This must be clearly understood for yourself, so that later you do not “break the fire of wood”. As one expert said, “Delete means, Apply means Delete,” and it would be even better to say in Mayakovsky’s style: “We say Delete” - we mean “Apply”, we say “Apply” - we mean “Delete”.
Let's see how this happens.
We want to roll back to the time of the installation of applications. To do this, select Snapshot "Apps Installed" ("Snapshot 2") and make "Apply". As soon as we do this, the current configuration of the virtual machine is replaced by a copy of the snapshot (i.e., the Configuration will be overwritten from the Copy of Configuration 2). After that, AVHD with the changes made before the “rollback” (“Differential disk AVHD 2”) is deleted, and a new AVHD is created, to which the recording is immediately redirected.
Now, let's say we finished our experiments, and before entering the virtual machine into production, we want to delete all our snapshots. If we remove the Apps Installed snapshot, the following will happen:
- First, the copy of the configuration file is deleted, and the snapshot itself disappears from the list.
- If the virtual machine is currently running, AVHD, the associated snapshot remains, and writing to it continues.
- As soon as the virtual machine stops (shutdown or reboot) - all data from AVHD is recorded in the previous AVHD, or in the VHD, if we delete the first snapshot, and the AVHD itself is deleted. This operation is called "Merging". The merging operation may take some time (depending on the amount of data), during which it is impossible to start the virtual machine.
When you roll back to the OS Installed snapshot, the AVHD currently in effect (as part of the Apps Installed snapshot) is removed, a new configuration copy and a new AVHD (AVHD Differential Disk 3) are created, which in our case refers to VHD itself. Further, if we, for example, create another snapshot (for simplicity, call it “New Snapshot”), then the new AVHD will be created on the basis of the “Differential disk AVHD 3”). There may be more such branches - for example, from the OS Installed snapshot there can be three or more branches. Delete / Apply operations on branching occur in the same way as described, but with some nuances. For example, if we now want to remove the OS Installed snapshot, it will disappear from the list and a copy of the configuration will be deleted, but merging will not occur after the virtual machine is stopped. Why? And everything is very simple: since not one but only two AVHDs are formed from our VHD - you cannot overwrite the VHD itself: if AVHD1 is used for rewriting, then AVHD3, and accordingly - all that is based on it possible rollback will not work for them.
Here is another "exception to the rule": let's say we remove the Apps Installed snapshot. As we can see, he does not have his AVHD. Therefore, the previous AVHD1 will be deleted.
If we want to return to the Apps Installed snapshot, a new AVHD will be created based on AVHD1 (well, that is, a new AVHD2, roughly speaking), and the currently active AVHD4 will be deleted.
Well, now I will say a few words in conclusion.
First of all, as I said before, you need to remember about “Delete means, Apply, means Delete”, and think before pressing the button, so as not to lose anything.
Secondly, if the virtual machine contains online snapshots, it is extremely not recommended to export and transfer it to another server. The fact is that the online snapshot contains the state of the processor registers and the contents of the memory, and using such a snapshot in another hardware environment can lead to the crash of the guest OS.
Thirdly, as already mentioned, snapshots are not recommended for use in a production environment. Surely, you know that for production it is recommended to use virtual disks of a fixed size - in order to get rid of the fragmentation of the VHD file. Creating snapshots, we artificially divide our virtual disk into separate files - VHD and AVHD set. On high-load systems, this can lead to some performance degradation. In addition, when you remove snapshots, a merge operation takes place, which can also affect the overall system performance, and, moreover, can increase the idle time when the virtual machine reboots. For example, if you deleted one or several snapshots on a virtual machine, and then you had to restart it (for example, when installing updates), the OS will not start loading until the merge operation is completed completely. Therefore, snapshots can be used before putting into production, to save time during software installation and initial setup. After that, all snapshots need to be removed, wait until the end of the merge, and only then enter into production.
Another small point: in the Hyper-V settings, you can set a separate path for placing virtual machine files and a path for placing VHD. By default, both are stored on the C: drive. If you plan to use a high-speed RAID array for VHD storage, for example, you need to store not only VHDs on it, but also virtual machine files. The fact is that when creating snapshots, AVHD files will be stored in the exact location that was chosen to store virtual machines. And it may happen that the VHD itself will be stored on a separate disk array, and the AVHD heap will be on the C: drive, which is not good.
On this I will finish this post, and without that already big. I apologize for some confusion, the topic with seeming simplicity is a bit non-trivial to explain. For a better understanding, I advise you to watch a screencast, with an animated presentation and demonstration: www.techdays.ru/videos/1490.html
If haboobschestvennost will not mind - I can give links to my other screencasts and articles about Hyper-V, so as not to cross-post and not copy-paste. I hope someone interested my article, in any case - thanks in advance.
Source: https://habr.com/ru/post/91190/
All Articles