Operating System - HP-UX
1748151 Members
3763 Online
108758 Solutions
New Discussion юеВ

vPars fail to communicate via vswitch

 
WereWolf
Collector

vPars fail to communicate via vswitch

Greetings, Community.

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.

7 REPLIES 7
Dave Olker
HPE Pro

Re: vPars fail to communicate via vswitch

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:

 

http://www.hp.com/go/hpux-vpars-docs

 

 

Dave

I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
WereWolf
Collector

Re: vPars fail to communicate via vswitch

Thanks, Dave.

 

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?

Dave Olker
HPE Pro

Re: vPars fail to communicate via vswitch

The easiest way to update to the newer version of vPars is to update to a newer version of HP-UX. vPars v6.1 shipped with the March 2012 Fusion release, v6.15 shipped with the September 2012 Fusion and v6.2 recently shipped with the March 2013 Fusion. I would update the VSP (hypervisor) to one of these newer Fusion releases and then update the OS inside the vPar guests to the same version along with any recommended patches (check the release notes for required patches for each version of vPars).

Dave
I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
WereWolf
Collector

Re: vPars fail to communicate via vswitch

Hi Dave,

 

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.

Dave Olker
HPE Pro

Re: vPars fail to communicate via vswitch

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.

 

Dave

I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
WereWolf
Collector

Re: vPars fail to communicate via vswitch

Dave,

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.

Dave Olker
HPE Pro

Re: vPars fail to communicate via vswitch

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?  

 

Dave

I work for HPE

[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo