We run ShadowProtect on Hyper-V host machines to backup multiple Hyper-V VM's. This works a treat, however, as Hyper-V uses GUID's to name the folder for its state files and assigns special security object permissions to them, restoring a VM from a Shadow Protect image can be a little tricky, so I've documented one restore method below:

1. Login to the Hyper-V server.
2. Identify the location(s) of the VHD file(s) (this can be obtained from the VM settings) – in particular note the volume they are stored on as this will determine the ShadowProtect image file(s) that you will need to mount.
3. Rename the relevant VHD folder(s) (eg: F:\VHDs\STVTER003 -> F:\VHDs\STVTER003-8Nov) - for fall back purposes.
4. Identify the location of the VM’s state folder – this will have been determined when the machine was created and is probably in the Virtual Machines sub folder under the default folder defined in Hyper-V settings (eg: E:\VSconfigs\Virtual Machines). Unfortunately, the VM’s config file and associated state sub-folder is named with a GUID (eg: 6A40F6D6-4DC7-4AF3-B427-FDEE944FC44A.xml) and the only way to confirm you have the correct file name is to open the XML config file in this folder and search for the VM name. Note the GUID folder name and location and and in particular note the volume they are stored on as this will determine the ShadowProtect image file(s) that you will need to mount.
5. Rename the state folder that shares the same name as the identified XML file (for fallback purposes). Note that you will not be able to rename the configuration (XML) file as this will be in use by Hyper-V. If you need to restore this file also you will probably have to stop the Hyper-V services.
6. Open the location of your Shadow Protect images in Windows explorer
7. Identify the volume backup image file(s) that contains the file(s) you want to restore for the relevant date (if you’re restoring back to an older version – otherwise select the latest file).
8. Right click on the image file and select Quick Mount. This will mount the entire volume image as the next available drive letter.
9. Repeat steps 7 & 8 for each volume image you require to restore from (depends on whether all your VM's VHD files and state folder are stored on different volumes).
10. Open a command prompt to run XCOPY.
11. The following ROBOCOPY commands are based on the following scenario:
a. The target VM VHDs folder is “F:\VHDs\STVTER003”
b. The target VM state folder is “E:\VSConfigs\Virtual Machines\6A40F6D6-4DC7-4AF3-B427-FDEE944FC44A”
c. The relevant ShadowProtect image file for Volume E: has been mounted as drive G:
d. The relevant ShadowProtect image file for Volume F: has been mounted as drive H:
12. Restore the VM’s state folder using this command (NB: this will ensure the correct Hyper-V specific permissions are retained on the files and folders):
ROBOCOPY "G:\VSConfigs\Virtual Machines" "E:\VSConfigs\Virtual Machines" 6A40F6D6-4DC7-4AF3-B427-FDEE944FC44A.* /S /DCOPY:T /COPYALL
13. Restore the VM’s VHD folder using this command:
ROBOCOPY "H:\VHDs\STVTER003" "F:\VHDs\STVTER003" *.* /S /DCOPY:T /COPYALL
14. Dismount the ShadowProtect volumes by right clicking their drive letters (eg: G: & H:) and selecting “Dismount…”
15. Start the VM within Hyper-V Manager
16. Windows will start and prompt you for the reason it shutdown unexpectedly – enter a reason (eg: restored version prior to software install failure)

Hope this comes in handy for someone...

Slight detour from the original post but anyway......

Are we saying that Shadowprotect is Hyper-V VSS aware, so that we are able to backup  Windows 2008 using it, and it will grab the Virtual Machines running within Hyper-V? and of course that it will do it properly?

ShadowProtect is very well integrated with the VSS interface.  This means that when ShadowProtect creates the snapshot, upon which its backup is based, it leverages the entire VSS framework to quiesce applications and flush file systems prior to creating the snapshot.  Applications such as Exchange, SQL, IIS, and also Hyper-V are call VSS Writers because they are applications which create data and which are also "VSS Aware," meaning that they will flush their files to disk when requested to do so by the VSS framework.  This means that backups of a Hyper-V host performed by ShadowProtect will capture the Hyper-V files in a state which is optimal for a backup.

Having restored a production Hyper-V SQL 2005 server hosting multiple SQL databases just this week, I can verify that this indeed is correct. Note that I believe it's important to restore the VSV file (the save state file that's created by VSS) as well as the VHD files to ensure a clean restore.