Blog Marcina Bojko

As we may know – Microsoft introduced new way of doing snapshots/checkpoints in Hyper-V 2016. However term „production” is misleading, implying Standard checkpoints are not production ready – which is simply not true.
The biggest difference is that Production checkpoints are mostly used with VSS-aware applications (like MS SQL/Exchange, MS Windows itself) allowing them to flush/sync/commit changes to filesystem.

As a major difference – production checkpoints don’t save memory or cpu state, starting always with machine powered off after restore.

You can choose which way you want to do your snapshots here:

👁 Selection_999(411)

Windows-based virtual machines have supported this since previous versions of integration services (2012 R2, 8/8.1) and from the start in case of Windows 2016/10. What about Linux-based, Centos 6/7 machines?

When installed out of the box, without any additional packages, trying to do a production snapshot of Centos 7 (with all updates) we got something like this:

👁 Selection_999(410)

Quick how-to.

1. If youre using external LIS (Linux Integration Services) from Microsoft, as an external package – remove it. It’s a piece of crap,  breaking kernels from time to time, packed with ‚latest’ errors and workaround rejected by linux kernel maintainers. It’s really not worth risk to have it installed: 

   yum remove microsoft-hyper-v kmod-microsoft-hyper-v

   or

   yum remove $(yum list installed|grep microsoft)

2. Check if your Hyper-V offers all Integration Services for this VM.👁 Selection_999(412)
   
3. Check  and install hyperv-daemons

    yum info hyperv-daemons

   Available Packages
   Name : hyperv-daemons
   Arch : x86_64
   Version : 0
   Release : 0.29.20160216git.el7
   Size : 4.5 k
   Repo : base/7/x86_64
   Summary : HyperV daemons suite
   URL : http://www.kernel.org
   Licence : GPLv2
   Description : Suite of daemons that are needed when Linux guest : is running on Windows Host with HyperV

   yum install hyperv-daemons -y

4. Enable and start services

   systemctl enable hypervfcopyd
   systemctl enable hypervkvpd
   systemctl enable hypervvssd
   
   systemctl start hypervkvpd 
   systemctl start hypervvssd 
   systemctl start hypervfcopyd

5. Check status

   [root@centos7 ~]# systemctl status hypervkvpd
   ● hypervkvpd.service - Hyper-V KVP daemon
    Loaded: loaded (/usr/lib/systemd/system/hypervkvpd.service; static; vendor preset: enabled)
    Active: active (running) since Wed 2017-07-26 02:37:30 CDT; 14s ago
    Main PID: 3478 (hypervkvpd)
    CGroup: /system.slice/hypervkvpd.service
    └─3478 /usr/sbin/hypervkvpd -n
   
   Jul 26 02:37:30 centos7 systemd[1]: Started Hyper-V KVP daemon.
   Jul 26 02:37:30 centos7 systemd[1]: Starting Hyper-V KVP daemon...
   Jul 26 02:37:30 centos7 KVP[3478]: KVP starting; pid is:3478
   Jul 26 02:37:30 centos7 KVP[3478]: KVP LIC Version: 3.1
   [root@centos7 ~]# systemctl status hypervvssd
   ● hypervvssd.service - Hyper-V VSS daemon
    Loaded: loaded (/usr/lib/systemd/system/hypervvssd.service; static; vendor preset: enabled)
    Active: active (running) since Wed 2017-07-26 02:37:30 CDT; 27s ago
    Main PID: 3485 (hypervvssd)
    CGroup: /system.slice/hypervvssd.service
    └─3485 /usr/sbin/hypervvssd -n
   
   Jul 26 02:37:30 centos7 systemd[1]: Started Hyper-V VSS daemon.
   Jul 26 02:37:30 centos7 systemd[1]: Starting Hyper-V VSS daemon...
   Jul 26 02:37:30 centos7 hypervvssd[3485]: Hyper-V VSS: VSS starting; pid is:3485
   Jul 26 02:37:30 centos7 hypervvssd[3485]: Hyper-V VSS: VSS: kernel module version: 129
   [root@centos7 ~]# systemctl status hypervfcopyd
   ● hypervfcopyd.service - Hyper-V FCOPY daemon
    Loaded: loaded (/usr/lib/systemd/system/hypervfcopyd.service; static; vendor preset: disabled)
    Active: active (running) since Wed 2017-07-26 02:37:30 CDT; 44s ago
    Main PID: 3492 (hypervfcopyd)
    CGroup: /system.slice/hypervfcopyd.service
    └─3492 /usr/sbin/hypervfcopyd -n
   
   Jul 26 02:37:30 centos7 systemd[1]: Started Hyper-V FCOPY daemon.
   Jul 26 02:37:30 centos7 systemd[1]: Starting Hyper-V FCOPY daemon...
   Jul 26 02:37:30 centos7 HV_FCOPY[3492]: starting; pid is:3492
   Jul 26 02:37:30 centos7 HV_FCOPY[3492]: kernel module version: 1

   As a result:
   👁 Selection_999(413)
   
   and in /var/log/messages

   Jul 26 02:43:27 centos7 journal: Hyper-V VSS: VSS: op=FREEZE: succeeded
   
   Jul 26 02:39:25 centos7 systemd: Time has been changed
   
   Jul 26 02:39:25 centos7 journal: Hyper-V VSS: VSS: op=THAW: succeeded

There was a lot of nice summary articles about latest „ransomware” attack caused by Petya. Soon, researchers started to claim almost permanent vaccine for this type of worm.

https://www.bleepingcomputer.com/news/security/vaccine-not-killswitch-found-for-petya-notpetya-ransomware-outbreak/

Even patched OS won’t save you from infection as one infected machine quickly spreads the infection using other protocols like WinRM.

So, how should one on its vast server farm vaccinate hundrets of machines?

For example, like this 🙂

win_manage:
 dsc_file: 
 petya_vaccine1:
 dsc_destinationpath: C:\Windows\perfc
 dsc_type: file
 dsc_attributes: readonly
 dsc_contents: ""
 petya_vaccine2:
 dsc_destinationpath: C:\Windows\perfc.dat
 dsc_type: file
 dsc_attributes: readonly
 dsc_contents: ""
 petya_vaccine3:
 dsc_destinationpath: C:\Windows\perfc.dll
 dsc_type: file
 dsc_attributes: readonly
 dsc_contents: ""