VSpehere 4.1 Cluster and VLAN renumbering.

[millardus]

Hi folks, me once more.

Aside from a subnet move I am preparing for (Need to move my 10 node ESX cluster across - Storage and Vmotion can remain the same) , I also have to at some stage renumber the VLANs that are being used for my ISCSI storage, Management Network and Server Subnet.

I believe that it isn't possible to stage this so I need to decide whether to perform this work on the same morning as moving all the ESX hosts onto a new subnet, or whether to do the Subnet moves HOST by HOST over a few days, and then either BEFORE or AFTER this work I perform the VLAN renumbering.

Anyone done the VLAN renumbering work and got any stories to share or advice to give? (I am posting this on a VMWare forum because ESX hosts are the only ones that have visibility of the VLANs being used, other production servers dont seem to care)

M

[beckham007fifa]

Millardus wrote:

Hi folks, me once more.

Aside from a subnet move I am preparing for (Need to move my 10 node ESX cluster across - Storage and Vmotion can remain the same) , I also have to at some stage renumber the VLANs that are being used for my ISCSI storage, Management Network and Server Subnet.

with this said, what are you going to do? VLAN id change or just the adding a new vlan in the port group?

[millardus]

>> with this said, what are you going to do? VLAN id change or just the adding a new vlan in the port group?

yeah, a bit more thinking and I have decided I can get the VLAN and new Subnet range presented onto the switch port group alongside the 4 existing VLANs in use. This will only be possible for the ESX switch ports though as they are trunked, all the other non-ESX ports are not trunking ports......

That should allow me to test and stage the IP change AND the VLAN renumbering....

As it turns out, my ISCSI adapters on the ESX Hosts DONT have a VLAN tag, so I suspect those ports will be fine. For all NON-ESX switch ports, it'll be a VLAN number CHANGE however as they are not trunked.

[beckham007fifa]

Millardus wrote:

>> with this said, what are you going to do? VLAN id change or just the adding a new vlan in the port group?

yeah, a bit more thinking and I have decided I can get the VLAN and new Subnet range presented onto the switch port group alongside the 4 existing VLANs in use. This will only be possible for the ESX switch ports though as they are trunked, all the other non-ESX ports are not trunking ports......

That should allow me to test and stage the IP change AND the VLAN renumbering....

As it turns out, my ISCSI adapters on the ESX Hosts DONT have a VLAN tag, so I suspect those ports will be fine. For all NON-ESX switch ports, it'll be a VLAN number CHANGE however as they are not trunked.

since its access vlan now, it will need downtime but I would say go one by one with it. First have the management network/vmkernel vlan truncked ( remember to disable HA in the cluster which you are targetting).

Once that is successful, go with iscsi which need downtime for all of your vms. Seems you are aware of these stuffs or do you have any questions again?

P.S. Assuming you have seperate vswitch for management/vmkernel and iscsi.

[millardus]

>> Once that is successful, go with iscsi which need downtime for all of your vms. Seems you are aware of these stuffs or do you have any questions again?

Hmm, I was hoping the ISCSI would not involve any downtime.  Within ESX, the ISCSI Service Console and VMkernel aren't conifgured with a VLANID...would you still expect downtime?

>> P.S. Assuming you have seperate vswitch for management/vmkernel and iscsi.

Yes indeed.

[beckham007fifa]

Millardus wrote:

>> Once that is successful, go with iscsi which need downtime for all of your vms. Seems you are aware of these stuffs or do you have any questions again?

Hmm, I was hoping the ISCSI would not involve any downtime.  Within ESX, the ISCSI Service Console and VMkernel aren't conifgured with a VLANID...would you still expect downtime?

>> P.S. Assuming you have seperate vswitch for management/vmkernel and iscsi.

Yes indeed.

you don't have vlan id for it and you are going for trunking, trunking always need downtime, however if you have already trunked ports and its matter to pass vlan that doesn't need any downtime

