Re: [ovirt-users] gluster replica volumes with different data usage

[Alex K]

Ok, noted...

Will reconfigure this volume from scratch.

Thanx,
Alex

On Mon, Sep 18, 2017 at 9:31 AM, Ravishankar N 
wrote:

> Possibly.  I don't think changing shard size on the fly is supported,
> especially when there are files on the volume that are sharded with a
> different size.
>
> -Ravi
>
>
> On 09/18/2017 11:40 AM, Alex K wrote:
>
> The heal status is showing that no pending files need healing (also shown
> at GUI).
> When checking the bricks on the file system I see that what is different
> between the server is the .shard folder of the volume. One server reports
> 835GB while the other 1.1 TB.
> I recall to have changed the shard size at some point from 4 MB to 64MB.
> Could this be the cause?
>
> Thanx,
> Alex
>
> On Mon, Sep 18, 2017 at 8:14 AM, Ravishankar N 
> wrote:
>
>>
>> On 09/18/2017 10:08 AM, Alex K wrote:
>>
>> Hi Ravishankar,
>>
>> I am not referring to the arbiter volume(which is showing 0% usage). I am
>> referring to the other 2 volumes which are replicas and should have the
>> exact same data. Checking the status of other bricks in ovirt (bricks used
>> from iso and export domain) I see that they all report same usage of data
>> on the data volumes, except the "vms" volume used for storing vms.
>>
>>
>> Ah, okay.  Some of the things that can cause a variation in disk usage:
>> - Pending self-heals in gluster (check if `gluster volume heal 
>> info` doesn't show any entries.  Also if there is anything under
>> `.glusterfs/landfill` folder of the bricks).
>> - XFS speculative preallocation
>> - Possibly some bug in self-healing of sparse files by gluster (although
>> we fixed known bugs a long time back in this area).
>>
>> Regards
>> Ravi
>>
>>
>> Thanx,
>> Alex
>>
>> On Sep 18, 2017 07:00, "Ravishankar N"  wrote:
>>
>>>
>>>
>>> On 09/17/2017 08:41 PM, Alex K wrote:
>>>
>>> Hi all,
>>>
>>> I have replica 3 with 1 arbiter.
>>> When checking the gluster volume bricks they are reported as using
>>> different space, as per attached. How come they use different space? One
>>> would expect to use exactly the same space since they are replica.
>>>
>>> The 3rd brick (arbiter ) only holds meta data, so it would not consume
>>> as much space as the other 2 data bricks. So what you are seeing is
>>> expected behaviour.
>>> Regards,
>>> Ravi
>>>
>>> Thanx,
>>> Alex
>>>
>>>
>>> ___
>>> Users mailing 
>>> listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>>
>>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt HC engine will not start

[Kasturi Narra]

Hi,

   In the agent.log file i see that it fails to connect to storage server.
Can you please check the following .

1) can you please check 'gluster peer status' and make sure that all the
nodes in the cluster are connected ?

2) can you gluster volume status  and make sure that at
least two of the bricks are online?

Thanks
kasturi

On Fri, Sep 15, 2017 at 12:29 PM, Jesper Andersson <
jesper.anders...@viconia.se> wrote:

> Hi.
>
> I have a HC environment (oVirt 4.1.4) where the engine does not start.
> Tryed to update it to the latest oVirt but something happend on the
> storage side.
> Seemed like there was no data on the second node so we did a full heal,
> restarted the environment and now the ha-agent, broker and the engine
> does not start.
> "The hosted engine configuration has not been retrieved from shared
> storage. Please ensure that ovirt-ha-agent is running and the storage
> server is reachable."
>
> Tried to start the ha-agent but receives this error:
> ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback
> (most recent call last):
>   File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> line 191, in _run_agent
>
> The broker wont start either:
> ovirt-ha-broker ovirt_hosted_engine_ha.broker.listener.ConnectionHandler
> ERROR Error handling request, data: 'set-storage-domain
> FilesystemBackend dom_type=glusterfs
> sd_uuid=2a79ea65-3df3-43cf-b1ba-304581f7918a'
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/ovirt...
>
> I'm not that experienced with ovirt nor gluster storage but gluster
> seems OK as far as I can see.
> Does anyone have an idea of how to resolve this?
>
> Please see attached logs.
>
>
> ___
> 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: [ovirt-users] gluster replica volumes with different data usage

