Disabling the BIN save state file on Hyper-V

This is a follow-up to my post: http://itproctology.blogspot.com/2013/07/the-forgotten-bin-element-in-hyper-v.html

Over time I have seen lots of posts from folks wanting to turn this off.

Well, that became possible with Hyper-V 2012. And actually is totally hidden, you might not know you are turning it off.

First, on the previous post I mentioned why the BIN (as I refer to them as the save state file) exist in the first place.

So, what if you turn them off?

Well, you turn them off and you lose the protection they offer. The safety net if you like. Think about that, consider the risk.  I did my job and warned you.

Before we jump in and disable it let's look at the settings option related to it first.

Per this post by Ben Armstrong this is rather simple; http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/03/26/option-to-remove-bin-files-with-hyper-v-in-windows-8.aspx

Set-VM -AutomaticStopAction Save

This is the default and what you get without thinking. The safety net is on.

Set-VM -AutomaticStopAction ShutDown

This will cause Hyper-V to attempt clean shut down of the VM or click it off if it can't

Set-VM -AutomaticStopAction TurnOff

This will just click off your VMs, and give you that wonderful "why did I not shutdown cleanly" dialog later on.

According to Ben’s post; if you set either ShutDown or TurnOff, Hyper-V no longer creates the BIN file as a placeholder.

Now, if you take a snapshot of a running VM, you get one as a part of the snapshot (it is the actual saved memory state, not a placeholder). But it won't be there from the moment you turn on your VM.

In case you didn’t know how to use Set-VM: Get-VM –Name “Foo” | Set-VM –AutomaticStopAction ShutDown

 

Now, what if you want something a bit more useful, or you have bunches of VMs?

If you are using SCVMM:

Import-Module virtualmachinemanager

$prefix = Read-Host "Enter prefix to search on"

$vms = get-scvirtualmachine | where {$_.name -match $Prefix}

foreach ($vm in $vms) {
    # check if its status is clean in VMM, and clear it if not
    if ($vm.Status -eq "UpdateFailed") {Repair-SCVirtualMachine -VM $vm -Dismiss}
    if ($vm.VirtualMachineState -eq "Running") {Stop-SCVirtualMachine -VM $vm -Shutdown}

    # wait for the darn thing to cleanly shut down
    Do {Start-Sleep 30} until ($vm.VirtualMachineState -eq "PowerOff")
    if ($vm.StopAction -ne "ShutdownGuestOS"){Set-SCVirtualMachine -VM $vm -StopAction ShutdownGuestOS}

    if ($vm.StartAction -ne "TurnOnVMIfRunningWhenVSStopped"){Set-SCVirtualMachine -VM $vm -StartAction TurnOnVMIfRunningWhenVSStopped}

}

With the Hyper-V cmdlets the script would be changed very little.

If you are using Hyper-V cmdlets:

$prefix = Read-Host "Enter prefix to search on"

$vms = get-vm | where {$_.name -match $Prefix}

foreach ($vm in $vms) {
    if ($vm.State -eq "Running") {Stop-VM -VM $vm}

    # wait for the darn thing to cleanly shut down
    Do {Start-Sleep 30} until ($vm.State -eq "Off")
    if ($vm.AutomaticStopAction -ne "ShutDown"){vm | set-vm -AutomaticStopAction ShutDown}

    if ($vm.AutomaticStartAction -ne "StartIfRunning"){$vm | set-vm -AutomaticStartAction StartIfRunning}

}

Discovering and initializing a data volume at VM provision

A few posts back I wrote about using PowerShell to find the DVD drive that a particular installer was attached to and then running that command line installer.

To take that a bit further I have a VM that I am deploying, and that VM has an empty VHDX attached to it.

This VHDX is on the second IDE controller (it needs to be available early in the boot process of the OS).  When I provision this VM the first time, I want to find, online, initialize, and format that virtual disk.

$disk = Get-Disk | where {($_.BusType -eq "ATA") -and ($_.IsBoot -eq $false)}

(You could also find the disk if it was on the SCSI controller)

$disk = Get-Disk | where {$_.BusType -eq "SCSI"}

And now for mounting, and formatting the disk.

Set-Disk -InputObject $disk -IsOffline $false

Set-Disk -InputObject $disk -IsReadOnly $false

Initialize-Disk -InputObject $disk -ErrorAction SilentlyContinue -WarningAction SilentlyContinue

$partition = New-Partition -InputObject $disk -UseMaximumSize –AssignDriveLetter

$partition | Format-Volume -FileSystem NTFS -NewFileSystemLabel "Cache" -Force:$true -Confirm:$false

And now you simply continue along with your scripting.

The reason that I capture the new partition to $partition is that there are lots of useful stuff in there for configuring things moving on.  Little things like: $partition.DriveLetter are highly useful.

FreeNAS as a storage target for simple testing

Working with various hypervisors I frequently have a need for various types of storage volumes.

We can always use local storage for testing, but how do you handle a cluster of Hyper-V Server or a Pool of XenServer hosts?

I have used a variety of services.  Right now in the lab I am running Windows Storage Server 2008 to present NFS volumes and StarWind to present iSCSI volumes (I found StarWind iSCSI far easier to get working with XenServer than the iSCSI target add-on to Storage Server).

Mind you, I don’t need any of the enterprise bells and whistles that Storage Server gives me, I simply need storage.

Just the other day someone pointed me to FreeNAS.  Hey, a storage system that can present many different types of volumes.  FreeNAS is built upon FreeBSD and is bundled as a LiveCD ISO that can be installed to a hard disk, USB, or run as a LiveCD.

