Re: [ovirt-users] Status libgfapi support in oVirt

2014-11-24 Thread Vijay Bellur

On 11/24/2014 08:44 PM, noc wrote:

Warning: option deprecated, use lost_tick_policy property of kvm-pit
instead.
[2014-11-24 15:09:13.069041] E [rpc-clnt.c:362:saved_frames_unwind] (--
/lib64/libglusterfs.so.0(_gf_log_callingfn+0x186)[0x7f0f46d79396] (--
/lib64/libgfrpc.so.0(saved_frames_unwind+0x1de)[0x7f0f49e30fce] (--
/lib64/libgfrpc.so.0(saved_frames_destroy+0xe)[0x7f0f49e310de] (--
/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x82)[0x7f0f49e32a42]
(-- /lib64/libgfrpc.so.0(rpc_clnt_notify+0x48)[0x7f0f49e331f8] )
0-GlusterTest-client-0: forced unwinding frame type(GF-DUMP) op(DUMP(1))
called at 2014-11-24 15:09:13.055308 (xid=0x3)


This seems to indicate that the handshake with glusterfs server failed. 
Can you please post glusterfs logs from the server specified in the 
gluster:// URI?


Thanks,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] replace ovirt engine host

2014-11-12 Thread Vijay Bellur

On 11/12/2014 09:16 PM, Nir Soffer wrote:

Hi Mario,

Please open a bug for this.

Include these logs in the bug for the ovirt engine host, one hypervisor node 
that
had no trouble, and one hypervisor node that had trouble (ovirt-node01?).

/var/log/mesages
/var/log/sanlock.log
/var/log/vdsm.log

And of course engine.log for the engine node.



Please also include glusterfs logs from:

/var/log/glusterfs

Thanks,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] two node replicated gluster

2014-09-25 Thread Vijay Bellur

On 09/25/2014 07:44 PM, ml ml wrote:

Hello List,

i have a Two Node replicated Gluster.

I am running about 15 vm on each host so that in case one node fails
the other one can take over.

My question is how the GlusterFS self-healing-daemon works.

I disconnected the two nodes on purpose and reconnected them again. So
that the self-heal-daemon jumps it.

It looks like it would transfer all the file. Does the
self-heal-deamon of glusterfs not just copy the missing increments?



self-heal daemon just syncs regions of files that need to be updated and 
the process of identification of regions to be updated involves 
comparison of a rolling checksum of various regions in the files. You 
can find more details about Gluster's replication and the self-healing 
algorithm in the Recovering from failures (Self-heal) section of this 
document [1].


-Vijay

[1] https://github.com/gluster/glusterfs/blob/master/doc/features/afr-v1.md



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] oVirt/gluster storage questions for 2-3 node datacenter

2014-08-29 Thread Vijay Bellur

On 08/29/2014 07:34 PM, David King wrote:

Paul,

Thanks for the response.

You mention that the issue is orphaned files during updates when one
node is down.  However I am less concerned about adding and removing
files because the file server will be predominately VM disks so the file
structure is fairly static.  Those VM files will be quite active however
- will gluster be able to keep track of partial updates to a large file
when one out of two bricks are down?



Yes, gluster only updates regions of the file that need to be 
synchronized during self-healing. More details on this synchronization 
can be found in the self-healing section of afr's design document [1].



Right now I am leaning towards using SSD for host local disk - single
brick gluster volumes intended for VMs which are node specific and then
3 way replicas for the higher availability zones which tend to be more
read oriented.   I presume that read-only access only needs to get data
from one of the 3 replicas so that should be reasonably performant.


Yes, read operations are directed to only one of the replicas.

Regards,
Vijay

[1] https://github.com/gluster/glusterfs/blob/master/doc/features/afr-v1.md

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] planning ovirt for production

2014-07-23 Thread Vijay Bellur

On 07/22/2014 06:15 PM, Itamar Heim wrote:

On 07/16/2014 06:46 PM, Demeter Tibor wrote:

Hi,

We have a production environment with KVM+centos6 and we want to switch
to ovirt.
At this moment we have 12 VM on three independent server.
This VMs uses the local disks of servers, we don't have a central
storage.

currently we have for ovirt

- Two Dell R710 with 128 gigs of ram.
- A third dell server for ovirt-engine.
- four 1 gb/sec NICs/ server.
- Smart GB switch

we would like make an ovirt environment with

- clusterized, redundant filesystem, data loss protection
- If a host goes to down the VMs could made a restart on the remain host
- LACP/bonding (mode 6) for fast I/O beetwen gluster hosts, we don't
have 10Gbe nics
- 8 TB of disk capacity for VMs

we don't want:

- using hw raid on servers, because we need free disk tray for more
capacity

My questions.

- Which glusterfs method is the best for us for performance?


vijay?



A replicated gluster volume does help for availability and performance. 
Please ensure that you optimize the gluster volume for virtualization by 
applying the performance settings in virt profile [1].



- Can I make a real performance disk i/o  by 4-4 NICs  ? Or I need 10
Gbe nic for this?
- How much disk need for good redundancy/performance? 4/server or
2/server ?
- What will the weak point our project?


make sure to use gluster with replica 3, which needs 3 servers?
maybe use hosted engine to remove need for dedicated server for it?



Using replica 3 volumes would provide better protection for split-brains.

Thanks,
Vijay

[1] 
https://github.com/gluster/glusterfs/blob/master/extras/group-virt.example


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] [Gluster-devel] Can we debug some truths/myths/facts about hosted-engine and gluster?

2014-07-23 Thread Vijay Bellur

On 07/22/2014 07:21 AM, Itamar Heim wrote:

On 07/22/2014 04:28 AM, Vijay Bellur wrote:

On 07/21/2014 05:09 AM, Pranith Kumar Karampuri wrote:


On 07/21/2014 02:08 PM, Jiri Moskovcak wrote:

On 07/19/2014 08:58 AM, Pranith Kumar Karampuri wrote:


On 07/19/2014 11:25 AM, Andrew Lau wrote:



On Sat, Jul 19, 2014 at 12:03 AM, Pranith Kumar Karampuri
pkara...@redhat.com mailto:pkara...@redhat.com wrote:


On 07/18/2014 05:43 PM, Andrew Lau wrote:

​ ​

On Fri, Jul 18, 2014 at 10:06 PM, Vijay Bellur
vbel...@redhat.com mailto:vbel...@redhat.com wrote:

[Adding gluster-devel]


On 07/18/2014 05:20 PM, Andrew Lau wrote:

Hi all,

As most of you have got hints from previous messages,
hosted engine
won't work on gluster . A quote from BZ1097639

Using hosted engine with Gluster backed storage is
currently something
we really warn against.


I think this bug should be closed or re-targeted at
documentation, because there is nothing we can do here.
Hosted engine assumes that all writes are atomic and
(immediately) available for all hosts in the cluster.
Gluster violates those assumptions.
​

I tried going through BZ1097639 but could not find much
detail with respect to gluster there.

A few questions around the problem:

1. Can somebody please explain in detail the scenario that
causes the problem?

2. Is hosted engine performing synchronous writes to ensure
that writes are durable?

Also, if there is any documentation that details the hosted
engine architecture that would help in enhancing our
understanding of its interactions with gluster.


​

Now my question, does this theory prevent a scenario of
perhaps
something like a gluster replicated volume being mounted
as a glusterfs
filesystem and then re-exported as the native kernel NFS
share for the
hosted-engine to consume? It could then be possible to
chuck ctdb in
there to provide a last resort failover solution. I have
tried myself
and suggested it to two people who are running a similar
setup. Now
using the native kernel NFS server for hosted-engine and
they haven't
reported as many issues. Curious, could anyone validate
my theory on this?


If we obtain more details on the use case and obtain gluster
logs from the failed scenarios, we should be able to
understand the problem better. That could be the first step
in validating your theory or evolving further
recommendations :).


​ I'm not sure how useful this is, but ​Jiri Moskovcak tracked
this down in an off list message.

​ Message Quote:​

​ ==​

​We were able to track it down to this (thanks Andrew for
providing the testing setup):

-b686-4363-bb7e-dba99e5789b6/ha_agent
service_type=hosted-engine'
Traceback (most recent call last):
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/listener.py,



line 165, in handle
  response = success  + self._dispatch(data)
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/listener.py,



line 261, in _dispatch
  .get_all_stats_for_service_type(**options)
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py,



line 41, in get_all_stats_for_service_type
  d = self.get_raw_stats_for_service_type(storage_dir,
service_type)
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py,



line 74, in get_raw_stats_for_service_type
  f = os.open(path, direct_flag | os.O_RDONLY)
OSError: [Errno 116] Stale file handle:
'/rhev/data-center/mnt/localhost:_mnt_hosted-engine/c898fd2a-b686-4363-bb7e-dba99e5789b6/ha_agent/hosted-engine.metadata'




Andrew/Jiri,
Would it be possible to post gluster logs of both the
mount and bricks on the bz? I can take a look at it once. If I
gather nothing then probably I will ask for your help in
re-creating the issue.

Pranith


​Unfortunately, I don't have the logs for that setup any more.. ​I'll
try replicate when I get a chance. If I understand the comment from
the BZ, I don't think it's a gluster bug per-say, more just how
gluster does its replication.

hi Andrew,
  Thanks for that. I couldn't come to any conclusions
because no
logs were available. It is unlikely that self-heal is involved because
there were no bricks going down/up according to the bug description.



Hi,
I've never had such setup, I guessed problem with gluster based on
OSError: [Errno 116] Stale file handle: which happens when the file
opened by application

Re: [ovirt-users] [Gluster-devel] Can we debug some truths/myths/facts about hosted-engine and gluster?

2014-07-21 Thread Vijay Bellur

On 07/21/2014 05:09 AM, Pranith Kumar Karampuri wrote:


On 07/21/2014 02:08 PM, Jiri Moskovcak wrote:

On 07/19/2014 08:58 AM, Pranith Kumar Karampuri wrote:


On 07/19/2014 11:25 AM, Andrew Lau wrote:



On Sat, Jul 19, 2014 at 12:03 AM, Pranith Kumar Karampuri
pkara...@redhat.com mailto:pkara...@redhat.com wrote:


On 07/18/2014 05:43 PM, Andrew Lau wrote:

​ ​

On Fri, Jul 18, 2014 at 10:06 PM, Vijay Bellur
vbel...@redhat.com mailto:vbel...@redhat.com wrote:

[Adding gluster-devel]


On 07/18/2014 05:20 PM, Andrew Lau wrote:

Hi all,

As most of you have got hints from previous messages,
hosted engine
won't work on gluster . A quote from BZ1097639

Using hosted engine with Gluster backed storage is
currently something
we really warn against.


I think this bug should be closed or re-targeted at
documentation, because there is nothing we can do here.
Hosted engine assumes that all writes are atomic and
(immediately) available for all hosts in the cluster.
Gluster violates those assumptions.
​

I tried going through BZ1097639 but could not find much
detail with respect to gluster there.

A few questions around the problem:

1. Can somebody please explain in detail the scenario that
causes the problem?

2. Is hosted engine performing synchronous writes to ensure
that writes are durable?

Also, if there is any documentation that details the hosted
engine architecture that would help in enhancing our
understanding of its interactions with gluster.


​

Now my question, does this theory prevent a scenario of
perhaps
something like a gluster replicated volume being mounted
as a glusterfs
filesystem and then re-exported as the native kernel NFS
share for the
hosted-engine to consume? It could then be possible to
chuck ctdb in
there to provide a last resort failover solution. I have
tried myself
and suggested it to two people who are running a similar
setup. Now
using the native kernel NFS server for hosted-engine and
they haven't
reported as many issues. Curious, could anyone validate
my theory on this?


If we obtain more details on the use case and obtain gluster
logs from the failed scenarios, we should be able to
understand the problem better. That could be the first step
in validating your theory or evolving further
recommendations :).


​ I'm not sure how useful this is, but ​Jiri Moskovcak tracked
this down in an off list message.

​ Message Quote:​

​ ==​