[Kasturi Narra]

Recommended would be creating a new storage domain with shard size as 64 MB
and migrating all the disks from 4MB storagedomain

On Mon, Sep 18, 2017 at 12:01 PM, Ravishankar N 
wrote:

> Possibly.  I don't think changing shard size on the fly is supported,
> especially when there are files on the volume that are sharded with a
> different size.
>
> -Ravi
>
>
> On 09/18/2017 11:40 AM, Alex K wrote:
>
> The heal status is showing that no pending files need healing (also shown
> at GUI).
> When checking the bricks on the file system I see that what is different
> between the server is the .shard folder of the volume. One server reports
> 835GB while the other 1.1 TB.
> I recall to have changed the shard size at some point from 4 MB to 64MB.
> Could this be the cause?
>
> Thanx,
> Alex
>
> On Mon, Sep 18, 2017 at 8:14 AM, Ravishankar N 
> wrote:
>
>>
>> On 09/18/2017 10:08 AM, Alex K wrote:
>>
>> Hi Ravishankar,
>>
>> I am not referring to the arbiter volume(which is showing 0% usage). I am
>> referring to the other 2 volumes which are replicas and should have the
>> exact same data. Checking the status of other bricks in ovirt (bricks used
>> from iso and export domain) I see that they all report same usage of data
>> on the data volumes, except the "vms" volume used for storing vms.
>>
>>
>> Ah, okay.  Some of the things that can cause a variation in disk usage:
>> - Pending self-heals in gluster (check if `gluster volume heal 
>> info` doesn't show any entries.  Also if there is anything under
>> `.glusterfs/landfill` folder of the bricks).
>> - XFS speculative preallocation
>> - Possibly some bug in self-healing of sparse files by gluster (although
>> we fixed known bugs a long time back in this area).
>>
>> Regards
>> Ravi
>>
>>
>> Thanx,
>> Alex
>>
>> On Sep 18, 2017 07:00, "Ravishankar N"  wrote:
>>
>>>
>>>
>>> On 09/17/2017 08:41 PM, Alex K wrote:
>>>
>>> Hi all,
>>>
>>> I have replica 3 with 1 arbiter.
>>> When checking the gluster volume bricks they are reported as using
>>> different space, as per attached. How come they use different space? One
>>> would expect to use exactly the same space since they are replica.
>>>
>>> The 3rd brick (arbiter ) only holds meta data, so it would not consume
>>> as much space as the other 2 data bricks. So what you are seeing is
>>> expected behaviour.
>>> Regards,
>>> Ravi
>>>
>>> Thanx,
>>> Alex
>>>
>>>
>>> ___
>>> Users mailing 
>>> listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>>
>>
>
>
> ___
> 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: [ovirt-users] gluster replica volumes with different data usage

[Ravishankar N]

Possibly.  I don't think changing shard size on the fly is supported, 
especially when there are files on the volume that are sharded with a 
different size.


-Ravi

On 09/18/2017 11:40 AM, Alex K wrote:
The heal status is showing that no pending files need healing (also 
shown at GUI).
When checking the bricks on the file system I see that what is 
different between the server is the .shard folder of the volume. One 
server reports 835GB while the other 1.1 TB.

I recall to have changed the shard size at some point from 4 MB to 64MB.
Could this be the cause?

Thanx,
Alex

On Mon, Sep 18, 2017 at 8:14 AM, Ravishankar N > wrote:



On 09/18/2017 10:08 AM, Alex K wrote:

