ASG V8.201 Hyper-v Drivers

Are you using Hyper-V on windows server 2008 or 2008 R2?  I've done a few installs on Server 2008 R2 using the 8.201 ISO without seeing this message.  With an upgrade from beta, you are only getting the soft-release and not final code.  Also, traditionally, Astaro can't re-detect hardware "on-the-fly" and requires a reinstall if new NICs are added.  I'm not certain how this affects driver changes during upgrades.  If it were me, I'd save off a config-backup and try a reinstall from the 8.102 ISO to see what happens.

Hi Scott,

This is from a fresh install using the latest v8.201 iso available for download.

The host is running Server 2008 R2 with SP1 and is fully patched to the most current level.

Service pack 1 does add quite a lot of features to the hyper-v role and did require the integration services to be updated on each guest, which probably did include an updated nic driver.

Given SP1 was released prior to the 8.2 beta, I would have expected the latest drivers to be used by astaro.

After even more testing, the plot thickens.

Performing a full vss backup of the host including guests causes the ASG guest to crash each time.

The backup runs without a hitch.  Puts the guest into a saved state, performs the backup and then restarts the guest.  However, the ASG is in a hung state when it restarts.

Thinking this may an integration services issue, I first tried disabling the time sync service as this has often caused issues in the past.  It turns out that if this is disabled, then the guest won't even boot and just hangs on startup.  Performing an installation with this disabled causes it to fail as it can't find the nics???

I have tried saving and restarting the guest a number of times, and each time it resumes normal operation without a hitch.  

It would therefore appear to be a hitch with the actual VSS save being performed on the guest.  I am going to try disabling the VSS Backup service next to see if that makes a difference, but I am not confident this will give a clean backup of the ASG guest.

Performing a full VSS backup on VMWare server never caused an issue, so it would appear that the hyper-v driver issue goes a lot deeper than just a message in the event log and in my opinion is clearly not fit for a production environment yet.

Finally, do the astaro support team read these forums?  I am surprised this oversight has not been acknowledge yet given it has been posted here for quite a few days.

Finally, do the astaro support team read these forums

For the most part, this is a user-to-user forum.  The support engineers generally don't hang out here much.  A few of the development team do, but they are split up into working on discrete sections of Astaro and will only respond to posts having to do with their area of expertise.  When they do post, it is mostly something that they do on their own time outside of business hours, as they are too busy answering support calls (for support engineers), writing code (for the devs), or running test scenarios (for QA) to visit the boards during work hours.  Can't fault them for wanting to just go home and relax after work is over.  [:)]

For a time, there was an Astaro employee whose job was, among many other duties, to serve as an official mouthpiece for the forum community to the company.  He went on to another role.  It is my understanding that they are currently actively working on a replacement.

Currently, if you need to report a bug, the only guaranteed way of letting Astaro know is to open up a support ticket if you are a paid business license user.  Then they'll be able to document the issue, gather information, enter it into their system, and get it to the correct people.

is it eventually possible to log on to the astaro as root via SSH and mount the Integration Services CD in order to install the integration services manually again? On Windows OS's its very easy to update outdated integration services... but I have no idea if its possible on a asg...

Another tip: While Installing the SP1 on the server 2008 R2 Host all running machines will be updated with the newest integration services. Perhaps you can try it that way?!? That means. Install a Server 2008 R2. Implement your Astaro virtual machine... and then install SP1... I would give it a go...

is it eventually possible to log on to the astaro as root via SSH and mount the Integration Services CD in order to install the integration services manually again?

Probably not.  Astaro runs on a heavily customized, stripped down, and locked down version of linux.  This is for security purposes, which makes it difficult to impossible to install standard linux software on ASG.

I have logged a ticket (00164333) for these issues.

I had to log it under ACC as I only have a home license for the ASG.

I have tried to install the drivers from the integration CD before, but failed miserably.

When I upgraded my host to SP1, I had to manually update the guest integration services myself in order to get the dynamic memory to work on the windows guests.

Performing a full vss backup of the host including guests causes the ASG guest to crash each time.
 
