Move Service Console Switch during Kickstart

[Stuarty1874]

Guys, during a manual build of ESX 3.x I would usually select the second onboard NIC to act as the Service Console and it would therefore be named VMNIC0.

I then set my VMOTION to use the primary onboard NIC and name it VMNIC1

When I use a scripted install, the KS.CFG creation wizard doesn't allow me to select or manipulate the NICs.

So I therefore do the following...

During my POSTINST section of my KS.CFG file, I use the following command to switch the Service Console and VMOTION NICs.

esxcfg-vswitch -U vmnic0 vswitch0

esxcfg-vswitch -L vmnic1 vswitch0

This sucessfully transfers the NICs and everything works fine and the Service Console is connected as vmnic1 and vmotion is connected as vmnic0

What I want to do though is change the vmnic label on both the nics so that the Service Console is connected vmnic0 and vmotion as vmnic1

Any ideas of a command that I can issue to either...

Have the build select the second NIC during install and assign it as vmnic0

or change the vmnic lableling after the base build has completed and during the post stage of the build.

Thanks

[Yattong]

Check the forum for other scripts that are available.

What I have done to specify a Nic I want to use for service console is to add '--device eth4' change the eth4 to the correct nic number.

#Network install type

network --device eth4 --bootproto static --ip x.x.x.x --netmask x.x.x.x --gateway x.x.x.x...............

This should also re-label the nics automatically.

My script is on thread

Good Luck

[Stuarty1874]

Thanks. Not sure if I fullly understand..

I'm using a HP DL585 G1 and my onboard NICs are labelled as PCI 02:06.0 and PCI 02:06.1

How do I assign PCI 02:06.1 to the Service Console using the command below, giving it the label vmnic0?

#Network install type

netwok --device ethX --bootproto static --ip x.x.x.x --netmask x.x.x.x -- gateway x.x.x.x

Is there a way to translate PCI 02:06.1 into the ethX ??

[Yattong]

Usually it will default to eth0.

You have 2 nics, I'm guessing the other one will be eth1

There is a way to find out which nic is which eth, and that is by triggerring a ftp/http install.

By not entering an IP address for the nic, or having DHCP working (correctly for the installer), then you will get a prompt screen to pick a nic/eth and to enter ip address.

This is where you will see what nic = eth.

Good Luck

[Stuarty1874]

Ok...

I've added the following entry to my config

network --device eth1 --bootproto static --ip x.x.x.x --netmask 255.255.252.0 --gateway x.x.x.x --nameserver x.x.x.x --hostname esx01.test.net --addvmportgroup=0

This now assigns the secondary onboad NIC as desired and configures it as vmnic0.

I then added the following to the POST section of my script

esxcfg-vswif -i x.x.x.x -n 255.255.252.0 vswif0

esxcfg-vswif -E vswif0

sleep 20

What I've found though is that the during the initial boot of the host the vmnic0 has no IP details and starts to porduce a few errors. The script then does configure vmnic0 with the correct IP address using the esxcfg-swif config during POST and then everything appears to work ok.

Then after the host has finished booting I get the following message at the F1 logon screen.

0:00:00:31. 617 cpu6: 1037) Init: 1586 : Invalid vmkernal id 0. Error in network configuration. VMFS2 distibuted locking might not work.

I can ping the Service Console and connected no problem.. but somethings wrong.

I foudnd this KB article...

Its all to do with the Service Console not getting any IP details when its booting. I can't understand why that would happen as I specifically issue the correct IP details in the script.

Any help would be much appreciated.... as I'm lost to explain why this is.

[Yattong]

Brilliant... Im so glad Im not the only one who gets these errors.

Check your /etc/host file

You will notice that your host is not included in this file. Once you add it, reboot and the error should disappear.

If you look at my script, you will see in the %post a section where I echo the hostname into that particular file.

Why is the error code completely out of synch of what the actual problem is, I have no idea!!!

Good Luck

[Stuarty1874]

Thanks Yattong. I noticed that you did update the etc/host file in your script but didn't think to check why.

Will check this out when I get back in to the office tomorrow.

Hope this works.

[Yattong]

cool,

for some reason, after much research and trouble-shooting. Ive just gave up on finding the reason why the nic or eth1 gets disabled and just scripted the fix.

I spoke to a vmware techy before xmas, and lets just say hes not too happy with the ppl who have just bunged the redhat/anaconda installer in with the esx cd.

Good luck with the install.

If you've found any of the comments helpful please allocate the points accordingly.;)

[stvkpln]

I noticed you're using DL585 G1's, so I thought I'd point out (since I know why you're doing this!) that the issue that existed in ESX 2.5.x with HP issuing a warning to not use the first onboard port for the service console is no longer an issue with VI3. Therefore, you're going to a lot of extra effort for an issue that isn't there anymore... Frankly, I'd think you'd be better off taking two NIC's, binding them to vSwitch0, then having both your SC and vmkernel interfaces on that vSwitch. More robust, higher level of redundancy, and you can configure (check through the thread pasted) so that the SC uses one NIC preferred, the vmkernel uses the other.. With the networking improvements in VI3, I don't know why you'd even want to not have that extra redundancy in there...

Just my $0.02..

[Yattong]

Diztorted, what you say is true.

If you only have 2 nics then why not just keep the SC on nic 1?

The problem I had, was that I had 4 more nics on pci cards and was unable to re-order the post/esx cd to initialise the onboard nics before the expansion ones.

[Stuarty1874]

Ahh... on the money!

This is exactly the reason for me wanting to move the Service Console NIC to onboard NIC 2 (eth1).

Could you provide a link to any documentation from either HP or VMware which confirms that this "work around" is no longer required when using ESX 3x?

I definatley believe what you're saying and it make my like so much easier.. but its always nice to have a note from the vendor confirming their status on the issue.

Thanks