​We were able to track it down to this (thanks Andrew for
providing the testing setup):

-b686-4363-bb7e-dba99e5789b6/ha_agent service_type=hosted-engine'
Traceback (most recent call last):
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/listener.py,

line 165, in handle
  response = success  + self._dispatch(data)
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/listener.py,

line 261, in _dispatch
  .get_all_stats_for_service_type(**options)
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py,

line 41, in get_all_stats_for_service_type
  d = self.get_raw_stats_for_service_type(storage_dir,
service_type)
File
/usr/lib/python2.6/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py,

line 74, in get_raw_stats_for_service_type
  f = os.open(path, direct_flag | os.O_RDONLY)
OSError: [Errno 116] Stale file handle:
'/rhev/data-center/mnt/localhost:_mnt_hosted-engine/c898fd2a-b686-4363-bb7e-dba99e5789b6/ha_agent/hosted-engine.metadata'


Andrew/Jiri,
Would it be possible to post gluster logs of both the
mount and bricks on the bz? I can take a look at it once. If I
gather nothing then probably I will ask for your help in
re-creating the issue.

Pranith


​Unfortunately, I don't have the logs for that setup any more.. ​I'll
try replicate when I get a chance. If I understand the comment from
the BZ, I don't think it's a gluster bug per-say, more just how
gluster does its replication.

hi Andrew,
  Thanks for that. I couldn't come to any conclusions because no
logs were available. It is unlikely that self-heal is involved because
there were no bricks going down/up according to the bug description.



Hi,
I've never had such setup, I guessed problem with gluster based on
OSError: [Errno 116] Stale file handle: which happens when the file
opened by application on client gets removed on the server. I'm pretty
sure we (hosted-engine) don't remove that file, so I

Re: [ovirt-users] Can we debug some truths/myths/facts about hosted-engine and gluster?

2014-07-18 Thread Vijay Bellur

[Adding gluster-devel]

On 07/18/2014 05:20 PM, Andrew Lau wrote:

Hi all,

As most of you have got hints from previous messages, hosted engine
won't work on gluster . A quote from BZ1097639

Using hosted engine with Gluster backed storage is currently something
we really warn against.


I think this bug should be closed or re-targeted at documentation, because 
there is nothing we can do here. Hosted engine assumes that all writes are 
atomic and (immediately) available for all hosts in the cluster. Gluster 
violates those assumptions.
​
I tried going through BZ1097639 but could not find much detail with 
respect to gluster there.


A few questions around the problem:

1. Can somebody please explain in detail the scenario that causes the 
problem?


2. Is hosted engine performing synchronous writes to ensure that writes 
are durable?


Also, if there is any documentation that details the hosted engine 
architecture that would help in enhancing our understanding of its 
interactions with gluster.



​

Now my question, does this theory prevent a scenario of perhaps
something like a gluster replicated volume being mounted as a glusterfs
filesystem and then re-exported as the native kernel NFS share for the
hosted-engine to consume? It could then be possible to chuck ctdb in
there to provide a last resort failover solution. I have tried myself
and suggested it to two people who are running a similar setup. Now
using the native kernel NFS server for hosted-engine and they haven't
reported as many issues. Curious, could anyone validate my theory on this?



If we obtain more details on the use case and obtain gluster logs from 
the failed scenarios, we should be able to understand the problem 
better. That could be the first step in validating your theory or 
evolving further recommendations :).


Thanks,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] sanlock + gluster recovery -- RFE

2014-06-02 Thread Vijay Bellur

I am sorry, this missed my attention over the last few days.

On 05/23/2014 08:50 PM, Ted Miller wrote:

Vijay, I am not a member of the developer list, so my comments are at end.

On 5/23/2014 6:55 AM, Vijay Bellur wrote:

On 05/21/2014 10:22 PM, Federico Simoncelli wrote:

- Original Message -

From: Giuseppe Ragusa giuseppe.rag...@hotmail.com
To: fsimo...@redhat.com
Cc: users@ovirt.org
Sent: Wednesday, May 21, 2014 5:15:30 PM
Subject: sanlock + gluster recovery -- RFE

Hi,


- Original Message -

From: Ted Miller tmiller at hcjb.org
To: users users at ovirt.org
Sent: Tuesday, May 20, 2014 11:31:42 PM
Subject: [ovirt-users] sanlock + gluster recovery -- RFE

As you are aware, there is an ongoing split-brain problem with
running
sanlock on replicated gluster storage. Personally, I believe that
this is
the 5th time that I have been bitten by this sanlock+gluster problem.

I believe that the following are true (if not, my entire request is
probably
off base).


 * ovirt uses sanlock in such a way that when the sanlock
storage is
 on a
 replicated gluster file system, very small storage
disruptions can
 result in a gluster split-brain on the sanlock space


Although this is possible (at the moment) we are working hard to
avoid it.
The hardest part here is to ensure that the gluster volume is properly
configured.

The suggested configuration for a volume to be used with ovirt is:

Volume Name: (...)
Type: Replicate
Volume ID: (...)
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
(...three bricks...)
Options Reconfigured:
network.ping-timeout: 10
cluster.quorum-type: auto

The two options ping-timeout and quorum-type are really important.

You would also need a build where this bug is fixed in order to
avoid any
chance of a split-brain:

https://bugzilla.redhat.com/show_bug.cgi?id=1066996


It seems that the aforementioned bug is peculiar to 3-bricks setups.

I understand that a 3-bricks setup can allow proper quorum formation
without
resorting to first-configured-brick-has-more-weight convention
used with
only 2 bricks and quorum auto (which makes one node special, so not
properly any-single-fault tolerant).


Correct.


But, since we are on ovirt-users, is there a similar suggested
configuration
for a 2-hosts setup oVirt+GlusterFS with oVirt-side power management
properly configured and tested-working?
I mean a configuration where any host can go south and oVirt
(through the
other one) fences it (forcibly powering it off with confirmation
from IPMI
or similar) then restarts HA-marked vms that were running there, all
the
while keeping the underlying GlusterFS-based storage domains
responsive and
readable/writeable (maybe apart from a lapse between detected
other-node
unresposiveness and confirmed fencing)?


We already had a discussion with gluster asking if it was possible to
add fencing to the replica 2 quorum/consistency mechanism.

The idea is that as soon as you can't replicate a write you have to
freeze all IO until either the connection is re-established or you
know that the other host has been killed.

Adding Vijay.

There is a related thread on gluster-devel [1] to have a better
behavior in GlusterFS for prevention of split brains with sanlock and
2-way replicated gluster volumes.

Please feel free to comment on the proposal there.

Thanks,
Vijay

[1]
http://supercolony.gluster.org/pipermail/gluster-devel/2014-May/040751.html


One quick note before my main comment: I see references to quorum being
N/2 + 1.  Isn't if more accurate to say that quorum is (N + 1)/2 or
N/2 + 0.5?


(N + 1)/2 or  N/2 + 0.5 is fine when N happens to be odd. For both 
odd and even cases of N, N/2 + 1 does seem to be the more appropriate 
representation (assuming integer arithmetic).




Now to my main comment.

I see a case that is not being addressed.  I have no proof of how often
this use-case occurs, but I believe that is does occur.  (It could
(theoretically) occur in any situation where multiple bricks are writing
to different parts of the same file.)

Use-case: sanlock via fuse client.

Steps to produce originally

(not tested for reproducibility, because I was unable to recover the
ovirt cluster after occurrence, had to rebuild from scratch), time
frame was late 2013 or early 2014

2 node ovirt cluster using replicated gluster storage
ovirt cluster up and running VMs
remove power from network switch
restore power to network switch after a few minutes

Result

both copies of .../dom_md/ids file accused the other of being out of
sync


This case would fall under the ambit of 1. Split-brains due to network 
partition or network split-brains in the proposal on gluster-devel.




Possible solutions

Thinking about it on a systems level, the only solution I can see is
to route all writes through one gluster brick.  That way all the
accusations flow from that brick to other bricks, and gluster will
find the one file

Re: [ovirt-users] sanlock + gluster recovery -- RFE

2014-05-23 Thread Vijay Bellur

On 05/21/2014 10:22 PM, Federico Simoncelli wrote:

- Original Message -

From: Giuseppe Ragusa giuseppe.rag...@hotmail.com
To: fsimo...@redhat.com
Cc: users@ovirt.org
Sent: Wednesday, May 21, 2014 5:15:30 PM
Subject: sanlock + gluster recovery -- RFE

Hi,


- Original Message -

From: Ted Miller tmiller at hcjb.org
To: users users at ovirt.org
Sent: Tuesday, May 20, 2014 11:31:42 PM
Subject: [ovirt-users] sanlock + gluster recovery -- RFE

As you are aware, there is an ongoing split-brain problem with running
sanlock on replicated gluster storage. Personally, I believe that this is
the 5th time that I have been bitten by this sanlock+gluster problem.

I believe that the following are true (if not, my entire request is
probably
off base).


 * ovirt uses sanlock in such a way that when the sanlock storage is
 on a
 replicated gluster file system, very small storage disruptions can
 result in a gluster split-brain on the sanlock space


Although this is possible (at the moment) we are working hard to avoid it.
The hardest part here is to ensure that the gluster volume is properly
configured.

The suggested configuration for a volume to be used with ovirt is:

Volume Name: (...)
Type: Replicate
Volume ID: (...)
Status: Started
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
(...three bricks...)
Options Reconfigured:
network.ping-timeout: 10
cluster.quorum-type: auto

The two options ping-timeout and quorum-type are really important.

You would also need a build where this bug is fixed in order to avoid any
chance of a split-brain:

https://bugzilla.redhat.com/show_bug.cgi?id=1066996


It seems that the aforementioned bug is peculiar to 3-bricks setups.

I understand that a 3-bricks setup can allow proper quorum formation without
resorting to first-configured-brick-has-more-weight convention used with
only 2 bricks and quorum auto (which makes one node special, so not
properly any-single-fault tolerant).


Correct.


But, since we are on ovirt-users, is there a similar suggested configuration
for a 2-hosts setup oVirt+GlusterFS with oVirt-side power management
properly configured and tested-working?
I mean a configuration where any host can go south and oVirt (through the
other one) fences it (forcibly powering it off with confirmation from IPMI
or similar) then restarts HA-marked vms that were running there, all the
while keeping the underlying GlusterFS-based storage domains responsive and
readable/writeable (maybe apart from a lapse between detected other-node
unresposiveness and confirmed fencing)?


We already had a discussion with gluster asking if it was possible to
add fencing to the replica 2 quorum/consistency mechanism.

The idea is that as soon as you can't replicate a write you have to
freeze all IO until either the connection is re-established or you
know that the other host has been killed.

Adding Vijay.




There is a related thread on gluster-devel [1] to have a better behavior 
in GlusterFS for prevention of split brains with sanlock and 2-way 
replicated gluster volumes.


Please feel free to comment on the proposal there.

Thanks,
Vijay

[1] 
http://supercolony.gluster.org/pipermail/gluster-devel/2014-May/040751.html

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] glusterfs tips/questions

2014-05-23 Thread Vijay Bellur

On 05/21/2014 07:22 PM, Kanagaraj wrote:

Ok.

I am not sure deleting the file or re-peer probe would be the right way
to go.

Gluster-users can help you here.


On 05/21/2014 07:08 PM, Gabi C wrote:

Hello!


I haven't change the IP, nor reinstall nodes. All nodes are updated
via yum. All I can think of was that after having some issue with
gluster,from WebGUI I deleted VM, deactivate and detach storage
domains ( I have 2) , than, _manually_, from one of the nodes , remove
bricks, then detach peers, probe them, add bricks again, bring the
volume up, and readd storage domains from the webGUI.


On Wed, May 21, 2014 at 4:26 PM, Kanagaraj kmayi...@redhat.com
mailto:kmayi...@redhat.com wrote:

What are the steps which led this situation?

Did you re-install one of the nodes after forming the cluster or
reboot which could have changed the ip?



On 05/21/2014 03:43 PM, Gabi C wrote:

On afected node:

gluster peer status

