Subject: [OPSAWG] VM-MIB issue vm-mib-01: storage sizes

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Apr 2012 12:35:06 +0200

Hi,

* vm-mib-01: storage sizes

  The MIB does not provide storage sizes, assuming this is provided by
  the hrStorageTable of the HOST-RESOURCES-MIB. However, some well
  known implementations of the HOST-RESOURCES-MIB only report about
  file systems used by the host system and not file systems residing
  in files used by virtual machines. Furthermore, the hrStorageTable
  reports sizes "usable by the requesting entity", "excluding loss due
  to formatting of file system reference information". For storage
  provided to virtual machines, this information is often not readily
  available since all you have is the raw block size.

** Solution #01-01

   Provide the storage block sizes as part of the VM-MIB. Provide a
   pointer to the hrStorageTable on systems that can provide this
   linkage but allow the pointer to be NULL.

** Resolution

   TBD

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 24 Apr 2012 20:27:02 -0700 (PDT)

>   The MIB does not provide storage sizes, assuming this is provided
>   by the hrStorageTable of the HOST-RESOURCES-MIB. However, some well
>   reports sizes "usable by the requesting entity", "excluding loss
>   due  to formatting of file system reference information". For storage

Would think if one wanted to see the file systems residing in files used
by virtual machines, they'd install another SNMP agent in the guest OS.
Have seen in large enterprises two sets of admins, some admins 
maintain block storage devices and are not allowed access to 
host/filesystems, then there  is another group of admins to who manage the 
host/filesystems.

>    linkage but allow the pointer to be NULL.

Virtual disks reside in host OS filesystems which can be NFS, or
local or possibly in a native partition. Would prefer we model this
better than just sticking stuff in hrStorageTable.

My experience, HOST-RESOURCES-MIB, in particular the hrFSTable 
and hrStorageTable provide useful data about 
the storage holding one or more virtual disks or a VM.
Would start with a reference to the containing filesystem then just use
the hr mib as it is defined to drill down into the partitions
and to the underlying  local or remote disk. Local disks are then
reported in hrDeviceTable which reports generic hardware health.

The hrStorageTable, while it is a nice catch all and quite useful 
in practice think it hard to standardize  what goes in it and then try to expand
indexing into other tables to understand how it fits into the overall 
storage stack and related indexing (ISCSI-MIB, Fiber Channel, ...). 

Thanks,
Mike MacFaden

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 24 Apr 2012 20:31:13 -0700 (PDT)

> Would start with a reference to the containing filesystem then just
> use the hr mib as it is defined to drill down into the partitions

Ah just remembered that some virtualization software supports
using native/raw disk partitions not mounted in the host OS,
so then a pointer into the hrPartitionTable would be better
than he hrFSTable to cover more configurations.

Mike MacFaden

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Apr 2012 16:04:57 +0200

> than he hrFSTable to cover more configurations.

But then, a file in my file system that I provide a virtual machine as
a disk drive is not a partition either. And networked partition are
not covered by the hrPartitionTable (but extremely useful if you want
to migrate VMs).

I get the feeling that the host resources MIB does not really help us
here. There are apparently many different ways to provide storage to a
virtual machine and neither the hrStorageTable nor the
hrPartitionTable nor the hrFSTable nor the hrDiskStorageTable is doing
what we need.

/js

---

From: Robert Story <[email-masked]>
Date: Wed, 25 Apr 2012 11:29:25 -0400

On Wed, 25 Apr 2012 16:04:57 +0200 Juergen wrote:
JS> I get the feeling that the host resources MIB does not really help us
JS> here. There are apparently many different ways to provide storage to a
JS> virtual machine and neither the hrStorageTable nor the
JS> hrPartitionTable nor the hrFSTable nor the hrDiskStorageTable is doing
JS> what we need.

+1.

But I also don't object to providing an OID to link to a hr*Table entry if
there is a 1-1 mapping...

Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 25 Apr 2012 10:58:11 -0700 (PDT)

js writes:
> But then, a file in my file system that I provide a virtual machine
> as a disk drive is not a partition either.

If your filesystem is remote mounted filesystem then true there is no partition.
That's but one type of configuration.

To recap, places where a virtual disk may be situated:
1) a file (virtual disk) in a mounted filesystem of the host.
  a) local filesystem which can be traced to a partition and 
     a disk/lun and a storage adapter. Note the LUN might attached via SAN:FC/ISCSI
  b) remote hrFSTable provides the remote mount information

This is common with desktop as well as hypervisor software systems.

2) A raw partition (/dev/sd...) is configured for use by the VM.
3) other?

This is common with the desktop virtualization software systems.

> There are apparently many different ways to provide storage to
> a virtual machine and neither the hrStorageTable nor the
> hrPartitionTable nor the hrFSTable nor the hrDiskStorageTable is
> doing what we need.

What is it we need to accomplish?

a) Report vm disk configuration? accurately portray how a given virtual disk maps to physical storage
b) Report vm disk capacity? storage allocations at the block level, filesystem level of the host 
c) Report vm disk performance? Be able to index into the host bus adapter, and disk, network stacks.
d) Report VM/Guest OS view a-c? 

One last bit that might impact this draft, virtual disk are not only simple files 
with a 1:1 relationship to a vm. Fielded products allow multiple VMs to share one or more 
virtual disk files but each having their copy-on-write logs. irtual disks can be configured to take up
their full measure of storage blocks when created, others grow up to their limit over time (aka thick or thin provisioned).
'Snapshots' of the virtual disk at some point in time (possibly along with the vm's memory) will be
common as well. 

Mike