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 -
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 tmac...@gmail.com wrote:
Mike, I've confirmed that the data items map as you suspected to XenCenter.
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
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.tutkow...@solidfire.com
wrote:
Hi,
Does anyone know how a XenServer SR could (correctly) say more space is
being used than is
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
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.tutkow...@solidfire.com
wrote:
Hi Tim,
You are correct that I was looking at XenCenter. Below is the output
Great - thanks!
I was just trying to make sense of the numbers. :)
On Thu, Jan 30, 2014 at 4:36 PM, Tim Mackey tmac...@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
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
Hi,
I just noticed a problem today while creating SRs in XenServer. Perhaps
someone with related experience could point me in the right direction.
Let's say my SAN's management IP address is X.
I can have XenServer create a shared SR using IP address X with CHAP
credentials Y.
If I try to have
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
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 tmac...@gmail.com wrote:
Unfortunately what you're experiencing is how it works. While XenServer
does support different CHAP
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
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
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, Tim
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
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 tmac...@gmail.com wrote:
The problem with doing that is during host reboot. Then only one of the
credential sets will be used to do the
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
17 matches
Mail list logo