gluster peer status
Number of Peers: 3

Hostname: 10.125.1.194
Uuid: 85c2a08c-a955-47cc-a924-cf66c6814654
State: Peer in Cluster (Connected)

Hostname: 10.125.1.196
Uuid: c22e41b8-2818-4a96-a6df-a237517836d6
State: Peer in Cluster (Connected)

Hostname: 10.125.1.194
Uuid: 85c2a08c-a955-47cc-a924-cf66c6814654
State: Peer in Cluster (Connected)





ls -la /var/lib/gluster



ls -la /var/lib/glusterd/peers/
total 20
drwxr-xr-x. 2 root root 4096 May 21 11:10 .
drwxr-xr-x. 9 root root 4096 May 21 11:09 ..
-rw---. 1 root root   73 May 21 11:10
85c2a08c-a955-47cc-a924-cf66c6814654
-rw---. 1 root root   73 May 21 10:52
c22e41b8-2818-4a96-a6df-a237517836d6
-rw---. 1 root root   73 May 21 11:10
d95558a0-a306-4812-aec2-a361a9ddde3e





Can you please check the output of cat 
/var/lib/glusterd/peers/d95558a0-a306-4812-aec2-a361a9ddde3e ?


If it does contain information about the duplicated peer and none of the 
other 2 nodes do have this file in /var/lib/glusterd/peers/, the file 
can be moved out of /var/lib/glusterd or deleted.


Regards,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] glusterfs tips/questions

2014-05-23 Thread Vijay Bellur

On 05/23/2014 05:25 PM, Gabi C wrote:

On problematic node:

[root@virtual5 ~]# ls -la /var/lib/glusterd/peers/
total 20
drwxr-xr-x. 2 root root 4096 May 21 16:33 .
drwxr-xr-x. 9 root root 4096 May 21 16:33 ..
-rw---. 1 root root   73 May 21 16:33
85c2a08c-a955-47cc-a924-cf66c6814654
-rw---. 1 root root   73 May 21 16:33
c22e41b8-2818-4a96-a6df-a237517836d6
-rw---. 1 root root   73 May 21 16:33
d95558a0-a306-4812-aec2-a361a9ddde3e
[root@virtual5 ~]# cat
/var/lib/glusterd/peers/85c2a08c-a955-47cc-a924-cf66c6814654
uuid=85c2a08c-a955-47cc-a924-cf66c6814654
state=3
hostname1=10.125.1.194
[root@virtual5 ~]# cat
/var/lib/glusterd/peers/c22e41b8-2818-4a96-a6df-a237517836d6
uuid=c22e41b8-2818-4a96-a6df-a237517836d6
state=3
hostname1=10.125.1.196
[root@virtual5 ~]# cat
/var/lib/glusterd/peers/d95558a0-a306-4812-aec2-a361a9ddde3e
uuid=85c2a08c-a955-47cc-a924-cf66c6814654
state=3
hostname1=10.125.1.194



Looks like this is stale information for 10.125.1.194 that has somehow 
persisted. Deleting this file and then restarting glusterd on this node 
should lead to a consistent state for the peers.


Regards,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] gluster performance oVirt 3.4

2014-05-11 Thread Vijay Bellur

On 05/11/2014 02:04 AM, Vadims Korsaks wrote:

HI!

Created 2 node setup with oVirt 3.4 and CentOS 6.5, for storage created
2 node replicated gluster (3.5) fs on same hosts with oVirt.
mount looks like this:
127.0.0.1:/gluster01 on
/rhev/data-center/mnt/glusterSD/127.0.0.1:_gluster01 type fuse.glusterfs
(rw,default_permissions,allow_other,max_read=131072)

when i making gluster test with dd, something like
dd if=/dev/zero bs=1M count=2
of=/rhev/data-center/mnt/glusterSD/127.0.0.1\:_gluster01/kaka
i'm gettting speed ~ 110 MB/s, so this is 1Gbps speed of ethernet adapter

but with in VM created in oVirt speed is lower than 20 MB/s

why there is so huge difference?
how can improve VMs disks speed?



What are your gluster volume settings? Have you applied the following 
performance tunables in gluster's virt profile:


eager-lock=enable
remote-dio=enable

Regards,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Very bad write performance in VM (ovirt 3.3.3)

2014-02-10 Thread Vijay Bellur

On 02/09/2014 11:08 PM, ml ml wrote:

Yes, the only thing which brings the wirte I/O almost on my Host Level
is by enabling viodiskcache = writeback.
As far as i can tell this is caching enabled for the guest and the host
which is critical if sudden power loss happens.
Can  i turn this is on if i have a BBU in my Host System?



I was referring to the set of gluster volume tunables in [1]. These 
options can be enabled through volume set interface in gluster CLI.


The quorum options are used for providing tolerance against split-brains 
and the remaining ones are recommended normally for performance.


-Vijay

[1] 
https://github.com/gluster/glusterfs/blob/master/extras/group-virt.example


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Very bad write performance in VM (ovirt 3.3.3)

2014-02-09 Thread Vijay Bellur

On 02/09/2014 09:11 PM, ml ml wrote:

I am on Cent OS 6.5 and i am using:

[root@node1 ~]# rpm -qa | grep gluster
glusterfs-rdma-3.4.2-1.el6.x86_64
glusterfs-server-3.4.2-1.el6.x86_64
glusterfs-fuse-3.4.2-1.el6.x86_64
glusterfs-libs-3.4.2-1.el6.x86_64
glusterfs-3.4.2-1.el6.x86_64
glusterfs-api-3.4.2-1.el6.x86_64
glusterfs-cli-3.4.2-1.el6.x86_64
vdsm-gluster-4.13.3-3.el6.noarch


Have you turned on Optimize for Virt Store for the gluster volume?

-Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Extremely poor disk access speeds in Windows guest

2014-01-24 Thread Vijay Bellur

On 01/25/2014 01:31 AM, Steve Dainard wrote:

Not sure what a good method to bench this would be, but:

An NFS mount point on virt host:
[root@ovirt001 iso-store]# dd if=/dev/zero of=test1 bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (410 MB) copied, 3.95399 s, 104 MB/s

Raw brick performance on gluster server (yes, I know I shouldn't write
directly to the brick):
[root@gluster1 iso-store]# dd if=/dev/zero of=test bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (410 MB) copied, 3.06743 s, 134 MB/s

Gluster mount point on gluster server:
[root@gluster1 iso-store]# dd if=/dev/zero of=test bs=4k count=10
10+0 records in
10+0 records out
40960 bytes (410 MB) copied, 19.5766 s, 20.9 MB/s

The storage servers are a bit older, but are both dual socket quad core
opterons with 4x 7200rpm drives.


A block size of 4k is quite small so that the context switch overhead 
involved with fuse would be more perceivable.


Would it be possible to increase the block size for dd and test?



I'm in the process of setting up a share from my desktop and I'll see if
I can bench between the two systems. Not sure if my ssd will impact the
tests, I've heard there isn't an advantage using ssd storage for glusterfs.


Do you have any pointers to this source of information? Typically 
glusterfs performance for virtualization work loads is bound by the 
slowest element in the entire stack. Usually storage/disks happen to be 
the bottleneck and ssd storage does benefit glusterfs.


-Vijay




Does anyone have a hardware reference design for glusterfs as a backend
for virt? Or is there a benchmark utility?

*Steve Dainard *
IT Infrastructure Manager
Miovision http://miovision.com/ | /Rethink Traffic/
519-513-2407 ex.250
877-646-8476 (toll-free)

*Blog http://miovision.com/blog  | **LinkedIn
https://www.linkedin.com/company/miovision-technologies  | Twitter
https://twitter.com/miovision  | Facebook
https://www.facebook.com/miovision*

Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener,
ON, Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential.
If you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.


On Thu, Jan 23, 2014 at 7:18 PM, Andrew Cathrow acath...@redhat.com
mailto:acath...@redhat.com wrote:

Are we sure that the issue is the guest I/O - what's the raw
performance on the host accessing the gluster storage?



*From: *Steve Dainard sdain...@miovision.com
mailto:sdain...@miovision.com
*To: *Itamar Heim ih...@redhat.com mailto:ih...@redhat.com
*Cc: *Ronen Hod r...@redhat.com mailto:r...@redhat.com,
users users@ovirt.org mailto:users@ovirt.org, Sanjay Rao
s...@redhat.com mailto:s...@redhat.com
*Sent: *Thursday, January 23, 2014 4:56:58 PM
*Subject: *Re: [Users] Extremely poor disk access speeds in
Windows guest


I have two options, virtio and virtio-scsi.

I was using virtio, and have also attempted virtio-scsi on
another Windows guest with the same results.

Using the newest drivers, virtio-win-0.1-74.iso.

*Steve Dainard *
IT Infrastructure Manager
Miovision http://miovision.com/ | /Rethink Traffic/
519-513-2407 tel:519-513-2407 ex.250
877-646-8476 tel:877-646-8476 (toll-free)

*Blog http://miovision.com/blog  | **LinkedIn
https://www.linkedin.com/company/miovision-technologies  |
Twitter https://twitter.com/miovision  | Facebook
https://www.facebook.com/miovision*

Miovision Technologies Inc. | 148 Manitou Drive, Suite 101,
Kitchener, ON, Canada | N2C 1L3
This e-mail may contain information that is privileged or
confidential. If you are not the intended recipient, please
delete the e-mail and any attachments and notify us immediately.


On Thu, Jan 23, 2014 at 4:24 PM, Itamar Heim ih...@redhat.com
mailto:ih...@redhat.com wrote:

On 01/23/2014 07:46 PM, Steve Dainard wrote:

Backing Storage: Gluster Replica
Storage Domain: NFS
Ovirt Hosts: CentOS 6.5
Ovirt version: 3.3.2
Network: GigE
# of VM's: 3 - two Linux guests are idle, one Windows
guest is
installing updates.

I've installed a Windows 2008 R2 guest with virtio disk,
and all the
drivers from the latest virtio iso. I've also installed
the spice agent
drivers.

Guest disk access is horribly slow, Resource 

Re: [Users] Gluster storage

2014-01-17 Thread Vijay Bellur

On 01/17/2014 12:55 PM, Gianluca Cecchi wrote:

On Fri, Nov 29, 2013 at 11:48 AM, Dan Kenigsberg  wrote:

On Fri, Nov 29, 2013 at 04:04:03PM +0530, Vijay Bellur wrote:



There are two ways in which GlusterFS can be used as a storage domain:

a) Use gluster native/fuse access with POSIXFS

