[libvirt] [test-API][PATCH] Add new case for listAllVolumes and update releated conf

[Cong Dong]

----- Original Message -----
> From: "Guannan Ren" <gren at redhat.com>
> To: "codong" <codong at redhat.com>
> Cc: libvir-list at redhat.com
> Sent: Thursday, December 12, 2013 11:57:31 AM
> Subject: Re: [libvirt][test-API][PATCH] Add new case for listAllVolumes and update releated conf
> 
> On 2013年12月12日 10:13, codong wrote:
> > listAllVolumes is a new API in RHEL7, so add a new case for it.
> > And add the case to releated conf to check the volumes list.
> >
> > 	modified:   cases/storage_dir.conf
> > 	modified:   cases/storage_dir_vol_resize_delta.conf
> > 	modified:   cases/storage_logical.conf
> > 	modified:   cases/storage_netfs.conf
> > 	new file:   repos/storage/list_volumes.py
> > ---
> >   cases/storage_dir.conf                  |   16 +++++
> >   cases/storage_dir_vol_resize_delta.conf |    8 +++
> >   cases/storage_logical.conf              |   16 +++++
> >   cases/storage_netfs.conf                |   16 +++++
> >   repos/storage/list_volumes.py           |   97
> >   +++++++++++++++++++++++++++++++
> >   5 files changed, 153 insertions(+), 0 deletions(-)
> >   create mode 100644 repos/storage/list_volumes.py
> >
> >
> 
> The testcase works for the pool of dir type only.
> If you want to test pool of all type in one testcase, the testcase is
> not good enough obviously.

The pool will be mappeed to the local filesystem , so I can check the
volumes list in the pool path as a dir type, right?

Info from libvirt.org/formatstorage.html#StoragePoolTarget

Target elements in storage xml is used to describe the mapping of the 
storage pool into the host filesystem. "path" is one of the  child 
elements.

path
    Provides the location at which the pool will be mapped into the 
local filesystem namespace. For a filesystem/directory based pool it
 will be the name of the directory in which volumes will be created. 
For device based pools it will be the name of the directory in which 
devices nodes exist. For the latter /dev/ may seem like the logical 
choice, however, devices nodes there are not guaranteed stable across 
reboots, since they are allocated on demand. It is preferable to use 
a stable location such as one of the /dev/disk/by-{path,id,uuid,label 
locations.