Thanks for the report.

Based on your problem description, I have ascertained it's worse than you
reported.  Even if libvirt did build the pool, it would still error out if
the pool was inactive or undefined yet still existing.

So I made two changes:
-If activating a pool that already exists is lvm backed, skip build since
it's unlikely that an inactive LVM pool would make it that far without
actually existing.
-If creating a new pool, eval the build and catch the two errors that
suggest the storage pool already existed and ignore them.

I took the libvirt doc on build to suggest that it will build if not
existing and silently skip if it does exist.  lvm is the first pool to
break that expectation.

While I was at it I fixed the Sys::Virt version check to work even after a
centos 6.4 upgrade.

commit d2be359f844110daecc91b4954947aadc4ea1217
Author: Jarrod Johnson <[email protected]>
Date:   Fri Mar 15 15:39:48 2013 -0400

    Correct Sys::Virt version check
    Fix broken LVM behavior when faced with a pre-built LVM VG/PV (as
reported by Michael Fenn)

diff --git a/xCAT-server/lib/xcat/plugins/kvm.pm
b/xCAT-server/lib/xcat/plugins/kvm.pm
index 84db86a..393848e 100644
--- a/xCAT-server/lib/xcat/plugins/kvm.pm
+++ b/xCAT-server/lib/xcat/plugins/kvm.pm
@@ -40,7 +40,7 @@ my $confdata; #a reference to serve as a common pointer
betweer VMCommon functio
 my $libvirtsupport;
 $libvirtsupport = eval {
     require Sys::Virt;
-    if (Sys::Virt->VERSION < "0.2.0") {
+    if (Sys::Virt->VERSION =~ /^0\.[10]\./) {
         die;
     }
     1;
@@ -176,6 +176,7 @@ sub get_storage_pool_by_url {
     push @currpools,$virtconn->list_defined_storage_pools();
     my $poolobj;
     my $pool;
+    my $islvm=0;
     foreach my $poolo (@currpools) {
         $poolobj = $poolo;
         $pool = $parser->parse_string($poolobj->get_xml_description());
#XMLin($poolobj->get_xml_description());
@@ -206,6 +207,7 @@ sub get_storage_pool_by_url {
            my $vgname = $1;
            my $checkname = $pool->findnodes("/pool/name/text()")->[0]->
data;
            if ($checkname eq $vgname) {
+               $islvm=1;
                last;
            }
         } elsif ($pool->findnodes('/pool/name/text()')->[0]->data eq $url)
{ #$pool->{name} eq $url) {
@@ -216,7 +218,7 @@ sub get_storage_pool_by_url {
     if ($pool) {
         my $inf=$poolobj->get_info();
         if ($inf->{state} == 0) { #Sys::Virt::StoragePool::STATE_INACTIVE)
{ #if pool is currently inactive, bring it up
-            $poolobj->build();
+            unless ($islvm) { $poolobj->build(); } #if lvm and defined,
it's almost certainly been built
             $poolobj->create();
         }
        eval { #we *try* to do this, but various things may interfere.
@@ -226,7 +228,13 @@ sub get_storage_pool_by_url {
         return $poolobj;
     }
     $poolobj = $virtconn->define_storage_pool(build_pool_xml
($url,$mounthost));
-    $poolobj->build();
+    eval { $poolobj->build(); };
+    if ($@) {
+       my $error = $@;
+       unless ($error =~ /vgcreate.*exit status 3/ or $error
=~ /pvcreate.*exit status 5/) {
+               die $@;
+       }
+    }
     $poolobj->create();
     eval { #wrap in eval, not likely to fail here, but calling it at all
may be superfluous anyway
        $poolobj->refresh();


From:   Michael Fenn <[email protected]>
To:     [email protected]
Date:   03/11/2013 11:42 AM
Subject:        [xcat-user] xCAT patch to support pre-existing lvm volume
            groups as   pools



I attempted to use the new xCAT 2.8.0 lvm:// pseudo-URI syntax for
specifying the vmstorage attribute, but discovered that it fails on mkvm
if you try to use an existing LVM volume group, eg.

$ chdef mynode vmstorage="lvm://vm"
$ mkvm mynode -s 100G
... error relating to failure running vgcreate ...

Obviously, vgcreate will (and should) fail upon trying to create an
volume group that already exists.  After some trial and error, I
discovered the call that prompts libvirt to call vgcreate is
$poolobj->build() in kvm.pm.  Avoiding that call allows everything to
work as expected.

In order to determine whether or not to call build(), my patch checks to
see if the user specifies any block devices for physical volumes in the
lvm:// URI.  If they didn't provide any, it assumes that the volume
group already exists and that it should not call build().  This is safe
because the call to build() (and thus vgcreate) cannot possibly succeed
without any physical volumes.  Conversely if the given volume group does
not exist, the call to mkvm will fail as before, though with a slightly
different reason given.

Side note, why would I want to do this?  The alternative is to specify
the physical volume that make up the LVM volume group in the lvm:// URI
for every VM (either directly or via a group).  This is bad because it
ruins the abstraction of LVM as a generic storage resource pool by
forcing each VM object to know about the physical composition of the
volume group

Michael
[attachment "xcat-kvm-support-preexisting-lvm-pools.patch" deleted by
Jarrod B Johnson/Raleigh/IBM]
------------------------------------------------------------------------------

Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user

<<inline: graycol.gif>>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user

Reply via email to