b) Use the gluster native storage domain to bypass fuse (with
libgfapi). We are currently addressing an issue in libvirt
(https://bugzilla.redhat.com/show_bug.cgi?id=1017289) to enable
snapshot support with libgfapi. Once this is addressed, we will have
libgfapi support in the native storage domain.


It won't be as immediate, since there's a required fix on Vdsm's side
(Bug 1022961 - Running a VM from a gluster domain uses mount instead of
gluster URI)


Till then, fuse would
be used with native storage domain. You can find more details about
native storage domain here:

http://www.ovirt.org/Features/GlusterFS_Storage_Domain

rg/mailman/listinfo/users

Hello,
revamping here
I'm using oVirt 3.3.3 beta1 after upgrade from 3.3.2 on fedora 19
ovirt beta repo
It seems bug referred by Vijay (1017289) is still marked as
assigned, but actually it is for rhel 6.
Bug referred by Dan (1022961) is marked as blocked but I don't see
any particular updates since late november. But it is for rhevm, so I
think it is for rhel 6...
So what is the situation for fedora 19 and oVirt in upcoming 3.3.3?
And upcoming fedora 19/20 and 3.4?




I ask because I see that in my qemu command line generated by oVirt there is:

for virtio (virtio-blk) disk
-drive 
file=/rhev/data-center/mnt/glusterSD/node01.mydomain:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/a5e4f67b-50b5-4740-9990-39deb8812445/53408cb0-bcd4-40de-bc69-89d59b7b5bc2,if=none,id=drive-virtio-disk0,format=raw,serial=a5e4f67b-50b5-4740-9990-39deb8812445,cache=none,werror=stop,rerror=stop,aio=threads

for virtio-scsi disk
-drive 
file=/rhev/data-center/mnt/glusterSD/node01.mydomain:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/c1477133-6b06-480d-a233-1dae08daf8b3/c2a82c64-9dee-42bb-acf2-65b8081f2edf,if=none,id=drive-scsi0-0-0-0,format=raw,serial=c1477133-6b06-480d-a233-1dae08daf8b3,cache=none,werror=stop,rerror=stop,aio=threads

So it is referred as mount point and not gluster:// way
Also, the output of mount command on hypervisors shows:

node01.mydomain:gvdata on
/rhev/data-center/mnt/glusterSD/node01.mydomain:gvdata type
fuse.glusterfs 
(rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

and it seems indeed fuse mount, so not using libgfapi...
output of
lsof -Pp pid where pid is the qemu process shows libgfapi:

qemu-syst 2057 qemu  mem   REG  253,0  99440
 541417 /usr/lib64/libgfapi.so.0.0.0

(btw: strange version 0.0.0 for a release.. not so reassuring ;-)


libgfapi uses a different internal versioning scheme and hence 
compatibility can be handled. However there is work happening in 
glusterfs upstream to change the version scheme for libraries and have 
it compatible with libtool guidelines.



# ll /usr/lib64/libgfapi.so.0*
lrwxrwxrwx. 1 root root17 Jan  7 12:45 /usr/lib64/libgfapi.so.0 -
libgfapi.so.0.0.0
-rwxr-xr-x. 1 root root 99440 Jan  3 13:35 /usr/lib64/libgfapi.so.0.0.0
)

At page http://www.gluster.org/category/qemu/ there is a schema about
mount types and benchmarks

1) FUSE mount
2) GlusterFS block driver in QEMU (FUSE bypass)
3) Base (VM image accessed directly from brick)
(
qemu-system-x86_64 –enable-kvm –nographic -smp 4 -m 2048 -drive
file=/test/F17,if=virtio,cache=none = /test is brick directory
)

I have not understood if we are in Base (best performance) or FUSE
(worst performance)



In this particular blog post, base refers to local disk storage and the 
FUSE performance was measured before a set of optimizations were done in 
GlusterFS. The Optimize for Virt action in oVirt ensures that these 
optimizations are enabled. Hence, even with FUSE the performance for VM 
image storage would be somewhere between the worst and best cases.




thanks in advance for clarifications and possible roadmaps...


If you are interested in seeing any new feature related to the 
oVirt-Gluster integration, please feel free to let us know as part of 
the GlusterFS 3.6 planning process [1] which is ongoing now.


- Vijay

[1] http://www.gluster.org/community/documentation/index.php/Planning36
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Stopping glusterfsd service shut down data center

2014-01-06 Thread Vijay Bellur

Adding gluster-users.

On 01/06/2014 12:25 AM, Amedeo Salvati wrote:

Hi all,

I'm testing ovirt+glusterfs with only two node for all (engine,
glusterfs, hypervisors),  on centos 6.5 hosts following guide at:

http://community.redhat.com/blog/2013/09/up-and-running-with-ovirt-3-3/
http://www.gluster.org/2013/09/ovirt-3-3-glusterized/

but with some change like setting on glusterfs, parameter
cluster.server-quorum-ratio to 50% (due to prevent glusterfs to go down
if one node goes done) and option on /etc/glusterfs/glusterd.vol option
base-port 50152 (due to libvirt port conflict).

So, with the above parameter I was able to stop/reboot node not used to
directly mount glusterfs (eg lovhm002), but when I stop/reboot node,
that is used to mount glusterfs (eg node lovhm001), all data center goes
done, especially when I stop service glusterfsd (not glusterd
service!!!), but the glusterfs still alive and is reachable on node
lovhm002 that survives but ovirt/libvirt marks DC/storage in error.

Do you have any ideas to configure DC/Cluster on ovirt that remains
aware if node used to mount glusterfs goes down?



This seems to be due to client quorum in glusterfs. It can be observed 
that client quorum is on since option cluster.quorum-type has been set 
to value auto.


client quorum gets enabled by default as part of Optimize for Virt 
action in oVirt or by enabling volume set group virt in gluster CLI. 
client quorum gets enabled by default to provide additional protection 
against split-brains. In case of a gluster volume with replica count  
2, client quorum returns an error if writes/updates fail in more than 
50% of the bricks. However, when the replica count happens to be 2, 
updates are failed if the first server/glusterfsd is not online.


If the chances of a network partition and a split brain is not 
significant in your setup, you can turn off client quorum by setting 
option cluster.quorum-type to value none.


Regards,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Creation of preallocated disk with Gluster replication

2014-01-02 Thread Vijay Bellur

Adding gluster-users.

On 01/02/2014 08:50 PM, gregoire.le...@retenodus.net wrote:

Hello,

I have a Gluster volume in distributed/replicated mode. I have 2 hosts.
When I try to create a VM with a preallocated disk, it uses 100% of the
available CPU and bandwidth (I have 1 Gigabit network card).
The result is I can't even create a preallocated disk because the engine
detects a network failure.

I get that kind of messages in /var/log/messages :

Jan  2 14:13:54 localhost sanlock[3811]: 2014-01-02 14:13:54+0100 167737
[3811]: s4 kill 21114 sig 15 count 1
Jan  2 14:13:54 localhost wdmd[3800]: test failed rem 51 now 167737 ping
167718 close 167728 renewal 167657 expire 167737 client 3811
sanlock_ef4978d6-5711-4e01-a0ec-7ffbd9 cdbe5d:1


And that in the Ovirt Gui :

2014-janv.-02, 15:35 Operation Add-Disk failed to complete.
2014-janv.-02, 15:35 Storage Pool Manager runs on Host HOST2 (Address:
X.X.X.X).
2014-janv.-02, 15:35 Invalid status on Data Center GlusterSewan. Setting
Data Center status to Non Responsive (On host HOST2, Error: done).
2014-janv.-02, 15:35 State was set to Up for host HOST2.
2014-janv.-02, 15:33 Used Network resources of host HOST2 [98%] exceeded
defined threshold [95%].
2014-janv.-02, 15:33 Add-Disk operation of test_Disk1 was initiated on
VM test by admin@internal.

I understand that the creation of a 10 Go disk image generates a lot of
traffic, but is there a way to limit it so that it doesn't have an
impact on the production ? Furthermore, Why does it use so much CPU
ressources ? I can see on my monitoring graph a big peak of CPU usage
when I launched the operation (probably until 100%).


Do you happen to notice what is consuming CPU? Since the same cluster 
does both virtualization and storage, a GigE network might get saturated 
very quickly. Is it possible to separate out the management and 
data/gluster traffic in this setup?


Regards,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] GlusterFS Distributed Replicate

2013-12-23 Thread Vijay Bellur

On 12/23/2013 06:24 PM, gregoire.le...@retenodus.net wrote:

Hi,


For the 2 host scenario, disable quorum will allow you to do this.


I just disabled quorum and disabled the auto migration for my cluster.
Here is what I get :

To remind, the path of my storage is localhost:/path and I selected
HOSTA as host.
Volume options are :
cluster.server-quorum-type none
cluster.quorum-type fixed
cluster.quorum-count 1



With this configuration, client side quorum is enabled and allows 
operations to continue as long as one brick is available. Is this the 
intended behaviour?



If one host is shutdown, le storage and cluster become shutdown. = Do
you have any idea about why I get this behaviour ?



Are bricks seen online in gluster volume status volname?

Thanks,
Vijay




Is there a way to
avoid it ?
VM on the UP host are OK; which is the expected behaviour.
I can migrate VM from one host to another when they're both UP.

However, when a host is down, VM on this host don't become down but in
an unknown state instead. Is it a normal behaviour ? If so, how am I
supposed to make them manually boot on the other host ?

Thank you,
Regards,
Grégoire Leroy
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] R: Re: How to - gluster

2013-12-17 Thread Vijay Bellur

On 12/17/2013 02:00 AM, tristan...@libero.it wrote:

yes my idea is to start with 1 node  ( storage+compute ) and then expand with
more server to add storage and compute.

what do you think ?



Definitely doable. I have not come across many instances of this in the 
community and would recommend to test your use cases thoroughly before 
going to production. Any feedback that you have from this would be 
interesting to us.


Thanks,
Vijay


Messaggio originale
Da: vbel...@redhat.com
Data: 16/12/2013 8.38
A: tristan...@libero.ittristan...@libero.it, users@ovirt.org
Ogg: Re: [Users] How to - gluster

On 12/15/2013 10:30 PM, tristan...@libero.it wrote:

i have 1 phisical node with SSD disks, can i install ovirt with glusterFS
storage as backend  . In a second time add new ovirt node ( same hardware )
and
attach to the first 1 to create a compute and storage HA ?




gluster volumes can be expanded from a single brick to multiple bricks
for providing HA.

Do you plan to use a converged compute and storage cluster?

Regards,
Vijay







___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] How to - gluster

2013-12-15 Thread Vijay Bellur

On 12/15/2013 10:30 PM, tristan...@libero.it wrote:

i have 1 phisical node with SSD disks, can i install ovirt with glusterFS
storage as backend  . In a second time add new ovirt node ( same hardware )
and
attach to the first 1 to create a compute and storage HA ?




gluster volumes can be expanded from a single brick to multiple bricks 
for providing HA.


Do you plan to use a converged compute and storage cluster?

Regards,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] install ovirt-engine-3.3.1, dependency broken

2013-12-10 Thread Vijay Bellur

On 12/09/2013 07:32 PM, lofyer wrote:

I was installing ovirt-engine-3.3.1 in CentOS-6.5 and got dependency
error below:
Error: Package: glusterfs-cli-3.4.0-8.el6.x86_64 (glusterfs-epel)
Requires: glusterfs-lib = 3.4.0-8.el6.x86_64
Available: glusterfs-3.4.0-8.el6.x86_64 (glusterfs-epel)
glusterfs-libs = 3.4.0-8.el6
Available: glusterfs-libs-3.4.0-8.el6.x86_64 (glusterfs-epel)
glusterfs-libs = 3.4.0-8.el6
Installing: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64 (base)
glusterfs-libs = 3.4.0.36rhs-1.el6
Installing: glusterfs-3.4.0.36rhs-1.el6.x86_64 (base)
Not found

I've got epel, rpm-fusion, ovirt, gluster-epel and gluster besides
CentOS standard repos in my box.
What should I do then?



You can upgrade to glusterfs-3.4.1 RPMs from gluster repo and attempt 
the ovirt-engine upgrade.


Regards,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Gluster storage

2013-11-29 Thread Vijay Bellur

On 11/29/2013 03:35 AM, tristan...@libero.it wrote:

Hello everybody,

i'm successful using ovirt with 16 physical node, in a FC cluster with a very
BIG dell compellent (and so expensive) enterprise storage ;)

I'm researching a new architecture for a new cluster, and i want to
understand
more better the glusterFS integration in ovirt.


GlusterFS is integrated with oVirt in two ways:

1. Use oVirt to manage gluster storage configuration options.

2. Use GlusterFS as a storage domain.



As i understand you have to install a normal physical node, with also the
glusterFS package… right ? after that you have to create a new cluster in
ovirt
, new datacenter and put in this new node. in that datacenter you can create
a
new data domain ( glusterFS ) that reside on that host. right ?


A cluster in oVirt can be configured to behave in 3 ways:

(i) virtualization only

(ii) Gluster storage only

(iii) virtualization + gluster storage

You need (ii) or (iii) to provide oVirt with the ability to perform 
gluster storage configuration and management. You can also configure 
gluster using its CLI and use (i) or (iii) for a glusterfs storage 
domain. You can also have two clusters for (i), (ii) and manage both 
using oVirt.


There are two ways in which GlusterFS can be used as a storage domain:

a) Use gluster native/fuse access with POSIXFS