Hi Ravishankar,

I am not referring to the arbiter volume(which is showing 0%
usage). I am referring to the other 2 volumes which are replicas
and should have the exact same data. Checking the status of other
bricks in ovirt (bricks used from iso and export domain) I see
that they all report same usage of data on the data volumes,
except the "vms" volume used for storing vms.


Ah, okay.  Some of the things that can cause a variation in disk
usage:
- Pending self-heals in gluster (check if `gluster volume heal
 info` doesn't show any entries.  Also if there is
anything under `.glusterfs/landfill` folder of the bricks).
- XFS speculative preallocation
- Possibly some bug in self-healing of sparse files by gluster
(although we fixed known bugs a long time back in this area).

Regards
Ravi



Thanx,
Alex

On Sep 18, 2017 07:00, "Ravishankar N" mailto:ravishan...@redhat.com>> wrote:



On 09/17/2017 08:41 PM, Alex K wrote:

Hi all,

I have replica 3 with 1 arbiter.
When checking the gluster volume bricks they are reported as
using different space, as per attached. How come they use
different space? One would expect to use exactly the same
space since they are replica.


The 3rd brick (arbiter ) only holds meta data, so it would
not consume as much space as the other 2 data bricks. So what
you are seeing is expected behaviour.
Regards,
Ravi

Thanx,
Alex


___
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: [ovirt-users] gluster replica volumes with different data usage

[Alex K]

The heal status is showing that no pending files need healing (also shown
at GUI).
When checking the bricks on the file system I see that what is different
between the server is the .shard folder of the volume. One server reports
835GB while the other 1.1 TB.
I recall to have changed the shard size at some point from 4 MB to 64MB.
Could this be the cause?

Thanx,
Alex

On Mon, Sep 18, 2017 at 8:14 AM, Ravishankar N 
wrote:

>
> On 09/18/2017 10:08 AM, Alex K wrote:
>
> Hi Ravishankar,
>
> I am not referring to the arbiter volume(which is showing 0% usage). I am
> referring to the other 2 volumes which are replicas and should have the
> exact same data. Checking the status of other bricks in ovirt (bricks used
> from iso and export domain) I see that they all report same usage of data
> on the data volumes, except the "vms" volume used for storing vms.
>
>
> Ah, okay.  Some of the things that can cause a variation in disk usage:
> - Pending self-heals in gluster (check if `gluster volume heal 
> info` doesn't show any entries.  Also if there is anything under
> `.glusterfs/landfill` folder of the bricks).
> - XFS speculative preallocation
> - Possibly some bug in self-healing of sparse files by gluster (although
> we fixed known bugs a long time back in this area).
>
> Regards
> Ravi
>
>
> Thanx,
> Alex
>
> On Sep 18, 2017 07:00, "Ravishankar N"  wrote:
>
>>
>>
>> On 09/17/2017 08:41 PM, Alex K wrote:
>>
>> Hi all,
>>
>> I have replica 3 with 1 arbiter.
>> When checking the gluster volume bricks they are reported as using
>> different space, as per attached. How come they use different space? One
>> would expect to use exactly the same space since they are replica.
>>
>> The 3rd brick (arbiter ) only holds meta data, so it would not consume as
>> much space as the other 2 data bricks. So what you are seeing is expected
>> behaviour.
>> Regards,
>> Ravi
>>
>> Thanx,
>> Alex
>>
>>
>> ___
>> Users mailing 
>> listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster replica volumes with different data usage

[Ravishankar N]

On 09/18/2017 10:08 AM, Alex K wrote:

Hi Ravishankar,

I am not referring to the arbiter volume(which is showing 0% usage). I 
am referring to the other 2 volumes which are replicas and should have 
the exact same data. Checking the status of other bricks in ovirt 
(bricks used from iso and export domain) I see that they all report 
same usage of data on the data volumes, except the "vms" volume used 
for storing vms.


