StarWind Software

Hello,

I'm looking for some clarification and advise regarding your products for creating a 2 node shared nothing SAN using two HP DL380p G8 servers for storage running WS2012 Standard.

We have 4 additional, separate servers, running Hyper-V 2012 to act as Hyper-V hosts.

I've read your Whitepaper "Configuring HA Storage for Live Migration on Windows Server 2012" and it appears to be the most suitable example of what we wish to achieve.

I was concerned that the instructions on Page 19 recommended using the MBR partition type. The HP DL380p servers currently have a 3.2 TB Volume each. If we use the MBR partition type I believe that will limit us to 2 TB. Can you confirm this, or suggest a workaround?

Also

You appear to have two products "StarWind iSCSI SAN & NAS" and "StarWind Native SAN for Hyper-V" which would be appropriate for our project?

I am not entirely certain, but thought "StarWind iSCSI SAN & NAS" would be the correct one to use.

However if we can achieve the same goals is "StarWind Native SAN for Hyper-V" a better choice?

Thank you

Hi!,

I was concerned that the instructions on Page 19 recommended using the MBR partition type. The HP DL380p servers currently have a 3.2 TB Volume each. If we use the MBR partition type I believe that will limit us to 2 TB. Can you confirm this, or suggest a workaround?

The workaround is to use the GPT formatting instead - its absolutelly safe. Currently we are updating the document that you`ve mentioned.

You appear to have two products "StarWind iSCSI SAN & NAS" and "StarWind Native SAN for Hyper-V" which would be appropriate for our project?

The Native SAN has limitation on the servers that can connect to the HA devices: anything else will be able to connect to the HA drives, except the OSes where the StarWind is installed. As I see from your scenario the iSCSI SAN fits you best.

First,

Thank you for the quick reply.

Second, I just wanted to be sure that's GPT instead of some proprietary format I've never heard of called FPT. I can easily understand a typo from the position of the keys on the keyboard. But I wanted to make sure.

And is there an announcement forum or subcription method to receive notice when updated documents are issued?

Anatoly (staff) wrote:Hi!,

I was concerned that the instructions on Page 19 recommended using the MBR partition type. The HP DL380p servers currently have a 3.2 TB Volume each. If we use the MBR partition type I believe that will limit us to 2 TB. Can you confirm this, or suggest a workaround?

The qorkaround is to use the FPT formatting instead - its absolutelly safe. Currently we are updating the document that you`ve mentioned.

You appear to have two products "StarWind iSCSI SAN & NAS" and "StarWind Native SAN for Hyper-V" which would be appropriate for our project?

The Native SAN has limitation on the servers that can connect to the HA devices: anything else will be able to connect to the HA drives, except the OSes where the StarWind is installed. As I see from your scenario the iSCSI SAN fits you best.

I also assume you mean .. "nothing else will be able to connect to the HA drives".. I had thought that might be the case.

If this is the case, describing it as a "embedded" or "localized SAN" to the Hyper-V hosts might be a more informative way to convey its usage model. Or a white paper example describing the use of this particualar product could be created. I might go as far as saying "its a SAN embedded within the nodes of a Hyper-V failover cluster which does not stand alone". Please correct me if I misunderstand the usage scenario.

In any event I am encouraged enough to begin trials.

Again thanks for the fast response.

Second, I just wanted to be sure that's GPT instead of some proprietary format I've never heard of called FPT. I can easily understand a typo from the position of the keys on the keyboard. But I wanted to make sure.

You got me) Yes, I`ve misspelled GPT. Pobody is nerfect

I also assume you mean .. "nothing else will be able to connect to the HA drives".. I had thought that might be the case.

If this is the case, describing it as a "embedded" or "localized SAN" to the Hyper-V hosts might be a more informative way to convey its usage model. Or a white paper example describing the use of this particualar product could be created. I might go as far as saying "its a SAN embedded within the nodes of a Hyper-V failover cluster which does not stand alone". Please correct me if I misunderstand the usage scenario.

Yes, that is exactly waht I`ve ment. And, yes, that is a good idea - we`ll definitelly try to use your idea.

Thank you