b) Use the gluster native storage domain to bypass fuse (with libgfapi). 
We are currently addressing an issue in libvirt 
(https://bugzilla.redhat.com/show_bug.cgi?id=1017289) to enable snapshot 
support with libgfapi. Once this is addressed, we will have libgfapi 
support in the native storage domain. Till then, fuse would be used with 
native storage domain. You can find more details about native storage 
domain here:


http://www.ovirt.org/Features/GlusterFS_Storage_Domain



and… after that ? ok i have 1 node that are also my  storage , and if i
want
to all more compute node ? … every new compute node are a new  brick  for
glusterFS so i can expand/redundant the first one ?


If you are having separate compute/virtualization and storage clusters, 
you would not be required to create bricks on your compute nodes. 
However if you are using a single cluster for both compute and storage 
(as in iii above), you need not necessarily have bricks on all compute 
nodes.



HTH,
Vijay



i don't have the architecture very clear in my mind, and the documentation
don't clarify the final architecture for this type of usage.






___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Trouble upgrading

2013-11-22 Thread Vijay Bellur

On 11/22/2013 01:00 PM, Itamar Heim wrote:

On 11/22/2013 06:08 AM, Vijay Bellur wrote:

On 11/22/2013 06:25 AM, Bob Doolittle wrote:


On 11/21/2013 07:53 PM, Itamar Heim wrote:

On 11/22/2013 02:52 AM, Bob Doolittle wrote:


On 11/21/2013 07:48 PM, Itamar Heim wrote:

On 11/22/2013 02:33 AM, Bob Doolittle wrote:


On 11/21/2013 12:57 PM, Itamar Heim wrote:

On 11/21/2013 07:38 PM, Bob Doolittle wrote:


On 11/21/2013 12:00 PM, Itamar Heim wrote:

On 11/21/2013 06:32 PM, Bob Doolittle wrote:

Yay!

Congratulations to all of the oVirt team.

I am having trouble locating upgrade instructions, however.
There's
nothing in the release notes.

I discovered through trial-and-error that running engine-setup
again
handles upgrade of the Engine.

But I don't know how to upgrade my RH 6.4 KVM host. When I
try to
run
yum update it fails due to dependency errors notably in:
glusterfs
qemu
vdsm



can you please include the yum output log?


Sorry yes. Attached are three outputs. First my repolist. Then yum
update with no options, and yum update with --skip-broken (so you
can
see the lurking issues masked by the first failure).

It appears that the glusterfs issue is due to a newer version
offered by
rhel-x86_64-server-6: glusterfs-3.4.0.36rhs-1.el6.x86_64. This has
dependencies which conflict with the version provided by
ovirt-stable
(and glusterfs-epel).

It looks like there was a large update to the Red Hat repo last
night
that has caused conflicts with ovirt-stable.

Note I can get it to the point where it's willing to install
packages if
I specify --skip-broken and also --exclude vdsm-python-4.12.1, but
that's a bit too scary for me without checking first.


oh, you may caught rhel repo in middle of a refresh - try again
in a
few hours first, but could be the refresh may cause an issue we'd
need
to resolve.


Not sure why I'm the only person reporting this (am I the only
person
who runs RH 6 on their KVM hosts who has tried upgrading??), but the
problem has not resolved.

What's the next step? Does it need a bug opened?

Let me know if I can provide any more information.



have you tried refreshing your repo / clear yum cache?
(since glusterfs-3.4.0.36rhs-1.el6 should be in the repo)


I just did yum clean all; yum update. Same result.



do you have glusterfs-3.4.0.36rhs-1.el6 in the repo?


Apparently:


Error: Package: glusterfs-cli-3.4.0-8.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-libs = 3.4.0-8.el6
   Removing: glusterfs-3.4.0-8.el6.x86_64 (@glusterfs-epel)
   glusterfs-libs = 3.4.0-8.el6
   Updated By: glusterfs-3.4.0.36rhs-1.el6.x86_64
(rhel-x86_64-server-6)
   Not found
   Removing: glusterfs-libs-3.4.0-8.el6.x86_64
(@glusterfs-epel)
   glusterfs-libs = 3.4.0-8.el6
   Updated By: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64
(rhel-x86_64-server-6)
   glusterfs-libs = 3.4.0.36rhs-1.el6
   Available: glusterfs-3.2.7-1.el6.i686 (epel)
   glusterfs-libs = 3.2.7-1.el6





If you are using EPEL packages to create/run gluster volumes on RHEL
(essentially the server side functionality of gluster), it would be
better to move to GlusterFS 3.4.1 and then try the upgrade.

If you are not making use of gluster's server side packages, you can
remove glusterfs-cli and related dependencies. If an upgrade is
initiated after that, it should go through.

Regards,
Vijay


doesn't vdsm require vdsm-gluster which requires them?


vdsm requires vdsm-gluster only in gluster, gluster+virt clusters. Hence 
if gluster server side functionality is being exercised, we would need 
to use EPEL packages.


For a virt only cluster, only the client side packages are needed and 
RHEL 6.5 has these packages.


Thanks,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Trouble upgrading

2013-11-22 Thread Vijay Bellur

On 11/22/2013 06:23 PM, Bob Doolittle wrote:


On 11/22/2013 06:54 AM, Kristaps wrote:

Bob Doolittle bob@... writes:



On 11/21/2013 12:57 PM, Itamar Heim wrote:

On 11/21/2013 07:38 PM, Bob Doolittle wrote:

On 11/21/2013 12:00 PM, Itamar Heim wrote:

On 11/21/2013 06:32 PM, Bob Doolittle wrote:

Yay!

Congratulations to all of the oVirt team.

I am having trouble locating upgrade instructions, however. There's
nothing in the release notes.

I discovered through trial-and-error that running engine-setup

again

handles upgrade of the Engine.

But I don't know how to upgrade my RH 6.4 KVM host. When I try to
run
yum update it fails due to dependency errors notably in:
glusterfs
qemu
vdsm


can you please include the yum output log?

Sorry yes. Attached are three outputs. First my repolist. Then yum
update with no options, and yum update with --skip-broken (so you can
see the lurking issues masked by the first failure).

It appears that the glusterfs issue is due to a newer version offered

by

rhel-x86_64-server-6: glusterfs-3.4.0.36rhs-1.el6.x86_64. This has
dependencies which conflict with the version provided by ovirt-stable
(and glusterfs-epel).

It looks like there was a large update to the Red Hat repo last night
that has caused conflicts with ovirt-stable.

Note I can get it to the point where it's willing to install packages

if

I specify --skip-broken and also --exclude vdsm-python-4.12.1, but
that's a bit too scary for me without checking first.

oh, you may caught rhel repo in middle of a refresh - try again in a
few hours first, but could be the refresh may cause an issue we'd need
to resolve.

Not sure why I'm the only person reporting this (am I the only person
who runs RH 6 on their KVM hosts who has tried upgrading??), but the
problem has not resolved.

What's the next step? Does it need a bug opened?

Let me know if I can provide any more information.

Thanks,
  Bob


Thanks,
  Bob


and also to a multilib version error due to vdsm-python 4.12 and

4.13.

What's the proper upgrade procedure for a Host?

Thanks,
  Bob

On 11/21/2013 10:43 AM, Kiril Nesenko wrote:

The oVirt development team is very happy to announce the general
availability of oVirt 3.3.1 as of November 21th 2013. This release
solidifies oVirt as a leading KVM management application, and open
source alternative to VMware vSphere.

oVirt is available now for Fedora 19 and Red Hat Enterprise Linux

6.4

(or similar).

See release notes [1] for a list of the new features and bug fixed.

[1] http://www.ovirt.org/OVirt_3.3.1_release_notes

- Kiril

___
Users mailing list
Users@...
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@...
http://lists.ovirt.org/mailman/listinfo/users

I'am experiencing same exact issue with upgrade on RHEL 6.4 and vdsm for
oVirt installed.

However, I did a little searching, and for me it seems it is like this:
vds requires these glsuterfs packages to have the latest version:

glusterfs
glusterfs-api
glusterfs-cli
glusterfs-fuse
glusterfs-libs

In RHEL repository are these packages are with version 3.4.0.36rhs-
1.el6.x86_64 EXCEPT for glusterfs-cli, which RHEL repo doesn't have at
all.

oVirt repo has all those packages with version 3.4.0-8.el6.x86_64,
which is
older than RHEL repo packages.

Hence, there is conflict. During vdsm update or even installation on RHEL
6.4 it tries to install the latest of all those packages. Looks likes
this:

glusterfs-3.4.0.36rhs-1.el6.x86_64
glusterfs-api-3.4.0.36rhs-1.el6.x86_64
glusterfs-fuse-3.4.0.36rhs-1.el6.x86_64
requires: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64

glusterfs-cli-3.4.0-8.el6.x86_64
requires: glusterfs-libs-3.4.0-8.el6.x86_64

While this is not fixed, in my opinion, ovirt installation from
repository
on RHEL 6.4 is essentially broken.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Thank you for confirming that this is indeed an issue. I was beginning
to think it was just me somehow. I have opened
https://bugzilla.redhat.com/show_bug.cgi?id=1033587 to track this.

I agree it seems to be a very big issue for RHEL 6 users. And we can't
simply uninstall glusterfs-cli, as Vijay suggested, because it is
required by vdsm. So I'm not seeing any easy workaround at the moment.


Would it be possible to update to glusterfs-3.4.1 by adding this repo?

http://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.1/RHEL/glusterfs-epel.repo

Once the glusterfs packages are updated, the yum upgrade shouldn't break 
as glusterfs-3.4.0 is available in RHEL 6.


-Vijay





I'm wondering if the qemu issue I was when I tried --skip-broken is just
an artifact of this, or some other issue entirely. We won't know until
this glusterfs-cli issue is resolved.

-Bob




___
Users mailing list
Users@ovirt.org

Re: [Users] Trouble upgrading

2013-11-22 Thread Vijay Bellur

On 11/22/2013 11:18 PM, Bob Doolittle wrote:


On 11/22/2013 12:21 PM, Vijay Bellur wrote:

On 11/22/2013 06:23 PM, Bob Doolittle wrote:


On 11/22/2013 06:54 AM, Kristaps wrote:

Bob Doolittle bob@... writes:



On 11/21/2013 12:57 PM, Itamar Heim wrote:

On 11/21/2013 07:38 PM, Bob Doolittle wrote:

On 11/21/2013 12:00 PM, Itamar Heim wrote:

On 11/21/2013 06:32 PM, Bob Doolittle wrote:

Yay!

Congratulations to all of the oVirt team.

I am having trouble locating upgrade instructions, however.
There's
nothing in the release notes.

I discovered through trial-and-error that running engine-setup

again

handles upgrade of the Engine.

But I don't know how to upgrade my RH 6.4 KVM host. When I try to
run
yum update it fails due to dependency errors notably in:
glusterfs
qemu
vdsm


can you please include the yum output log?

Sorry yes. Attached are three outputs. First my repolist. Then yum
update with no options, and yum update with --skip-broken (so you
can
see the lurking issues masked by the first failure).

It appears that the glusterfs issue is due to a newer version
offered

by

rhel-x86_64-server-6: glusterfs-3.4.0.36rhs-1.el6.x86_64. This has
dependencies which conflict with the version provided by
ovirt-stable
(and glusterfs-epel).

It looks like there was a large update to the Red Hat repo last
night
that has caused conflicts with ovirt-stable.

Note I can get it to the point where it's willing to install
packages

if

I specify --skip-broken and also --exclude vdsm-python-4.12.1, but
that's a bit too scary for me without checking first.

oh, you may caught rhel repo in middle of a refresh - try again in a
few hours first, but could be the refresh may cause an issue we'd
need
to resolve.

Not sure why I'm the only person reporting this (am I the only person
who runs RH 6 on their KVM hosts who has tried upgrading??), but the
problem has not resolved.

What's the next step? Does it need a bug opened?

Let me know if I can provide any more information.

Thanks,
  Bob


Thanks,
  Bob


and also to a multilib version error due to vdsm-python 4.12 and

4.13.

What's the proper upgrade procedure for a Host?

