03-31-2013 01:58 PM
I'm facing weird behavour of HP-UX Virtual Partitions: all vPars are unable to establish any network communication via vswitch their avio_lans attached to, except one.
My host system is B.11.31.1109 HP-UX Data Center Operating Environment (hardware architecture is ia64 if it does matter) with HP-UX Virtual Partitions B.06.00. I've created vswitch attached to physical NIC of the server (not APA (as there's no any), not VLAN), started it and created 3 vPars attached to this switch. As my host server is connected to physical switch with port in trunk mode tagged with several VIDs, I've set all ports of my virtual switch to which vPars are attached to to accept traffic from VLAN where my Ignite-UX server resides (vparnet -s 2 -u portid:1:vlanid:107). I was able to successfully lanboot my first (-p 1) vPar from my Ignite-UX server, but two other vPars weren't able to reach Ignite-UX (all three of them were added to /etc/bootptab on the server beforehand).
Investigating further, using `vparnet -S LAN -p all -A` command, I noticed that counters of all ports except first one, to which is "good" vPar attached, are all zeroes, which means that the problem has nothing to do with physical networking.
I tried following in different combinations:
- reboot vswitch (vparnet -r)
- cold reboot vswitch (vparnet -h & vparnet -b)
- recreation of vPar avio_lan (vparmodify -d & vparmodify -a)
- recreation of vPar itself
but with no luck.
Then I tried to vparmodify both "good" and "bad" vPars to attach the former to "non-working" port of vswitch and latter - to "working" one. And things were still there, meaning that "good" vPar was still reachable via network and "bad" one wasn't able to establish BOOTP session. Output of `vparnet -S LAN -p all -A` was same as before: traffic on port to which "good" is attached to and zeroes on "bad's" one. So I decided that the problem with vPars themselves, but deletion and recreation of them didn't help. Reading of mans and different guides (BTW, I'm confused why there's no any information about vparnet command and/or vswitch entity in HP-UX Virtual Partitions v6.0 Administrator Guide) didn't help either. So now I'm totally out of ideas :(
Are there any relevant logfiles (I'm aware of /var/opt/hpvm/common/command.log, but there's no anything significant there)? Is there any way to compare "good" and "bad" vPars internals?
Any thoughts and suggestions are greatly appreciated.
03-31-2013 02:12 PM
I helped another customer with a very similar problem and it turned out to be a defect with vPars v6.0. The solution was for them to upgrade to a newer version of vPars. Therefore, my suggestion to you would be to update to a newer version of vPars.
vPars v6.0 was really more of a "technology preview" release. There are lots of problems with it and the lab will not release any patches for it. I suggest you upgrade to version 6.1, 6.1.5 or 6.2. All three versions are currently supported.
Each newer version adds more features and bug fixes. You can find the release notes for each version here:
03-31-2013 02:37 PM
I'm sorry for stupid question, but could you provide exact steps to update as I need to resolve this issue ASAP?
Shall I recreate vPars after update? I'm quite new to HP-UX :(
P.S. I got a new idea: the server is physically consists of two Integrity BL870c i2 devices in c3000 chasis with HP 1Gb Ethernet Pass-Thru Module in 1st interconnect bay. Could it be the reason of the problem that only port mapped to Monarch blade is physically connected to the network while one mapped to Auxiliaru blade is not? Shouldn't APA of two of these ports be there which vswitch should be attached to?
03-31-2013 02:44 PM
04-01-2013 02:47 PM
I've successfully updated my server as you suggested using DC-OE_11i_v3_DVD_BA931-10014.iso and DC-OE_11i_v3_DVD_BA931-10015.iso consequently attached to nPar's iLO Virtual Media module with update-ux targeted at mount point of first media (the tool managed umount/mount of media automagically). So now I've got "BB068AA B.06.20 HP-UX vPars & Integrity VM v6". I've noticed slight changes in vPars EFI behaviour and fortunately after recreation of vswitch there's some traffic flowing on other ports than one which "good" vPar is attached to (yes, it's still there and still works as before, I didn't recreate it to have something to compare "bad" vPars to, I didn't update it's OS either). And it looks lawful:
bash-4.2# vparnet -S LAN -p 5 -A Vswitch Name : LAN Max Number of Ports : 512 Port Number : 5 Port State : Active Active VM : azlk Untagged VlanId : 107 Reserved VMs : azlk Adapter : avio_lan Inbound Octets : 3010 Inbound Unicast Pkts (wire) : 0 Inbound Unicast Pkts (local) : 0 Inbound Non-Unicast Pkts (wire) : 6 Inbound Non-Unicast Pkts (local) : 0 Inbound Discards : 186 Outbound Octets : 2950 Outbound Unicast Pkts (wire) : 0 Outbound Unicast Pkts (local) : 0 Outbound Non-Unicast Pkts : 5 Outbound Discards : 0 Tagged VLANs :
The capture represents several (five, I believe) attempts of problem vPar to reach any DHCP/BOOTP server. And I'm totally confused with the result of this communication. If I understand correctly (do I?), vPar did reach some host (which should be Ignite-UX server according to our network design, but why there are Inbound Non-Unicast Pkts then?), and this host in turn did try to answer to it 186 times, but all it's attempts were discarded for unknown reason. Which means that outbound communication vPar->vswitch port->vswitch->physical NIC and further works well while response packets are discarded on vswitch port on their way back. One more confusing thing is Inbound traffic flowing through wire while Outbound doesn't flow neither via wire nor locally (I'm unsure what did authors of vparnet mean using these terms in command output though).
So now the questions are:
1. how to find out the difference between "good" and "bad" vPars?
2. why inbound traffic is being discarded for "bad" vPars?
3. are there any logs for vswitch?
4. may one set debug level for these if they are?
Any suggestions? Thanks in advance.
04-01-2013 02:53 PM
If you haven't updated the OS inside the vPars, have you at least done the following?
- Ensure the OS version is supported to run inside a v6.2 vPar
- Loaded the latest version of the vPar guest kit
- Loaded the latest AVIO storage and networking drivers inside the vPar
- Loaded any required patches (according to the v6.2 release notes) inside the vPar
If you haven't done those steps then you're not really running a supported v6.2 vPar configuration.
04-01-2013 03:17 PM
I got one (first at this nPar) newly created vPar which acts well, where I was able to successfully install OS via our Ignite-UX and which were (before configuring VLANs in guest OS an on vswitch port this vPar is connected to) and is (after vswitch port reconfiguration back to untagged in Ignite VLAN) able to communicate to Ignite-UX server. I'm taking it as example, as communication to it is first what happens just after newly created vPar started and set to boot from LAN.
And I got a couple of newly created vPars without any OS installed. I experience problems booting/installing OS from Ignite-UX (well, actually it appears now that it can't connect back to my "bad" vPars).
So I believe the problem has nothing to do with guest OSes, as new vPars can't communicate to Ignite-UX at EFI lanboot stage. And vPars EFI had to be updated (and they were I believe) along with update of host OS.
Sorry if I didn't clarify that in my previous posts.
04-02-2013 10:36 AM
So let's be as clear as possible on what configuration you have today. My understanding is you currently have:
- VSP running March 2013 Fusion and vPars v6.2
- One vPar that is configured using a virtual switch and was able to successfully boot to your ignite server and load the OS
- Other vPars that are configured identically to the same virtual switch but are not able to boot to your ignite server
Is this accurate? Are there any differences between the working and failing vPars? Are you saying the vPars boot when VLANs are not used but fail when VLANs are used?