OK!! Seeking procedural advice on moving server OS to new controller

[BonzaiDuck]

First -- the long way around this problem is probably a few hours worth. But even for that, "Hard is the road and long is the path" or so it seems.

WHS [Servr 2008 R2] OS is on an HDD running off a goll-dang nForce controller for which AHCI was only "casually" implemented with something often called "IDE-SATA."

I want to move that HDD to a Marvell controller -- known to work with the OS for boot-system. The Marvell controller apparently doesn't have much in the way of driver installation, or Windows has a driver built-in that recognizes the hardware. The controller will be set up for "AHCI mode" -- no RAID configuration.

I can do a couple things:

Make an OS-generated repair CD
Uninstall the nForce driver
Move the drive, and if it doesn't "figure out" the new controller, run the install disk and choose "repair" with the repair CD

The hard way -- not all that hard, but I had to visit that burden in recent days already once: Pull the existing nForce-configured HDD from the system and reinstall the OS on another SSD or HDD connected to the Marvell controller. And supposedly, this would most certainly be a reversible approach in the event of some problem.

This nFarce "IDE-SATA" mode apparently doesn't lend itself to the easy formula for converting "IDE" to "AHCI" -- as noted in disclaimers on the "guides" for that.

I need to find out if the Marvell PCI-E controller is "reliable," but given the bad signs of small-sample customer experience, the "good signs" are very encouraging.

IF it is stable and IF it works like the good sign folks say, I want to completely disable nFarce "SATA."

IF it is unreliable (the Marvell controller), then I want to quickly re-enable the nFarce SATA version until such time as I have another "solution" ready.

Thoughts or comments?? Procedural "formulas?"

 

[Dahak]

Before doing anything i would

1) backup the os drive
2) verified that you backed up the os drive


I did something very similar a while back and this seemed to be what it did for XP.

Now WHS 2011 / server 2008 is not tied to the storage controller as bad as XP /Server 2003/WHS V1 was so you could just try to swap the drive over first and see what happens. Worse case is it will give a boot errors, and swap it back then continue on

3) make sure that the marvell controller driver is installed
4) make sure that current controller is listed as standard IDE / or ACHI controller
5) shut down and move drive to other controller.

Now this was a while ago and it was going from an intel to amd and thats roughly what I remember doing. I cant remember if I had any issues after the fact.

 

[BonzaiDuck]

Before doing anything i would

1) backup the os drive
2) verified that you backed up the os drive


I did something very similar a while back and this seemed to be what it did for XP.

Now WHS 2011 / server 2008 is not tied to the storage controller as bad as XP /Server 2003/WHS V1 was so you could just try to swap the drive over first and see what happens. Worse case is it will give a boot errors, and swap it back then continue on

3) make sure that the marvell controller driver is installed
4) make sure that current controller is listed as standard IDE / or ACHI controller
5) shut down and move drive to other controller.

Now this was a while ago and it was going from an intel to amd and thats roughly what I remember doing. I cant remember if I had any issues after the fact.

I appreciate your contribution here.

The storage drives are indeed divorced from the OS under the same controller, but I'm pretty sure they're divorced from it generally. They are simply "Simple 'Basic' volumes" with no boot sector. They're all "NTFS" format drives. I've moved these drives back and forth from one machine to the next -- you can read and write to them once they're mounted.

I see this as a process in several steps:

First, get the OS and boot drive working properly on the new controller. I could simply reinstall the OS on a different HDD or the SDD I bought for that purpose.

I have two new 2TB NAS drives coming tomorrow with that controller. I can move the server folders to one of them -- taking one of the old drives out of the pool at a time, then use the drivepool software to balance between the two new drives. But I need to know these drives will be reliable.

It is likely that I could just move the pooled disks to the new controller -- first, then kill the onboard nForce controller once I see things working properly. Then, cautiously incorporate the new NAS drives into the pool one by one, making sure that I've backed up data in case one of them screws the pooch.

 

[Cerb]

Thoughts or comments?? Procedural "formulas?"

1. Enable AHCI via registry tweak.
2. Move drive to new machine.
3. Move on.

