Bug 1280496

Description of problem:

Went setting the maximum number of PVs that can be added to a VG the behavior is inconsistent.

If I do (2**32-1)...
# vgchange -p 4294967295 foo
Volume group "foo" successfully changed

It reports 
# vgs -o+max_pv
  VG   #PV #LV #SN Attr   VSize  VFree  MaxPV     
  foo    1   0   0 wz--n- 18.00g 18.00g 4294967295

which look fine

If I do (2**32)
# vgchange -p 4294967296 foo
Volume group "foo" successfully changed

It reports
# vgs -o+max_pv
  VG   #PV #LV #SN Attr   VSize  VFree  MaxPV
  foo    1   0   0 wz--n- 18.00g 18.00g     0

Which seems reasonable I guess as '0' == unlimited, lvm could reject the value too.

However, when I do (2**64-1)
# vgchange -p 18446744073709551615 foo
  Volume group "foo" successfully changed

I get
# vgs -o+max_pv
  VG   #PV #LV #SN Attr   VSize  VFree  MaxPV     
  foo    1   0   0 wz--n- 18.00g 18.00g 4294967295

Which seems inconsistent based on the previous behavior

If I do (2**64) I get
# vgchange -p 18446744073709551616 foo
  Invalid argument for --maxphysicalvolumes: 18446744073709551616
  Error during parsing of command line.

Version-Release number of selected component (if applicable):

LVM version:     2.02.132(2) (2015-09-22)
Library version: 1.02.109 (2015-09-22)
Driver version:  4.33.0


How reproducible:

Always

Steps to Reproduce:

See above

Actual results:

Inconsistent behavior

Expected results:

Either we should reject the value when it's too big or we set it to '0' when it overflows a uint32_t.

Additional info: