A tree indicates the VM was restored, reverted to a previous checkpoint. Future checkpoints start a new node with a new delta. Look at the time stamps in that screenshot.
Trees of checkpoints are not a long term solution. The accumulated deltas consume storage space and performance. To store a point in time for more than a couple days, use a backup system.
Considering it's a Standard version of Windows Server, you won't be able to deploy more than 2 VMs on it, according to Microsoft's version comparison:
So your first option wouldn't be quite viable to go with.
Do I need to leave one core "free" so that the host stays stable/accessible?
No. See, the "host" is a VM. And that particular master VM has a higher priority than any other VM's.
If so, can I leave a partial core free instead of a whole core?
Given that assigned core counts are all INTEGER, how would you even ENTER a non integer number?
Microsoft recommends joining the Hyper-V host to a domain. You certainly can join it to the domain of the guest DC.
Hyper-V itself does not need the DC for any Hyper-V related functions. Hyper-V will happily run and start any and all VM's without having access to the DC, so there is no chicken or egg scenario.
The domain join process is completed before ...
One of the methods of gathering information about VMs is "Measure-VM" PowerShell cmdlet. It will require "Enable-VMResourceMetering" in the VM.
The example of using it:
Get-VM | Enable-VMResourceMetering
Also, you can take a look at Veeam One Community edition (https://www.veeam.com/virtual-server-management-one-free.html) which is one of the ...
My solution for this was to completely remove all replication and start again from scratch. To do so I simply removed replication on both sides, deleted all replicas on replica server and then initiated the replication on the main server again.
This was definitely not a connectivity issue, so I really do not know why I was getting the 'timeout' error.
I cannot answer why, but during an outage I used the opportunity to move the VM back over again and when the system came back up again, it all worked on the new host.
I can only assume that there was a conflict (somewhere) that I cannot explain nor understand, that was causing this problem and needed a little more time to 'settle down' than I was giving it.
You can’t share block device with non-clustered file system like NTFS, ReFS, Ext3/4 or ZFS on top... There’s nobody to arbiter concurrent writes, metadata updates etc. Good story here:
So either you switch to clustered file system or use network redirector like f.e. SMB3 or NFS.
While still running in GCE, confirm the ssh key you want is in ~/.ssh/authorized_keys. When python Linux guest environment for GCE is installed, this probably already exists if you ever logged in with gcloud. (I don't think the users are removed when the metadata service isn't there. But if so, create different named users.)
Give the guest known names and ...
The network configuration of your VM is relevant here. Please share it?
Though I'm more familiar with Linux than Windows, if you are using a simple bridge network, I could imagine this happening either due to resource exhaustion caused by one or more other nodes (two VMs and a host sharing an IP, and between them they use up all the ephems), or simply ...
PS C:> Move-VM "VMNAME" "DestinationServerName" -IncludeStorage -DestinationStoragePath D:\"VMNAME"
Alternatively, you can do it with Windows 10 Pro machine and Hyper-V manager on it, connect the hosts and Move the VM.
The following requirements must be met to implement nested virtualization in Hyper-V:
The host operating system must be Windows Server 2016 or Windows 10 (Anniversary update or later). Older Windows versions don’t support nested virtualization.
The Hyper-V VM must be of version 8 or higher.
The physical server must have a compatible CPU that supports the ...
Essentially every Hyper-V Virtual Machine has at least one file. It is its configuration file. And it is always stored in XML format.
You could find this file for a VM you exported under Virtual Machines folder.
You could either import it in place or have more options. Look at the docs there
PS C:\> Import-VM -Path 'D:\Test\VirtualMachines\...