[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/


[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_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: 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: 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: 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] 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: 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] 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: 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=02%7C01%7C%7C7e6324f27cec4c61e53008d5d5f96b0b%7C84df9e7fe9f640afb435%7C1%7C0%7C636650189570671175=f21XohOzUZFSHeh1DXADEONFkZy9hVk8OVB0m9lCaKE%3D=0
oVirt Code of Conduct: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2F=02%7C01%7C%7C7e6324f27cec4c61e53008d5d5f96b0b%7C84df9e7fe9f640afb435%7C1%7C0%7C636650189570671175=3iX5GXTxhszloLbTm1MWkOBx%2BQ6diX1oeZkDFoApG%2Bg%3D=0
List Archives: 
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2F3D3TFBVEV4I7KKPP4JYCVMWZCOGFIY4K%2F=02%7C01%7C%7C7e6324f27cec4c61e53008d5d5f96b0b%7C84df9e7fe9f640afb435%7C1%7C0%7C636650189570671175=%2BfR8yruTYRkY3Ji1asW1V8yiD8D0s9w%2FvL7j537lHP8%3D=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: [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: 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] [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: 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] 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 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: [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] 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: 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 

[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
> 

[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 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] 

[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: cloud-init reverting static network settings to DHCP on shutdown and restart

2018-06-20 Thread Florian Schmid
Hi, 

we made this solution for us: 
We add a cloud-init script to the cloud image, before we add this to our 
templates. 
In /etc/cloud/cloud.cfg.d/, we create a file 98_runcmd.cfg with the following 
content: 
write_files: 
- content: | 
network: {config: disabled} 
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg 
permissions: '0700' 
- content: | 
#!/bin/bash 
rm /etc/cloud/cloud.cfg.d/90_dpkg.cfg 
path: /var/lib/cloud/scripts/per-boot/datasources.sh 
permissions: '0700' 


This should create the file 
/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg after first cloud-init run 
and then network config is never touched again. 
Without disabling cloud-init completely, you are able for example to set a root 
password to login into VM console, when you have to debug something and can't 
login anymore to ssh. 
We have password logins disabled by default over ssh. 

We also remove /etc/cloud/cloud.cfg.d/90_dpkg.cfg and set datasource_list to 
["NoCloud", "ConfigDrive"] in /etc/cloud/cloud.cfg 
-> VM will reboot with this a way faster. Without it, cloud-init will look for 
too much different location to find a valid config. 




LG Florian 


Von: "Eitan Raviv"  
An: "Ryan McCabe"  
CC: "users" , "geoff carr"  
Gesendet: Mittwoch, 20. Juni 2018 08:20:54 
Betreff: [ovirt-users] Re: cloud-init reverting static network settings to DHCP 
on shutdown and restart 

Hi Ryan, 

This behaviour reproduces for me as well with 

ovirt-engine-latest-nightly-snapshot, 
cloud-init-0.7.9-24.el7.x86_64, 
Centos-7.4.1708 VM. 

Can you comment? 

Thanks 

On Thu, Jun 7, 2018 at 10:45 AM, Luca 'remix_tj' Lorenzetto < [ 
mailto:lorenzetto.l...@gmail.com | lorenzetto.l...@gmail.com ] > wrote: 


Hello Geoff, 


On Wed, Jun 6, 2018 at 9:14 PM, < [ mailto:geoff.c...@beazley.com | 
geoff.c...@beazley.com ] > wrote: 
> I think that before a shutdown / restart the cloud-init configuration is 
> attached as there is /dev/sr1 visible. On shutdown / restart the config is no 
> longer attached and there is seemingly an error related to not being able to 
> find the data source: - 
> 
> 2018-06-06 15:15:11,297 - handlers.py[DEBUG]: finish: 
> init-network/search-NoCloudNet: SUCCESS: no network data found from 
> DataSourceNoCloudNet 
> 2018-06-06 15:15:11,298 - util.py[WARNING]: No instance datasource found! 
> Likely bad things to come! 
> 2018-06-06 15:15:11,298 - util.py[DEBUG]: No instance datasource found! 
> Likely bad things to come! 
> Traceback (most recent call last): 
> File "/usr/lib/python2.7/site-packages/cloudinit/cmd/main.py", line 236, in 
> main_init 
> init.fetch(existing=existing) 
> File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 343, in 
> fetch 
> return self._get_data_source(existing=existing) 
> File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 253, in 
> _get_data_source 
> pkg_list, self.reporter) 
> File "/usr/lib/python2.7/site-packages/cloudinit/sources/__init__.py", line 
> 320, in find_source 
> raise DataSourceNotFoundException(msg) 
> DataSourceNotFoundException: Did not find any data source, searched classes: 
> (DataSourceNoCloudNet) 
> 2018-06-06 15:15:11,302 - util.py[DEBUG]: Reading from 
> /sys/class/net/eth0/carrier (quiet=False) 
> 2018-06-06 15:15:11,303 - util.py[DEBUG]: Read 2 bytes from 
> /sys/class/net/eth0/carrier 
> 2018-06-06 15:15:11,303 - util.py[DEBUG]: Reading from 
> /sys/class/net/eth0/address (quiet=False) 
> 2018-06-06 15:15:11,303 - util.py[DEBUG]: Read 18 bytes from 
> /sys/class/net/eth0/address 
> 2018-06-06 15:15:11,303 - stages.py[DEBUG]: applying net config names for 
> {'version': 1, 'config': [{'subnets': [{'type': 'dhcp'}], 'type': 'physical', 
> 'name': 'eth0', 'mac_address': '00:1a:4a:16:01:05'}]} 

I have the same issue since some months. Since cloud-init doesn't sees 
any configuration, applies the default, which is to use dhcp. 

I don't remember if it is a bug of cloud-init or a misconfiguration, 
but now i solved removing cloud-init package after the first boot. 

In case you want redeploying, you can keep cloud-init and disable its 
work by disabling the service: 

touch /etc/cloud/cloud-init.disabled 

Luca 

-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare 
calcoli che potrebbero essere affidati a chiunque se si usassero delle 
macchine" 
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) 

