Summary:
How to delete Hyper-V checkpoints that cannot be deleted.
Problem:
Checkpoint cannot be removed from the Hyper-V Manager.
Symptoms:
- Hyper-V Manager shows a checkpoint. No option to remove checkpoint.
- VM disk directory has VHDX and AVHD files:
Solution:
1. Use PowerShell to view existing snapshot:
PS C:\Users Get-VMSnapshot -VMName tfs.stevenjordan.net
VMName Name SnapshotType CreationTime
------ ---- ------------ ------------
tfs tfs (2/13/2018 - 2:52:36 PM) Standard
2. Remove VM-Snapshot.
PS C:\User Get-VMSnapshot -VMName tfs | Remove-VMSnapshot
3. Confirm Snapshot has been removed.
PS C:\Users Get-VMSnapshot -VMName tfs
PS C:\Users
That's It!
| |
Repair Windows installation licensing errors. |
Problem:
Windows 2012R2 license error reads, "Windows cannot find the Microsoft Software License Terms. Make sure the installation sources are valid and restart the installation".
Background:
This error occurs after selecting the "operating system you want to install" in the Windows Setup wizard. This error occurs on VMWare, VirtualBox, or Hyper-V virtual machines (VMs).
Solution:
This licencing terms error occurs if there is not enough memory allocated to the virtual machine. Increase the VM's start-up memory in the VM settings to resolve.
Problem:
Import VMWare virtual machine (VM) into Hyper-V hypervisor. Convert VMDK virtual disk into VHDX disk.
Solution:
Use Microsoft Virtual Machine Converter (MVMC) 3.1 to import and convert the VMWare ESXi VM into Hyper-V.
Background:
The MVMC GUI provides a simple import wizard. Please note, the GUI only imports VMWare hypervisors (including ESXi) connected to VMSphere. MVMC PowerShell commands can convert stand-alone ESX and ESXi VMs.
Convert:
- Download MVMC. The Microsoft download sites lists MVMC as 3.0. N.B., the file installs version 3.1.
- Install MVMC on Hyper-V host.
- Uninstall VMTools from VMDK VM.
- Copy VMDK to Hyper-V host.
- Open PowerShell. Import MVMC PowerShell library.
Import-Module "C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1"
- Use PowerShell to convert VMDK to VHD. N.B., Do not use VMDK_Flat file!
PS D:\TMP> ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath "D:\VMS\DEV.vmdk" -DestinationLiteralPath "S:\VMS" -VhdType DynamicHardDisk
- Create new VM in Hyper-V. Add newly created (i.e., system) disk to IDE adapter. Additional disks can use the SCSI adapter. This is the time to configure dynamic memory or add additional CPUs.
N.B., Do not resize the disk until after the VM starts at least once in Hyper-V!
- Start-up VM. Install Hyper-V tools. Restart.
- Optional: New NIC "hardware" causes problems with retaining preexisting static IPs. Resolve problem by deleting the network adapter and restating. Windows creates a new network adapter upon start-up. Manually add IP addresses into new adapter.
That's It!
Problem:
Windows Server Backup fails on Windows 2012 R2 Hyper-v server. System fails to create shadow copy.
Specific Windows Server Backup Errors:
-Backup not started.
-The backup operation of the volume did not start.
-Location is Invalid
Event Log Errors:
-The backup operation attempted at xxxx has failed to start, error code '0x8078000C' ('The specified backup storage location is invalid.').
-The backup operation that started at xxxx has failed because the Volume Shadow Copy Service operation to create a shadow copy of the volumes being backed up failed with following error code '0x80780119'.
Background:
The EFI-based server uses a GUID partition table (GPT) file system. A GPT drive includes the following partitions:
- EFI System Partition:
-The server boots to the EFI partition.
-The EFI partition cannot store user data.
-The typical size for a 512-byte sector drive is 100MB.
- Microsoft Reserved Partition (MSR):
-Windows uses the MSR (i.e., recovery partition) partition to store security and recovery tools (e.g., Windows Recovery (RE).
-The MSR cannot store user data.
-The typical size for a the MSR partition is 300MB.
Solution: System partitions must have enough free space to create shadow copies of the partition -including both the EFI and MSR volumes:
- Partitions smaller than 500 MB require at least 50 MB of free space.
- Partitions larger than 500 MB require at least 320 MB of free space.
- Partitions larger than 1 GB require at least 1 GB of free space.
Therefore, Windows backups fail when there is not enough free space on either the EFI or MSR volumes.
Recovery Steps:
- Free-up space by shrinking one of the primary partitions.
- Use unallocated disk space to create a new volume for VSS snapshots. For example:
Volume Name: VSS Backup
Format: NTFS
Size: 512MB
Drive Letter: None
- Identify volume GUIDs:
d:\vssadmin.exe list volumes
- Add additional VSS storage to the MSR. For example:
vssadmin.exe add shadowstorage /for=\\?\Volume{247c09ad-xxx-xxx-xxx-xxxxxxxx}\ /On=\\?\Volume{815230ad-xxx-xxx-xxx-xxxxxxx}\ /MaxSize=Unbounded
Note: VSSAdmin may need run from non-system volume (e.g., D:\).
- Use Diskshadow for related VSS errors (optional):
d:\Diskshadow
DISKSHADOW>delete shadows all
It's also worth mentioning that most vssadmin functions can be completed with the Windows GUI:
|
C: → Properties → Shadow Copies → Advanced |
That's it!
References:
https://technet.microsoft.com/en-us/library/dd799232%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
http://answers.microsoft.com/en-us/windows/forum/windows_8-performance/backup-error-0x80780119/78adc0e0-c793-4b6c-95db-af625f3c9fe7
I was unable to collect flow data with Foglight on the Hyper-V guest I was
working with. I thought I had everything
set up right but I was missing data.
I enabled port mirroring on the switch port that connected to the router
(source) and copied the data to an extra NIC (destination) on my Hyper-V
server.
I installed the Quest/ Foglight agent (PTflow) and added the NIC with the
mirrored data to a guest. After I enabled the PTflow traffic monitoring on the
new NIC I was able to get some traffic flow data; but a lot was either missing,
or showed up only as TCP 5053, or TCP 5054 traffic.
I was unable to find a straight answer on the Internet however I did find
some people were experiencing similar problems with Wire Shark.
The problem was specific to Hyper-V guests. The virtual NICs are unable to
run in promiscuous mode which is necessary to view all traffic data. I began to monitor the PTFlow from the host,
rather than the guest, and a wealth of information began to populate.
My previous post about time drift addressed the inherent problem with VMs and time drift. I previously explained how to set the Linux server to use NTP. After I configured the guest to use the NTP servers, I found the server's clock was still accelerating up to 4 minutes of virtual time, for every minute in real time. I found a good article on VM's site that was able to fit it:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
Specifically:
1. Locate the correct Kernel parameters. There are different configuration settings that must be used depending on which version of Linux you may be using. Compare it with the chart on the above URL. There are separate settings for 32-bit and 64-bit environments.
2. Edit the Kernel configuration. On my system, I was able to do so with:
vi /boot/grub/menu.lst
Others may use LILO so chose the correct file for your system. I added the following at the end of the "append" line:
clock=notsc divider=10 nohpet
Other versions may use different parameters.
3. I had to make further changes to the server's NTP settings. I was able to edit the NTP config file with:
vi /etc/ntp.conf
I made the following changes:
A. Put "
tinker panic 0" at the top of the config file. This command instructs the server to continue to use NTP if there is a large time drift. This is also handy if the VM was suspended or copied from another system.
B. Comment out the following:
#server 127.127.1.0
#fudge 127.127.1.0 stratum 10
If a large time drift occurs the system has a tendency use the local clock as the time source. Commenting out the above prevents this.
There were additional recommendations with the above VMWare article, but the 3 changes I listed were enough to fix my problem.
My CentOS guest's time was constantly running ahead of the host server's actual time.
Time drift issues are common when working with virtualization. I found a good article about Hyper-V time synchronization issues at Ben Armstrong's Blog at
http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx.
I was able to resolve the issue by installing the NTP service:
yum install ntp
The default NTP servers were OK but they can be changed with:
vi /etc/ntp.conf
The following commands then started the service, synced the guest, and set the NTP service to start automatically.
service ntpd start
netpd -q
hwclock --systohc
chkconfig ntpd on