Ah, okay.  Some of the things that can cause a variation in disk usage:
- Pending self-heals in gluster (check if `gluster volume heal  
info` doesn't show any entries.  Also if there is anything under 
`.glusterfs/landfill` folder of the bricks).

- XFS speculative preallocation
- Possibly some bug in self-healing of sparse files by gluster (although 
we fixed known bugs a long time back in this area).


Regards
Ravi



Thanx,
Alex

On Sep 18, 2017 07:00, "Ravishankar N" > wrote:




On 09/17/2017 08:41 PM, Alex K wrote:

Hi all,

I have replica 3 with 1 arbiter.
When checking the gluster volume bricks they are reported as
using different space, as per attached. How come they use
different space? One would expect to use exactly the same space
since they are replica.


The 3rd brick (arbiter ) only holds meta data, so it would not
consume as much space as the other 2 data bricks. So what you are
seeing is expected behaviour.
Regards,
Ravi

Thanx,
Alex


___
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: [ovirt-users] gluster replica volumes with different data usage

[Alex K]

Hi Ravishankar,

I am not referring to the arbiter volume(which is showing 0% usage). I am
referring to the other 2 volumes which are replicas and should have the
exact same data. Checking the status of other bricks in ovirt (bricks used
from iso and export domain) I see that they all report same usage of data
on the data volumes, except the "vms" volume used for storing vms.

Thanx,
Alex

On Sep 18, 2017 07:00, "Ravishankar N"  wrote:

>
>
> On 09/17/2017 08:41 PM, Alex K wrote:
>
> Hi all,
>
> I have replica 3 with 1 arbiter.
> When checking the gluster volume bricks they are reported as using
> different space, as per attached. How come they use different space? One
> would expect to use exactly the same space since they are replica.
>
> The 3rd brick (arbiter ) only holds meta data, so it would not consume as
> much space as the other 2 data bricks. So what you are seeing is expected
> behaviour.
> Regards,
> Ravi
>
> Thanx,
> Alex
>
>
> ___
> Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster replica volumes with different data usage

[Ravishankar N]

On 09/17/2017 08:41 PM, Alex K wrote:

Hi all,

I have replica 3 with 1 arbiter.
When checking the gluster volume bricks they are reported as using 
different space, as per attached. How come they use different space? 
One would expect to use exactly the same space since they are replica.


The 3rd brick (arbiter ) only holds meta data, so it would not consume 
as much space as the other 2 data bricks. So what you are seeing is 
expected behaviour.

Regards,
Ravi

Thanx,
Alex


___
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: [ovirt-users] Manual transfer of VMs from DC to DC

[FERNANDO FREDIANI]

Alex, porting VMs in oVirt is not very flexible as some may expect or
commonly look for. Perhaps in future versions there will be things
like Host to Host transfer and not need to run commands to convert VMs
For now you need to use Exports (mount, umount, mount aigain) and so on.

2017-09-17 18:18 GMT-03:00 Alex K :
> Thanx, I can confirm that this way i may transfer VMs, but I was thinking a
> more dirty and perhaps portable way.
>
> Say I want to get to a external disk just one VM from DC A and copy/import
> it on DC B that has no access to the export domain of DC A.
>
> I've seen also articles converting the VM disk to qcow or raw then importing
> it with some perl script.
>
> I guess that the OVA import/export feature, still to be implemented, is what
> I need for this case.
>
> Thanx,
> Alex
>
> On Sep 17, 2017 10:13, "Fred Rolland"  wrote:
>>
>> Hi,
>>
>> You could import the storage domain from a DC to another DC with all the
>> VMs and disks.
>> See in [1], there is also a video explaining how to do it.
>>
>> Regards,
>> Fred
>>
>> [1]
>> https://www.ovirt.org/develop/release-management/features/storage/importstoragedomain/
>>
>> On Fri, Sep 15, 2017 at 10:40 AM, Abi Askushi 
>> wrote:
>>>
>>> Hi all,
>>>
>>> Is there any way of transferring VMs manually from DC to DC, without the
>>> DCs having connectivity with each other?
>>>
>>> I was thinking to backup all the export domain directory, and then later
>>> rsync this directory VMs to a new NFS share, then import this NFS share as
>>> an export domain on the other DC.
>>>
>>> What do you think?
>>>
>>> Thanx,
>>> Alex
>>>
>>>
>>> ___
>>> 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
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Manual transfer of VMs from DC to DC