Thanks,
  Bob

On 11/21/2013 10:43 AM, Kiril Nesenko wrote:

The oVirt development team is very happy to announce the general
availability of oVirt 3.3.1 as of November 21th 2013. This
release
solidifies oVirt as a leading KVM management application, and
open
source alternative to VMware vSphere.

oVirt is available now for Fedora 19 and Red Hat Enterprise Linux

6.4

(or similar).

See release notes [1] for a list of the new features and bug
fixed.

[1] http://www.ovirt.org/OVirt_3.3.1_release_notes

- Kiril

___
Users mailing list
Users@...
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@...
http://lists.ovirt.org/mailman/listinfo/users

I'am experiencing same exact issue with upgrade on RHEL 6.4 and vdsm
for
oVirt installed.

However, I did a little searching, and for me it seems it is like this:
vds requires these glsuterfs packages to have the latest version:

glusterfs
glusterfs-api
glusterfs-cli
glusterfs-fuse
glusterfs-libs

In RHEL repository are these packages are with version 3.4.0.36rhs-
1.el6.x86_64 EXCEPT for glusterfs-cli, which RHEL repo doesn't have at
all.

oVirt repo has all those packages with version 3.4.0-8.el6.x86_64,
which is
older than RHEL repo packages.

Hence, there is conflict. During vdsm update or even installation on
RHEL
6.4 it tries to install the latest of all those packages. Looks likes
this:

glusterfs-3.4.0.36rhs-1.el6.x86_64
glusterfs-api-3.4.0.36rhs-1.el6.x86_64
glusterfs-fuse-3.4.0.36rhs-1.el6.x86_64
requires: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64

glusterfs-cli-3.4.0-8.el6.x86_64
requires: glusterfs-libs-3.4.0-8.el6.x86_64

While this is not fixed, in my opinion, ovirt installation from
repository
on RHEL 6.4 is essentially broken.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Thank you for confirming that this is indeed an issue. I was beginning
to think it was just me somehow. I have opened
https://bugzilla.redhat.com/show_bug.cgi?id=1033587 to track this.

I agree it seems to be a very big issue for RHEL 6 users. And we can't
simply uninstall glusterfs-cli, as Vijay suggested, because it is
required by vdsm. So I'm not seeing any easy workaround at the moment.


Would it be possible to update to glusterfs-3.4.1 by adding this repo?

http://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.1/RHEL/glusterfs-epel.repo


Once the glusterfs packages are updated, the yum upgrade shouldn't
break as glusterfs-3.4.0 is available in RHEL 6.

-Vijay



Vijay,

Do you know why the glusterfs folks felt compelled to do a minor update
of 3.4.0 to 3.4.1 utilizing an entirely new repository, instead of
reusing the old repository with new

Re: [Users] [node-devel] GlusterFS on oVirt node

2013-10-26 Thread Vijay Bellur

On 10/25/2013 11:57 AM, Fabian Deutsch wrote:

Am Donnerstag, den 24.10.2013, 19:59 +0200 schrieb Saša Friedrich:

I reinstalled node and remounter / rw then I checked fs before
activating host (in oVirt Engine) and after (which files have been
changed)... The ro problem seems to be in /var/lib/glusterd/. Is there
any way I can change node so this directory would be mounted rw? And to
persist this setting after reboot.


Hey,

do you know if the data in /var/lib/glusterd needs to survive reboots?


/var/lib/glusterd does need to survive reboots.

-Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] oVirt October Updates

2013-10-21 Thread Vijay Bellur

On 10/19/2013 10:44 AM, Gianluca Cecchi wrote:

On Wed, Oct 16, 2013 at 1:01 PM, Itamar Heim wrote:

Hope to meet many next week in LinuxCon Europe/KVM Forum/oVirt conference in
Edinburgh


Unfortunately not me ;-(



- LINBIT published High-Availability oVirt-Cluster with
   iSCSI-Storage[9]




[9] note: link requires registeration:
http://www.linbit.com/en/company/news/333-high-available-virtualization-at-a-most-reasonable-price
the pdf is:
http://www.linbit.com/en/downloads/tech-guides?download=68:high-availability-ovirt-cluster-with-iscsi-storage


About 3 years ago I successfully tested plain Qemu/KVM with two nodes
and drbd dual-primary with live migration on Fedora, so I know it
works very well.
I think the LINBIT guide gives many suggestions, one of them is in
particular just another way to have a High Available oVirt Engine for
example, that is a hot topic lately
Deep attention is to be put in fencing mechanism though, as always it
is in general when talking about drbd, pacemaker, oVirt.
I don't know it quite well, but the drbd proxy feature (closed source
and not free) could also be then an option for DR in small
environments

I'm going to experiment the solution of the paper (possibly using
clusterlabs.org repo for cluster and so using corosync instead of
heartbeat).
To compare in small environments where two nodes are ok, in my opinion
glusterfs is far away from robust at the moment: with 3.4.1 on fedora
19 I cannot put a host in maintenance and get back a workable node
after normal reboot.


Are you referring to the absence of self-healing after maintenance? 
Please see below as to why this should not happen. If there's a 
reproducible test case, it would be good to track this bug at:


https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS


Didn't find any safe way for a node in distributed-replicated two
nodes config to leave the cluster and get it back without becoming
crazy to manual solve the brick differences generated in the mean
time. And this was with only one VM running .
Possibly I have to dig more in this, but I didn't find great resources
for it. Any tips/links are welcome


The following commands might help:

1. gluster volume heal volname  - perform a fast index based self-heal

2. gluster volume heal volname full - perform a full self-heal if 1. 
does not work.


3. gluster volume heal volname info - provide information about 
files/directories that were healed recently.


Neither of 1. or 2. would be required in normal operational course as 
the proactive self-healing feature in glusterfs takes care of healing 
after a node comes online.




I would like to have oVirt more conscious about it and have sort of
capability to solve itself the misalignments generated on gluster
backend during mainteneance of a node.
At the moment it seems to me it only shows volumes are ok in the sense
of started, but they could be very different...
For example another tab with details about heal info; something like
the output of the command

gluster volume heal $VOLUME info

and/or

gluster volume heal $VOLUME info split-brain


Yes, we are looking to build this for monitoring replicated gluster volumes.

- Vijay


so that if one finds 0 entries, he/she is calm and at the same doesn't
risk to be erroneously calm in the other scenario...

just my opinion.

Gianluca
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] unable to start vm in 3.3 and f19 with gluster

2013-09-25 Thread Vijay Bellur

On 09/25/2013 11:36 AM, Gianluca Cecchi wrote:

qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
Gluster connection failed for server=ovnode01 port=0 volume=gv01
image=20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161
transport=tcp
qemu-system-x86_64: -drive
file=gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161,if=none,id=drive-virtio-disk0,format=raw,serial=d004045e-620b-4d90-8a7f-6c6d26393a08,cache=none,werror=stop,rerror=stop,aio=threads:
could not open disk image
gluster://ovnode01/gv01/20042e7b-0929-48ca-ad40-2a2aa22f0689/images/d004045e-620b-4d90-8a7f-6c6d26393a08/dff09892-bc60-4de5-85c0-2a1fa215a161:
No data available
2013-09-25 05:42:32.291+: shutting down



Have the following configuration changes been done?

1) gluster volume set volname server.allow-insecure on

2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to contain this 
line:

option rpc-auth-allow-insecure on

Post 2), restarting glusterd would be necessary.

Regards,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] unable to start vm in 3.3 and f19 with gluster

2013-09-25 Thread Vijay Bellur

On 09/25/2013 11:51 AM, Gianluca Cecchi wrote:

On Wed, Sep 25, 2013 at 8:11 AM, Vijay Bellur  wrote:




Have the following configuration changes been done?

1) gluster volume set volname server.allow-insecure on

2) Edit /etc/glusterfs/glusterd.vol on all gluster nodes to contain this
line:
 option rpc-auth-allow-insecure on

Post 2), restarting glusterd would be necessary.

Regards,
Vijay



No, because I didn't find find this kind of info anywhere... ;-)


The feature page wiki does provide this information but it gets missed 
in the details. Should we highlight it more?




Done on both hosts (step 1 only one time) and I see that the gui
detects the change in volume setting.
Now the VM can start (I see the qemu process on ovnode02) but it seems
to remain in hourglass state icon.
After 5 minutes it still remains in executing phase in tasks



Let us know how this goes.

-Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Cannot start VMs or delete disks from gluster storage

2013-09-23 Thread Vijay Bellur

On 09/23/2013 08:08 PM, David Riedl wrote:

Hello everyone,
I recently created my first ovirt/vdms/gluster cluster. I did everything
as it is described in the ovirt and glusterfs quick start.
The glusterfs Domain is recognized in the UI and is also mounted in the
system. Everything looks fine to me. I can even create VMs.
But when I try to start them, the VM is stuck and doesn't start up and I
don't get any error message (in the WebUI) either.
I can delete the VM, but not the disk.

OS Version:
RHEL - 6 - 4.el6.centos.10
Kernel Version:
2.6.32 - 358.18.1.el6.x86_64
KVM Version:
0.12.1.2 - 2.355.0.1.el6.centos.7
LIBVIRT Version:
libvirt-0.10.2-18.el6_4.14
VDSM Version:
vdsm-4.12.1-2.el6
SPICE Version:
0.12.0 - 12.el6_4.3



What versions of qemu and glusterfs are you using?



Oh and which log files do you need?

Regards

David

PS: Sorry if this is the wrong place to ask such things/problems. I'm
pretty new to oVirt. :)


This certainly is the right place to ask for all queries related to oVirt :)



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] attaching glusterfs storage domain -- method glusterServicesGet is not supported

2013-07-16 Thread Vijay Bellur

On 07/16/2013 06:02 PM, Itamar Heim wrote:

On 07/02/2013 12:01 AM, Steve Dainard wrote:

Creating /var/lib/glusterd/groups/virt on each node and adding
parameters found here:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Storage/2.0/html/Quick_Start_Guide/chap-Quick_Start_Guide-Virtual_Preparation.html
solved
this issue.


vijay - anything that should be fixed so no manual intervention will be
needed?



Logged https://bugzilla.redhat.com/show_bug.cgi?id=985085 for tracking this.

Thanks,
Vijay






Steve Dainard
Infrastructure Manager
Miovision Technologies Inc.
Phone: 519-513-2407 x250


On Mon, Jul 1, 2013 at 4:54 PM, Steve Dainard sdain...@miovision.com
mailto:sdain...@miovision.com wrote:

I'm using Ovirt nightly on Fedora 18 to determine if ovirt + gluster
is something that will work for my organization (or at least when
RHEV is released with this functionality). I'm attempting to use the
nodes for both virt and gluster storage.

I've successfully created gluster bricks on two hosts, ovirt001 
ovirt002, and started volume vol1 through engine web ui. I've
created a gluster storage domain, but cannot attach to data center.

*Engine UI error:*
Failed to attach Storage Domains to Data Center Default. (User:
admin@internal)

*Engine /var/log/ovirt-engine/engine.log errors:*
2013-07-01 16:29:02,650 ERROR

[org.ovirt.engine.core.vdsbroker.gluster.GlusterServicesListVDSCommand]
(pool-6-thread-49) Command GlusterServicesListVDS execution failed.
Exception: VDSNetworkException: org.apache.xmlrpc.XmlRpcException:
type 'exceptions.Exception':method glusterServicesGet is not
supported
I've attached the much larger log file

*Host
/var/log/glusterfs/rhev-data-center-mnt-glusterSD-ovirt001\:vol1.log
when attaching:*
[2013-07-01 20:40:33.718871] I
[afr-self-heal-data.c:655:afr_sh_data_fix] 0-vol1-replicate-0: no
active sinks for performing self-heal on file
/b2076340-84de-45ff-9d4b-d0d48b935fca/dom_md/ids
[2013-07-01 20:40:33.721059] W
[client-rpc-fops.c:873:client3_3_writev_cbk] 0-vol1-client-0: remote
operation failed: Invalid argument
[2013-07-01 20:40:33.721104] W
[client-rpc-fops.c:873:client3_3_writev_cbk] 0-vol1-client-1: remote
operation failed: Invalid argument
[2013-07-01 20:40:33.721130] W [fuse-bridge.c:2127:fuse_writev_cbk]
0-glusterfs-fuse: 304: WRITE = -1 (Invalid argument)

