Hyper-V VMs behavior on shutdown

For a new Hyper-V VM, the default automatic stop action is to the Save the virtual machine state, which saves the contents of memory (and device state) to a file. This can be quite time and storage consuming.

Typically, it’s actually faster to select the Shut down the guest operating system option that’s available as part of the VM properties. It performs a clean shutdown of the guest OS.

The only reason the default is the “save the state” is that saving the state doesn’t  require the Hyper-V Integration Services running in the guest OS, while performing a shutdown needs the Integration Services to instruct the guest OS to shutdown.

If you have the Integration Services installed in the guest OS,  then I recommend changing the default automatic stop action to shutdown instead of save.

To do so, this one liner will help changing this behavior:

get-vm | set-vm -AutomaticStopAction ShutDown

And if you wanted to gather settings prior doing so use you can use the following:

get-vm | fl name,AutomaticStopAction,state

Actually I’ve had inconsistent result applying the automatic stop action, about 70% of the time, hyper-v allowed to change it while the VM was started, but sometimes not. I haven’t had time to dig further…

All together, if you do not have the above set up, you will need to properly shutdown all VMs first prior to shutting down the host. You can do so with this script I remember stealing from somewhere – please ask for credits/ was it from the powershell script guys? I don’t remember – oh well.

Param($vmhost = 'hyper-v_host')
Write-Verbose "getting running VM's on $vmhost"
$runningVM = Get-VM -ComputerName $vmhost| where state -eq 'running'
foreach ($cn in $runningVM)
Write-Verbose "registering shutdown event for $($cn.name)"
Register-WmiEvent -Class win32_ComputerShutdownEvent -ComputerName $cn.name `
-SourceIdentifier $cn.name.tostring()
Write-Verbose "Shutting down $($cn.name)"
Stop-Computer -ComputerName $cn.name -Force
Write-Verbose "Waiting for shutdown to complete"
Wait-Event -SourceIdentifier $cn.Name.ToString()
Get-Event -SourceIdentifier $cn.name.Tostring() | Remove-Event}
Write-Verbose "Shuting down $vmhost"
Stop-Computer -ComputerName $vmhost -Force

And because I was curious, the automaticstartaction for not starting the VM automatically is Nothing – not Off as I first though.

get-vm | set-vm -AutomaticStartAction Nothing

The DMZ server that did not want to update

Once upon a time there was a server placed in a DMZ that would not want to update…

symptoms: using sconfig, the server would say that no updates were available.

problems: wsus settings had been deployed

solution: remove wsus settings

It sounds easy said like this but somehow this client manages to present things a different way leading to wasting my time.

As I said, it all started with company X administrator saying they could not update this windows 2012 R2 core server while it worked yesterday. Indeed, once in sconfig, the server is in a workgroup, automatic updates is disabled and running get and install updates would results in no updates to apply.

Steering in this direction, I run

wuauctl /detectnow

I verify the wua version using

$WindowsUpdateAgentVer = (Get-ItemProperty -Path 'C:\Windows\System32\wuaueng.dll' -ErrorAction SilentlyContinue).VersionInfo.ProductVersion

> Write-Host $WindowsUpdateAgentVer


it looks like a bit out of date as I see a lot of 7.9.9600.256 on the web. I try updating it without success. This URL brings me to some other kb and download which did not work, I guess I am giving up this path and not try to install kb2919355 which is all above WUA update. None of the downloads from this URL do anything for me.

But wait, why did not I check the windowsupdate log? A stroll to c:\windows\windowsupdate.log showed me that it fails getting update lists from some wsus server!

WARNING: There was an error communicating with the endpoint at ‘http://wsus.xxx.ca/SimpleAuthWebService/SimpleAuth.asmx

Bummer, what did not I start here? I hop on the web to look for the reg key and delete it.

Stop-Service wuauserv
Remove-Item -Path 'HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\*' -recurse -force
Start-Service wuauserv

Once removed, I start an update again using sconfig – bingo – updates show up. I then finish it with my favorite WUA script and invoke-windowsupdate to keep things rolling.

It guess it would be so much better for sconfig to actually say there was an error instead of saying that there are no updates available for this server…

Installing .Net3.5 on Windows 2012 R2

I had encountered this in the past, because .net 3.5 became an on-demand addon it would not come installed on a fresh windows 2012 install.

To fix this, one add to play with the following commands to get the feature available on the system and install it.

Dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:c:\dotnet35 /LimitAccess

Somehow, I could not get this to work and even if the source was here with .net 3.5 files, it just would not install saying dotnet35 could not be found.

I eventually found a magic key to actually let the server connect to msupdate instead of trying to get it from a source.

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing] “RepairContentServerSource”=DWORD(2)

By enabling this, I was able to install dotnet35. Apparently there is a GPO for this, but all of the policy templates I found did not include “Specify settings for optional component installation and component repair”.

SQL execution took too long on vCenter – SQL execution took too long: INSERT INTO VPX_EVENT_ARG WITH (ROWLOCK)

One day I woke with several warning alerts from foglight saying it got disconnected from a vCenter and reconnected almost right away but then flipping on and off all the time making foglight a bit spammy.

Looking at my vServer logs, I found out a repetitive peculiar message about queries taking too long while looking around the DB is undersized, and DB processes being responsive.

A few KB searches after, I read up that dbo.VPX_EVENT and dbo.VPX_EVENT_ARG tables are too large and must be truncated. (KB 2020507)

As per KB…

  1. Take a back-up of your current database. Do not skip this step.
  2. Use SQL Management Studio to connect to the vCenter Server database.
  3. Select New Query.
  4. Enter these queries in the new window and click Execute:

    Note: Execute each query separately and wait for the query to complete prior to running subsequent queries. Depending on the size of the tables, the process may take up to 15 minutes.

    • EXEC sp_msforeachtable “ALTER TABLE ? NOCHECK CONSTRAINT all”
    • USE name_of_the_vcdb
      TRUNCATE TABLE vpx_event_arg;
      DELETE FROM vpx_event;
    • Exec sp_msforeachtable @command1=”print ‘?'”, @command2=”ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all”

Then all went back to normal after a restart of all services involved eventhough the KB title did not seem very related to my case.