Get Adobe Flash player

P2V strategy for a Physical Server with an iSCSI Partition

Most physical to virtual migrations (P2V) of servers end up as virtual machines with the partitions encapsulated in virtual disk (.vmdk or .vhd) files. But what if the physical server already has a partition that’s configured through an iSCSI connection to the SAN, and what if that’s the same SAN that the new VM will run on? Of course, the new VM will have to be on a different LUN (formatted for use by the virtualization host), but should you encapsulate the current NTFS iSCSI partition or should you maintain the iSCSI initiator within the resulting VM? The former option depends on how much available SAN space you have to work with, the latter requires some extra thinking before you begin.

When you decide to maintain a server’s existing iSCSI partitions as a VM, there are several configuration considerations to plan for.

Multipathing Support for iSCSI is no longer needed in the VM

When you were configuring the iSCSI initiator chances are you used two physical network interface cards (NICs) for a redundant connection in the server operating system to the storage. You then used the NIC manufacturer’s drivers/management software to create a team and a virtual ip address. Your SAN was configured to allow an iSCSI initiator to connect via that NIC team virtual ip address.

As a VM that same team ip address will probably still be maintained as the initiator, but the need for two NICs and the former manufacturer’s drvers and software will be removed. The VM only needs a single vNIC to the iSCSI storage. The virtual host should be configured with a vSwitch mapped to two pNICs. Therefore the virtual host provides the redundant connection to the storage.

Be sure to remove the team configuration and the old NIC drivers and software.

Dedicate a vSwitch with it’s own pNICs for the VM iSCSI traffic

Separate the VM’s iSCSI traffic from the virtualization host’s iSCSI traffic. You could add an extra portgroup to your iSCSI vSwitch in VMware ESX for example, but ideally, you want 2 NICs dedicated to the host, and 2 other NICs dedicated to the VM(s). This requires separate vSwitches. This will maximize performance and provide redundancy.  

Consider the cables needed to the SAN switches

Before P2V each server needed 2 cables to the storage switches for redundancy. After P2V, each virtualization host will need 4 cables. Two of the cables will be replaced by the connection to the host’s dedicated LUNs where the VM’s operating systems and and other partitions are encapsulated. The second set of two cables will be for the VM’s initiator to access it’s own iSCSI partitions. 

Disconnect the iSCSI initiator before P2V

This is not a must do, but rather a safety net for the P2V migration process. Disconnecting the server’s iSCSI initiator ensures the LUNs you need to maintain will not be selectable as disks to be converted during the migration.

Be prepared to recreate any file shares and permissions

If you disconnect the iSCSI initiator as previously mentioned then be prepared to recreate any file permissions and shares that were configured. To be honest, I am not sure of the best way to prepare for this or if it’s even necessary, but in my experience I have had to recreate shares. Thank goodness it was never a complex user or department hierarchy as you can imagine the impact and administrator time needed that overlooking this would cause.

Check out this VMTN Communities thread on this topic too:

VMware Communities: P2V when server has a LUN through iSCSI? …