[millardus]

>> you don't have vlan id for it and you are going for trunking, trunking always need downtime, however if you have already trunked ports and its matter to pass vlan that doesn't need any downtime

Well, I dont have a VLANID set for the ISCSI Service Console or the VMKernel for ISCSI, these are on Vswitch1 for instance.

What I DO have, on VSwitch0, is a Storage port group that does have the VLANID showing (There is also a Storage Port Group on this switch for Mgmt, Access and a private subnet). These are the ports that have trunking to my knowledge.

I'm now confused and trying to figure out the significance of these 3 things.... the VSwitch1 ISCSI kernel and SC both have IP's on the Storage subnet...so what is the storage port group doing??

Where is my ESX guy when i need him!

[beckham007fifa]

plan1 :

step1.

see, for better result, i would say seggregate the traffic for sc, vmkernel on vswitch0. have this cable truked with your desired vlan id.( don't take downtime of ur vm's)

step2: downtime of the vm's required during the activity.

have your iscsi- storage and vm's on another switch. have it trunked after successful truking of the first one.

What I DO have, on VSwitch0, is a Storage port group that does have the VLANID showing (There is also a Storage Port Group on this switch for Mgmt, Access and a private subnet).


okie, as you said your sc, storage are in same subnet, if its not trunked vms will be also in same subnet. trunk all the required vlans here.

I'm now confused and trying to figure out the significance of these 3 things.... the VSwitch1 ISCSI kernel and SC both have IP's on the Storage subnet...so what is the storage port group doing??


Storage portgroup is your vmkernel portgroup which is to be dedicately made for iscsi configuration where you would be enabling software iscsi and provide your storage ip. iscsi works on ethernet. So, your storage portgroup is for your storage communication.

Another thing

Plan2.

downtime of the vm's required during the complete activity.

Have all of your cables trunked with your all desired vlan ( SC, Vmkernel, Storage vlan) and do the changes in ur switch. Only you have to create vlan portgroups with vlan id on the switches and seggregate them with proper configurations.

[rickardnobel]

Millardus wrote:

What I DO have, on VSwitch0, is a Storage port group that does have the VLANID showing (There is also a Storage Port Group on this switch for Mgmt, Access and a private subnet). These are the ports that have trunking to my knowledge.

I'm now confused and trying to figure out the significance of these 3 things.... the VSwitch1 ISCSI kernel and SC both have IP's on the Storage subnet...so what is the storage port group doing??

There is really no specific type of portgroups called "storage port group", but an ordinary portgroup could be given that name. There are also no need for the Service console to access the iSCSI network, however this was the case back on 3.5, which could have "lived on" on your hosts.

Could you provide a screenshot of the virtual switch setup?

[millardus]

>> There is really no specific type of portgroups called "storage port group", but an ordinary portgroup could be given that name. There are also no need

>> for  .. the Service console to access the iSCSI network, however this was the case back on 3.5, which could have "lived on" on your hosts.

>> Could you provide a screenshot of the virtual switch setup?

The *storage* port group it turns out is something we created in order to directly present some ISCSI storage to a handful of VM's...so that explains *what* it's doing.

VSwitch0 has all the Port Groups, VSwitch1 seems to have ONLY the ISCSI Service Console port and the ISCSI VMKernel port, neither of which has a VLANID assigned to them.

I believe it is the latter 2 that are the ones which COULD have required an ESX cluster outage if they needed to have a VLANID change (Our networks team prefer to change the Physical switch port VLAN numbers in 1 fell swoop).  With them NOT having a VLANID assigned, I'm going to Test on the assumption ESX's ISCSI storage wont care about a physical switch port getting it's VLAN number changed....because it doesn't know or care about the VLANID... sound accurate?

Below is ascreenshot of the config as it appears on 1 of the ESX hosts we have.  This ESX has no VM's on it which need to be in the Storage Port group however.