[ovirt-users] Re: Agentless backup solutions

2018-06-20 Thread Gianluca Cecchi 
On Mon, Jun 18, 2018 at 7:56 AM, femi adegoke 
wrote:

> What backup solutions are people using?
>
> I'm only interested in host-level backups (no agents in the vm's)
>
> I am aware of the following products:
> https://storware.eu/en/storware-vprotect/
> https://github.com/zipurman/oVIRT_Simple_Backup
> https://www.sepusa.com/
>
> Any others?
> ___
>

I recently found this solution that is in Red Hat ecosystem and tells to
cover both RHV (only 4.1 up to now but 4.2 seems in testing) and oVirt.
It seems you can use a full featured trial. Not tried myself yet
https://access.redhat.com/ecosystem/software/3338211

Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VYCSNGMAXUXJDZHE75TJTFP3W6B343CB/

[ovirt-users] Re: Failed to update VMs/Templates OVF data, cannot change SPM

2018-06-20 Thread Bruckner, Simone 
Hi Nir,

  I identified the reason for the failing OVF updates on the initial VG – 
metadata was affected by blkdiscard tests in scope of 
https://bugzilla.redhat.com/show_bug.cgi?id=1562369

However, the OVF updates are failing on other installations as well (on 2 out 
of 40 storage domains). Here is the output of your commands:

# lvs -o vg_name,lv_name,tags | grep 3ad1987a-8b7d-426d-9d51-4a78cb0a888f
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f 212d644c-0155-4999-9df9-72bacfc7f141 
IU_0ebefe5e-9053-4bf1-bdfd-fdb26579c179,MD_4,PU_----
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f 94f519de-bc19-4557-82c4-86bbcfc5dd2f 
IU_60d9eec7-951f-4594-ae99-7d31318ee3a9,MD_5,PU_----
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f ids
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f inbox
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f leases
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f master
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f metadata
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f outbox
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f xleases

# for i in 4 5; do
  dd if=/dev/3ad1987a-8b7d-426d-9d51-4a78cb0a888f/metadata bs=512 count=1 
skip=$i of=metadata.$i
done
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00121297 s, 422 kB/s
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000735026 s, 697 kB/s

# file metadata.*
metadata.4: data
metadata.5: ASCII text

# cat metadata.5
DOMAIN=3ad1987a-8b7d-426d-9d51-4a78cb0a888f
CTIME=1520597691
FORMAT=RAW
DISKTYPE=OVFS
LEGALITY=LEGAL
SIZE=262144
VOLTYPE=LEAF
DESCRIPTION={"Updated":true,"Size":4669440,"Last Updated":"Fri Jun 08 09:51:18 
CEST 2018","Storage 
Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk 
Description":"OVF_STORE"}
IMAGE=60d9eec7-951f-4594-ae99-7d31318ee3a9
PUUID=----
MTIME=0
POOL_UUID=
TYPE=PREALLOCATED
GEN=0
EOF

# od -c metadata.4
000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0001000

vdsm.log from manual OVF update test:

2018-06-20 09:28:27,840+0200 INFO  (jsonrpc/7) [vdsm.api] START 
setVolumeDescription(sdUUID=u'3ad1987a-8b7d-426d-9d51-4a78cb0a888f', 
spUUID=u'5849b030-626e-47cb-ad90-3ce782d831b3', 
imgUUID=u'0ebefe5e-9053-4bf1-bdfd-fdb26579c179', 
volUUID=u'212d644c-0155-4999-9df9-72bacfc7f141', 
description=u'{"Updated":false,"Last Updated":"Fri Jun 08 09:51:18 CEST 
2018","Storage Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk 
Description":"OVF_STORE"}', options=None) from=:::,51790, 
flow_id=7e4edb74, task_id=5f1fda67-a073-419a-bba5-9bf680c0e5d5 (api:46)
2018-06-20 09:28:28,072+0200 WARN  (jsonrpc/7) [storage.ResourceManager] 
Resource factory failed to create resource 
'01_img_3ad1987a-8b7d-426d-9d51-4a78cb0a888f.0ebefe5e-9053-4bf1-bdfd-fdb26579c179'.
 Canceling request. (resourceManager:543)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/storage/resourceManager.py", line 
539, in registerResource
obj = namespaceObj.factory.createResource(name, lockType)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/resourceFactories.py", 
line 193, in createResource
lockType)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/resourceFactories.py", 
line 122, in __getResourceCandidatesList
imgUUID=resourceName)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/image.py", line 206, in 
getChain
if len(uuidlist) == 1 and srcVol.isShared():
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 1434, in 
isShared
return self._manifest.isShared()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 141, in 
isShared
return self.getVolType() == sc.type2name(sc.SHARED_VOL)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 134, in 
getVolType
self.voltype = self.getMetaParam(sc.VOLTYPE)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volume.py", line 118, in 
getMetaParam
meta = self.getMetadata()
  File "/usr/lib/python2.7/site-packages/vdsm/storage/blockVolume.py", line 
112, in getMetadata
md = VolumeMetadata.from_lines(lines)
  File "/usr/lib/python2.7/site-packages/vdsm/storage/volumemetadata.py", line 
103, in from_lines
"Missing metadata key: %s: found: %s" % (e, md))
MetaDataKeyNotFoundError: Meta Data key not found error: ("Missing metadata 
key: 'DOMAIN': found: {}",)
2018-06-20 09:28:28,072+0200 WARN  (jsonrpc/7) 
[storage.ResourceManager.Request] 
(ResName='01_img_3ad1987a-8b7d-426d-9d51-4a78cb0a888f.0ebefe5e-9053-4bf1-bdfd-fdb26579c179',
 ReqID='10c95223-f349-4ac3-ab2f-7a5f3d1c7749') Tried to cancel a processed 
request (resourceManager:187)
2018-06-20 09:28:28,073+0200 INFO  (jsonrpc/7) [vdsm.api] FINISH 
setVolumeDescription error=Could not acquire resource. Probably resource 
factory threw an exception.: () from=:::,51790, flow_id=7e4edb74, 
task_id=5f1fda67-a073-419a-bba5-9bf680c0e5d5 (api:50)
2018-06-20 09:28:28,073+0200 ERROR (jsonrpc/7) [storage.TaskManager.Task] 
(Task='5f1fda

[ovirt-users] Re: ovirt upgrade 4.1 -> 4.2: host bricks down

2018-06-20 Thread Alex K 
I am running 4.2.3.8-1.el7.
I will upgrade and check.

Thanx,
Alex

On Tue, Jun 19, 2018 at 11:59 AM, Sahina Bose  wrote:

>
>
> On Sat, Jun 16, 2018 at 5:34 PM, Alex K  wrote:
>
>> Hi all,
>>
>> I have a ovirt 2 node cluster for testing with self hosted engine on top
>> gluster.
>>
>> The cluster was running on 4.1. After the upgrade to 4.2, which generally
>> went smoothly, I am seeing that the bricks of one of the hosts (v1) are
>> detected as down, while the gluster is ok when checked with command lines
>> and all volumes mounted.
>>
>> Below is the error that the engine logs:
>>
>> 2018-06-17 00:21:26,309+03 ERROR 
>> [org.ovirt.engine.core.bll.gluster.GlusterSyncJob]
>> (DefaultQuartzScheduler2)
>> [98d7e79] Error while refreshing brick statuses for volume 'vms' of
>> cluster 'test': null
>> 2018-06-17 00:21:26,318+03 ERROR [org.ovirt.engine.core.vdsbrok
>> er.gluster.GetGlusterLocalLogicalVolumeListVDSCommand]
>> (DefaultQuartzScheduler2) [98d7e79] Command 
>> 'GetGlusterLocalLogicalVolumeListVDSCommand(HostName
>> = v0.test-group.com,
>> VdsIdVDSCommandParametersBase:{hostId='d5a96118-ca49-411f-86cb-280c7f9c421f'})'
>> execution failed: null
>> 2018-06-17 00:21:26,323+03 ERROR [org.ovirt.engine.core.vdsbrok
>> er.gluster.GetGlusterLocalLogicalVolumeListVDSCommand]
>> (DefaultQuartzScheduler2) [98d7e79] Command 
>> 'GetGlusterLocalLogicalVolumeListVDSCommand(HostName
>> = v1.test-group.com,
>> VdsIdVDSCommandParametersBase:{hostId='12dfea4a-8142-484e-b912-0cbd5f281aba'})'
>> execution failed: null
>> 2018-06-17 00:21:27,015+03 INFO  
>> [org.ovirt.engine.core.bll.lock.InMemoryLockManager]
>> (DefaultQuartzScheduler9)
>> [426e7c3d] Failed to acquire lock and wait lock
>> 'EngineLock:{exclusiveLocks='[0002-0002-0002-0002-017a=GLUSTER]',
>> sharedLocks=''}'
>> 2018-06-17 00:21:27,926+03 ERROR 
>> [org.ovirt.engine.core.bll.gluster.GlusterSyncJob]
>> (DefaultQuartzScheduler2)
>> [98d7e79] Error while refreshing brick statuses for volume 'engine' of
>> cluster 'test': null
>>
>> Apart from this everything else is operating normally and VMs are running
>> on both hosts.
>>
>
> Which version of 4.2? This issue is fixed with 4.2.4
>
>
>> Any idea to isolate this issue?
>>
>> Thanx,
>> Alex
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: https://www.ovirt.org/communit
>> y/about/community-guidelines/
>> List Archives: https://lists.ovirt.org/archiv
>> es/list/users@ovirt.org/message/J3MQD5KRVIRHFCD3I54P5PHCQCCZ3ETG/
>>
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PMVE6UGFAL5SOWFP6M6XF46WVHEGF6VD/

