cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: XenServer SR Question
Date Fri, 31 Jan 2014 21:33:58 GMT
Thanks, Tim!

Do you know of a good doc on the web I can view to see specifically what
these numbers mean (like what they include and don't include)?


On Fri, Jan 31, 2014 at 2:29 PM, Tim Mackey <tmackey@gmail.com> wrote:

> Mike, I've confirmed that the data items map as you suspected to XenCenter.
>  In this case the values had a rounding effect just on either side of 20.05
> respectively to create the observed numbers.
>
>
> On Thu, Jan 30, 2014 at 6:37 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
> > Great - thanks!
> >
> > I was just trying to make sense of the numbers. :)
> >
> >
> > On Thu, Jan 30, 2014 at 4:36 PM, Tim Mackey <tmackey@gmail.com> wrote:
> >
> > > I'll need to confirm with engineering, but that makes sense. I'll also
> > see
> > > if there is a different format specifier in the XenCenter string
> > > On Jan 30, 2014 6:27 PM, "Mike Tutkowski" <
> mike.tutkowski@solidfire.com>
> > > wrote:
> > >
> > > > Hi Tim,
> > > >
> > > > You are correct that I was looking at XenCenter. Below is the output
> > from
> > > > xe.
> > > >
> > > > It looks like physical-size (below) corresponds to total in
> XenCenter,
> > > > physical-utilization (below) corresponds to used in XenCenter, and
> > > > virtual-allocation (below) corresponds to allocated in XenCenter.
> > > >
> > > > Does that look right?
> > > >
> > > > Thanks!
> > > >
> > > > [root@XenServer-6 ~]# xe sr-list
> > > uuid=ec8db98c-8338-7bc7-75aa-f45207c32a83
> > > > params=all
> > > > uuid ( RO)                    : ec8db98c-8338-7bc7-75aa-f45207c32a83
> > > >               name-label ( RW):
> > > /iqn.2010-01.com.solidfire:3y8w.vol-1.126/0
> > > >         name-description ( RW):
> > > /iqn.2010-01.com.solidfire:3y8w.vol-1.126/0
> > > >                     host ( RO): <shared>
> > > >       allowed-operations (SRO): VDI.create; VDI.snapshot; PBD.create;
> > > > PBD.destroy; plug; update; VDI.destroy; scan; VDI.clone; VDI.resize;
> > > unplug
> > > >       current-operations (SRO):
> > > >                     VDIs (SRO): 8f14728f-938f-4e02-bc9c-8f67e86d5c86
> > > >                     PBDs (SRO): c4766cdc-7975-9ae7-5953-6fd831a5c654;
> > > > 7ef960f0-4074-ef18-b17b-1f9a1ae8a6ff
> > > >       virtual-allocation ( RO): 21525168128
> > > >     physical-utilisation ( RO): 21529362432
> > > >            physical-size ( RO): 85886763008
> > > >                     type ( RO): lvmoiscsi
> > > >             content-type ( RO): user
> > > >                   shared ( RW): true
> > > >            introduced-by ( RO): <not in database>
> > > >             other-config (MRW):
> > > >                sm-config (MRO): allocation: thick; use_vhd: true;
> > > > multipathable: true; devserial:
> scsi-36f47acc100000000337938770000007e
> > > >                    blobs ( RO):
> > > >      local-cache-enabled ( RO): false
> > > >                     tags (SRW):
> > > >
> > > >
> > > > On Thu, Jan 30, 2014 at 4:08 PM, Tim Mackey <tmackey@gmail.com>
> wrote:
> > > >
> > > > > I'm assuming that's the value from XenCenter. What does the cli
> say?
> > I
> > > > > could see this being just a formatting question.
> > > > > On Jan 30, 2014 5:59 PM, "Mike Tutkowski" <
> > > mike.tutkowski@solidfire.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Does anyone know how a XenServer SR could (correctly) say more
> > space
> > > is
> > > > > > being used than is allocated?
> > > > > >
> > > > > > This is what the Size field of one of my shared SRs says:
> > > > > >
> > > > > > Size: 20.1 GB used of 80 GB total (20 GB allocated)
> > > > > >
> > > > > > I would have expected used to be <= allocated at all times
> > (typically
> > > > I'd
> > > > > > expect it to be < allocated most of the time).
> > > > > >
> > > > > > Any thoughts on this?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > --
> > > > > > *Mike Tutkowski*
> > > > > > *Senior CloudStack Developer, SolidFire Inc.*
> > > > > > e: mike.tutkowski@solidfire.com
> > > > > > o: 303.746.7302
> > > > > > Advancing the way the world uses the
> > > > > > cloud<http://solidfire.com/solution/overview/?video=play>
> > > > > > *(tm)*
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Mike Tutkowski*
> > > > *Senior CloudStack Developer, SolidFire Inc.*
> > > > e: mike.tutkowski@solidfire.com
> > > > o: 303.746.7302
> > > > Advancing the way the world uses the
> > > > cloud<http://solidfire.com/solution/overview/?video=play>
> > > > *(tm)*
> > > >
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud<http://solidfire.com/solution/overview/?video=play>
> > *(tm)*
> >
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message