Hyper-V pass through disk problem
- Hello group,
I have the following problem, on a two node cluster with Windows6.0-KB950050-x64.msu and Windows6.0-KB951308-v2-x64.msu installed
I have a guest server (Windows 2003 R2 SP2 X86) and i added a 2.3 TB GPT pass-through disk, and then i get the following behaviour :
- When the GPT pass through disk is not partitionned, the guest detects it but show only 200 GB of 2.3 TB
- When the GPT pass through disk is fully partitionned, the guest does not boot (black screen without blinking cursor)
I will try several options in order to pinpoint the problem, but if someone has any idea at this point, thanks...
Answers
- The official way of getting the best performance out of an HDD is to connect the parent via iSCSI to a LUN and then present it as a pass-through disc to the guest. Connecting the guest directly to the SAN via iSCSI is said to be slower than the pass-through version.
- Marked As Answer byVincent HuMSFT, ModeratorThursday, January 08, 2009 1:33 AM
- Hi
iSCSI is the only shared storage solution that is supported for Hyper-V scenarios. Sharing a disk from the host into the guest OS is not recommended. One should create any disk connections through iSCSI on the guest.
Best Regards,
Vincent Hu
- Marked As Answer byVincent HuMSFT, ModeratorThursday, January 08, 2009 1:33 AM
All Replies
- Solved the problem by using a SCSI disk instead of a IDE disk
- I still have Two problems with pass through disks in a clustered configuration after switching to SCSI :
- When i rescan the disks on the Parent Server, even if the disk is reserved as a cluster resource, it mounts the file system, The result : errors appear on the guest that it cant write to the disk
- When i move the VM from one node to another, it fails to make the VM online because of the pass-through disk (in the settings sheet of the VM instead of showing disk 2 it shows "not found")
this is quite strange because i dont see any similar problems on the net, Am i alone with pass thru disks in a clustered setup, or is it just bad luck ?
More information about the hardware : Blade HP BL460c G1 with a MSA 2012 fc SAN (several LUNs store the VHDs and the pass thru disk)
Thanks if you have any information. - Hi
iSCSI is the only shared storage solution that is supported for Hyper-V scenarios. Sharing a disk from the host into the guest OS is not recommended. One should create any disk connections through iSCSI on the guest.
Best Regards,
Vincent Hu
- Marked As Answer byVincent HuMSFT, ModeratorThursday, January 08, 2009 1:33 AM
- Thanks for the information, so if i understand well :
- Shared storage used in cluster operations should be ISCSI not FC for Hyper-V scenarios
- Guest access to a LUN on the SAN should use a ISCSI initiator (the SAN being the target)
But then, i fail to see the use cases of pass-through disks, does it mean that they are not officialy supported ?
Best Regards, - The official way of getting the best performance out of an HDD is to connect the parent via iSCSI to a LUN and then present it as a pass-through disc to the guest. Connecting the guest directly to the SAN via iSCSI is said to be slower than the pass-through version.
- Marked As Answer byVincent HuMSFT, ModeratorThursday, January 08, 2009 1:33 AM
- WVincent,
I'm very confused as to what you are recommending:
You say:
Hi
Does this mean that we should make iSCSI connections from the guest to the iSCSI storage array? I think so but then you also mark as an answer that:iSCSI is the only shared storage solution that is supported for Hyper-V scenarios. Sharing a disk from the host into the guest OS is not recommended. One should create any disk connections through iSCSI on the guest.
Best Regards,
Vincent Hu
The official way of getting the best performance out of an HDD is to connect the parent via iSCSI to a LUN and then present it as a pass-through disc to the guest. Connecting the guest directly to the SAN via iSCSI is said to be slower than the pass-through version.
This says I should make the iSCSI connections from the Parent and pass the disk through to the child. While I know both are options, I am looking for the option that is going to give the best performance for the file server with the data being stored on the iSCSI array.
Could you clarify which is better:
1. iSCSI from the Parent/Host and pass through to the Child/Guest or
2. iSCSI from both the Parent and child
If 2 is better could you refer me to some material about configuring hyper-v with regards to iSCSI nics at both parent and child because I can't find anything and am really confused. - I am very interested in the answer to the question above. We have diskless blade hyper-v servers booting from SAN using QLogic iSCSI HBAs. We use a local disk only for their pagefile. We then mount iSCSI volumes for the Guest VM OS's using the iSCSI HBAs with MPIO. (this all works great) We want to do SQL clustering (which requires shared storage) between VMs running on two different blades. Since we can't pass the HBA's through to the Guest VM, we're trying to decide which way (disk pass thru, or iSCSI using standard NICs within VM). We are a start-up University with a relatively small user base (perhaps < 400) total users so I realize just about anything will work without us incurring performance issues. But, we plan to grow quickly to about 2000 users and I do not want to have to re-engineer this solution later on. We've moved just about everything to run leveraging our back-end SQL cluster (Sharepoint, WSUS, and about 10 other DBs), so we want a robust solution. Thank you in advance.
- In our experience, I would opt for option 1.
I've only heard of people getting an iSCSI connection from host to SAN, and then passing through the LUN to the Guest/Child. I've not seen anyone run an iSCSI connection from guest directly to SAN, nor have i tried this myself.. so cannot verify what its like. The documentation I've come across seems to suggest the host iSCSI to SAN as well.
Maybe I'll try it out once i get my R2 host to add VHDs to R2 guests via the SCSI controller without causing errors, as I cant even get that working yet.