2008 R2 supports AHCI natively, as in out of the box. You just have to turn it on. If it fails to boot, put it back in the old box, uninstall the NForce drivers, changing the ATA controller to a plain Intel, and then swap again, with the drive as IDE mode, and do the regular in-place IDE- to AHCI move.

Pooled disks do not matter, either, assuming by drivepool you mean StableBit DrivePool.

 

[BonzaiDuck]

1. Enable AHCI via registry tweak.
2. Move drive to new machine.
3. Move on.

2008 R2 supports AHCI natively, as in out of the box. You just have to turn it on. If it fails to boot, put it back in the old box, uninstall the NForce drivers, changing the ATA controller to a plain Intel, and then swap again, with the drive as IDE mode, and do the regular in-place IDE- to AHCI move.

Pooled disks do not matter, either, assuming by drivepool you mean StableBit DrivePool.

Thanks, Cerb. Maybe you still have more insight to this. I was a bit confused after reading the caveats of online guides that nForce was different with AHCI, but I'm moving the boot drive off the nForce controller and onto another one, so I think I see how what you say makes sense.

The very worst case means that I'd have to reinstall the OS, user accounts and add-ins all over again. I want to avoid that.

The new controller is Marvell-- not Intell. But it requires very little in the way of drivers, as I understand it. This was the "plus" cited by some few user reviews.

And -- yes -- it is so far my experience and understanding that a Simple/Basic NTFS volume is just that -- whatever controller it's attached to. I should be able to move the whole array over to the new controller if I can reduce the number of drive-members to three -- or even two. The current four 1TB drive-pool members have just over 1TB of data total.

I'm trying to kill several birds here. First, get rid of nForce, and see if I can use this old LGA_775 box some more. Thus, the new controller. Second, get rid of some sort of driver contention I've mentioned elsewhere -- in which the web discussions always seem to include nForce as a component. Third, I want to pull the 1TB members from the pool one by one, replacing with 2TB units -- this will reduce power consumption for 24/7, even if there are eventually four 2TB's.

 

[BonzaiDuck]

Somebody with their own 680i motherboard posted at Intel with practically the same question, the same half-baked nForce controller, etc. and their desire to get off the nForce so their SSD would have TRIM.

https://communities.intel.com/message/84042

They pretty much did the same thing: purchased a Marvell SATA-III controller for PCI_E. Apparently enabled the boot drive for AHCI in the registry, and then move the drive to the new controller.

It actually looks as though there was no problem getting the system to boot after those simple steps.

I just hope it all works out -- totally parallel situation to that of the Intel poster. Otherwise, it means another OS install. At least I can just move my drive pool from one controller to the other . . .

 

[Cerb]

The new controller is Marvell-- not Intell. But it requires very little in the way of drivers, as I understand it. This was the "plus" cited by some few user reviews.

With AHCI, the driver you need is the AHCI driver, which is included in Windows. If you change drivers for the SATA controller, shut down, and then boot up in the new hardware, it should work.

If you're using the same mobo, make sure the Marvell card is working in Windows before the reboot, and then just disable chipset SATA ports in the BIOS. with the registry change for AHCI at boot, it should "just work." But, if it doesn't, you can move back to the chipset controller and troubleshoot, generally.

 

[PhIlLy ChEeSe]

With AHCI, the driver you need is the AHCI driver, which is included in Windows. If you change drivers for the SATA controller, shut down, and then boot up in the new hardware, it should work.

If you're using the same mobo, make sure the Marvell card is working in Windows before the reboot, and then just disable chipset SATA ports in the BIOS. with the registry change for AHCI at boot, it should "just work." But, if it doesn't, you can move back to the chipset controller and troubleshoot, generally.

^ Yes
Also remove original motherboard drivers as your changing your motherboard........Everything else stays. Youll be fine once new drivers are in.

 

[BonzaiDuck]

^ Yes
Also remove original motherboard drivers as your changing your motherboard........Everything else stays. Youll be fine once new drivers are in.