[ovirt-users] Re: Failed to update VMs/Templates OVF data, cannot change SPM

2018-06-20 Thread Nir Soffer 
On Wed, Jun 20, 2018 at 10:33 AM Bruckner, Simone <
simone.bruck...@fabasoft.com> wrote:

> Hi Nir,
>
>
>
>   I identified the reason for the failing OVF updates on the initial VG –
> metadata was affected by blkdiscard tests in scope of
> https://bugzilla.redhat.com/show_bug.cgi?id=1562369
>
>
>
> However, the OVF updates are failing on other installations as well (on 2
> out of 40 storage domains). Here is the output of your commands:
>
>
>
> # lvs -o vg_name,lv_name,tags | grep 3ad1987a-8b7d-426d-9d51-4a78cb0a888f
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f
> 212d644c-0155-4999-9df9-72bacfc7f141
> IU_0ebefe5e-9053-4bf1-bdfd-fdb26579c179,MD_4,PU_----
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f
> 94f519de-bc19-4557-82c4-86bbcfc5dd2f
> IU_60d9eec7-951f-4594-ae99-7d31318ee3a9,MD_5,PU_----
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f ids
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f inbox
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f leases
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f master
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f metadata
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f outbox
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f xleases
>

Looks good


>
>
> # for i in 4 5; do
>
>   dd if=/dev/3ad1987a-8b7d-426d-9d51-4a78cb0a888f/metadata bs=512 count=1
> skip=$i of=metadata.$i
>
> done
>
> 1+0 records in
>
> 1+0 records out
>
> 512 bytes (512 B) copied, 0.00121297 s, 422 kB/s
>
> 1+0 records in
>
> 1+0 records out
>
> 512 bytes (512 B) copied, 0.000735026 s, 697 kB/s
>
>
>
> # file metadata.*
>
> metadata.4: data
>
> metadata.5: ASCII text
>
>
>
> # cat metadata.5
>
> DOMAIN=3ad1987a-8b7d-426d-9d51-4a78cb0a888f
>
> CTIME=1520597691
>
> FORMAT=RAW
>
> DISKTYPE=OVFS
>
> LEGALITY=LEGAL
>
> SIZE=262144
>
> VOLTYPE=LEAF
>
> DESCRIPTION={"Updated":true,"Size":4669440,"Last Updated":"Fri Jun 08
> 09:51:18 CEST 2018","Storage
> Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk
> Description":"OVF_STORE"}
>
> IMAGE=60d9eec7-951f-4594-ae99-7d31318ee3a9
>
> PUUID=----
>
> MTIME=0
>
> POOL_UUID=
>
> TYPE=PREALLOCATED
>
> GEN=0
>
> EOF
>

Looks good

>
>
> # od -c metadata.4
>
> 000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>
> *
>
> 0001000
>

There is no metada in this volume. This will fail every time when we try to
store something
into this volume.

I wonder how the metadata was deleted,  maybe there was some error when the
volume
was created?

Can you file a bug for this, and attach vdsm.log from the point this storage
domain was created until the error started?

An important date seems Fri Jun 08 09:51:18 CEST 2018 - at this date the
volume
metadata was updated in the last time.

For recovering this volume, you can write valid metadata to the same offset
using dd.

Basically it is the same as the metadata of the other ovf storage
(metadata.5)
the only changes needed are:

DESCRIPTION={"Updated":false,"Size":0,"Last Updated":"Fri Jun 08 09:51:18
CEST 2018","Storage
Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk
Description":"OVF_STORE"}

IMAGE=0ebefe5e-9053-4bf1-bdfd-fdb26579c179

I took the image uuid from the IU_ tag in lvs output.

Make sure the size of the metadata file is less then 512 bytes, otherwise
you will overwrite and corrupt the metadata of the next volume.

To write the metadata you should use:

# makes your metadata file aligned to sector size
truncate -s 512 fixed-metadata.txt

# write exactly one sector
dd if=fixed-metadata.txt of=/dev/vgname/metadata  seek=4 count=1 bs=512
oflag=direct conv=fsync

After this change, engine should be able to use this volume again.



> vdsm.log from manual OVF update test:
>
>
>
> 2018-06-20 09:28:27,840+0200 INFO  (jsonrpc/7) [vdsm.api] START
> setVolumeDescription(sdUUID=u'3ad1987a-8b7d-426d-9d51-4a78cb0a888f',
> spUUID=u'5849b030-626e-47cb-ad90-3ce782d831b3',
> imgUUID=u'0ebefe5e-9053-4bf1-bdfd-fdb26579c179',
> volUUID=u'212d644c-0155-4999-9df9-72bacfc7f141',
> description=u'{"Updated":false,"Last Updated":"Fri Jun 08 09:51:18 CEST
> 2018","Storage
> Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk
> Description":"OVF_STORE"}', options=None) from=:::,51790,
> flow_id=7e4edb74, task_id=5f1fda67-a073-419a-bba5-9bf680c0e5d5 (api:46)
>
> 2018-06-20 09:28:28,072+0200 WARN  (jsonrpc/7) [storage.ResourceManager]
> Resource factory failed to create resource
> '01_img_3ad1987a-8b7d-426d-9d51-4a78cb0a888f.0ebefe5e-9053-4bf1-bdfd-fdb26579c179'.
> Canceling request. (resourceManager:543)
>
> Traceback (most recent call last):
>
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/resourceManager.py",
> line 539, in registerResource
>
> obj = namespaceObj.factory.createResource(name, lockType)
>
>   File
> "/usr/lib/python2.7/site-packages/vdsm/storage/resourceFactories.py", line
> 193, in createResource
>
> lockType)
>
>   File
> "/usr/lib/python2.7/site-packages/vdsm/storage/resourceFactories.py",

[ovirt-users] Re: Failed to update VMs/Templates OVF data, cannot change SPM

2018-06-20 Thread Albl, Oliver 
Nir,

  thank you! I could successfully recover the corrupt metadata blocks on all 
affected storage domains!

Affected storage domains were created between January and March this year, 
accessed by 40 hosts in parallel with changing SPMs…unfortunately matching vdsm 
logs are not available anymore. I could privide a vsdm.log backup from SPM 
showing the first occurrence (+15 minutes prior the error).

All the best,
Oliver

Von: Nir Soffer 
Gesendet: Mittwoch, 20. Juni 2018 10:01
An: Bruckner, Simone 
Cc: users@ovirt.org
Betreff: [ovirt-users] Re: Failed to update VMs/Templates OVF data, cannot 
change SPM

On Wed, Jun 20, 2018 at 10:33 AM Bruckner, Simone 
mailto:simone.bruck...@fabasoft.com>> wrote:
Hi Nir,

  I identified the reason for the failing OVF updates on the initial VG – 
metadata was affected by blkdiscard tests in scope of 
https://bugzilla.redhat.com/show_bug.cgi?id=1562369

However, the OVF updates are failing on other installations as well (on 2 out 
of 40 storage domains). Here is the output of your commands:

# lvs -o vg_name,lv_name,tags | grep 3ad1987a-8b7d-426d-9d51-4a78cb0a888f
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f 212d644c-0155-4999-9df9-72bacfc7f141 
IU_0ebefe5e-9053-4bf1-bdfd-fdb26579c179,MD_4,PU_----
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f 94f519de-bc19-4557-82c4-86bbcfc5dd2f 
IU_60d9eec7-951f-4594-ae99-7d31318ee3a9,MD_5,PU_----
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f ids
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f inbox
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f leases
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f master
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f metadata
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f outbox
  3ad1987a-8b7d-426d-9d51-4a78cb0a888f xleases

Looks good


# for i in 4 5; do
  dd if=/dev/3ad1987a-8b7d-426d-9d51-4a78cb0a888f/metadata bs=512 count=1 
skip=$i of=metadata.$i
done
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00121297 s, 422 kB/s
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000735026 s, 697 kB/s

# file metadata.*
metadata.4: data
metadata.5: ASCII text

# cat metadata.5
DOMAIN=3ad1987a-8b7d-426d-9d51-4a78cb0a888f
CTIME=1520597691
FORMAT=RAW
DISKTYPE=OVFS
LEGALITY=LEGAL
SIZE=262144
VOLTYPE=LEAF
DESCRIPTION={"Updated":true,"Size":4669440,"Last Updated":"Fri Jun 08 09:51:18 
CEST 2018","Storage 
Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk 
Description":"OVF_STORE"}
IMAGE=60d9eec7-951f-4594-ae99-7d31318ee3a9
PUUID=----
MTIME=0
POOL_UUID=
TYPE=PREALLOCATED
GEN=0
EOF

Looks good

# od -c metadata.4
000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0001000

There is no metada in this volume. This will fail every time when we try to 
store something
into this volume.

I wonder how the metadata was deleted,  maybe there was some error when the 
volume
was created?

Can you file a bug for this, and attach vdsm.log from the point this storage
domain was created until the error started?

An important date seems Fri Jun 08 09:51:18 CEST 2018 - at this date the volume
metadata was updated in the last time.

For recovering this volume, you can write valid metadata to the same offset
using dd.

Basically it is the same as the metadata of the other ovf storage (metadata.5)
the only changes needed are:

DESCRIPTION={"Updated":false,"Size":0,"Last Updated":"Fri Jun 08 09:51:18 CEST 
2018","Storage Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk 
Description":"OVF_STORE"}

IMAGE=0ebefe5e-9053-4bf1-bdfd-fdb26579c179

I took the image uuid from the IU_ tag in lvs output.

Make sure the size of the metadata file is less then 512 bytes, otherwise
you will overwrite and corrupt the metadata of the next volume.

To write the metadata you should use:
# makes your metadata file aligned to sector size
truncate -s 512 fixed-metadata.txt

# write exactly one sector
dd if=fixed-metadata.txt of=/dev/vgname/metadata  seek=4 count=1 bs=512 
oflag=direct conv=fsync

After this change, engine should be able to use this volume again.

vdsm.log from manual OVF update test:

2018-06-20 09:28:27,840+0200 INFO  (jsonrpc/7) [vdsm.api] START 
setVolumeDescription(sdUUID=u'3ad1987a-8b7d-426d-9d51-4a78cb0a888f', 
spUUID=u'5849b030-626e-47cb-ad90-3ce782d831b3', 
imgUUID=u'0ebefe5e-9053-4bf1-bdfd-fdb26579c179', 
volUUID=u'212d644c-0155-4999-9df9-72bacfc7f141', 
description=u'{"Updated":false,"Last Updated":"Fri Jun 08 09:51:18 CEST 
2018","Storage Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk 
Description":"OVF_STORE"}', options=None) from=:::,51790, 
flow_id=7e4edb74, task_id=5f1fda67-a073-419a-bba5-9bf680c0e5d5 (api:46)
2018-06-20 09:28:28,072+0200 WARN  (jsonrpc/7) [storage.ResourceManager] 
Resource factory failed to create resource 
'01_img_3ad1987a-8b7d-426d-9d51-4a78cb0a888f.0ebefe5e-9053-4bf1-bdfd-fdb26579c179'.
 Canceling request. (resourceManager:543)
Traceback (most recent call last):
  File "/usr/l

[ovirt-users] Ignore extra parameters in oVirt API

2018-06-20 Thread Hari Prasanth Loganathan 
Hi Team,

I want to attach the disk using the oVIrt rest API, I use the version* 4.2*
and completed my script.
But when I downgrade my oVirt to lower version *4.1*, I get the following
error.

detail: 'For correct usage, see:
https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-attachments/methods/add',\n
reason: 'Request syntactically incorrect.',\n  error: 'For correct usage,
see:
https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-attachments/methods/add
',\n

*Reason*: I added an extra parameter called 'isSharable' which is not
expected in this API.


*So Is there a way to Ignore the extra parameters sent for oVirt API?*

*Example :*


*Expected :*

*{*
* "a"  : "1"*

*}*

*I sent :*

*{*
*  "a" : "1",*
*  "b" : "2"*
*}*


*My expectation is, Ignore the "b" and the API should work, Is there a flag
in oVirt API which ignores the extra parameters?  *

Thanks,
Hari
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3KQOHNPY56WRYA7GPRCVEKIGOVDV66AM/

[ovirt-users] Re: [spice-list] Fwd: Fwd: VM hanging at boot - [drm] Initialized qxl

2018-06-20 Thread Christophe Fergeau 
On Wed, Jun 20, 2018 at 12:38:00PM +0300, Yaniv Kaul wrote:
> On Wed, Jun 20, 2018 at 12:26 PM, Christophe Fergeau 
> wrote:
> > > > -- Forwarded message --
> > > > From: Leo David 
> > > > Date: Wed, Jun 13, 2018 at 8:24 PM
> > > > Subject: VM hanging at boot - [drm] Initialized qxl
> > > > To: users@ovirt.org
> > > >
> > > >
> > > > Hello everyone,
> > > > I have some Centos7 vms created from template ( CentOS 7 Generic Cloud
> > > > Image v1802 for x86_64 )
> > > > I have alocated planty of resources to them,  but they all have this
> > issue
> > > > when starting, they hang with the following message in console about
> > 5-7
> > > > minutes.
> > > >
> > > > [drm] Initialized qxl 0.1.0 20120117 for :00:02:0 on mirror 0
> > > >
> > > > After a while,  vm eventually boots up...
> > > > Running self-hosted ovirt-node 4.2
> > > > Does anyone know what could be the issue for this behavior ?
> > > > Thank you !
> >
> > There were recently some hangs at startup due to a kernel bug in the qxl
> > driver related to atomic modesetting, no idea if centos could be
> > impacted by this or not. Does the issue go away when using another
> > graphics device than QXL?
> >
> 
> Can you please respond on the oVirt users mailing list?

I added it to cc:

Christophe


signature.asc
Description: PGP signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OIKDCZ3MFYQNPS6QLJLH45NIS3OUX56Z/

[ovirt-users] Re: Ignore extra parameters in oVirt API

2018-06-20 Thread Hari Prasanth Loganathan 
Hi all,

To clarify my payload is like below,

*Expected :*

{
   "alias": "testdisk",
   "shareable": false,
   "storage_type": "cinder",
   "openstack_volume_type": {
"name": "ceph"
},
   "description": "",
   "storage_domains": {
 "storage_domain": [{
"name": "cinder_newone"
 }]
},
   "provisioned_size": 1073741824,
 "interface": "virtio",
 "format": "cow"
}

*I sent : *

{
   "alias": "testdisk",
   "shareable": false,
   "storage_type": "cinder",
   "openstack_volume_type": {
"name": "ceph"
},
   "description": "",
   "storage_domains": {
 "storage_domain": [{
"name": "cinder_newone"
 }]
},
   "provisioned_size": 1073741824,
 "interface": "virtio",
 "format": "cow",
* "test" : "value"*
}


Is there a way to ignore the *test* field? Please let me know any way /
work around.


Any help is much appreciated.

Thanks,
Hari


On Wed, Jun 20, 2018 at 3:09 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi Team,
>
> I want to attach the disk using the oVIrt rest API, I use the version*
> 4.2* and completed my script.
> But when I downgrade my oVirt to lower version *4.1*, I get the following
> error.
>
> detail: 'For correct usage, see: https://X.X.99.84/ovirt-
> engine/api/v4/model#services/disk-attachments/methods/add',\n  reason: 
> 'Request
> syntactically incorrect.',\n  error: 'For correct usage, see:
> https://X.X.99.84/ovirt-engine/api/v4/model#services/
> disk-attachments/methods/add',\n
>
> *Reason*: I added an extra parameter called 'isSharable' which is not
> expected in this API.
>
>
> *So Is there a way to Ignore the extra parameters sent for oVirt API?*
>
> *Example :*
>
>
> *Expected :*
>
> *{*
> * "a"  : "1"*
>
> *}*
>
> *I sent :*
>
> *{*
> *  "a" : "1",*
> *  "b" : "2"*
> *}*
>
>
> *My expectation is, Ignore the "b" and the API should work, Is there a
> flag in oVirt API which ignores the extra parameters?  *
>
> Thanks,
> Hari
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XISQ3CETFK7VEXEW2I2IYGN22DAHTDIK/

[ovirt-users] Re: ovirt upgrade 4.1 -> 4.2: host bricks down

2018-06-20 Thread Alex K 
Updated hosts and engine. Ran engine-setup but still version is showing
4.2.3.8-1.el7.
The issue has been resolved though. Bricks are shown up.

Thanx,
Alex

On Wed, Jun 20, 2018 at 10:48 AM, Alex K  wrote:

> I am running 4.2.3.8-1.el7.
> I will upgrade and check.
>
> Thanx,
> Alex
>
> On Tue, Jun 19, 2018 at 11:59 AM, Sahina Bose  wrote:
>
>>
>>
>> On Sat, Jun 16, 2018 at 5:34 PM, Alex K  wrote:
>>
>>> Hi all,
>>>
>>> I have a ovirt 2 node cluster for testing with self hosted engine on top
>>> gluster.
>>>
>>> The cluster was running on 4.1. After the upgrade to 4.2, which
>>> generally went smoothly, I am seeing that the bricks of one of the hosts
>>> (v1) are detected as down, while the gluster is ok when checked with
>>> command lines and all volumes mounted.
>>>
>>> Below is the error that the engine logs:
>>>
>>> 2018-06-17 00:21:26,309+03 ERROR 
>>> [org.ovirt.engine.core.bll.gluster.GlusterSyncJob]
>>> (DefaultQuartzScheduler2)
>>> [98d7e79] Error while refreshing brick statuses for volume 'vms' of
>>> cluster 'test': null
>>> 2018-06-17 00:21:26,318+03 ERROR [org.ovirt.engine.core.vdsbrok
>>> er.gluster.GetGlusterLocalLogicalVolumeListVDSCommand]
>>> (DefaultQuartzScheduler2) [98d7e79] Command
>>> 'GetGlusterLocalLogicalVolumeListVDSCommand(HostName = v0.test-group.com
>>> ,
>>> VdsIdVDSCommandParametersBase:{hostId='d5a96118-ca49-411f-86cb-280c7f9c421f'})'
>>> execution failed: null
>>> 2018-06-17 00:21:26,323+03 ERROR [org.ovirt.engine.core.vdsbrok
>>> er.gluster.GetGlusterLocalLogicalVolumeListVDSCommand]
>>> (DefaultQuartzScheduler2) [98d7e79] Command
>>> 'GetGlusterLocalLogicalVolumeListVDSCommand(HostName = v1.test-group.com
>>> ,
>>> VdsIdVDSCommandParametersBase:{hostId='12dfea4a-8142-484e-b912-0cbd5f281aba'})'
>>> execution failed: null
>>> 2018-06-17 00:21:27,015+03 INFO  
>>> [org.ovirt.engine.core.bll.lock.InMemoryLockManager]
>>> (DefaultQuartzScheduler9)
>>> [426e7c3d] Failed to acquire lock and wait lock
>>> 'EngineLock:{exclusiveLocks='[0002-0002-0002-0002-017a=GLUSTER]',
>>> sharedLocks=''}'
>>> 2018-06-17 00:21:27,926+03 ERROR 
>>> [org.ovirt.engine.core.bll.gluster.GlusterSyncJob]
>>> (DefaultQuartzScheduler2)
>>> [98d7e79] Error while refreshing brick statuses for volume 'engine' of
>>> cluster 'test': null
>>>
>>> Apart from this everything else is operating normally and VMs are
>>> running on both hosts.
>>>
>>
>> Which version of 4.2? This issue is fixed with 4.2.4
>>
>>
>>> Any idea to isolate this issue?
>>>
>>> Thanx,
>>> Alex
>>>
>>>
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct: https://www.ovirt.org/communit
>>> y/about/community-guidelines/
>>> List Archives: https://lists.ovirt.org/archiv
>>> es/list/users@ovirt.org/message/J3MQD5KRVIRHFCD3I54P5PHCQCCZ3ETG/
>>>
>>>
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/O5JCX5NU7P3U2PAVX7HXXXF5RZOU57NQ/

[ovirt-users] Re: Ignore extra parameters in oVirt API

2018-06-20 Thread Hari Prasanth Loganathan 
Hi Team,

I got one clue, using the code base :
https://github.com/oVirt/ovirt-engine/blob/e2aad594a55c7272b513736616cb4b9841c2c43d/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/serialization/json/JsonObjectDeserializer.java


formattedMapper.configure(Feature.FAIL_ON_UNKNOWN_PROPERTIES, false);

As a default, this flag is set as false, then How I get this error? Any
idea?


Thanks,
Hari



On Wed, Jun 20, 2018 at 5:21 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi all,
>
> To clarify my payload is like below,
>
> *Expected :*
>
> {
>"alias": "testdisk",
>"shareable": false,
>"storage_type": "cinder",
>"openstack_volume_type": {
> "name": "ceph"
> },
>"description": "",
>"storage_domains": {
>  "storage_domain": [{
> "name": "cinder_newone"
>  }]
> },
>"provisioned_size": 1073741824,
>  "interface": "virtio",
>  "format": "cow"
> }
>
> *I sent : *
>
> {
>"alias": "testdisk",
>"shareable": false,
>"storage_type": "cinder",
>"openstack_volume_type": {
> "name": "ceph"
> },
>"description": "",
>"storage_domains": {
>  "storage_domain": [{
> "name": "cinder_newone"
>  }]
> },
>"provisioned_size": 1073741824,
>  "interface": "virtio",
>  "format": "cow",
> * "test" : "value"*
> }
>
>
> Is there a way to ignore the *test* field? Please let me know any way /
> work around.
>
>
> Any help is much appreciated.
>
> Thanks,
> Hari
>
>
> On Wed, Jun 20, 2018 at 3:09 PM, Hari Prasanth Loganathan  msystechnologies.com> wrote:
>
>> Hi Team,
>>
>> I want to attach the disk using the oVIrt rest API, I use the version*
>> 4.2* and completed my script.
>> But when I downgrade my oVirt to lower version *4.1*, I get the
>> following error.
>>
>> detail: 'For correct usage, see: https://X.X.99.84/ovirt-engine
>> /api/v4/model#services/disk-attachments/methods/add',\n  reason: 'Request
>> syntactically incorrect.',\n  error: 'For correct usage, see:
>> https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-
>> attachments/methods/add',\n
>>
>> *Reason*: I added an extra parameter called 'isSharable' which is not
>> expected in this API.
>>
>>
>> *So Is there a way to Ignore the extra parameters sent for oVirt API?*
>>
>> *Example :*
>>
>>
>> *Expected :*
>>
>> *{*
>> * "a"  : "1"*
>>
>> *}*
>>
>> *I sent :*
>>
>> *{*
>> *  "a" : "1",*
>> *  "b" : "2"*
>> *}*
>>
>>
>> *My expectation is, Ignore the "b" and the API should work, Is there a
>> flag in oVirt API which ignores the extra parameters?  *
>>
>> Thanks,
>> Hari
>>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XVGYZ553IUIAAQVJB34XUDO5VCFTLOH7/

[ovirt-users] [ANN] oVirt 4.2.4 Fifth Release Candidate is now available

2018-06-20 Thread Lev Veyde 
The oVirt Project is pleased to announce the availability of the oVirt
4.2.4 Fifth Release Candidate, as of June 20th, 2018.

This update is a release candidate of the fourth in a series of
stabilization updates to the 4.2
series.
This is pre-release software. This pre-release should not to be used in
production.

This release is available now for:
* Red Hat Enterprise Linux 7.5 or later
* CentOS Linux (or similar) 7.5 or later

This release supports Hypervisor Hosts running:
* Red Hat Enterprise Linux 7.5 or later
* CentOS Linux (or similar) 7.5 or later

See the release notes [1] for installation / upgrade instructions and
a list of new features and bugs fixed.

Notes:
- oVirt Appliance is available
- oVirt Node is available [2]

Additional Resources:
* Read more about the oVirt 4.2.4 release highlights:
http://www.ovirt.org/release/4.2.4/
* Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/

[1] http://www.ovirt.org/release/4.2.4/
[2] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/

-- 

Lev Veyde

Software Engineer, RHCE | RHCVA | MCITP

Red Hat Israel



l...@redhat.com | lve...@redhat.com

TRIED. TESTED. TRUSTED. 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QS2ADLQWRDJ5YKPTYJ3EHMUTFTNFPPEE/

[ovirt-users] Re: upgrade 4.1 to 4.2

2018-06-20 Thread Staniforth, Paul 
Thanks Ido,

 I actually used 
https://resources.ovirt.org/pub/ovirt-4.1/rpm/el7/ which worked.


I am now trying to configure the test system from backup and doing an 
engine-rename but am having difficulty with the certificate as we are using an 
externally signed certificate.


Regards,

  Paul S.


From: Ido Rosenzwig 
Sent: 20 June 2018 07:32
To: Staniforth, Paul
Cc: Yedidyah Bar David; users@ovirt.org
Subject: Re: [ovirt-users] Re: upgrade 4.1 to 4.2

Dear paul,

You can do the following:
1. Check which repos are unavailable with:
   # yum repolist
2. Detect the repos that have no packages:
repo id   repo name 
  status
base/7/x86_64  CentOS-7 - Base  
9,911
centos-opstools-release/x86_64   CentOS-7 - OpsTools - release  
   493
extras/7/x86_64CentOS-7 - Extras
 313
ovirt-4.1/7  Latest oVirt 4.1 
Release   2,229
ovirt-4.1-centos-gluster38/x86_64CentOS-7 - Gluster 3.8 
 0
ovirt-4.1-centos-qemu-ev/x86_64 CentOS-7 - QEMU EV  
 55
...

3. Edit /etc/yum.repo.d/ovirt-4.1-dependencies.repo and switch from enable=1 to 
enable=0 the repos you found.

4. Now try:
# yum install ovirt-engine

NOTE: This will disable those repos permanently. If you you wish to enable them 
back switch from 0 to 1 in the repo file.

Best regards,
Ido Rosenzwig








On Tue, Jun 19, 2018 at 12:49 PM, Staniforth, Paul 
mailto:p.stanifo...@leedsbeckett.ac.uk>> wrote:
Thanks Didi,
  It doesn't seem to have ovirt-engine,   amongst  
other missing packages.
Regards,
  Paul S.

From: Yedidyah Bar David mailto:d...@redhat.com>>
Sent: 19 June 2018 08:18
To: Staniforth, Paul
Cc: users@ovirt.org
Subject: Re: [ovirt-users] upgrade 4.1 to 4.2

On Mon, Jun 18, 2018 at 6:55 PM, Staniforth, Paul
mailto:p.stanifo...@leedsbeckett.ac.uk>> wrote:
> Hello,
>
>  I am trying to test the upgrade of our system from oVirt 4.1 to
> oVirt 4.2. I'm trying to restore a backup onto a test system but cannot
> install version 4.1 as the repos are not available.
>
>
> yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm
>
>
> yum install ovirt-engine
>
>
> gives
> http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/repodata/repomd.xml:
> [Errno 14] HTTP Error 404 - Not Found
>
>
> and
>
>
>
> yum  --disablerepo=ovirt-4.1-centos-gluster38 install ovirt-engine
>
> gives
>
>
> http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.1/repodata/repomd.xml:
> [Errno 14] HTTP Error 404 - Not Found
>
>
>
> are there any alternate repos to try?

Please check:

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

Thanks,

>
>
>
> Thanks,
>
> Paul S.
>
> To view the terms under which this email is distributed, please go to:-
> http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to 
> users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XFJHS7OGUY4BS3JWG4NB6JCPVWMTR74J/
>



--
Didi
To view the terms under which this email is distributed, please go to:-
http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LG6TA3NLYKYFHSXBXDDVLJ4DCIFSIP37/

To view the terms under which this email is distributed, please go to:-
http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YVNGRZRELB3ODJSA4YCCYKOR7SZWEPRR/

[ovirt-users] Re: [spice-list] Fwd: Fwd: VM hanging at boot - [drm] Initialized qxl

2018-06-20 Thread Leo David 
Thank you,
Weird, but issue seems to be present with VGA too. I haven't start to debug
to much on this, being pressed on creating a whole bunch of vms I prefered
to run a Centos7 vm installation from schratch and template it.
It would be good anyway to have those oVirt provided templates good and
reliable...
Looking further on this.
Thank you very much !

On Wed, Jun 20, 2018 at 12:53 PM, Christophe Fergeau 
wrote:

> On Wed, Jun 20, 2018 at 12:38:00PM +0300, Yaniv Kaul wrote:
> > On Wed, Jun 20, 2018 at 12:26 PM, Christophe Fergeau <
> cferg...@redhat.com>
> > wrote:
> > > > > -- Forwarded message --
> > > > > From: Leo David 
> > > > > Date: Wed, Jun 13, 2018 at 8:24 PM
> > > > > Subject: VM hanging at boot - [drm] Initialized qxl
> > > > > To: users@ovirt.org
> > > > >
> > > > >
> > > > > Hello everyone,
> > > > > I have some Centos7 vms created from template ( CentOS 7 Generic
> Cloud
> > > > > Image v1802 for x86_64 )
> > > > > I have alocated planty of resources to them,  but they all have
> this
> > > issue
> > > > > when starting, they hang with the following message in console
> about
> > > 5-7
> > > > > minutes.
> > > > >
> > > > > [drm] Initialized qxl 0.1.0 20120117 for :00:02:0 on mirror 0
> > > > >
> > > > > After a while,  vm eventually boots up...
> > > > > Running self-hosted ovirt-node 4.2
> > > > > Does anyone know what could be the issue for this behavior ?
> > > > > Thank you !
> > >
> > > There were recently some hangs at startup due to a kernel bug in the
> qxl
> > > driver related to atomic modesetting, no idea if centos could be
> > > impacted by this or not. Does the issue go away when using another
> > > graphics device than QXL?
> > >
> >
> > Can you please respond on the oVirt users mailing list?
>
> I added it to cc:
>
> Christophe
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/OIKDCZ3MFYQNPS6QLJLH45NIS3OUX56Z/
>
>


-- 
Best regards, Leo David
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UD76I3MPUCM5RUQRE5A2NFKA3Y463QZT/

[ovirt-users] Re: Trying to update a host. (ovirt4.1)

2018-06-20 Thread Spickiy Nikita 
Disable EPEL repo and repeat update

On 19 Jun 2018, at 22:26, Jacob Green 
mailto:jgr...@aasteel.com>> wrote:


I just did not know where to look for the errors, I now see that it is telling 
me it is failing on this package "collectd"



So when I go to my host and I run yum list collectd I see that collectd is 
available to install via EPEL repos. Note: I did not setup this cluster not 
sure if epel is normal.




So looks like my problem here has to do with the epel package being available 
and being newer?


Thank you all.


On 06/19/2018 09:40 AM, Jacob Green wrote:
When I right click an empty host, and select upgrade and confirm that I 
want to upgrade. It simply comes back with install failed after a minute or 
two. I have no idea why its failing, there also does not appear to be anything 
in /var/log/yum.log so I am not sure where else to look to figure out why it 
cannot upgrade. Also to be clear, the wording in Ovirt uses the term upgrade, 
however I am under the impression it simply means update, not actually upgrade 
to 4.2.



Thank you all.


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org
Privacy Statement: 
https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZFVQXUEYBCHORCRKYRBU4JTLQZPFACK3/


--
Jacob Green

Systems Admin

American Alloy Steel

713-300-5690

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org
Privacy Statement: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fsite%2Fprivacy-policy%2F&data=02%7C01%7C%7C7e6324f27cec4c61e53008d5d5f96b0b%7C84df9e7fe9f640afb435%7C1%7C0%7C636650189570671175&sdata=f21XohOzUZFSHeh1DXADEONFkZy9hVk8OVB0m9lCaKE%3D&reserved=0
oVirt Code of Conduct: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2F&data=02%7C01%7C%7C7e6324f27cec4c61e53008d5d5f96b0b%7C84df9e7fe9f640afb435%7C1%7C0%7C636650189570671175&sdata=3iX5GXTxhszloLbTm1MWkOBx%2BQ6diX1oeZkDFoApG%2Bg%3D&reserved=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2F3D3TFBVEV4I7KKPP4JYCVMWZCOGFIY4K%2F&data=02%7C01%7C%7C7e6324f27cec4c61e53008d5d5f96b0b%7C84df9e7fe9f640afb435%7C1%7C0%7C636650189570671175&sdata=%2BfR8yruTYRkY3Ji1asW1V8yiD8D0s9w%2FvL7j537lHP8%3D&reserved=0

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VJT7O3UUBNVQYORC4FSBSHNPFKBXBD6W/

[ovirt-users] Re: Trying to update a host. (ovirt4.1)

2018-06-20 Thread Chris Boot 
[re-send from my lists address]

On 19/06/18 19:25, Joop wrote:
> On 19-6-2018 17:26, Jacob Green wrote:
>>
>> I just did not know where to look for the errors, I now see that it is
>> telling me it is failing on this package "collectd"
>>
>> So when I go to my host and I run *yum list collectd *I see that
>> collectd is available to install via EPEL repos. _/Note: I did not
>> setup this cluster not sure if epel is normal./
>>
>>
>>
>>
>> So looks like my problem here has to do with the epel package being
>> available and being newer?
>>
> There is a warning on the ovirt site about enabling epel :-)
> 
> Disable the epel repo and just use yum install whatever
> --enablerepo=epel just in case you need it.

In my opinion this is bad advice, as keeping the repo disabled (but
still obtaining packages from it occasionally) will mean you never
automatically receive updates to packages you've installed from it.

Instead, I recommend that you edit /etc/yum.repos.d/epel.repo and add
the line "exclude=collectd*" under the "[epel]" heading. I've only ever
seen issues with the collectd packages from EPEL and no others.

If you want to be a bit stricter you can instead only
"include=" the packages that you are specifically interested
in. In my case that's too many packages to be practical.

Cheers,
Chris

-- 
Chris Boot
bo...@boo.tc
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6TVOQ3PRPOLICDMF7644GHXDBHIWUBHD/

[ovirt-users] Re: Ignore extra parameters in oVirt API

2018-06-20 Thread Hari Prasanth Loganathan 
Guys any update on this?  if you have any clarification let me know please.

Thanks

On Wed, 20 Jun 2018 at 5:41 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi Team,
>
> I got one clue, using the code base :
> https://github.com/oVirt/ovirt-engine/blob/e2aad594a55c7272b513736616cb4b9841c2c43d/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/serialization/json/JsonObjectDeserializer.java
>
>
> formattedMapper.configure(Feature.FAIL_ON_UNKNOWN_PROPERTIES, false);
>
> As a default, this flag is set as false, then How I get this error? Any
> idea?
>
>
> Thanks,
> Hari
>
>
>
> On Wed, Jun 20, 2018 at 5:21 PM, Hari Prasanth Loganathan <
> hariprasant...@msystechnologies.com> wrote:
>
>> Hi all,
>>
>> To clarify my payload is like below,
>>
>> *Expected :*
>>
>> {
>>"alias": "testdisk",
>>"shareable": false,
>>"storage_type": "cinder",
>>"openstack_volume_type": {
>> "name": "ceph"
>> },
>>"description": "",
>>"storage_domains": {
>>  "storage_domain": [{
>> "name": "cinder_newone"
>>  }]
>> },
>>"provisioned_size": 1073741824,
>>  "interface": "virtio",
>>  "format": "cow"
>> }
>>
>> *I sent : *
>>
>> {
>>"alias": "testdisk",
>>"shareable": false,
>>"storage_type": "cinder",
>>"openstack_volume_type": {
>> "name": "ceph"
>> },
>>"description": "",
>>"storage_domains": {
>>  "storage_domain": [{
>> "name": "cinder_newone"
>>  }]
>> },
>>"provisioned_size": 1073741824,
>>  "interface": "virtio",
>>  "format": "cow",
>> * "test" : "value"*
>> }
>>
>>
>> Is there a way to ignore the *test* field? Please let me know any way /
>> work around.
>>
>>
>> Any help is much appreciated.
>>
>> Thanks,
>> Hari
>>
>>
>> On Wed, Jun 20, 2018 at 3:09 PM, Hari Prasanth Loganathan <
>> hariprasant...@msystechnologies.com> wrote:
>>
>>> Hi Team,
>>>
>>> I want to attach the disk using the oVIrt rest API, I use the version*
>>> 4.2* and completed my script.
>>> But when I downgrade my oVirt to lower version *4.1*, I get the
>>> following error.
>>>
>>> detail: 'For correct usage, see:
>>> https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-attachments/methods/add',\n
>>> reason: 'Request syntactically incorrect.',\n  error: 'For correct
>>> usage, see:
>>> https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-attachments/methods/add
>>> ',\n
>>>
>>> *Reason*: I added an extra parameter called 'isSharable' which is not
>>> expected in this API.
>>>
>>>
>>> *So Is there a way to Ignore the extra parameters sent for oVirt API?*
>>>
>>> *Example :*
>>>
>>>
>>> *Expected :*
>>>
>>> *{*
>>> * "a"  : "1"*
>>>
>>> *}*
>>>
>>> *I sent :*
>>>
>>> *{*
>>> *  "a" : "1",*
>>> *  "b" : "2"*
>>> *}*
>>>
>>>
>>> *My expectation is, Ignore the "b" and the API should work, Is there a
>>> flag in oVirt API which ignores the extra parameters?  *
>>>
>>> Thanks,
>>> Hari
>>>
>>
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q3S2KU4PXZ7P2ZBLAYM7CYAK2S4NUJD5/

[ovirt-users] HE + Gluster : Engine corrupted?

2018-06-20 Thread Hanson Turner 

Hi Benny,

Who should I be reaching out to for help with a gluster based hosted 
engine corruption?



--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : True
Hostname   : ovirtnode1.abcxyzdomains.net
Host ID    : 1
Engine status  : {"reason": "failed liveliness 
check", "health": "bad", "vm": "up", "detail": "Up"}

Score  : 3400
stopped    : False
Local maintenance  : False
crc32  : 92254a68
local_conf_timestamp   : 115910
Host timestamp : 115910
Extra metadata (valid at timestamp):
    metadata_parse_version=1
    metadata_feature_version=1
    timestamp=115910 (Mon Jun 18 09:43:20 2018)
    host-id=1
    score=3400
    vm_conf_refresh_time=115910 (Mon Jun 18 09:43:20 2018)
    conf_on_shared_storage=True
    maintenance=False
    state=GlobalMaintenance
    stopped=False


My when I VNC into my HE, All I get is:
Probing EDD (edd=off to disable)... ok


So, that's why it's failing the liveliness check... I cannot get the 
screen on HE to change short of ctl-alt-del which will reboot the HE.

I do have backups for the HE that are/were run on a nightly basis.

If the cluster was left alone, the HE vm would bounce from machine to 
machine trying to boot. This is why the cluster is in maintenance mode.
One of the nodes was down for a period of time and brought back, 
sometime through the night, which is when the automated backup kicks, 
the HE started bouncing around. Got nearly 1000 emails.


This seems to be the same error (but may not be the same cause) as 
listed here:

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

Thanks,

Hanson

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3NLA2URX3KN44FGFUVV4N5EJBPICABHH/

[ovirt-users] Re: Failed to update VMs/Templates OVF data, cannot change SPM

2018-06-20 Thread Nir Soffer 
On Wed, Jun 20, 2018 at 12:17 PM Albl, Oliver 
wrote:

> Nir,
>
>
>
>   thank you! I could successfully recover the corrupt metadata blocks on
> all affected storage domains!
>
>
>
> Affected storage domains were created between January and March this year,
> accessed by 40 hosts in parallel with changing SPMs…unfortunately matching
> vdsm logs are not available anymore. I could privide a vsdm.log backup from
> SPM showing the first occurrence (+15 minutes prior the error).
>

These logs may be useful to understand why the metadata was wiped.

Please file a bug and attach these logs.

Nir


>
>
> All the best,
>
> Oliver
>
>
>
> *Von:* Nir Soffer 
> *Gesendet:* Mittwoch, 20. Juni 2018 10:01
> *An:* Bruckner, Simone 
> *Cc:* users@ovirt.org
>
>
> *Betreff:* [ovirt-users] Re: Failed to update VMs/Templates OVF data,
> cannot change SPM
>
>
>
> On Wed, Jun 20, 2018 at 10:33 AM Bruckner, Simone <
> simone.bruck...@fabasoft.com> wrote:
>
> Hi Nir,
>
>
>
>   I identified the reason for the failing OVF updates on the initial VG –
> metadata was affected by blkdiscard tests in scope of
> https://bugzilla.redhat.com/show_bug.cgi?id=1562369
>
>
>
> However, the OVF updates are failing on other installations as well (on 2
> out of 40 storage domains). Here is the output of your commands:
>
>
>
> # lvs -o vg_name,lv_name,tags | grep 3ad1987a-8b7d-426d-9d51-4a78cb0a888f
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f
> 212d644c-0155-4999-9df9-72bacfc7f141
> IU_0ebefe5e-9053-4bf1-bdfd-fdb26579c179,MD_4,PU_----
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f
> 94f519de-bc19-4557-82c4-86bbcfc5dd2f
> IU_60d9eec7-951f-4594-ae99-7d31318ee3a9,MD_5,PU_----
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f ids
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f inbox
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f leases
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f master
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f metadata
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f outbox
>
>   3ad1987a-8b7d-426d-9d51-4a78cb0a888f xleases
>
>
>
> Looks good
>
>
>
>
>
> # for i in 4 5; do
>
>   dd if=/dev/3ad1987a-8b7d-426d-9d51-4a78cb0a888f/metadata bs=512 count=1
> skip=$i of=metadata.$i
>
> done
>
> 1+0 records in
>
> 1+0 records out
>
> 512 bytes (512 B) copied, 0.00121297 s, 422 kB/s
>
> 1+0 records in
>
> 1+0 records out
>
> 512 bytes (512 B) copied, 0.000735026 s, 697 kB/s
>
>
>
> # file metadata.*
>
> metadata.4: data
>
> metadata.5: ASCII text
>
>
>
> # cat metadata.5
>
> DOMAIN=3ad1987a-8b7d-426d-9d51-4a78cb0a888f
>
> CTIME=1520597691
>
> FORMAT=RAW
>
> DISKTYPE=OVFS
>
> LEGALITY=LEGAL
>
> SIZE=262144
>
> VOLTYPE=LEAF
>
> DESCRIPTION={"Updated":true,"Size":4669440,"Last Updated":"Fri Jun 08
> 09:51:18 CEST 2018","Storage
> Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk
> Description":"OVF_STORE"}
>
> IMAGE=60d9eec7-951f-4594-ae99-7d31318ee3a9
>
> PUUID=----
>
> MTIME=0
>
> POOL_UUID=
>
> TYPE=PREALLOCATED
>
> GEN=0
>
> EOF
>
>
>
> Looks good
>
>
>
> # od -c metadata.4
>
> 000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>
> *
>
> 0001000
>
>
>
> There is no metada in this volume. This will fail every time when we try
> to store something
>
> into this volume.
>
>
>
> I wonder how the metadata was deleted,  maybe there was some error when
> the volume
>
> was created?
>
>
>
> Can you file a bug for this, and attach vdsm.log from the point this
> storage
> domain was created until the error started?
>
>
>
> An important date seems Fri Jun 08 09:51:18 CEST 2018 - at this date the
> volume
>
> metadata was updated in the last time.
>
> For recovering this volume, you can write valid metadata to the same offset
> using dd.
>
> Basically it is the same as the metadata of the other ovf storage
> (metadata.5)
> the only changes needed are:
>
> DESCRIPTION={"Updated":false,"Size":0,"Last Updated":"Fri Jun 08 09:51:18
> CEST 2018","Storage
> Domains":[{"uuid":"3ad1987a-8b7d-426d-9d51-4a78cb0a888f"}],"Disk
> Description":"OVF_STORE"}
>
>
> IMAGE=0ebefe5e-9053-4bf1-bdfd-fdb26579c179
>
> I took the image uuid from the IU_ tag in lvs output.
>
> Make sure the size of the metadata file is less then 512 bytes, otherwise
> you will overwrite and corrupt the metadata of the next volume.
>
> To write the metadata you should use:
>
> # makes your metadata file aligned to sector size
> truncate -s 512 fixed-metadata.txt
>
> # write exactly one sector
> dd if=fixed-metadata.txt of=/dev/vgname/metadata  seek=4 count=1 bs=512
> oflag=direct conv=fsync
>
>
> After this change, engine should be able to use this volume again.
>
>
>
> vdsm.log from manual OVF update test:
>
>
>
> 2018-06-20 09:28:27,840+0200 INFO  (jsonrpc/7) [vdsm.api] START
> setVolumeDescription(sdUUID=u'3ad1987a-8b7d-426d-9d51-4a78cb0a888f',
> spUUID=u'5849b030-626e-47cb-ad90-3ce782d831b3',
> imgUUID=u'0ebefe5e-9053-4bf1-bdfd-fdb26579c179',
> volUUID=u'212d644c-0155-4999-9df9-72bacfc7f141',

[ovirt-users] Re: Ignore extra parameters in oVirt API

2018-06-20 Thread Greg Sheremeta 
+Ondra and Ori

On Wed, Jun 20, 2018 at 1:07 PM Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Guys any update on this?  if you have any clarification let me know please.
>
> Thanks
>
> On Wed, 20 Jun 2018 at 5:41 PM, Hari Prasanth Loganathan <
> hariprasant...@msystechnologies.com> wrote:
>
>> Hi Team,
>>
>> I got one clue, using the code base :
>> https://github.com/oVirt/ovirt-engine/blob/e2aad594a55c7272b513736616cb4b9841c2c43d/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/serialization/json/JsonObjectDeserializer.java
>>
>>
>> formattedMapper.configure(Feature.FAIL_ON_UNKNOWN_PROPERTIES, false);
>>
>> As a default, this flag is set as false, then How I get this error? Any
>> idea?
>>
>>
>> Thanks,
>> Hari
>>
>>
>>
>> On Wed, Jun 20, 2018 at 5:21 PM, Hari Prasanth Loganathan <
>> hariprasant...@msystechnologies.com> wrote:
>>
>>> Hi all,
>>>
>>> To clarify my payload is like below,
>>>
>>> *Expected :*
>>>
>>> {
>>>"alias": "testdisk",
>>>"shareable": false,
>>>"storage_type": "cinder",
>>>"openstack_volume_type": {
>>> "name": "ceph"
>>> },
>>>"description": "",
>>>"storage_domains": {
>>>  "storage_domain": [{
>>> "name": "cinder_newone"
>>>  }]
>>> },
>>>"provisioned_size": 1073741824,
>>>  "interface": "virtio",
>>>  "format": "cow"
>>> }
>>>
>>> *I sent : *
>>>
>>> {
>>>"alias": "testdisk",
>>>"shareable": false,
>>>"storage_type": "cinder",
>>>"openstack_volume_type": {
>>> "name": "ceph"
>>> },
>>>"description": "",
>>>"storage_domains": {
>>>  "storage_domain": [{
>>> "name": "cinder_newone"
>>>  }]
>>> },
>>>"provisioned_size": 1073741824,
>>>  "interface": "virtio",
>>>  "format": "cow",
>>> * "test" : "value"*
>>> }
>>>
>>>
>>> Is there a way to ignore the *test* field? Please let me know any way /
>>> work around.
>>>
>>>
>>> Any help is much appreciated.
>>>
>>> Thanks,
>>> Hari
>>>
>>>
>>> On Wed, Jun 20, 2018 at 3:09 PM, Hari Prasanth Loganathan <
>>> hariprasant...@msystechnologies.com> wrote:
>>>
 Hi Team,

 I want to attach the disk using the oVIrt rest API, I use the version*
 4.2* and completed my script.
 But when I downgrade my oVirt to lower version *4.1*, I get the
 following error.

 detail: 'For correct usage, see:
 https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-attachments/methods/add',\n
 reason: 'Request syntactically incorrect.',\n  error: 'For correct
 usage, see:
 https://X.X.99.84/ovirt-engine/api/v4/model#services/disk-attachments/methods/add
 ',\n

 *Reason*: I added an extra parameter called 'isSharable' which is not
 expected in this API.


 *So Is there a way to Ignore the extra parameters sent for oVirt API?*

 *Example :*


 *Expected :*

 *{*
 * "a"  : "1"*

 *}*

 *I sent :*

 *{*
 *  "a" : "1",*
 *  "b" : "2"*
 *}*


 *My expectation is, Ignore the "b" and the API should work, Is there a
 flag in oVirt API which ignores the extra parameters?  *

 Thanks,
 Hari

>>>
>>>
>> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q3S2KU4PXZ7P2ZBLAYM7CYAK2S4NUJD5/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/E44T73RTP7AV2FW7WLLNVZ2DLL3RURIQ/

[ovirt-users] Re: HE + Gluster : Engine corrupted?

2018-06-20 Thread Greg Sheremeta 
+Benny

On Wed, Jun 20, 2018 at 2:07 PM Hanson Turner 
wrote:

> Hi Benny,
>
> Who should I be reaching out to for help with a gluster based hosted
> engine corruption?
>
>
> --== Host 1 status ==--
>
> conf_on_shared_storage : True
> Status up-to-date  : True
> Hostname   : ovirtnode1.abcxyzdomains.net
> Host ID: 1
> Engine status  : {"reason": "failed liveliness check",
> "health": "bad", "vm": "up", "detail": "Up"}
> Score  : 3400
> stopped: False
> Local maintenance  : False
> crc32  : 92254a68
> local_conf_timestamp   : 115910
> Host timestamp : 115910
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=115910 (Mon Jun 18 09:43:20 2018)
> host-id=1
> score=3400
> vm_conf_refresh_time=115910 (Mon Jun 18 09:43:20 2018)
> conf_on_shared_storage=True
> maintenance=False
> state=GlobalMaintenance
> stopped=False
>
>
> My when I VNC into my HE, All I get is:
> Probing EDD (edd=off to disable)... ok
>
>
> So, that's why it's failing the liveliness check... I cannot get the
> screen on HE to change short of ctl-alt-del which will reboot the HE.
> I do have backups for the HE that are/were run on a nightly basis.
>
> If the cluster was left alone, the HE vm would bounce from machine to
> machine trying to boot. This is why the cluster is in maintenance mode.
> One of the nodes was down for a period of time and brought back, sometime
> through the night, which is when the automated backup kicks, the HE started
> bouncing around. Got nearly 1000 emails.
>
> This seems to be the same error (but may not be the same cause) as listed
> here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1569827
>
> Thanks,
>
> Hanson
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3NLA2URX3KN44FGFUVV4N5EJBPICABHH/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JPFZYUEB7ZSRN4XUHETFYJMRHYCRX4N5/

[ovirt-users] Re: Unable to backend oVirt with Cinder

2018-06-20 Thread rumanzo 
Hi. Did you solve this problem?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R4AMON6RE72LD2CHJJNAHYYCERUZBEHX/

[ovirt-users] Re: Ignore extra parameters in oVirt API

2018-06-20 Thread Hari Prasanth Loganathan 
*Hi Ondra / Ori,*

https://github.com/oVirt/ovirt-engine/search?q=FAIL_ON_UNKNOWN_PROPERTIES%2C+false%29%3B&unscoped_q=FAIL_ON_UNKNOWN_PROPERTIES%2C+false%29%3B

Check the above link, As per the code it is always set as false, So is
there a way in payload / headers in client API / server configuration in
oVirt engine which can ignore the extra payload parameters?

Any help / workaround is much appreciated.

Thanks, Greg for pointing the right ppl.

Thanks,
Hari

On Thu, Jun 21, 2018 at 1:35 AM, Greg Sheremeta  wrote:

> +Ondra and Ori
>
> On Wed, Jun 20, 2018 at 1:07 PM Hari Prasanth Loganathan  msystechnologies.com> wrote:
>
>> Guys any update on this?  if you have any clarification let me know
>> please.
>>
>> Thanks
>>
>> On Wed, 20 Jun 2018 at 5:41 PM, Hari Prasanth Loganathan > msystechnologies.com> wrote:
>>
>>> Hi Team,
>>>
>>> I got one clue, using the code base : https://github.com/oVirt/
>>> ovirt-engine/blob/e2aad594a55c7272b513736616cb4b
>>> 9841c2c43d/backend/manager/modules/utils/src/main/java/
>>> org/ovirt/engine/core/utils/serialization/json/
>>> JsonObjectDeserializer.java
>>>
>>>
>>> formattedMapper.configure(Feature.FAIL_ON_UNKNOWN_PROPERTIES, false);
>>>
>>> As a default, this flag is set as false, then How I get this error? Any
>>> idea?
>>>
>>>
>>> Thanks,
>>> Hari
>>>
>>>
>>>
>>> On Wed, Jun 20, 2018 at 5:21 PM, Hari Prasanth Loganathan <
>>> hariprasant...@msystechnologies.com> wrote:
>>>
 Hi all,

 To clarify my payload is like below,

 *Expected :*

 {
"alias": "testdisk",
"shareable": false,
"storage_type": "cinder",
"openstack_volume_type": {
 "name": "ceph"
 },
"description": "",
"storage_domains": {
  "storage_domain": [{
 "name": "cinder_newone"
  }]
 },
"provisioned_size": 1073741824,
  "interface": "virtio",
  "format": "cow"
 }

 *I sent : *

 {
"alias": "testdisk",
"shareable": false,
"storage_type": "cinder",
"openstack_volume_type": {
 "name": "ceph"
 },
"description": "",
"storage_domains": {
  "storage_domain": [{
 "name": "cinder_newone"
  }]
 },
"provisioned_size": 1073741824,
  "interface": "virtio",
  "format": "cow",
 * "test" : "value"*
 }


 Is there a way to ignore the *test* field? Please let me know any way
 / work around.


 Any help is much appreciated.

 Thanks,
 Hari


 On Wed, Jun 20, 2018 at 3:09 PM, Hari Prasanth Loganathan <
 hariprasant...@msystechnologies.com> wrote:

> Hi Team,
>
> I want to attach the disk using the oVIrt rest API, I use the version*
> 4.2* and completed my script.
> But when I downgrade my oVirt to lower version *4.1*, I get the
> following error.
>
> detail: 'For correct usage, see: https://X.X.99.84/ovirt-
> engine/api/v4/model#services/disk-attachments/methods/add',\n
> reason: 'Request syntactically incorrect.',\n  error: 'For correct
> usage, see: https://X.X.99.84/ovirt-engine/api/v4/model#services/
> disk-attachments/methods/add',\n
>
> *Reason*: I added an extra parameter called 'isSharable' which is not
> expected in this API.
>
>
> *So Is there a way to Ignore the extra parameters sent for oVirt API?*
>
> *Example :*
>
>
> *Expected :*
>
> *{*
> * "a"  : "1"*
>
> *}*
>
> *I sent :*
>
> *{*
> *  "a" : "1",*
> *  "b" : "2"*
> *}*
>
>
> *My expectation is, Ignore the "b" and the API should work, Is there a
> flag in oVirt API which ignores the extra parameters?  *
>
> Thanks,
> Hari
>


>>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
>> guidelines/
>> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
>> message/Q3S2KU4PXZ7P2ZBLAYM7CYAK2S4NUJD5/
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/I2S4Q5K2CAF6Z5XQCWZYCHURPZ4KX5UN/

[ovirt-users] Re: HE + Gluster : Engine corrupted?

2018-06-20 Thread Sahina Bose 
On Wed, Jun 20, 2018 at 11:33 PM, Hanson Turner 
wrote:

> Hi Benny,
>
> Who should I be reaching out to for help with a gluster based hosted
> engine corruption?
>


Krutika, could you help?


>
> --== Host 1 status ==--
>
> conf_on_shared_storage : True
> Status up-to-date  : True
> Hostname   : ovirtnode1.abcxyzdomains.net
> Host ID: 1
> Engine status  : {"reason": "failed liveliness check",
> "health": "bad", "vm": "up", "detail": "Up"}
> Score  : 3400
> stopped: False
> Local maintenance  : False
> crc32  : 92254a68
> local_conf_timestamp   : 115910
> Host timestamp : 115910
> Extra metadata (valid at timestamp):
> metadata_parse_version=1
> metadata_feature_version=1
> timestamp=115910 (Mon Jun 18 09:43:20 2018)
> host-id=1
> score=3400
> vm_conf_refresh_time=115910 (Mon Jun 18 09:43:20 2018)
> conf_on_shared_storage=True
> maintenance=False
> state=GlobalMaintenance
> stopped=False
>
>
> My when I VNC into my HE, All I get is:
> Probing EDD (edd=off to disable)... ok
>
>
> So, that's why it's failing the liveliness check... I cannot get the
> screen on HE to change short of ctl-alt-del which will reboot the HE.
> I do have backups for the HE that are/were run on a nightly basis.
>
> If the cluster was left alone, the HE vm would bounce from machine to
> machine trying to boot. This is why the cluster is in maintenance mode.
> One of the nodes was down for a period of time and brought back, sometime
> through the night, which is when the automated backup kicks, the HE started
> bouncing around. Got nearly 1000 emails.
>
> This seems to be the same error (but may not be the same cause) as listed
> here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1569827
>
> Thanks,
>
> Hanson
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/3NLA2URX3KN44FGFUVV4N5EJBPICABHH/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SIPMUIPXWPHUCFJSGJPYTCYMNDN5IAKI/