I found a few things, for one SQL needs to be configured for Native SQL Client DSN (I had to reconfigure the DSN). Then it will upgrade the database schema.
Then this takes quite a long time to upgrade the database. That's all I found for now.
[11:27a EST - The VIM (Virtual Infrastructure Management) install was fine. Everything looks good for client install (Vista 32-bit)
3.5 Server I upgraded one of my servers, and I had invalid sda (even thought it boots fine with 3.02). I tried upgrading, no good. I am now doing a NEW install (retaining current VMFS configurations). Looks like I will be here a while cleaning up .. but hey, at least I can test 3.5.
Has anyone figured out how to get all of your vmnics into the active list yet short of manual intervention?
Yea I have been beating my head looking for this answer also
I'm pretty sure it's a bug. I've asked my TAM to see if he can ask someone internal to VMware to see if they have a workaround. Will you send me an email if you find a solution before I do?
I'm also contacting my TAM about this.
Lets see who comes up with the code first!!! Let the race begin
I don't have a TAM... -sniff-
Seriously though, I spent most of yesterday messing around with this. I tried all sorts of combinations using vimsh, esxcfg-* and even some scripts I found buried in the bowels of ESX. Nothing seems to work, but I can't help but feel that the -string- expected by vimsh isn't accepting a list of nics. Kind of like if a reg_multi_sz registry setting was mistakenly configured as reg_sz. Eh, who knows...
My money is on Beaver.
Jason Boche
VMware Communities User Moderator
My money is on Beaver.
Jason Boche
VMware Communities User Moderator
Thems fighting words.
Gosh sorry dominic - I didn't even see you were in on this thread. I'm a bit absent minded tonight and very tired. Sorry about that!
Jason Boche
VMware Communities User Moderator
vswitch0 seems to configure the adapters as active standby, then the portgroups works as how I configure them....working on getting vswitch0 as active/active and the portgroups as active/standby
I may have a work around I am going to give a try now. One last thing I added to do once the switch is set and configured is to unlink the 2 pNics and then re-link them
Steve Beaver
VMware Communities User Moderator
*Virtualization is a journey, not a project.*
It's really strange to hear you guys are having these problems. What versions did you upgrade from? Everything here went smooth as glass, and my nics weren't changed at all. Everything is still setup in active/active with auto negotiate/status connected. If it's a bug, I don't think it's a pandemic.
Did you guys all upgrade from 3.0.2?
Did you upgrade or do a fresh install?
If we can compile some common variables (no pun intended!! HAR!) maybe we can sort out what is causing this problem for you guys.
These are new installs (at least for me).
At my company, we rarely patch anything but production database servers. Instead, we invest a ton of time into tools to make autoinstalls possible. At this point, its faster for me to kick off an autoinstall of an app server (takes about 7 minutes) than diagnose a problem with it.
I'm trying to get to the same point with ESX hosts , and aprt of that is getting fully automated installs (and configuration) working. I'm most of the way there - this NIC thing is holding me back.
Isn't that ironic? I did upgrades here, and I couldn't be any happier. Like you, I always went for a clean, trouble free install. I think Microsoft taught a lot of us that back in 95 with their fantastic operating systems. (Ok THAT was sarcasm) But this is why I brought it up.. my hunch is there is code that puts the nics in active/standby during the detection process of a new install. In an upgrade, the vmnic configuration isn't messed with. Can we get some more people to confirm this?
Mine are also fresh installs and the issue is esxcfg-vswitch when creating a network from scratch for me. It when linking 2pNics on a switch ESX sets them up Active / Standby
Steve Beaver
VMware Communities User Moderator
*Virtualization is a journey, not a project.*
These are fresh installs. Ugrades wouldn't (shouldn't!) be affected by this.
I have this working will post tomorrow - 100% WORKING
If you can post sooner, I'll check it out & test WAY early in the morning. I'm 8 hours ahead of the East coast. If you found it, you deserve some points!
Zippy found one work around and I have found another...
Check out code and information below
setConsoleNIC()
{
echo "Deleting current network configuration" >> /root/PostInstall/PostInstall.log
/usr/sbin/esxcfg-vswitch vSwitch0 -D "VM Network"
/usr/sbin/esxcfg-vswitch -U vmnic0 vSwitch0
/usr/sbin/esxcfg-vswitch -U vmnic1 vSwitch0
/usr/sbin/esxcfg-vswif -d vswif0
/usr/sbin/esxcfg-vswitch -d vSwitch0
service mgmt-vmware restart
echo "Reconfiguring Service Console NIC..." >> /root/PostInstall/PostInstall.log
cp /etc/vmware/esx.conf /tmp/post/esx.conf.bak
/usr/sbin/esxcfg-vswitch -a vSwitch0
/usr/sbin/esxcfg-vswitch vSwitch0 -L vmnic0
/usr/sbin/esxcfg-vswitch vSwitch0 -L vmnic1
/usr/sbin/esxcfg-vswitch -A "Service Console" vSwitch0
/usr/sbin/esxcfg-vswitch vSwitch0 -p "Service Console" -v 0
/usr/sbin/esxcfg-vswif -a vswif0 -p "Service Console" -i $SCIP -n 255.255.255.0
route add default gw $DGW
echo "GATEWAY=$DGW" >> /etc/sysconfig/network
/usr/sbin/esxcfg-vswitch -U vmnic0 vSwitch0
/usr/sbin/esxcfg-vswitch -U vmnic1 vSwitch0
/usr/sbin/esxcfg-vswitch vSwitch0 -L vmnic0
/usr/sbin/esxcfg-vswitch vSwitch0 -L vmnic1
service mgmt-vmware restart
sleep 20
vimsh -n -e "hostsvc/net/vswitch_setpolicy --nicorderpolicy-active vmnic0 vSwitch0"
vimsh -n -e "hostsvc/net/vswitch_setpolicy --nicorderpolicy-active vmnic0,vmnic1 vSwitch0"
}
Notice what is in bold. I added an unlink and re-link of the nics to the virtual switch. This left both nics currently in Active / Active state
r
VMware Communities User Moderator
*Virtualization is a journey, not a project.*
This process, while silly, worked for me as well.
I still consider this a bug.