Windows 2008 R2 SP1

camealy · Sun Mar 20, 2011 2:08 am

Any issues with Windows 2008 R2's recent Service Pack 1 for either Starwind Hosts or Hyper-V Clusters talking to Starwind iSCSI targets?

I know that StarWind can't support Microsoft software or be held responsible, etc, etc.

Just looking for any experiences anyone has had?

Thanks!

Kurt

Sun Mar 20, 2011 10:17 am

Should not be any issue with SP1 installed. At least nobody complained and our internal QA team has no problems so far.

Aitor_Ibarra · Mon Mar 21, 2011 6:04 pm

I'm running 2008 R2 SP1 on all my hyper-v cluster nodes, and on the physical boxes that run Starwind (I run Starwind virtualised). I have NOT installed SP1 on the Starwind VMs, as I could see no advantages to doing so (apart from the hyper-v features like dynamic memory, SP1 is effectively a hotfix roll-up, so if you are upto date, you don't need it for Starwind).

No problems on my hyper-v cluster, however, one (of two identical) of my physical boxes for Starwind VMs did have a problem; the update failed to install correctly, and the server was left in a limbo state where it said SP1 had failed to install but also that it was running SP1. It also disabled Hyper-V which was a big problem. In the end I had to reinstall Windows - I used media with SP1 integrated. This was fine excpet that the Intel ProSet drivers refuse to install under SP1 so I had to use in-box drivers - which was OK for me, as the features I needed were available with the in-box drivers.

When I did get the box reinstalled, I could reimport my Starwind VM, and the HA fast sync kicked in and all was well.

So - based on my small sample size - you may get a problem with installation on servers running hyper-v; if your drivers will install under SP1 then you can always reinstall from SP1 integrated media. If you are building a server from scratch then definitely go with SP1 integrated, it saves a lot of patching.

Oh, if you do run Starwind virtualised, then I don't think it's a good idea to use dynamic memory for it, so I haven't even tried. Dynamic memory works well with vanilla windows and SQL, but is a bad idea for Exchange, which tries to grab all the RAM it can, and if you are running Starwind you will be tuning RAM by hand to make sure you have enough for caching, so there would be no benefit trying to save a few MB. However, SP1 on the host can still be a good idea, e.g. I've used dynamic memory on the other VMs (DC, DNS etc) which has minimised their footprints a bit, but not dramatically.

camealy · Mon Mar 21, 2011 6:24 pm

I did install SP1 last night on all locations and it seemed to work fine. No benefit other than the dynamic memory that I could see.
Ended up having to do a full sync because the allowed change rate % is so small for fast sync that my VM's exceeded it. As usual it made the VM's almost unusable during the sync even with 10Gb sync channel.

Mon Mar 21, 2011 9:19 pm

As usual you should wait for V5.7 with sync channel bandwidth throttling. If we'll have to delay V5.7 we'll back-port this feature into V5.6 branch.

camealy · Mon Mar 21, 2011 9:25 pm

OK, what is the rough ETA of 5.7 barring any unforseen issues?

Mon Mar 21, 2011 9:27 pm

Mid-May 2011 I guess. You can get Beta version much quicker. AFAIK you don't run production environment (at least have non-production as well). So you have excellent chance to see V5.7 in the way you want it to be seen.

camealy wrote:OK, what is the rough ETA of 5.7 barring any unforseen issues?

Aitor_Ibarra · Tue Mar 22, 2011 3:38 pm

camealy wrote:Ended up having to do a full sync because the allowed change rate % is so small for fast sync that my VM's exceeded it.

Hi Camealy, do you mind me asking how big your HA targets are, and how full they are? I managed to get away with a fast sync after at least 48 hours of a node being down; I'm currently running about 16 VMs on 2x 2TB targets, with about 50% used on one and say 25% on the other. From my understanding of fast sync, the bigger the target, the more data can change before you have to do a full sync. Workloads vary; but there's a couple of small Exchange servers in there and a few reasonably busy SQL databases, as well as guest level backups, so quite a lot of i/o...

Having said that, the fast sync on one target did take a few hours, because the underlying drives were busy, but it didn't cause issues with the VMs like full sync does.

jeffhamm · Tue Mar 22, 2011 4:27 pm

Quoting Anton: "As usual you should wait for V5.7 with sync channel bandwidth throttling" I think I posted this before, but until 5.7 comes out can we accomplish the same goal by temporarily hard-coding the NICs used for the SYNC channel to only 100mbbs/Full duplex or even 10mbps/half duplex to limit the bandwidth that a full sync can use? Would this help to prevent the targets from getting overwhelmed by I/O during the full sync process?

Tue Mar 22, 2011 8:57 pm

Yes of course. This or any other QoS control should work.

jeffhamm wrote:Quoting Anton: "As usual you should wait for V5.7 with sync channel bandwidth throttling" I think I posted this before, but until 5.7 comes out can we accomplish the same goal by temporarily hard-coding the NICs used for the SYNC channel to only 100mbbs/Full duplex or even 10mbps/half duplex to limit the bandwidth that a full sync can use? Would this help to prevent the targets from getting overwhelmed by I/O during the full sync process?

camealy · Tue Mar 22, 2011 9:13 pm

Except what happens when the Sync NIC goes offline for a moment to make the change?

Tue Mar 22, 2011 10:13 pm

Not sure I've got your question... Could you please re-phrease it?

camealy wrote:Except what happens when the Sync NIC goes offline for a moment to make the change?