"Internet è la più grande biblioteca del mondo. 
Ma il problema è che i libri sono tutti sparsi sul pavimento" 
John Allen Paulos, Matematico (1945-vivente) 

Luca 'remix_tj' Lorenzetto, [ http://www.remixtj.net/ | http://www.remixtj.net 
] , < [ mailto:lorenzetto.l...@gmail.com | lorenzetto.l...@gmail.com ] > 
___ 
Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ] 
To unsubscribe send an email to [ mailto:users-le...@ovirt.org | 
users-le...@ovirt.org ] 
Privacy Statement: [ https://www.ovirt.org/site/privacy-policy/ | 

[ovirt-users] Re: upgrade 4.1 to 4.2

2018-06-20 Thread Ido Rosenzwig
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 <
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 
> 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
>  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/
>
___
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/7JDM2BGCAQVHYJKKHQ6BZSN2EOGJ4ASL/


[ovirt-users] Re: Missing step(s) after custom x509 certificates

2018-06-20 Thread Yedidyah Bar David
On Tue, Jun 19, 2018 at 5:35 PM, John Florian  wrote:
> On 2018-06-19 02:57, Yedidyah Bar David wrote:
>> On Mon, Jun 18, 2018 at 4:19 PM, John Florian  wrote:
>>> On 2018-06-18 02:46, Yedidyah Bar David wrote:
 On Mon, Jun 18, 2018 at 9:19 AM, Tomas Jelinek 
 wrote:
>
> On Mon, Jun 18, 2018 at 8:01 AM, Yedidyah Bar David 
> wrote:
>> On Sun, Jun 17, 2018 at 6:11 PM, John Florian 
>> wrote:
>>> I followed the docs at
>>> https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ and
>>> all
>>> works well from the usual web portal.  Went to test moVirt and ran into
>>> a
>>> snag.  It wants to download the CA using
>>>
>>>
>>> http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA,
>> I never tried movirt, but the user's guide [1] says it can import
>> user-supplied certs, so you can supply your own CA's cert, no?
>
> correct, you can supply your own certificate, movirt just by default
> grabs
> the one which is provided by engine at:
>
> http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA
>
> @Ravi: is it correct that after you provide your own CA that the
>
> http://fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA
> is still pointing to the old one?
 Yes - check this:

 https://ovirt.org/develop/release-management/features/infra/pki/#services

 It does not have a resource "apache-certificate" or anything like that.
 The assumption is that user that changes httpd's conf to use a 3rd-party
 CA,
 is in control of it, not the engine - so the engine can't handle it. This
 is
 even if the user followed the documentation, because in principle, the
 user
 can do other things - e.g. point SSLCACertificateFile at a different file
 instead of replacing the content of the existing apache-ca.pem (which
 defaults
 to a symlink to ca.pem, which _is_ controlled by the engine (as in "we do
 not
 have any documentation about how to replace it, and doing that will break
 many
 flows").
>>> Okay, this is what threw me.  The docs are written in such a way that I
>>> never touch httpd's conf, as if maybe I am not supposed to do that.  The
>>> docs have me change the target of a symlink and do other swaps and avoids
>>> touching the conf, be it intentional or not.  I may have inferred too much
>>> based on the approach.
>> I don't remember every exact detail in the docs, but I do know the relevant
>> code.
>>
>> The engine (itself) runs as user ovirt, and can't touch or do anything to 
>> your
>> httpd conf.
>>
>> engine-setup is basically the only thing [1] that runs as root and touches
>> httpd conf. It asks you some stuff, and does (currently) only these things:
>>
>> 1. Always add /etc/httpd/conf.d/z-ovirt-engine-proxy.conf . This file is
>> considered to be "owned" by engine-setup and can be changed as needed by
>> upgrades. So you are not supposed to touch it.
>>
>> 2. Optionally add /etc/httpd/conf.d/ovirt-engine-root-redirect.conf which
>> does a very simple redirect from '/' to '/ovirt-engine'. I am not aware of
>> anyone not doing this, and guess things might not work perfectly, and also
>> that it might be unsupported, but in principle you can reply 'no', and then
>> have other web apps on the engine machine. See also [2]. This is _not_ done
>> on upgrades - so if you reply 'yes', then remove the file, then run
>> 'engine-setup' again, it should not re-add the file.
>>
>> 3. Optionally edit ssl.conf, which is the subject of current thread. This
>> one also used to be not done on upgrades, but this recently changed [3][4].
>>
>> This is considered mandatory and the only supported flow in production.
>> If you reply 'no', you are supposed to configure apache manually.
>>
>> However, for development, you can talk to jboss directly [5]. This used to
>> be possible also in production in very old releases, see e.g. [6].
>>
>> So, to summarize:
>>
>> We (engine developers, engine-setup in particular) try to be "good citizens"
>> and not take control of the machine, allowing the admin do what s/he wants,
>> and still try hard to make the engine work nicely. But we default to do
>> "take over", and (IIRC) only document the default, and (IIUC) only test the
>> default - so anything else is somewhat more likely to cause problems.
>>
>> [1] currently. We add lots of ansible stuff in recent releases, I suspect
>> that engine-setup has a chance to be partially replaced with ansible code
>> some time.
>>
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=961677
>>
>> [3] https://bugzilla.redhat.com/1558500
>>
>> [4] https://bugzilla.redhat.com/1576377
>>
>> [5] 
>> https://www.ovirt.org/develop/developer-guide/engine/engine-development-environment/
>>
>> [6] https://bugzilla.redhat.com/show_bug.cgi?id=905754
>
> That is some excellent detail.