[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] ESX and inaccessible storage pools



On Sun, Apr 18, 2010 at 10:55:04PM +0200, Matthias Bolte wrote:
> I'm currently implementing the storage driver for ESX and have a
> mapping problem.
> 
> libvirt storage pools can be either running or inactive just like the
> domain. ESX is a bit different here. A datastore is always active. It
> can be inaccessible, e.g. if an NFS is mounted as datastore but the
> NFS server went unreachable. I discussed this with Daniel on IRC and
> he summarized it like this:
> 
>   <DV> they are defined, the system knows them, but they are not
> available for use
> 
> The question is, what should the ESX driver do with inaccessible datastores?
> 
> Option 1: They could just be represented as inactive storage pools,
> but libvirt's semantic for inactive storage pools includes that the
> user can start an inactive storage pool. That's not possible for an
> inaccessible datastore, so the driver would report an error if a user
> tries to start an inaccessible storage pool.

I don't think this is a good match, because 'inactive' implies that
the system hasn't even connected to the NFS server.

> Option 2: Just ignore inaccessible datastores and make the ESX storage
> driver to pretend that they don't exist. But this would hide
> information from the user.

Agreed, hiding info is not good.

> Option 3: Extend libvirt's API for inaccessible storage pools.

This is the only one left !

IMHO, the 'inaccessible' data store is active. A little noticed fact
is that the storage pool state is actually more than just a boolean.
At least in the public API we define

  typedef enum {
    VIR_STORAGE_POOL_INACTIVE = 0, /* Not running */
    VIR_STORAGE_POOL_BUILDING = 1, /* Initializing pool, not available */
    VIR_STORAGE_POOL_RUNNING = 2,  /* Running normally */
    VIR_STORAGE_POOL_DEGRADED = 3, /* Running degraded */
  } virStoragePoolState;


THe 'BUILDING' state is to indicate cases where the storage is being
constructed in some way.

The 'RUNNING' state is the normal runtime state.

The 'DEGRADED' state indicates that it is fully operational, but in a 
degraded state. eg, one of the members of a RAID array failed, or one
of the SCSI paths failed, etc.

The DEGRADED state doesn't exactly map to your NFS example though because
in case of a non-responsive NFS server, you can't use the pool.

Thus I'd suggest just adding a 5th option

  VIR_STORAGE_POOL_INACCESSIBLE = 4 /* Running, but not accessible */

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]