Bug 486994 - RFE: Improve error message if unable to activate lv due to tags.
RFE: Improve error message if unable to activate lv due to tags.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
5.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Rajnoha
Cluster QE
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-23 11:21 EST by Dean Jansa
Modified: 2011-01-13 17:39 EST (History)
10 users (show)

See Also:
Fixed In Version: lvm2-2.02.73-1.el5
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-13 17:39:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dean Jansa 2009-02-23 11:21:40 EST
Description of problem:

I had tagging set up on my cluster, and attempted to create a volume as:

[root@z2 ~]# lvcreate -n lv -L 10G name
Aborting. Failed to activate new LV to wipe the start of it

Could the error message reflect the fact that lvcreate failed due to a tag conflict?  The above error message sent me searching for untold errors/issues until I realized that it was due to a leftover tag from testing.
Comment 1 Peter Rajnoha 2009-06-01 07:15:48 EDT
If you define a tag, that's another namespace prefixed by '@'. It should not conflict with proper LV/VG names so I think the LV activation failure should not be caused by tagging.

Could you be more specific in the definition of "tag conflict"? Does it really mean that only removing existing tag caused the lvcreate command to succeed?
Comment 2 Corey Marthaler 2009-12-23 13:24:19 EST
This was absolutely caused by the left over tag. When you have a tag such as
this for HA LVM, all activation will fail unless you have that tag in the VG.

volume_list = [ "VolGroup00", "@node_name" ]

A customer has run into this issue now as well. We need an actual error saying
something like "Hey dummy, we can't activate this volume because it doesn't
have the proper tag".

Besides, what does, "Failed to activate new LV to wipe the start of it" even
mean? It's not even proper English.
Comment 3 Peter Rajnoha 2010-01-04 06:25:38 EST
Ah, I see...

Actually there's one line in verbose output related to this that says:

 "Not activating vgname/lvname due to config file settings"

It does not give much help in this situation anyway, I have to admit :) The strange looking error message about failed activation and wipe is just a consequence of failing the activation filter (..first few sectors of new LVs are wiped with zeroes).

OK, I'll have a look if we can make the messages less confusing here...
Comment 5 Alasdair Kergon 2010-07-09 16:32:06 EDT
It's hard to be specific without generating warnings when people don't want them - verbose-level is probably right.  (Two independent parts of the code are involved.)

Changing the original message to mention it might be due to tags should be fine.

It could actually check if activation/volume_list is defined and give a second message if it is.  "This may be due to the volume_list setting in the activation section of your lvm configuration."
Comment 6 Peter Rajnoha 2010-07-12 07:46:32 EDT
OK, I've added a few messages:

If activation/volume_list IS NOT defined:

"activation/volume_list configuration setting not defined, checking host tags only"
...
"No host tag matches <vgname>/<lvname>"


If activation/volume_list IS defined:

"activation/volume_list configuration setting, defined, checking the list to match <vgname>/<lvname>"
...
"No item supplied in activation/volume_list configuration setting matches <vgname>/<lvname>"


That should provide enough info about what's going on and people should be able to trace the problem easily. The messages are seen in verbose output with "-v" now.

(scheduled for upstream release v2.02.71)
Comment 7 Milan Broz 2010-08-30 06:39:32 EDT
Fix in lvm2-2.02.73-1.el5.
Comment 9 Corey Marthaler 2010-11-02 16:29:31 EDT
Seems like the same error message still appears in lvm2-2.02.74-1.el5.

    volume_list = [ "VolGroup00", "@node_name" ]

[root@taft-01 ~]# lvcreate -m 1 --corelog -n mirror2 -L 1G taft
  Aborting. Failed to activate new LV to wipe the start of it.
