1) Does not really use iSCSI in hyper-converged scenario (running on the same hardware with Hyper-V). Yes, we LOOK and uplink to system like we're iSCSI but after connection is established TCP and iSCSI stacks on server are bypassed and everything is handled by kernel-mode acceleration path driver. Think about MSFT and when they go from TCP -> SMB Direct (RDMA). We do very similar thing here except we go not RDMA but actual DMA (same host in a loopback).
Okay I think I understand this. You could always have decided to run Starwind on a Hyper-V host because it's just another Windows program. But in this scenario in v6, the Hyper-V host would have been using the Microsoft initiator to establish a connection to the storage and this went all the way through the iSCSI network path even though it was on the same server. So in v8, it knows the iSCSI target is on the same server so cuts out the networking stage.
Separate iSCSI server:
Hyper-V Host -> Microsoft iSCSI initiator -> TCP/IP network -> Starwind Server listener -> Starwind SAN -> Disks
When running on Hyper-V host:
Hyper-V host -> iSCSI initiator (your own?) -> Starwind SAN -> Disks
Yes I can see how that would give a performance boost.
A further question - that's fine for a single host. If you have other Hyper-V hosts (ignoring SAN mirror for now), I assume they would connect via the traditional method:
Another Hyper-V Host -> Microsoft iSCSI initiator -> TCP/IP network -> Starwind Server listener on Hyper-V host -> Starwind SAN -> Disks
So their performance would be much as it would be with Starwind running on a dedicated server? Therefore in terms of design, you'd get better performance if the VMs were running on the same Hyper-V host (i.e. make that the preferred Hyper-V server) but it would continue to work if you happened to failover to another Hyper-V host without Starwind running locally.
>MSFT "blessed" approach
I'm afraid I'm not familiar with these terms so will need to do some more background reading.
>That's in terms of a storage protocols. In terms of a management we do SMI-S now so you can use System Center Virtual Machine Manager to control StarWind and not use StarWind Management Console at all.
We've yet to implement VMM - we've bought it as part of System Centre data edition version just haven't had time.
>4) (OF COURSE) running inside Hyper-V kernel is what we think makes StarWind the only real NATIVE solution on the market. We're not "just another iSCSI target running inside virtual machine" or similar "solutions" on the market built on top of an open-source stuff.
You need to leverage on this as I've sat through all the recent videos and this didn't jump out at me.
>Dynamic cache is not YET inside StarWind Virtual SAN but it would be there for sure in mid-Fall 2014 (VMworld 2014 in SF is coming and we're busy with some of the VMware-specific things).
As I said in the other post, this is a little disappointing as it would be a great selling point. Many Hyper-V hosts run at way less than maximum memory (just in case of other host failover) so been able to use this RAM whilst it's free for write-back caching would be excellent. Would go someway to my reservations about how much cache is needed for large disk arrays in another post.
So glad that it's something you're looking at although the devil's advocate would say your release schedules have slipped in the past
BUT I've been a developer so I know it's better to get a solid product first before adding features. Especially in the SAN world where it's the backbone of your entire system alongside the network. If that's broken, then you're in deep doo doo.
Cheers, Rob.