FreeNAS can do NFS, SMB, iSCSI, iTunes, FTP, TFTP, SSH, UPnP, BitTorrent, and other sharing protocols – from that standpoint it is pretty slick.

I must say that other than dealing with having to learn the UI – I have been pleasantly surprised at how well it is working.

Mind you, I am running FreeNAS in a VM.  That VM is hosted by Hyper-V.  And I have a XenServer that is accessing the LUNs being presented by the NAS device.

At the moment I have an iSCSI LUN and an NFS volume presented.  the big limitation that I currently have is that I can only have 4 IDE devices on my Hyper-V VM that limits me to one virtual disk for install, and three for serving as storage LUNs.

My VM simply runs with 512 Mb of RAM and a Legacy NIC.  The rest involved about an hour of figuring out how to install and configure the LUNs. 

Very little overhead and the storage actually ran pretty well when deploying a XenServer VM to the NFS share.  I really can’t argue.

When it is time to upgrade my current lab test storage server I think I will have to boot into the LiveCD and see if FreeNAS can identify the really old adaptec SCSI card and Compaq storage array.  If it can, it will win moving forward as Server 2008 R2 no longer has drivers for my really old Adaptec SCSI card – making the antique array useless. 

But that array is not useless, I just wouldn’t trust it for anything important.

The next step might be trying to build it into a paravirtualized VM for use on XenServer.  Since it sees the XenServer virtual devices as QEMU devices, I know that the kernel is Xen aware…

Virtual Machine storage considerations

Storage.

Storage is your issue.

Storage is all about design and deployment.

Passthrough disks were first used for SQL servers, file servers, and Exchange servers.  Workloads that all require large storage volumes with high Disk IO.

Using passthrough dedicates a physical storage resource to a VM.  Before that you carve up the physical resource.

The negative is that you lose flexability in HA, failover, etc.  Not that it cannot be done with proper planning, but it isn't just plug, click and go.  It does take planning, equipment, and design.
I know that lots of folks are producing incredibly large VHDs and using them as storage for VMs.  What does this give you?  A VHD to restore, and backup at the host level.

Otherwise all backup that you do is at the machine level with a traditional backup agent within the VM to back up the volume.
In my mind, it is all about how you design it and want to recover it.

After working through a Disaster Recovery exercise for a particular application, I frequently found myself re-architecting the deployment so I could not only get good running performance, but a fast and easy to execute recovery of the system.

Our most limiting factor was frequently the time to recover the system from the backups (disk or tape).

Again, it is all about design.

The most humbling DR exercise to do is to recover the backup system itself.  A DR exercise that is frequently over-looked. But that is a different story.

As far as tweaking - no, don't tweak storage, design smart.
Split the spindles, spread the load.  Is putting two disk intensive servers on the same RAID 5 array better or worse?  Could that big array be split in two so one VM does not limit the other?

This is the big thing with storage and VMs.

One consideration is volume (gigabytes / terabytes).
The second consideration is performance.  Unlike RAM and Processor - the hardware IO bus is not carved into virtual channels.  It frequently becomes THE limiting resource.  Especially when you have multiple disk intensive VMs fighting  for that same primary resource.  In this case it is not a pool, it is a host resource.  It is finite.  It takes planning. 

VM A will limit VM B (and vice versa) when they fight for the same read / write heads on the same disk array.

This is where you must think about the VMs that you place, where you put their OS VHD, where you put their data.  How you do that storage, how you present storage, etc.

This is where the SAN argument really wins.  As the throughput, carving of storage, sheer number of spindles and heads, really shines.

If you are resource limited and can't afford the SAN, then think about the workloads that you are placing and how you divide the physical resources.  Give each disk intensive VM enough to do its job, but isolate them from each other.

Another strategy is multiple hosts.  Each host has one disk intensive VM.  All other VMs are low disk.  This way they have less IO effect upon each other.

Be creative.

Should I put all my VHDs on one volume?

I recently responded to someone who was considering placing all of their VHDs onto one huge storage volume.

This might be easy for storage management and for backup management. But you have to consider the ancillary impacts that this might have on the overall environment.
The greatest impact will be the impact that each VM has upon another VM.

This is where we need to h ave a full understanding of all of the components involved in our virtualization infrastructure and how all of those components interact and affect each other.

Here is the statement that began the idea for putting this to blog:

"We were hoping to create a "big" LUN, store all our Hyper-V Guests on that LUN, assign the LUN to several HOSTS, and access the Guests that way."

Now, the response:

That is all fine, good, and noble - but you may want to reconsider.

Even VMware has had the recommendation (for a great number of years now) of no more than 10 VMs per LUN (they consider this a 'rule of thumb' that is taught in class).

Why? Disk IO.

You have to balance the disk IO demands of the VMs stored on the LUNs.

If you have VMs with a bunch of disk IO all happening at the same time they end up impacting each other.

For example - you always split out your SQL databases from the temp log, from the OS - for the same reason.

In this case you have different considerations - VM1 will impact VM2.

An easy test you can do at home:

With many VMs on a single LUN, boot one and wait for Integration Services to report some data from within the VM (Integration Services loads late in the stack so it is a good measure that the VM is nearly done booting).

Be sure to time it.

Now, repeat the test, this time with 4 VMs all at once.

Don't stop timing until all four are up, then get your average time to boot.

All that disk reading and page file building created massive disk IO.

Just something to think about as you plan your infrastructure.