Comment 10 Peter Rajnoha 2010-11-03 04:55:34 EDT
(In reply to comment #9)
> Seems like the same error message still appears in lvm2-2.02.74-1.el5.
> 
>     volume_list = [ "VolGroup00", "@node_name" ]
> 
> [root@taft-01 ~]# lvcreate -m 1 --corelog -n mirror2 -L 1G taft
>   Aborting. Failed to activate new LV to wipe the start of it.

There's more info in verbose output:

   lvcreate -m 1 --corelog -l 1 vg -vvv

    ...
    activation/volume_list configuration setting defined, checking the list item to match vg/lvol0
    activation/volume_list configuration setting defined, checking the list item to match vg/lvol0
    No item supplied in activation/volume_list configuration setting matches vg/lvol0
    Not activating vg/lvol0 due to config file settings
  Aborting. Failed to activate new LV to wipe the start of it. 

(...hmm, maybe I should add what is being checked in the "checking the list item" message - which volume_list item)

But I kept the last message "Aborting. Failed to activate new LV to wipe the start of it." Or do you want to reformulate it?

(I like this wording bugs... :))
Comment 11 Peter Rajnoha 2010-11-03 05:07:29 EDT
If it's an LV that doesn't need to be wiped, there's only a message:
   
  "Failed to activate new LV."

If that LV needs to be wiped in addition, we show a more detailed error message:

  "Failed to activate new LV to wipe the start of it."

(So we can decide on code path that is problematic when debugging. But yes, maybe the sentence sounds a little bit strange :))
Comment 12 Corey Marthaler 2010-11-03 15:28:34 EDT
This bug is about improving the current error message, so I'm surprised that it hasn't changed at all, or that there was confusion about whether or not the fix should change it. Also, I don't think the verbose messages really give that much more information. 

In a perfect world, I think that if the volume can't be created/activated because it's VG doesn't have the proper tag, then the error message should reflect that. Something like "Unable to create/activate logical volume due to improper or missing VG tag." I realize that is easier said than done based on lvm activation logic.

The fact remains that "Failed to activate new LV to wipe the start of it." is not proper english (not that all errors need to be) and doesn't actually mean anything. It's gibberish.
Comment 13 Peter Rajnoha 2010-11-05 09:01:45 EDT
Well, we use exactly the same check for testing only (not necessarily failing) the activation so changing these verbose messages into error messages is not a good idea.

However, I'd probably leave out the "..to wipe the start of it" part of the error message since this has no information gain for a user. Also, I'd change one message from verbose to error level. So now, when the activation filter (which is hosttags or activation/volume_list) fails, we will show:

# lvcreate -l1 vg1
Not activationf vg1/lvol1 since it does not pass activation filter.
Failed to activate new LV.


If the user wants to know more info, he can just use verbose level:

# lvcreate -v -l1 vg1
...
  Found volume group "vg1"
    activation/volume_list configuration setting defined, checking the list to match vg1/lvol1
    No item supplied in activation/volume_list configuration setting matches vg1/lvol1
  Not activating vg1/lvol1 since it does not pass activation filter.
  Failed to activate new LV.
...

So is this error/verbose scheme acceptable? There's nothing else to report, I think - activation fails because it does not pass activation filter and that one fails either because of the "host tags" or firm activation/volume_list setting.

(I can't put all the info in one error message - there could be even more causes of the activation failure and, at the same time, we reuse some parts of the code for testing only whether it passes some condition or not, not failing.)
Comment 15 Peter Rajnoha 2010-11-05 09:23:30 EDT
(In reply to comment #13)
> # lvcreate -l1 vg1
> Not activationf vg1/lvol1 since it does not pass activation filter.

"Not activating...", of course...
Comment 16 Peter Rajnoha 2010-11-05 09:34:42 EDT
(In reply to comment #12)
> Something like "Unable to create/activate logical volume due to
> improper or missing VG tag."

Hmm, it's fine to have improper or missing VG tag, we can still define VG itself or VG/LV directly in the activation/volume_list. I think the verbose messages are just fine - they're pointing the user to check exactly the place we need and then he should make any corrections if needed.
Comment 17 Corey Marthaler 2010-11-05 12:25:04 EDT
The suggestion in comment #15 works for me, anything is better than "to wipe the start of it."
Comment 18 Peter Rajnoha 2010-11-05 14:19:26 EDT
OK, checked in (2.02.76).
Comment 19 Milan Broz 2010-11-09 08:58:03 EST
And in lvm2-2.02.74-2.el5.
Comment 21 Corey Marthaler 2010-11-10 16:18:08 EST
Fix verified in lvm2-2.02.74-2.el5.

[root@taft-01 ~]# lvcreate -m 1 --corelog -n mirror2 -L 1G taft
  Not activating taft/mirror2 since it does not pass activation filter.
  Failed to activate new LV.
Comment 23 errata-xmlrpc 2011-01-13 17:39:47 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0052.html

Note You need to log in before you can comment on or make changes to this bug.