Related Posts

  • Pingback: Posts about Windows 7 as of January 27, 2009 | The Lessnau Lounge

  • http://www.veristor.com Omar Torres, VCP

    great article guys. I just finished up 3 large conversions for several customers over the past few months and can definitely attest to this method when P2V'ing systems that already have volumes on the target array for the consolidation. The nice benefit here is that the data is already on the array, so you don't have to resort to any long and tedious flat-file copies using robocopy to get to the data over to remount later.

    just a few things to add from my experiences:

    1. regarding shares and file permissions: if it's a physical server running windows, and the original volume on the iSCSI array is formatted in NTFS (which it likely is), permissions will all remain. The file system is not touched when you do a P2V and you exclude those volumes. So when the P2V conversion is complete, and the new VM re-attaches to the volumes with the software iSCSI initiator, the file system will be the same, including all ACL's and permissions. As for shares, they will also come right back. Windows will not delete the shares and their associated permissions from the registry unless you manually delete the shares yourself. The key is to ensure that when you remount the volume, that it retains the same drive letter as it did when it was still a physical server. Otherwise you will definitely loose the shares. If you don't feel safe about it, then here is the M$ support kb that provides you the steps to backup your share config and restore it:

    http://www.suvi.org/funstuff/slapit.html

    2. regarding vswitch / vmnic configuration for iSCSI: in all of my designs and installs, I've seen no issues with creating the port group for the Virtual Machine iSCSI traffic on the same vSwitch that the host uses for the iSCSI VMKernal and the iSCSI console (in the case of ESXi, just the VMKernel, since it does not require an additional console for iSCSI connectivity). EqualLogic even recommends this config within their whitepaper for ESX/PS Series array best-practices. And in some cases this may be your only choice if you are limited on eth interfaces and/or PCIx/PCIe expansion slots to add additional interfaces. Otherwise, I agree, absolute best-practice “sure-fire” least-risk is to dedicate two more additional interfaces teamed in a vSwitch to segment the VM iSCSI traffic from the ESX host iSCSI traffic.

    cheers!

  • http://www.veristor.com Omar Torres, VCP

    lmao…wow…wrong URL there folks…but I'm sure some of you had fun with it anyways.

    here's the write URL for the Microsoft kb on backup/restore of your shares…

    http://support.microsoft.com/kb/125996

    ;)

  • http://vmetc.com rbrambley

    Omar,

    Thanks for the insight. Good stuff to know about the MS shares process
    and thanks for the links. In my recent scenario the customer
    disconnected the iSCSI volume before p2v and the new VM did end up
    with a different drive letter on reattach.

    As far as the dedicated vSwitch versuis combining a portgroup on the
    ESX iSCSI vSwitch, you are right. It depends on how many NICs/ports
    your ESX host can provide. Dedicating 2 for VM iSCSI traffic is best
    for performance in I/O greedy VMs which means 8 to 10 NIC ports in
    each ESX host!

  • dhhruvarya

    Please advise me – I need some help with the ESX – As described below – Please help me if any body can help.

    I have two ESX hosts ESX1, and ESX2. On ESX1 have 9 HDrives, where I am using 3 drives with RAID 5 for the ESX OS, and the remaining 6 HDrives I want to share as a shared storage with other ESX hosts in the cluster. Presently I have a cluster with these 2 ESX hosts in that cluster.

    I am unable to see the storage on the ESX1 on to the ESX2. Please what do I need to do, I have iScsi enabled and portgroup (VMKernel) enabled in ESX1. Please help me.

  • http://vmetc.com rbrambley

    You will not be able to share the local storage on your ESX hosts with
    each other through the Service Console OS (ESX). You do have some
    options from VMs running on your local storage.

    You could use xtravirt's xvs (free) or Lefthand's VSA to create a
    virtual SAN out of one or both of the local storage on each ESX hosts.

    OR

    You can build a VM and give it virtual hard drives (.vmdks) that use
    up 80% of your local VMFS datastore. Leave 20% free space for ESX
    health. From within that VM, configure a NFS or iSCSI share/target.
    Use Openfiler, FreeSAN, or even MS 2003 R2. As long as your ESX hosts
    are on the same ip subnet as your NFS/iSCSI VM then they can both see
    the shared storage.

    Search vmetc.com for any of these products or local storage concepts.

  • dhhruvarya

    I personally thank you for your effort to send this response, I shall certainly try the way you have mentioned here – as below:

    ” You can build a VM and give it virtual hard drives (.vmdks) that use

    up 80% of your local VMFS datastore. Leave 20% free space for ESX

    health. From within that VM, configure a NFS or iSCSI share/target.

    Use Openfiler, FreeSAN, or even MS 2003 R2. As long as your ESX hosts

    are on the same ip subnet as your NFS/iSCSI VM then they can both see

    the shared storage.”

    I do not want to try the NFS part but I am more interested in iSCSI share/target. Using iSCSI share/target, do I still need to use OpenFiler, or I can see those .vmdks disks through iSCSI share/target.

    Thanks, my friend, truly appreciated.
    Dhhruv Arya
    Network Engineer

    Tel: 905-362-8550 x 216
    Fax: 905-362-8555
    Email: dhhruv.arya@xcino.com
    Web: http://www.xcino.com

    XCINO INC.
    7035 Maxwell Rd., #2
    Mississauga, ON
    L5S 1R5

    Disclaimer:
    Information contained and transmitted by this E-MAIL is proprietary to XCINO and is intended for exclusive use by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law and  shall  not attach  any liability on the originator. Any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately.

    ? Please consider the environment before printing this e-mail

  • http://vmetc.com rbrambley

    Just to be clear:

    You have to create a iSCSI server / service / target inside a VM.

    The ESX iSCSI config in the vSwitch Networking is not for sharing
    server storage to other hosts, but for connecting to the shared iSCSI
    Storage Source (VMs in your case)

    Yes, any of those products mentioned can be iSCSI targets.

  • http://vmetc.com rbrambley

    You will not be able to share the local storage on your ESX hosts with
    each other through the Service Console OS (ESX). You do have some
    options from VMs running on your local storage.

    You could use xtravirt's xvs (free) or Lefthand's VSA to create a
    virtual SAN out of one or both of the local storage on each ESX hosts.

    OR

    You can build a VM and give it virtual hard drives (.vmdks) that use
    up 80% of your local VMFS datastore. Leave 20% free space for ESX
    health. From within that VM, configure a NFS or iSCSI share/target.
    Use Openfiler, FreeSAN, or even MS 2003 R2. As long as your ESX hosts
    are on the same ip subnet as your NFS/iSCSI VM then they can both see
    the shared storage.

    Search vmetc.com for any of these products or local storage concepts.

  • dhhruvarya

    I personally thank you for your effort to send this response, I shall certainly try the way you have mentioned here – as below:

    ” You can build a VM and give it virtual hard drives (.vmdks) that use

    up 80% of your local VMFS datastore. Leave 20% free space for ESX

    health. From within that VM, configure a NFS or iSCSI share/target.

    Use Openfiler, FreeSAN, or even MS 2003 R2. As long as your ESX hosts

    are on the same ip subnet as your NFS/iSCSI VM then they can both see

    the shared storage.”

    I do not want to try the NFS part but I am more interested in iSCSI share/target. Using iSCSI share/target, do I still need to use OpenFiler, or I can see those .vmdks disks through iSCSI share/target.

    Thanks, my friend, truly appreciated.
    Dhhruv Arya
    Network Engineer

    Tel: 905-362-8550 x 216
    Fax: 905-362-8555
    Email: dhhruv.arya@xcino.com
    Web: http://www.xcino.com

    XCINO INC.
    7035 Maxwell Rd., #2
    Mississauga, ON
    L5S 1R5

    Disclaimer:
    Information contained and transmitted by this E-MAIL is proprietary to XCINO and is intended for exclusive use by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law and  shall  not attach  any liability on the originator. Any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately.

    ? Please consider the environment before printing this e-mail

  • http://vmetc.com rbrambley

    Just to be clear:

    You have to create a iSCSI server / service / target inside a VM.

    The ESX iSCSI config in the vSwitch Networking is not for sharing
    server storage to other hosts, but for connecting to the shared iSCSI
    Storage Source (VMs in your case)

    Yes, any of those products mentioned can be iSCSI targets.

Badges

follow-me-twitter

I blog with Blogsy

Comments / DISQUS