Hi,
I'm trying to make sense of this bug and what it really is about as well as 
what exactly one could analyze and action on.

So you had an LVM with a volume group, a bunch of Physical Volumes (PV)
and a Volume Group (VG) composed of these. And finally the Logical
volumes (LV) that are carved out of that VG.

Like:
[PV * x] -building-> [ VG ] -carved-into-> LVs

Throwing multipath into the mix you'd usually have the PVs being multipathed 
disks.
So you would have:
[Disk * y] -mathed-> [Mpathdevice] -being-> [PV * x] -building-> [ VG ] 
-carved-into-> LVs

An example of such a config from my system looks like this:
PVs:
- 4 DASDs building VG "LVMpool"
- 2 FCP disks with 4 paths each into mpath disks
- Those two mpath disks building VG "vgdisks"
- vgdisks defining LVs: lv_var and lv_tmp
- LVMpool defining one LV "testlvm"
- Note that LVMPool is one defined by libvirt and vgdisk a "manual" LVM config

You can grab all that config if you want to share via:
$ sudo vgcfgbackup -f "/home/ubuntu/vg-%s.cfg"
  Volume group "vgdisks" successfully backed up.
  Volume group "LVMpool" successfully backed up.
$ sudo lvm dumpconfig > /home/ubuntu/lvm.dumpconfig
$ sudo multipath -ll > ~/mp.config
$ sudo multipath -t > mp.config 
$ sudo multipath -ll > mp.overview


I attached mine for comparison.

Now lets get to your request, you said:
- "After Ubuntu upgrade following problem occur"

  Upgrade from which to which Ubuntu version?
  Upgrade from which to which Package version(s)?

- "volumes in the libvirt volumegroup no longer has an lvm2 signature
for some reason"

  That makes no sense, it would mean that the LV carved out of the VG has no 
LVM signature.
  But the LV is just a device it has no lvm related metadata.
  PVs get a little metadata on disk and a VG saves it's config on all PVs it is 
composed of.
  What exactly was lost in your case - did someone overwrite one of your PVs?
  Essentially, what exactly was overwritten?

- "libvirt has been removed from /etc/fstab already"

  Sorry, but what - it makes no sense to me yet?
  What setup did you have to have "libvirt in fstab"?
  Is the fact that libvirt is in the mix is at all important to the issue you 
are describing?

- "Persistence in naming is lost"

  Did you set up custom naming rules in /etc/mutlipathd.conf ?
  With user-friendly-names this will be mpath[N]... did you mean these?
  Without user-friendly-names it will be based on the WWID only changing
  when well the WWID changes.
  Or did you have custom alias<->WWID mappings for special names in the conf 
file?
  What exactly is "lost" what did you have before what do you see now?

- "/ gets mounted, but /boot fails to mount because of the change in
naming"

  It should be mounted via UUID by default, did the UUID change?

- "I can successfully mount /boot by UUID instead."

  Well ok, mount via UUID would have been the default any reasons this
was changed?

- "While a corrupted volume is a corrupted volume, I would have expected the
  multipather to handle it more gracefully and not impacted other LUNs in this 
way."

  Does multipathd show any error messages due to that change?
  Default config for user friendly names didn't change in /etc/multipath.conf - 
why was it lost?
  Do you have no user friendly names at all now?
  What do you have left in /dev/mapper/ ?


Please:
- report your config in detail (gathered as I outlined above).
- Answer all the questions above
- add as much as you can to help people understand your setup/scenario scenario

Otherwise is is a complaint/rant and not an actionable bug.

P.S. I almost all cases of similar reports it turned out to be an issue
with the local configuration, so please outline in detail what you have,
you had and what happened in between. In many cases to be actionable it
is required to break the complex scenarios down into something that can
be recreated in a clean environment e.g. a KVM guest - so if there is
any chance to do so please do it and add the steps to recreate based on
that.

** Attachment added: "example config of MP+LVM"
   
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1867620/+attachment/5337829/+files/lvm-mp.cfg.tar.gz

** Changed in: multipath-tools (Ubuntu)
       Status: New => Incomplete

** Changed in: multipath-tools (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867620

Title:
  Failure after Ubuntu upgrade - libvirt volumegroup no longer has an
  lvm2 signature

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1867620/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to