*Engine repos:*
[root@ovirt-manager2 yum.repos.d]# ll
total 16
-rw-r--r--. 1 root root 1145 Dec 20  2012 fedora.repo
-rw-r--r--. 1 root root 1105 Dec 20  2012 fedora-updates.repo
-rw-r--r--. 1 root root 1163 Dec 20  2012 fedora-updates-testing.repo
-rw-r--r--. 1 root root  144 Jun 21 18:34 ovirt-nightly.repo

[root@ovirt-manager2 yum.repos.d]# cat *
[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority

#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/


mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releaseverarch=$basearch

enabled=1
#metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

[fedora-debuginfo]
name=Fedora $releasever - $basearch - Debug
failovermethod=priority

#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/


mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releaseverarch=$basearch

enabled=0
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

[fedora-source]
name=Fedora $releasever - Source
failovermethod=priority

#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/


mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-source-$releaseverarch=$basearch

enabled=0
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority

#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/


mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releaseverarch=$basearch

enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

[updates-debuginfo]
name=Fedora $releasever - $basearch - Updates - Debug
failovermethod=priority

#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/debug/


mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f$releaseverarch=$basearch

enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

[updates-source]
name=Fedora $releasever - Updates Source
failovermethod=priority


Re: [Users] Issues using local storage for gluster shared volume

2013-04-01 Thread Vijay Bellur

On 03/29/2013 07:19 PM, Tony Feldmann wrote:

Aren't there concerns with xfs and large files in cases of failures?  I
was under the impression that if xfs was writing to a file and the
system died it would zero out the entire file.  Just hesitant to put
large vm files on a fs like that.  Is this still an issue with xfs?


There are no known problems with recent kernels. There are quite a few 
enterprise storage solutions that run on xfs.


Thanks,
Vijay



On Fri, Mar 29, 2013 at 1:08 AM, Vijay Bellur vbel...@redhat.com
mailto:vbel...@redhat.com wrote:

On 03/28/2013 08:19 PM, Tony Feldmann wrote:

I have been trying for a month or so to get a 2 node cluster up and
running.  I have engine installed on the first node, then add
each each
system as a host to a posix dc.  Both boxes have 4 data disks.
  After
adding the hosts I create a distributed replicate volume using 3
disk
from each host with ext4 filesystems. I click the 'optimize for
virt'
option on the volume.  There is a message in events that says
that it
can't set a volume option, then it sets 2 volume options.
  Checking the
options tab I see that it added the gid/uid options.  I was
unable to
find in the logs what option was not set, I just see a message about
usage for volume set volname option.  The volume starts fine
and I
am able to create a data domain on the volume.  Once the domain is
created I try to create a vm and it fails creating the disk.  Error
messages are along the lines of task file exists and can't
remove task
files.  There are directories under tasks and when trying to
manually
remove them I get the directory not empty error.  Can someone
please
shed some light on what I am doing wrong to get this 2 node
cluster with
local disk as shared storage up and running?


There are known problems with ext4 and gluster at the moment. Can
you please confirm if you see similar behaviour with xfs and gluster?

Thanks,
Vijay




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] 2 node cluster with local storage?

2013-04-01 Thread Vijay Bellur

On 04/01/2013 06:13 PM, russell muetzelfeldt wrote:

On 01/04/2013, at 8:53 PM, Itamar Heim ih...@redhat.com wrote:

On 04/01/2013 12:33 PM, russell muetzelfeldt wrote:


Is there any supported way (or advice on the best unsupported way) to provision 
a 2-node cluster using local storage?


have you considered using gluster? if you setup the cluster as 'gluster' as 
well, it should be installed, you should be able to create a volume on it, then 
create a posixfs storage domain using it (and in ovirt 3.3, a glusterfs storage 
domain, which will provide better performance)?



I've got to admit I'd discounted gluster mainly because I've never touched it 
before and assumed the learning curve would distract me from what I actually 
want to be doing (getting a reasonably functional cluster to use as a target 
for programming against the REST API).

Is the gluster support reasonably straightforward out of the box? If so I might 
give that a go and see how it pans out.


Yes, setting up gluster is considered relatively easy. You can reach out 
for support here and/or on gluster-users mailing list.


Cheers,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Issues using local storage for gluster shared volume

2013-03-29 Thread Vijay Bellur

On 03/28/2013 08:19 PM, Tony Feldmann wrote:

I have been trying for a month or so to get a 2 node cluster up and
running.  I have engine installed on the first node, then add each each
system as a host to a posix dc.  Both boxes have 4 data disks.  After
adding the hosts I create a distributed replicate volume using 3 disk
from each host with ext4 filesystems. I click the 'optimize for virt'
option on the volume.  There is a message in events that says that it
can't set a volume option, then it sets 2 volume options.  Checking the
options tab I see that it added the gid/uid options.  I was unable to
find in the logs what option was not set, I just see a message about
usage for volume set volname option.  The volume starts fine and I
am able to create a data domain on the volume.  Once the domain is
created I try to create a vm and it fails creating the disk.  Error
messages are along the lines of task file exists and can't remove task
files.  There are directories under tasks and when trying to manually
remove them I get the directory not empty error.  Can someone please
shed some light on what I am doing wrong to get this 2 node cluster with
local disk as shared storage up and running?



There are known problems with ext4 and gluster at the moment. Can you 
please confirm if you see similar behaviour with xfs and gluster?


Thanks,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3

2013-03-07 Thread Vijay Bellur

On 03/07/2013 04:36 PM, Dave Neary wrote:

Hi Rob,

On 03/06/2013 05:59 PM, Rob Zwissler wrote:

On one hand I like oVirt, I think you guys have done a good job with
this, and it is free software so I don't want to complain.

But on the other hand, if you release a major/stable release (ie:
oVirt 3.2), but it relies on a major/critical component (clustering
filesystem server) that is in alpha, not even beta, but alpha
prerelease form, you really should be up front and communicative about
this.  My searches turned up nothing except an offhand statement from
a GlusterFS developer, nothing from the oVirt team until now.

It is not acceptable to expect people to run something as critical as
a cluster filesystem server in alpha form on anything short of a
development test setup.  Are any other components of oVirt 3.2
dependent on non-stable general release packages?

What is the latest release of oVirt considered to be stable and
considered safe for use on production systems?


It seems like there has been conflation of two things here - I may be
wrong with what I say, but having checked, I do not believe so.

With oVirt 3.2/Gluster 3.4, you will be able to manage Gluster clusters
using the oVirt engine. This is a completely new integration, which is
still not in a production Gluster release.

However, it is still completely fine to use Gluster as storage for an
oVirt 3.1 or 3.2 managed cluster. The ability to use Gluster easily as a
storage back-end was added in oVirt 3.1, and as far as I know, there is
no problem using glusterfs 3.3 as a POSIX storage filesystem for oVirt 3.2.

Vijay, Shireesh, Ayal, is my understanding correct? I am worried that
we've been giving people the wrong impression here.



Yes, your description is right.

Thanks,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Testday aftermath

2013-02-01 Thread Vijay Bellur

On 02/01/2013 07:38 PM, Kanagaraj wrote:

On 02/01/2013 06:47 PM, Joop wrote:

Shireesh Anjal wrote:

On 02/01/2013 05:13 PM, noc wrote:

On 1-2-2013 11:07, Kanagaraj wrote:

Hi Joop,

 Looks like the problem is because of the glusterfs version you are
using. vdsm could not parse the output from gluster.

 Can you update the glusterfs to
http://bits.gluster.org/pub/gluster/glusterfs/v3.4.0qa7/x86_64/ and
check it out?

How??

I tried adding this repo but but yum says that there are no updates
available, atleast yesterday it did.

[gluster-nieuw]
name=GlusterFS
baseurl=http://bits.gluster.org/pub/gluster/glusterfs/stage/
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Gluster
enabled=1

My yumfoo isn't that good so I don't know how to force it. Besides I
tried through yum localinstall but it will revert when yum update is
run. It looks like it thinks that 3.3.1 is newer than 3.4


The problem is that, released glusterfs rpms in fedora repository are
of the form 3.3.1-8, whereas the ones from above QA release are
v3.4.0qa7. I think because of the v before 3.4, these are
considered as lower version, and by default yum picks up the rpms
from fedora repository.


The 'v' is 99.9% the culprit. I had 3.4.0qa6 before I wiped and just
had a look that folder and repo doesn't have the 'v' in front of it.


Thats correct.

[kanagaraj@localhost ~]$ rpmdev-vercmp glusterfs-3.3.1-8.fc18.x86_64
glusterfs-v3.4.0qa7-1.el6.x86_64
glusterfs-3.3.1-8.fc18.x86_64  glusterfs-v3.4.0qa7-1.el6.x86_64


Is there someone on this list that has the 'powers' to change that ??



[Adding Vijay]



3.4.0qa8 is available now. Can you please check with that?

Thanks,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] cannot add gluster domain

2013-01-23 Thread Vijay Bellur

On 01/22/2013 03:28 PM, T-Sinjon wrote:

HI, everyone:
Recently , I newly installed ovirt 3.1 from 
http://resources.ovirt.org/releases/stable/rpm/Fedora/17/noarch/,
and node use 
http://resources.ovirt.org/releases/stable/tools/ovirt-node-iso-2.5.5-0.1.fc17.iso

when i add gluster domain via nfs, mount error occurred,
I have do manually mount action on the node but failed if without -o 
nolock option:
# /usr/bin/mount -t nfs -o soft,nosharecache,timeo=600,retrans=6 
my-gluster-ip:/gvol02/GlusterDomain 
/rhev/data-center/mnt/my-gluster-ip:_gvol02_GlusterDomain
mount.nfs: rpc.statd is not running but is required for remote locking. 
mount.nfs: Either use '-o nolock' to keep locks local, or start statd. 
mount.nfs: an incorrect mount option was specified




Can you please confirm the glusterfs version that is available in 
ovirt-node-iso?


Thanks,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] ovirt fails to attach gluster volume

2013-01-11 Thread Vijay Bellur

On 01/11/2013 12:56 PM, Jithin Raju wrote:

Traceback (most recent call last):
   File /usr/share/vdsm/storage/hsm.py, line 1929, in connectStorageServer
 conObj.connect()
   File /usr/share/vdsm/storage/storageServer.py, line 179, in connect
 self._mount.mount(self.options, self._vfsType)
   File /usr/share/vdsm/storage/mount.py, line 190, in mount
 return self._runcmd(cmd, timeout)
   File /usr/share/vdsm/storage/mount.py, line 206, in _runcmd
 raise MountError(rc, ;.join((out, err)))
MountError: (1, 'Mount failed. Please check the log file for more
details.\n;ERROR: failed to create logfile
/var/log/glusterfs/rhev-data-center-mnt-fig:_vol1.log (Permission
denied)\nERROR: failed to open logfile
/var/log/glusterfs/rhev-data-center-mnt-fig:_vol1.log\n')



Do you have selinux in enforcing mode on the host?

Thanks,
Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] What do you want to see in oVirt next?

2013-01-03 Thread Vijay Bellur

On 01/03/2013 10:14 PM, Adrian Gibanel wrote:

This is what I'm missing right now in oVirt 3.1:

Better GlusterFS support.
===
1. Add a checkbox when creating a volume: Set oVirt permissions so
that the vdsm : kvm permissions are set. I don't want it to be
per-default because I'd like to use Volumes tabs as a Volumes manager
for Glusterfs volumes and not only Glusterfs volumes aimed at virtual
machines.

From: http://blog.jebpages.com/archives/ovirt-3-1-glusterized/ :
( For now, the Gluster volume manager neglects to set brick directory
permissions correctly, so after adding bricks on a machine, you have to
return to the terminal and run chown -R 36.36 /data (assuming /data is
where you are storing your volume bricks) to enable oVirt to write to
the volumes. )


