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 wrote:
> Mike, I've confirmed that the data items map as you suspected to XenCenter.
> In this case
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.tutkow...@solidfire.com> wrote:
> Great - th
Great - thanks!
I was just trying to make sense of the numbers. :)
On Thu, Jan 30, 2014 at 4:36 PM, Tim Mackey 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
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"
wrote:
> Hi Tim,
>
> You are correct that I was looking at XenCenter. Below is the output from
> xe.
>
> It looks l
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 t
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"
wrote:
> Hi,
>
> Does anyone know how a XenServer SR could (correctly) say more space is
> being used than is allocated?
>
> This is wh
Just as an FYI to those it may concern:
The way I got around this issue with XenServer is to use a SolidFire
feature we refer to as Volume Access Groups (VAGs).
A VAG is essentially a way to map a host IQN to the volumes it can access
on the SAN without using CHAP.
For the sake of consistency (a
One alternative I have is to abandon using SolidFire's multi-tenancy
ability (separating volumes by accounts for reporting purposes). If I only
used one uber account, then I'd only be using one set of credentials.
Another is more work and would have to wait until 4.4: Add logic to the
storage plug
Good points, Tim.
Do you know if this is an issue the XenServer group plans to address
anytime soon?
Thanks
On Wed, Dec 18, 2013 at 5:13 PM, Tim Mackey wrote:
> The problem with doing that is during host reboot. Then only one of the
> credential sets will be used to do the discovery, and on e
The problem with doing that is during host reboot. Then only one of the
credential sets will be used to do the discovery, and on each reboot a
discovery will occur. It'll also have issues with multipath.
There will also be an issue during pool join, and there could be
replication issues in xenstor
We have noticed if I ssh into XenServer and delete the file /etc/iscsi/
10.10.8.108,3260 (where 10.10.8.108 is our storage's IP address and 3260 is
the port) that I can create SRs using different CHAP credentials.
Can anyone think of a "got-cha" here?
Thanks!
On Wed, Dec 18, 2013 at 3:18 PM, Ti
Mike,
I'm referring to the open-iscsi code used by XAPI. XAPI has a storage
manager API which deals with all the SR management. It's also where the
issue you're running into exists.
In terms of clearing the connections and credentials, the easiest way is
via a reboot. Since your using multiple
Hey Tim,
When you refer to modifying the storage manager, are you referring to
CloudStack?
Perhaps you are referring to CitrixResourceBase, which is where we discover
and log in to iSCSI targets.
Do you know of a way to delete those cached CHAP credentials via XAPI so
when new ones are used for
Thanks, Tim!
I am working with someone at SolidFire now who has experience with this
issue and might have a workaround.
On Wed, Dec 18, 2013 at 2:22 PM, Tim Mackey wrote:
> Unfortunately what you're experiencing is how it works. While XenServer
> does support different CHAP credentials by SR,
Unfortunately what you're experiencing is how it works. While XenServer
does support different CHAP credentials by SR, it only supports a single
CHAP credential for discovery. It can be made to work, but you'd need to
either modify how the storage manager works to pull it off, or rewrite some
of
15 matches
Mail list logo
