Ovirt devel - Jun 2008 - [PATCH] Fix problem where start_vm fails if storage pool is not already active

When a vm is started the existing storage pools on the managed node are
scanned to see if the storage volume that the guest needs is present.
If it is present it is used, if not present it is created and started.

However, there is another case where the pool could be present and
inactive.  In this case (not sure how it gets in this state, but it
could happen) we need to start the pool.

So this code runs if the pool is defined and inactive, it activates

This fixes some bugs seen where the start action in the WUI would
fail silently.

Signed-off-by: Perry Myers <pmyers at redhat.com>
---
 wui/src/task-omatic/task_vm.rb |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/wui/src/task-omatic/task_vm.rb b/wui/src/task-omatic/task_vm.rb
index 12d1b0b..9269a33 100644
--- a/wui/src/task-omatic/task_vm.rb
+++ b/wui/src/task-omatic/task_vm.rb
@@ -339,6 +339,20 @@ def start_vm(task)
         thepool = conn.define_storage_pool_xml(thisstorage.getxml, 0)
         thepool.build(0)
         thepool.create(0)
+      elsif thepool.info.state == Libvirt::StoragePool::INACTIVE
+        # only try to start the pool if it is currently inactive; in all other
+        # states, assume it is already running
+        begin
+          thepool.create(0)
+        rescue
+          # this can fail, for instance, if the remote storage that the user
+          # put in is not actually available.  We just return here with a
failure;
+          # there's not a lot more we can do
+          setTaskState(task, Task::STATE_FAILED,"Could not create storage
volume")
+          conn.close
+          errmsg = "Unable to activate storage volume"
+          raise
+        end
       end
 
       storagedevs <<
thepool.lookup_volume_by_name(volume.read_attribute(thisstorage.db_column)).path
-- 
1.5.5.1

On Thu,  5 Jun 2008 01:49:56 -0400
Perry Myers <pmyers at redhat.com> wrote:
> When a vm is started the existing storage pools on the managed node are
> scanned to see if the storage volume that the guest needs is present.
> If it is present it is used, if not present it is created and started.
> 
> However, there is another case where the pool could be present and
> inactive.  In this case (not sure how it gets in this state, but it
> could happen) we need to start the pool.
> 
> So this code runs if the pool is defined and inactive, it activates
> 
> This fixes some bugs seen where the start action in the WUI would
> fail silently.
> 
> Signed-off-by: Perry Myers <pmyers at redhat.com>
> ---
>  wui/src/task-omatic/task_vm.rb |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/wui/src/task-omatic/task_vm.rb
b/wui/src/task-omatic/task_vm.rb
> index 12d1b0b..9269a33 100644
> --- a/wui/src/task-omatic/task_vm.rb
> +++ b/wui/src/task-omatic/task_vm.rb
> @@ -339,6 +339,20 @@ def start_vm(task)
>          thepool = conn.define_storage_pool_xml(thisstorage.getxml, 0)
>          thepool.build(0)
>          thepool.create(0)
> +      elsif thepool.info.state == Libvirt::StoragePool::INACTIVE
> +        # only try to start the pool if it is currently inactive; in all
other
> +        # states, assume it is already running
> +        begin
> +          thepool.create(0)
> +        rescue
> +          # this can fail, for instance, if the remote storage that the
user
> +          # put in is not actually available.  We just return here with a
failure;
> +          # there's not a lot more we can do
> +          setTaskState(task, Task::STATE_FAILED,"Could not create
storage volume")
> +          conn.close
> +          errmsg = "Unable to activate storage volume"
> +          raise
> +        end
>        end
>  
>        storagedevs <<
thepool.lookup_volume_by_name(volume.read_attribute(thisstorage.db_column)).path
> -- 
> 1.5.5.1
Very nice!  ACK

    Ian