This feature is available in 3.2. Enabling a checkbox to optimize 
gluster volume for oVirt will set vdsm:kvm permissions on bricks that 
are part of the volume.




2. Add a quota tab in Volumes. So that you can enable/disable/edit its
quota:
http://www.gluster.org/community/documentation/index.php/Gluster_3.2:_Enabling_Quota
http://gluster.org/community/documentation/index.php/Gluster_3.2:_Managing_Directory_Quota


Noted. We will address this in a subsequent release.

Thanks,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Testing gluster in 3.2 nightlies

2013-01-03 Thread Vijay Bellur

On 01/04/2013 02:12 AM, Joop wrote:

Just saw the question what route to follow for post 3.2 and picked up
something that I didn't know about was going to ask if it was possible
to implement, namely setting permissions on the volume folder when
creating a gluster volume.
But when trying it out I found a little snag. I installed two hosts with
a minimal fed17 install, added a couple of repos to enable installing
the latest nightlies (it needed a later then 0.9 libvirt (0.10 from
danken) and qemu-kvm and since a couple of days a later gluster which
outputs in xml (gluster-3.4..)
Steps:




Can you please provide vdsm and engine logs too?

Thanks,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Continuing my ovirt-3.2 nightlies queste

2012-12-28 Thread Vijay Bellur

On 12/28/2012 03:24 AM, Joop wrote:



qemu-img-1.2.0-25.fc17.x86_64
qemu-common-1.2.0-25.fc17.x86_64
qemu-kvm-1.2.0-25.fc17.x86_64
qemu-kvm-tools-1.2.0-25.fc17.x86_64
ipxe-roms-qemu-20120328-1.gitaac9718.fc17.noarch
qemu-system-x86-1.2.0-25.fc17.x86_64

Other logs are available but don't know whether they are needed. Didn't
see anything obvious in the gluster logs. The commands for the gluster
volume creating are done on st01 according to .cmd_log_history.




Can you please mention the version of glusterfs RPMs being used on the 
storage nodes? Due to a recent change in xml output, you may need 
pre-release glusterfs-3.4.0 RPMs.


Thanks,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Ovirt-nightly and gluster volume problem

2012-11-08 Thread Vijay Bellur

On 11/08/2012 03:55 PM, Joop wrote:

Continuing my quest for a system consisting of oVirt en gluster I came
across the following.
I'm using the latest nightlies and had tried something with gluster but
it didn't work out. So I tried starting over en did a stop on my gluster
volumes, that went OK, removed them, that went OK too.
Then I tried to create a nieuw Volume using the same name and same
location and got an unexpected exception. Look at the folder which had
contained the data I still see a .glusterfs folder but all other data is
gone. Ok.
Googling I found that the following two commands should give me the
ability to reuse that folder for glusterfs.
setfattr -x trusted.glusterfs.volume-id /gluster-data
setfattr -x trusted.gfid /gluster-data
Tried again from the webui and the volume was created and I could start it.
Stopped it, removed it and tried to recreate, same error. See the
attached logs.



This is expected behavior as you need to be careful while re-using 
bricks across different volume types. You can actually have a striped 
volume and use a brick from there to create a replicated volume after 
the striped volume has been deleted. If the brick contains data from the 
striped volume, then the results of accessing such a volume from a 
client mount point would not be desirable. xattr removals are necessary 
so that the admin is aware of the consequences of re-using bricks 
across different volume types.


Thanks,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Issue adding a gluster storage domain.

2012-10-29 Thread Vijay Bellur

On 10/29/2012 11:46 AM, Daniel Rowe wrote:

Hi

I can't seem to get a gluster storage domain added I am using Fedora
17 on both the nodes management machine. I have the gluster volumes
showing in ovirt and I can manually mount the gluster volume both
locally on the node and on the management machine.

If I manually mount the volume on the node with /usr/bin/mount -t
glusterfs -o vers=3 localhost:/bsdvol1
/rhev/data-center/mnt/localhost:_bsdvol1 as root then add the domain
in the web interface it works.

Although I have the domain done with the manual mounting, I am
wondering what is going on.

Thread-1934::INFO::2012-10-29
13:27:09,793::logUtils::37::dispatcher::(wrapper) Run and protect:
validateStorageServerConnection(domType=6,
spUUID='----', conList=[{'port': '',
'connection': 'localhost:/bsdvol1', 'iqn': '', 'portal': '', 'user':
'', 'vfs_type': 'glusterfs', 'password': '**', 'id':
'----'}], options=None)
Thread-1934::INFO::2012-10-29
13:27:09,793::logUtils::39::dispatcher::(wrapper) Run and protect:
validateStorageServerConnection, Return response: {'statuslist':
[{'status': 0, 'id': '----'}]}
Thread-1934::DEBUG::2012-10-29
13:27:09,793::task::1172::TaskManager.Task::(prepare)
Task=`4f9131eb-45cd-4e82-bc35-e29ed14f0818`::finished: {'statuslist':
[{'status': 0, 'id': '----'}]}
Thread-1934::DEBUG::2012-10-29
13:27:09,793::task::588::TaskManager.Task::(_updateState)
Task=`4f9131eb-45cd-4e82-bc35-e29ed14f0818`::moving from state
preparing - state finished
Thread-1934::DEBUG::2012-10-29
13:27:09,794::resourceManager::809::ResourceManager.Owner::(releaseAll)
Owner.releaseAll requests {} resources {}
Thread-1934::DEBUG::2012-10-29
13:27:09,794::resourceManager::844::ResourceManager.Owner::(cancelAll)
Owner.cancelAll requests {}
Thread-1934::DEBUG::2012-10-29
13:27:09,794::task::978::TaskManager.Task::(_decref)
Task=`4f9131eb-45cd-4e82-bc35-e29ed14f0818`::ref 0 aborting False
Thread-1935::DEBUG::2012-10-29
13:27:09,842::BindingXMLRPC::156::vds::(wrapper) [192.168.1.10]
Thread-1935::DEBUG::2012-10-29
13:27:09,842::task::588::TaskManager.Task::(_updateState)
Task=`ef920d52-3082-495f-bfbc-2eb508c3de18`::moving from state init -
state preparing
Thread-1935::INFO::2012-10-29
13:27:09,843::logUtils::37::dispatcher::(wrapper) Run and protect:
connectStorageServer(domType=6,
spUUID='----', conList=[{'port': '',
'connection': 'localhost:/bsdvol1', 'mnt_options': 'vers=3', 'portal':
'', 'user': '', 'iqn': '', 'vfs_type': 'glusterfs', 'password':
'**', 'id': 'bbe1bbc5-62b8-4115-b409-6ddea910a688'}],
options=None)
Thread-1935::DEBUG::2012-10-29
13:27:09,851::__init__::1249::Storage.Misc.excCmd::(_log)
'/usr/bin/sudo -n /usr/bin/mount -t glusterfs -o vers=3
localhost:/bsdvol1 /rhev/data-center/mnt/localhost:_bsdvol1' (cwd
None)
Thread-1935::ERROR::2012-10-29
13:27:09,930::hsm::1932::Storage.HSM::(connectStorageServer) Could not
connect to storageServer
Traceback (most recent call last):
   File /usr/share/vdsm/storage/hsm.py, line 1929, in connectStorageServer
 conObj.connect()
   File /usr/share/vdsm/storage/storageServer.py, line 179, in connect
 self._mount.mount(self.options, self._vfsType)
   File /usr/share/vdsm/storage/mount.py, line 190, in mount
 return self._runcmd(cmd, timeout)
   File /usr/share/vdsm/storage/mount.py, line 206, in _runcmd
 raise MountError(rc, ;.join((out, err)))
MountError: (1, 'unknown option vers (ignored)\nMount failed. Please
check the log file for more details.\n;ERROR: failed to create logfile
/var/log/glusterfs/rhev-data-center-mnt-localhost:_bsdvol1.log
(Permission denied)\nERROR: failed to open logfile
/var/log/glusterfs/rhev-data-center-mnt-localhost:_bsdvol1.log\n')



Looks like there was a permission error in creating log file for the 
glusterfs client. Can you please check if you have SELinux enabled and 
if permissions are fine on the directory?


Thanks,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] oVirt 3.1, Gluster + non-IP storage networks

2012-07-09 Thread Vijay Bellur

On 07/09/2012 12:41 PM, Justin Clift wrote:

Hi all,

Saw the ongoing thread on oVirt 3.1 and Gluster, discussing
how to handle/portray storage networks in the Engine UI.

What's the right way to approach this, for people who use
non-IP based storage networks?  (Infiniband, Fibre Channel,
etc).



Do you intend performing all management operations over non-IP based 
networks?


The ability to provision non-IP (read Infiniband/rdma) storage volumes 
in Gluster will be enabled at a later date.


Regards,
Vijay


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Ovirt and gluster storage (two servers in a cluster)

2012-07-04 Thread Vijay Bellur

On 07/04/2012 12:18 PM, Robert Middleswarth wrote:

I was just able to repeat the issue.  If you only have one node active
it will activate and work fine.  But if you have 2 or more hosts / nodes
it will just round robin though the hosts with each host contending on
each round.  I don't have that problem with NFS shares.


Does mounting the volume fail when you have two nodes?

-Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Ovirt and gluster storage (two servers in a cluster)

2012-07-04 Thread Vijay Bellur

On 07/04/2012 12:58 PM, Robert Middleswarth wrote:

On 07/04/2012 03:15 AM, Vijay Bellur wrote:

On 07/04/2012 12:18 PM, Robert Middleswarth wrote:

I was just able to repeat the issue. If you only have one node active
it will activate and work fine. But if you have 2 or more hosts / nodes
it will just round robin though the hosts with each host contending on
each round. I don't have that problem with NFS shares.


Does mounting the volume fail when you have two nodes?

-Vijay

No. It will mount and activate for a few seconds then the 2nd host will
start contending for SPM. Will become the SPM host then the 1st host
will start contending rise and repeat the data center is never up for
more then a few seconds. If I put all hosts but one into maintenance
then the data center will become active and will work fine including
allowing me to start hosts but if I take the host out of maintenance
then all the hosts will fight for SPM and the datacenter will never
become active.



Can you please send across vdsm, engine and glusterfs logs?

Thanks,
Vijay

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Ovirt 3.1 and gluster (creation in ovirt)

2012-06-22 Thread Vijay Bellur

On 06/21/2012 07:35 AM, зоррыч wrote:

Vijay?


-Original Message-
From: Itamar Heim [mailto:ih...@redhat.com]
Sent: Thursday, June 21, 2012 12:47 AM
To: зоррыч
Cc: 'Daniel Paikov'; users@ovirt.org; Vijay Bellur
Subject: Re: [Users] Ovirt 3.1 and gluster (creation in ovirt)

On 06/20/2012 11:41 PM, зоррыч wrote:

Exactly the same problem:
http://www.mail-archive.com/vdsm-devel@lists.fedorahosted.org/msg00555
.html


ok, so this is still not available in fedora based on the last comment:
  From #gluster i figure that fuse still does not support O_DIRECT  From 
linux-fsdevel, it looks like patches to enable O_DIRECT in fuse are just 
getting in.

vijay - any estimation on when this may be available?





O_DIRECT support from FUSE is available in 3.4.x kernels.

-Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Ovirt 3.1 and gluster (creation in ovirt)

2012-06-16 Thread Vijay Bellur



On 06/16/2012 11:08 AM, Robert Middleswarth wrote:
I am seeing the same thing.  I also notice that glusterfs seems to die 
every-time I try.  I am wonder if this could be a glusterfs / f17 issue.




Are you running GlusterFS 3.2.x in Fedora 17? For this volume creation 
to complete successfully from oVirt, you will need GlusterFS 3.3.0. You 
can download Fedora RPMs for 3.3.0 from:


http://download.gluster.com/pub/gluster/glusterfs/3.3/LATEST/Fedora/


-Vijay
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users