[Alex K]

Thanx, I can confirm that this way i may transfer VMs, but I was thinking a
more dirty and perhaps portable way.

Say I want to get to a external disk just one VM from DC A and copy/import
it on DC B that has no access to the export domain of DC A.

I've seen also articles converting the VM disk to qcow or raw then
importing it with some perl script.

I guess that the OVA import/export feature, still to be implemented, is
what I need for this case.

Thanx,
Alex

On Sep 17, 2017 10:13, "Fred Rolland"  wrote:

> Hi,
>
> You could import the storage domain from a DC to another DC with all the
> VMs and disks.
> See in [1], there is also a video explaining how to do it.
>
> Regards,
> Fred
>
> [1] https://www.ovirt.org/develop/release-management/features/
> storage/importstoragedomain/
>
> On Fri, Sep 15, 2017 at 10:40 AM, Abi Askushi 
> wrote:
>
>> Hi all,
>>
>> Is there any way of transferring VMs manually from DC to DC, without the
>> DCs having connectivity with each other?
>>
>> I was thinking to backup all the export domain directory, and then later
>> rsync this directory VMs to a new NFS share, then import this NFS share as
>> an export domain on the other DC.
>>
>> What do you think?
>>
>> Thanx,
>> Alex
>>
>>
>> ___
>> 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

[ovirt-users] Unable to resolve gluster hooks conflict

[Sherin George]

Hello Guys,

I am trying to fix an issue with "hooks conflict".

Basically, I am seeing an exclamation mark for the hook 
"57glusterfind-delete-post.py" due to hooks conflict.

I am seeing this in Ovirt >> Clusters >> GlusterStorage >> Gluster Hooks >> 
"57glusterfind-delete-post.py"

When I started, the hook "57glusterfind-delete-post.py" was missing in some 
gluster hosts. So, I used "Resolve Conflicts" option and copied hooks in all 
gluster hosts.

Now, I am able to see the hook in all gluster hosts and I am able to see same 
md5 sum for all hosts

However, the exclamation mark for "57glusterfind-delete-post.py" is still there.

When I examined each hook in "Resolve Content Conflict" option, I noticed that 
same code is shown for hook for all gluster hosts. However, the code is not 
shown when I check engine. Engine also shows same md5 sum as other gluster 
hosts.

I tried to run "Resolve Conflicts" with "Resolve Content Conflict" option to 
copy the hook from a gluster host to others. However, the tool failed to see 
any content difference and it is giving me the error "Error while executing 
action: Cannot edit Gluster Hook. There are no conflicting servers to add or 
update hook."

I think it is because same md5 sum is found for all.

Any ideas or insights about a solution is much appreciated.

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

Re: [ovirt-users] engine randomly updated 1 package on all my hosts overnight

[Charles Kozler]

Yedidyah - yes, update would be best of course. I've had this HIDS running
for a little over a year or so and never saw this before so was a little
weary

On Sun, Sep 17, 2017 at 3:00 AM, Yedidyah Bar David  wrote:

