Link to home
Start Free TrialLog in
Avatar of sara2000
sara2000

asked on

vmware upgrades

I am in a situation of upgrading esx4.1 to 5.1.  I checked the current network configuration and noticed that esx4.1 uses service console and iscsi vmkernel port with nic teaming load balance policy “ route based on ip hash”. I started my vmware from ver 5 and I was told that you have to bind iscsi port and use multi-path, this is the best practice and do not use link aggregation for iscsi, correct me if I am wrong. Here it uses link aggregation, I think  I will not be able to bind the nic to iscsi, if I do then it might give break?
I am wondering if I use inplace upgrade option then the current configurations will be upgraded to ver 5.1 and the esxi will work as before in ver 4.1.
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Best practice is to use bindings and multipath as per my EE Article

HOW TO: Add an iSCSI Software Adaptor and Create an iSCSI Multipath Network in VMware vSphere Hypervisor ESXi 5.0

However, VMware Admins do use link aggregation!

In place upgrade option from ESX to ESXi 5.1 may change the networking and you will have to change networking anyway.

Personally I do not recommend upgrades, but fresh, clean installations, because as you will see here in EE, many fail or do not work correctly!
Avatar of sara2000
sara2000

ASKER

Thank you for your reply,
However, VMware Admins do use link aggregation!
if I use link aggregation then i can not use port binding then multipath will not available, am I correct?
Otherwise I have to get network admin to reconfigure the switch , this might be an extra delay.
I would recommend, you carry out Best Practice and use multipath.

Your upgrade is likely to change and re-layout the vSwitch, if it cannot proceed.
One more question.
Is it better to use link aggregation for NFS with IP hash?
NFS does not use multipath, therefore your link aggregation e.g. trunking, works with the default teaming policies of route based on the originating port id.
This  stumped me, I see that existing  config is using link aggregation on the physical switches  , “route based ip hash” nic teaming load balancing policy on vswitches and no iscsi binding.
Is it possible to do it for iscsi?, that is, do not bind the vmkernel port, “if you use route based ip hash”
I can only imagine that he uses like this because of NFS and iscsi.

This is what I did do to see whether there is any port binding for iscsi.
esxcli swiscsi nic list -d vmhb35
the result was
no nic found for this adapter.
Yes, it's possible to use it like that for iSCSI, alrthough maybe not best practice!
Then NFS and iscsi are using same vmkernel port?
They can do, unless you have different IP schemes or VLANs.
My client want to keep same network layout as it is  and use same subnet for nfs and iscsi becuase they have to change IPs on storage etc, this can be too much for them.

If i use link aggregation then I can only have one vmkernel port in the vswitch, AM I Correct?
that is, i am going to team three nic together an duse ip hash.
I will appreciate ig you can bounce with some ideas.
You can create two vmkernel portgroups on two vSwitches, and  link aggregation on both vSwitches.
Still I can not vmkernel port binding to iscsi?
hanccoka:
I want to clarify this , look like i can get away.
You can create two vmkernel portgroups on two vSwitches, and  link aggregation on both vSwitches.

so total of four vmkernel I will have ,am i correct?
Do I put two nic as  active adapter? or one used and other unused.
ASKER CERTIFIED SOLUTION
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial