iSCSI Traffic From Windows VM

[chris_delaney]

Hi Everybody,

I'd like to P2V my main user file storage server which is currently a Windows 2000 box with lots of local storage.

In my mind I thought that it would probably be best to P2V the operating system as a VM and then copy the user data on to my SAN directly (to take advantage of it's snapshotting, etc) and point the 'stub' VM at this data using iSCSI. Is it possible to point Windows VMs to iSCSI targets directly? I have provisioned for a separate NIC on the physical host to cope with this additional iSCSI traffic (the ESX iSCSI traffic will go via two other NICs).

Does this sound reasonable or am I a complete fool?

Many thanks.

Chris

[acr]

Install your MS Initaitor in your guest and off you go.. You can even get MPIO etc (not supported).. not quite sure what your trying to do re: snaps etc though..

Message was edited by:

acr

[chris_delaney]

The snapshotting provided by the SAN will let me have file-level recovery of user files. Hence why I thought it would be better to have them on the SAN in a 'raw' filesystem rather than being tied up in a VMDK file.

[mprigge]

I've done this a bunch of times through the same sort of method that acr suggested. If your file server box has its data on a separate drive letter it's really quite easy. Lets say the system is on C: and the data is on D:. I'm also assuming that your ESX hosts have access to the iSCSI SAN.

Install the MS iSCSI initiator on your file server. Create a LUN on your SAN that's big enough to hold the data you want to hold. Mount that on your existing file server. Some night when you can get away with making the data read-only, copy all of the data onto the iSCSI LUN (I usually use ntbackup to backup to file and then restore the data to ensure that I retain all of the permissions, but that's the long way around and requires a lot of temporary space). Once you have all of the data where you want it on the iSCSI LUN (should look identical to the current D:), swap the drive letters of the 😧 and iSCSI LUN using the Disk Management plugin in the Computer Management control panel. That will essentially make your file server believe that the iSCSI LUN is the same old 😧 that it has all of its shares pointed to.

After that (several days/weeks later if you want), you can P2V the machine. When you do the P2V, only P2V the C:, not the 😧 or the old D:. Also make sure to remove any persistent connections in the iSCSI initiator control panel before you do the P2V so that it doesn't try to connect to the SAN on it's own again. Once the machine is imported into ESX, map the iSCSI LUN you migrated the files to previously to the VM as an RDM. After that you can boot it up. Absent any normal P2V type problems (dealing with NIC drivers and installing the VMware Tools), you should be good to go.

That procedure has worked well for me in the past because it disjoins the tasks of copying local data to the SAN and doing the P2V so that you can test them (and back out of them) separately. It also means you need two shorter outage windows rather than one big one. Having your data in an RDM allows you to mount that LUN on any machine you want (physical stand-alone or mapped into a VM via an RDM). Flexibility is good.

HTH

[Nitemare]

Good idea, going to try it next week :-}

[mprigge]

Happy to help!

I forgot to mention that you'll probably need to reboot the server or restart the Netlogon service after you do the drive letter swap. Usually just making 😧 go away and come back again brings back the shares, but sometimes you need a reboot. Obviously if you're working with something more complicated than a file server (SQL server for example) you'll want to stop and disable all of the application services before you start (that's true for both the data copy and P2V phases).

[Rumple]

As another data copy option you can use Robocopy to do the job and if you use the /mir /copyall you will get an exct copy with all permissions.

I am currently doing that myself and was able to copy 400GB in about 6 hours from SAN disk to disk on the physical side. On Saturday night i will drop the share, complete a last copy and remount the share on the new location.

[chris_delaney]

Thanks guys - that sounds like a plan. Now all I have to do is order my ESX host machines and I'm away....

[chris_delaney]

Sorry - I have another quick question. If I use an RDM in the VM to the user data on the SAN does that mean that ESX will handle the iSCSI traffic behind the scenes? Or will it be the guest OS dealing with it?

[mprigge]

If it's an RDM, then VMWare will be handling the iSCSI traffic - the guest will just see a SCSI disk underneath it. You could also skip the RDM and continue to run the iSCSI Initiator from within the guest, but that's usually not as efficient (though I have done it before quite a lot with ESX 2.5.x and it works well). If the iSCSI SAN is your primary datastore for an ESX cluster, you should also think about getting hardware initiators for it rather than using the software initiator within ESX. The Qlogic QLA4050/QLA4052 is a good one (the only one really).