> On Fri, Sep 15, 2017 at 5:12 PM, Charles Kozler 
> wrote:
> > Hello -
> >
> > Can anyone just briefly tell me if this is expected behavior or not?
> >
> > I know you can tell the engine to update hosts, but nobody was using the
> > engine and I see the engine logging in and the yum command being run so
> I am
> > curious if this is expected or not?
>
> It is, unless you have otopi-1.6.2 or later:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1405838
>
> >
> > On Thu, Sep 14, 2017 at 10:54 AM, Charles Kozler 
> > wrote:
> >>
> >> I received an alert from OSSEC HIDS that a package was installed at
> 00:59.
> >> Nobody uses this infrastructure but me
> >>
> >> Upon investigation I find this
> >>
> >> Sep 14 00:59:18 ovirthost1 sshd[93263]: Accepted publickey for root from
> >> 10.0.16.50 port 50197 ssh2: RSA
> >> 1c:fc:0d:b8:40:2c:bf:87:f7:8f:b2:52:0b:c4:f6:4d
> >> Sep 14 00:59:18 ovirthost1 sshd[93263]: pam_unix(sshd:session): session
> >> opened for user root by (uid=0)
> >> Sep 14 00:59:46 ovirthost1 sshd[93263]: pam_unix(sshd:session): session
> >> closed for user root
> >>
> >> 10.0.16.50 is my ovirt engine
> >>
> >> And the yum log
> >>
> >> Sep 14 00:59:28 Updated: iproute-3.10.0-87.el7.x86_64
> >>
> >> However, what is baffling to me is that this is a cluster I setup about
> 9
> >> months ago and have not updated at all (its a testing env for VM
> systems)
> >>
> >> Why would ovirt seemingly randomly update and install a package? I know
> >> the engine checks for updates on hosts but this is the first time in my
> time
> >> using ovirt that ovirt instructed a host to install a package. This
> occurred
> >> on all of my ovirt nodes in this infrastructure (3)
>
> Probably the reason this didn't happen before is a mere coincidence -
> there are not many updates to 'iproute', or you did update it manually
> in other cases, or something like that.
>
> >>
> >> ovirt Version 4.0.1.1-1.el7.centos
>
> Most likely you have otopi-1.5.2, which does not have above bug fixed.
>
> You might consider upgrading to oVirt 4.1.
>
> Best,
> --
> Didi
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] engine randomly updated 1 package on all my hosts overnight

[Charles Kozler]

Thanks for confirming

On Sun, Sep 17, 2017 at 11:05 AM, Christopher Cox 
wrote:

> On 09/17/2017 02:00 AM, Yedidyah Bar David wrote:
>
>> On Fri, Sep 15, 2017 at 5:12 PM, Charles Kozler 
>> wrote:
>>
>>> Hello -
>>>
>>> Can anyone just briefly tell me if this is expected behavior or not?
>>>
>>> I know you can tell the engine to update hosts, but nobody was using the
>>> engine and I see the engine logging in and the yum command being run so
>>> I am
>>> curious if this is expected or not?
>>>
>>
> My iproute mysteriously updated as well.
>
> ___
> 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: [ovirt-users] engine randomly updated 1 package on all my hosts overnight

[Christopher Cox]

On 09/17/2017 02:00 AM, Yedidyah Bar David wrote:

On Fri, Sep 15, 2017 at 5:12 PM, Charles Kozler  wrote:

Hello -

Can anyone just briefly tell me if this is expected behavior or not?

I know you can tell the engine to update hosts, but nobody was using the
engine and I see the engine logging in and the yum command being run so I am
curious if this is expected or not?


My iproute mysteriously updated as well.

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

[ovirt-users] gluster replica volumes with different data usage

[Alex K]

Hi all,

I have replica 3 with 1 arbiter.
When checking the gluster volume bricks they are reported as using
different space, as per attached. How come they use different space? One
would expect to use exactly the same space since they are replica.

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

Re: [ovirt-users] API auto delete vms snapshot

[Fred Rolland]

Lionel hi,

You should wait until the operation is done. Take a look at this example
[1].

Regards,
Fred

[1]
https://github.com/oVirt/ovirt-engine-sdk/blob/e4ef67041a639cddbae82b172572ac5c45217341/sdk/examples/vm_backup.py#L163