Well, the devil is in the details. When I found online guides about conversion between IDE, AHCI and RAID (back and forth all ways . . ), the advice about registry edits included a reference to the MS driver MSahci. Looking in my registry, this entry was missing among the three recommended for edit. Needless to say -- I bricked my boot disk or otherwise failed to do something correctly (like setting boot-order in BIOS). That's all water under the bridge.

I think I linked the forum exchange at the Intel site which shows that my Marvell controller (expected to arrive here tomorrow) may be especially good for achieving my objectives here. The recommendation in that link points to two possible ways of moving a boot disk from the nForce controller to the Marvell: First-- install the controller board, then boot windows which will load the native driver for it automatically, then shut down, move the HDD to the new controller, then reboot to change BIOS boot order, and after that -- (supposedly) "Voila'!" The second option required editing the registry.

I'm wondering if a registry edit would also be required under the first method, even though the recommendation for "option A" doesn't include it.

Even good advice can contain an omission. Of course, the author explicitly states that "option B" requires the registry edit.

UPDATE: While I would like to remove the nForce drivers and disable the SATA controller in the mobo BIOS immediately, there are four 1TB (non-bootable) data drives on that controller. The easiest way for me to move them to the new controller involves eliminating them one at a time from the StableBit drive pool as I add two new Seagate 2TB drives to the new controller. But I will only have three available ports for data drives on the Marvell controller (unless I obtain a breakout cable -- I think it's called "mini-SAS" -- for the port multiplier feature on the Marvell Controller). I'll have to remove the nForce drivers when there are no longer any data drives attached to them -- which means "after the system is bootable from the new controller and data has been moved to disks on the new controller."

 

[Dahak]

First-- install the controller board, then boot windows which will load the native driver for it automatically, then shut down, move the HDD to the new controller, then reboot to change BIOS boot order, and after that -- (supposedly) "Voila'!" The second option required editing the registry.

I'm wondering if a registry edit would also be required under the first method, even though the recommendation for "option A" doesn't include it.

Even good advice can contain an omission. Of course, the author explicitly states that "option B" requires the registry edit.

Now I have only skimmed the rest of the posts here and a bit, so with that in mind.

The primary reason for the registry edit is to make sure the driver will load at boot. If it does not then it will not boot any further as it cannot load.
Now this was the reason for XP/Server2003/Whs v1.

For Server 2008/WHS 2011 it still may be necessary although I have not looked at it for those. But it may not hurt change it after the driver is installed.

You just have to look to see what the service is and change the startup registry bit from what ever it is to 0 which is for boot

 

[Cerb]

Turning AHCI on in the registry, then shutting down, then changing to the Marvell's ports, then turning off the chipset SATA controller, should do the job, without needing to change what the chipset ATA controller driver is.

Originally, I was expecting that you were changing whole computers, not adding a card. If it fails, you should be able to plug the drive back into a chipset SATA port, and boot right back up.

 

[Cerb]

The primary reason for the registry edit is to make sure the driver will load at boot. If it does not then it will not boot any further as it cannot load.
Now this was the reason for XP/Server2003/Whs v1.

Nope, just 2008 R2 and WHS 2011. 2008/Vista and older do not natively support AHCI.

 

[BonzaiDuck]

Nope, just 2008 R2 and WHS 2011. 2008/Vista and older do not natively support AHCI.

So . . . you're saying that all I need to do is install the PCI_E controller card, boot to get Windows WHS 2011 to recognize the controller and load the driver -- then move the drive from the onboard nFarce to the Marvell controller -- without any registry edits?

 

[Cerb]

So . . . you're saying that all I need to do is install the PCI_E controller card, boot to get Windows WHS 2011 to recognize the controller and load the driver -- then move the drive from the onboard nFarce to the Marvell controller -- without any registry edits?

No. You will still need to enable AHCI on boot, setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci\Start to 0. You probably won't even need a driver for it, if the card is AHCI compatible.

Unused storage drivers are disabled when you install Windows, for faster booting. AHCI is there, but it needs to be told to load on boot. Turning that on will not disable any other drivers, so you should be able to revert to the chipset SATA ports for troubleshooting, should it not, "just work."