The backup runs without a hitch. Puts the guest into a saved state, performs the backup and then restarts the guest. However, the ASG is in a hung state when it restarts.
 

Another tip for you. I think you need to shut the server down before backing up the server. I have written a PowerShell Script in order to shut down a virtual machine, backup it up and then it will restarted. 60 seconds later the Script will then take the next server from a manually filled Array...

If you would like to try it with the powershell Script it looks like this:

$strServername = Get-WmiObject -namespace root\cimv2 -Query "Select * From Win32_OperatingSystem"
$realservername = $strServername.CSName
$dest = "d:\export[/COLOR]$realservername"

$VM_Service = get-wmiobject -namespace root\virtualization Msvm_VirtualSystemManagementService

$ListofVMs = get-wmiobject -namespace root\virtualization -query "select * from Msvm_ComputerSystem where ElementName = 'Ares' or ElementName = 'DC10' or ElementName = 'dc20'"   

foreach ($VM in [array] $ListOfVMs) 
{
	$VMReturnState = $VM.EnabledState
	$VMName = $VM.ElementName

	if (($VM.EnabledState -eq 2) -or ($VM.EnabledState -eq 32768) -or ($VM.EnabledState -eq 32770))
	{
		(gwmi win32_operatingsystem -ComputerName $VM.ElementName).Win32Shutdown(1+4,0) 
	}

	while (!($VM.EnabledState -eq 32769) -and !($VM.EnabledState -eq 3))
	{
		Start-Sleep(1)
		$VM = get-wmiobject -namespace root\virtualization -Query "Select * From Msvm_ComputerSystem Where ElementName='$VMName'"
	} 


	if ([IO.Directory]::Exists("$dest\TmpDir\$VMName"))
	{
		[IO.Directory]:[[:D]]elete("$dest\TmpDir\$VMName", $True)
	}

	$status = $VM_Service.ExportVirtualSystem($VM.__PATH, $True, "$dest\TmpDir")
		
	if ($status.ReturnValue -eq 4096)
	{
		$job = [Wmi]$status.Job	
	
		while (!($job.PercentComplete -eq 100) -and ($job.ErrorCode -eq 0))
		{
			Start-Sleep(5)
			$job = [Wmi]$status.Job	
		} 
	}


	##	Store the files on in a temp directory before moving them to their location and then remove the old files.

	if ([IO.Directory]::Exists("$dest\$VMName"))
	{
		[IO.Directory]::Move("$dest\$VMName", "$dest\$VMName-OldTmpDir")
		[IO.Directory]::Move("$dest\TmpDir\$VMName", "$dest\$VMName")
		[IO.Directory]:[[:D]]elete("$dest\$VMName-OldTmpDir", $True)
	}
	else
	{
		[IO.Directory]::Move("$dest\TmpDir\$VMName", "$dest\$VMName")
	}
	$VM.RequestStateChange($VMReturnState)
	Start-Sleep(60)
}[/CODE]

All in all I need to add that I can't stand backup systems which use the save state... DC's produce unbelievable errors. So we implemented PowerShell Scripts which will started periodically by the Task Planer from windows. A low cost backup system which works great. Afterwards we copy the exported system by robocopy to another backup server because its not possible to export a machine via the network... why ever! The robocopy job starts via the taskplaner, too.

I use 8.201 in hyper-v with server 2008R2 w/ sp1 in a home environment.

I recently had to rebuild the host machine.  Had previously backed up the astaro guest.  The backup was made with the astaro guest powered down and exported through the hyper-v console.

 The guest had only 2 nics - both mapped to physical nics on the host.  The import process worked fine.  However, I could not connect to the astaro box through the internal interface.  It did not respond to pings (and the astaro was configured to respond to pings).  The wan interface also did not connect to the router.

On the host machine, I was able to login to the actual astaro guest machine.  It turned out both nics were in a DOWN state after the astaro guest was imported in hyper-v.  I spent only 5 minutes trying unsuccessfuly to get them in an UP state.  It was simpler to just rebuild a new Astaro and restore the config file than spend any more time on it.

Rayik,

Have you connected the nic to the virtual network switches after the import?  Seem to remember it doesn't connect the imported guest automatically??