On Fri, Sep 15, 2017 at 5:28 PM, Lionel Caignec  wrote:

> Hi,
>
> i'm playing with ovirt sdk, to automatically manage snapshots.
> My script is for now very basic
> step 1) list all vm of cluster
> step 2) for each vm create a snapshot if needed
> step 3) for each vm delete oldest snapshot
> No problem for step 1 and 2.
>
> But step 3 is harder.
> If i launch snap remove with command "snapshots_service.snapshot_service(
> snap.id).remove()", python tell me snapshot operation already in progress
> (creation of snapshot in step2).
>
> If i launch snap remove with parameter "async=true" the snapshot to delete
> is locked by ovirt, but never deleted.
>
> So how can i do? Also there is some way to monitor running task about
> snapshot (ovirt-shell ...)?
>
> --
> Lionel
> ___
> 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: [ovirt-users] Manual transfer of VMs from DC to DC

[Fred Rolland]

Hi,

You could import the storage domain from a DC to another DC with all the
VMs and disks.
See in [1], there is also a video explaining how to do it.

Regards,
Fred

[1]
https://www.ovirt.org/develop/release-management/features/storage/importstoragedomain/

On Fri, Sep 15, 2017 at 10:40 AM, Abi Askushi 
wrote:

> Hi all,
>
> Is there any way of transferring VMs manually from DC to DC, without the
> DCs having connectivity with each other?
>
> I was thinking to backup all the export domain directory, and then later
> rsync this directory VMs to a new NFS share, then import this NFS share as
> an export domain on the other DC.
>
> What do you think?
>
> Thanx,
> Alex
>
>
> ___
> 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: [ovirt-users] engine randomly updated 1 package on all my hosts overnight

[Yedidyah Bar David]

On Fri, Sep 15, 2017 at 5:12 PM, Charles Kozler  wrote:
> Hello -
>
> Can anyone just briefly tell me if this is expected behavior or not?
>
> I know you can tell the engine to update hosts, but nobody was using the
> engine and I see the engine logging in and the yum command being run so I am
> curious if this is expected or not?

It is, unless you have otopi-1.6.2 or later:

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

>
> On Thu, Sep 14, 2017 at 10:54 AM, Charles Kozler 
> wrote:
>>
>> I received an alert from OSSEC HIDS that a package was installed at 00:59.
>> Nobody uses this infrastructure but me
>>
>> Upon investigation I find this
>>
>> Sep 14 00:59:18 ovirthost1 sshd[93263]: Accepted publickey for root from
>> 10.0.16.50 port 50197 ssh2: RSA
>> 1c:fc:0d:b8:40:2c:bf:87:f7:8f:b2:52:0b:c4:f6:4d
>> Sep 14 00:59:18 ovirthost1 sshd[93263]: pam_unix(sshd:session): session
>> opened for user root by (uid=0)
>> Sep 14 00:59:46 ovirthost1 sshd[93263]: pam_unix(sshd:session): session
>> closed for user root
>>
>> 10.0.16.50 is my ovirt engine
>>
>> And the yum log
>>
>> Sep 14 00:59:28 Updated: iproute-3.10.0-87.el7.x86_64
>>
>> However, what is baffling to me is that this is a cluster I setup about 9
>> months ago and have not updated at all (its a testing env for VM systems)
>>
>> Why would ovirt seemingly randomly update and install a package? I know
>> the engine checks for updates on hosts but this is the first time in my time
>> using ovirt that ovirt instructed a host to install a package. This occurred
>> on all of my ovirt nodes in this infrastructure (3)

Probably the reason this didn't happen before is a mere coincidence -
there are not many updates to 'iproute', or you did update it manually
in other cases, or something like that.

>>
>> ovirt Version 4.0.1.1-1.el7.centos

Most likely you have otopi-1.5.2, which does not have above bug fixed.

You might consider upgrading to oVirt 4.1.

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