Re: [ovirt-users] oVirt 2018 Survey

[Gianluca Cecchi]

On Wed, Jan 17, 2018 at 8:03 AM, Barak Korren  wrote:

> On 17 January 2018 at 01:02, ~Stack~  wrote:
> > Greetings,
> > FYI, your Ubuntu options are antiquated.
> >
> > 12.10, 13.04, 13.10 are all unsupported.
> >
> > 12.04 is only in extended security maintenance.
> >
> > I believe the options should be 12.04, 14.04, 16.04, and 17.10 (latest
> > non-LTS).
> >
>
> I guess you're referring to the images in glance.ovirt.org? We're
> looking for help maintaining that...
>

No, it is referring to the section of the survey where it is asked the
flavor and version of OS you are running in your oVirt infra...

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

Re: [ovirt-users] oVirt 2018 Survey

[Barak Korren]

On 17 January 2018 at 01:02, ~Stack~  wrote:
> Greetings,
> FYI, your Ubuntu options are antiquated.
>
> 12.10, 13.04, 13.10 are all unsupported.
>
> 12.04 is only in extended security maintenance.
>
> I believe the options should be 12.04, 14.04, 16.04, and 17.10 (latest
> non-LTS).
>

I guess you're referring to the images in glance.ovirt.org? We're
looking for help maintaining that...

Here is a tracker ticket in the meantime:
https://ovirt-jira.atlassian.net/browse/OVIRT-1848

-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Problems with some vms

[Endre Karlson]

It's there now for each of the hosts. ovirt1 is not in service yet.

2018-01-17 5:52 GMT+01:00 Gobinda Das :

> In the above url only data and iso mnt log present,But there is no engine
> and vmstore mount log.
>
> On Wed, Jan 17, 2018 at 1:26 AM, Endre Karlson 
> wrote:
>
>> Hi, all logs are located here: https://www.dropbox.com/
>> sh/3qzmwe76rkt09fk/AABzM9rJKbH5SBPWc31Npxhma?dl=0 for the mounts
>>
>> additionally we replaced a broken disk that is now resynced.
>>
>> 2018-01-15 11:17 GMT+01:00 Gobinda Das :
>>
>>> Hi Endre,
>>>  Mount logs will be in below format inside  /var/log/glusterfs :
>>>
>>>  /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_engine.log
>>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_data.log
>>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_vmstore.log
>>>
>>> On Mon, Jan 15, 2018 at 11:57 AM, Endre Karlson >> > wrote:
>>>
 Hi.

 What are the gluster mount logs ?

 I have these gluster logs.
 cli.log  etc-glusterfs-glusterd.vol.log  glfsheal-engine.log
 glusterd.lognfs.log
 rhev-data-center-mnt-glusterSD-ovirt0:_engine.log
 rhev-data-center-mnt-glusterSD-ovirt3:_iso.log
 cmd_history.log  glfsheal-data.log   glfsheal-iso.log
  glustershd.log  rhev-data-center-mnt-glusterSD-ovirt0:_data.log
 rhev-data-center-mnt-glusterSD-ovirt0:_iso.log statedump.log


 I am running version
 glusterfs-server-3.12.4-1.el7.x86_64
 glusterfs-geo-replication-3.12.4-1.el7.x86_64
 libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64
 glusterfs-libs-3.12.4-1.el7.x86_64
 glusterfs-api-3.12.4-1.el7.x86_64
 python2-gluster-3.12.4-1.el7.x86_64
 glusterfs-client-xlators-3.12.4-1.el7.x86_64
 glusterfs-cli-3.12.4-1.el7.x86_64
 glusterfs-events-3.12.4-1.el7.x86_64
 glusterfs-rdma-3.12.4-1.el7.x86_64
 vdsm-gluster-4.20.9.3-1.el7.centos.noarch
 glusterfs-3.12.4-1.el7.x86_64
 glusterfs-fuse-3.12.4-1.el7.x86_64

 // Endre

 2018-01-15 6:11 GMT+01:00 Gobinda Das :

> Hi Endre,
>  Can you please provide glusterfs mount logs?
>
> On Mon, Jan 15, 2018 at 6:16 AM, Darrell Budic  > wrote:
>
>> What version of gluster are you running? I’ve seen a few of these
>> since moving my storage cluster to 12.3, but still haven’t been able to
>> determine what’s causing it. Seems to be happening most often on VMs that
>> haven’t been switches over to libgfapi mounts yet, but even one of those
>> has paused once so far. They generally restart fine from the GUI, and
>> nothing seems to need healing.
>>
>> --
>> *From:* Endre Karlson 
>> *Subject:* [ovirt-users] Problems with some vms
>> *Date:* January 14, 2018 at 12:55:45 PM CST
>> *To:* users
>>
>> Hi, we are getting some errors with some of our vms in a 3 node
>> server setup.
>>
>> 2018-01-14 15:01:44,015+0100 INFO  (libvirt/events) [virt.vm]
>> (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop
>> device virtio-disk0  error eother (vm:4880)
>>
>> We are running glusterfs for shared storage.
>>
>> I have tried setting global maintenance on the first server and then
>> issuing a 'hosted-engine --vm-start' but that leads to nowhere.
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
> --
> Thanks,
> Gobinda
> +91-9019047912 <+91%2090190%2047912>
>


>>>
>>>
>>> --
>>> Thanks,
>>> Gobinda
>>> +91-9019047912 <+91%2090190%2047912>
>>>
>>
>>
>
>
> --
> Thanks,
> Gobinda
> +91-9019047912 <+91%2090190%2047912>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt 4.2 Windows guest tools

[Yedidyah Bar David]

On Tue, Jan 16, 2018 at 11:33 PM, Alex K  wrote:
> Hi all,
>
> Is the ISO at
> http://plain.resources.ovirt.org/pub/ovirt-4.2/iso/oVirt-toolsSetup/4.2-1.el7.centos/
> the  latest guest tools?

Yes.

> I'm interested for Windows 2016 and Windows 10.

Good luck!

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

Re: [ovirt-users] Problems with some vms

[Gobinda Das]

In the above url only data and iso mnt log present,But there is no engine
and vmstore mount log.

On Wed, Jan 17, 2018 at 1:26 AM, Endre Karlson 
wrote:

> Hi, all logs are located here: https://www.dropbox.com/
> sh/3qzmwe76rkt09fk/AABzM9rJKbH5SBPWc31Npxhma?dl=0 for the mounts
>
> additionally we replaced a broken disk that is now resynced.
>
> 2018-01-15 11:17 GMT+01:00 Gobinda Das :
>
>> Hi Endre,
>>  Mount logs will be in below format inside  /var/log/glusterfs :
>>
>>  /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_engine.log
>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_data.log
>> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_vmstore.log
>>
>> On Mon, Jan 15, 2018 at 11:57 AM, Endre Karlson 
>> wrote:
>>
>>> Hi.
>>>
>>> What are the gluster mount logs ?
>>>
>>> I have these gluster logs.
>>> cli.log  etc-glusterfs-glusterd.vol.log  glfsheal-engine.log
>>> glusterd.lognfs.log
>>> rhev-data-center-mnt-glusterSD-ovirt0:_engine.log
>>> rhev-data-center-mnt-glusterSD-ovirt3:_iso.log
>>> cmd_history.log  glfsheal-data.log   glfsheal-iso.log
>>>  glustershd.log  rhev-data-center-mnt-glusterSD-ovirt0:_data.log
>>> rhev-data-center-mnt-glusterSD-ovirt0:_iso.log statedump.log
>>>
>>>
>>> I am running version
>>> glusterfs-server-3.12.4-1.el7.x86_64
>>> glusterfs-geo-replication-3.12.4-1.el7.x86_64
>>> libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64
>>> glusterfs-libs-3.12.4-1.el7.x86_64
>>> glusterfs-api-3.12.4-1.el7.x86_64
>>> python2-gluster-3.12.4-1.el7.x86_64
>>> glusterfs-client-xlators-3.12.4-1.el7.x86_64
>>> glusterfs-cli-3.12.4-1.el7.x86_64
>>> glusterfs-events-3.12.4-1.el7.x86_64
>>> glusterfs-rdma-3.12.4-1.el7.x86_64
>>> vdsm-gluster-4.20.9.3-1.el7.centos.noarch
>>> glusterfs-3.12.4-1.el7.x86_64
>>> glusterfs-fuse-3.12.4-1.el7.x86_64
>>>
>>> // Endre
>>>
>>> 2018-01-15 6:11 GMT+01:00 Gobinda Das :
>>>
 Hi Endre,
  Can you please provide glusterfs mount logs?

 On Mon, Jan 15, 2018 at 6:16 AM, Darrell Budic 
 wrote:

> What version of gluster are you running? I’ve seen a few of these
> since moving my storage cluster to 12.3, but still haven’t been able to
> determine what’s causing it. Seems to be happening most often on VMs that
> haven’t been switches over to libgfapi mounts yet, but even one of those
> has paused once so far. They generally restart fine from the GUI, and
> nothing seems to need healing.
>
> --
> *From:* Endre Karlson 
> *Subject:* [ovirt-users] Problems with some vms
> *Date:* January 14, 2018 at 12:55:45 PM CST
> *To:* users
>
> Hi, we are getting some errors with some of our vms in a 3 node server
> setup.
>
> 2018-01-14 15:01:44,015+0100 INFO  (libvirt/events) [virt.vm]
> (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop device
> virtio-disk0  error eother (vm:4880)
>
> We are running glusterfs for shared storage.
>
> I have tried setting global maintenance on the first server and then
> issuing a 'hosted-engine --vm-start' but that leads to nowhere.
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


 --
 Thanks,
 Gobinda
 +91-9019047912 <+91%2090190%2047912>

>>>
>>>
>>
>>
>> --
>> Thanks,
>> Gobinda
>> +91-9019047912 <+91%2090190%2047912>
>>
>
>


-- 
Thanks,
Gobinda
+91-9019047912
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] gluster volume permission denied

[Bill James]

I have one node in our cluster that has problems when migrating a VM if 
the VM is hosted on a gluster volume.

If the VM is hosted on a NFS volume it migrates fine.

/var/log/messages:
Jan 16 14:36:09 ovirt1 libvirtd: 2018-01-16 22:36:09.769+: 9700: 
error : qemuProcessReportLogError:1862
 : internal error: process exited while connecting to monitor: 
2018-01-16T22:36:09.587405Z qemu-kvm: -drive

 
file=/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/60
3271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90,format=raw,if=none,id=drive-virtio-
disk0,serial=603271e4-3089-4779-aa1c-faf280fabd17,cache=none,werror=stop,rerror=stop,aio=threads: 
Could not
 open 
'/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/603271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90': 
Permission denied

(libvirt/csapi1.test.j2noc.com.log says same thing)

[root@ovirt1 test log]# ls -hl 
/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/603271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90
-rw-rw 1 vdsm kvm 20G Jan 16 15:32 
/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb/images/603271e4-3089-4779-aa1c-faf280fabd17/7c7f7726-4ab0-4047-9b91-e0817a139e90


lrwxrwxrwx 1 vdsm kvm  98 Jan 10 21:21 
67b4d9aa-f174-436a-b5a1-ec7cee5f2edb -> 
/rhev/data-center/mnt/glusterSD/ovirt3-ks.test.j2noc.com:_gv3/67b4d9aa-f174-436a-b5a1-ec7cee5f2edb



engine.log:
2018-01-16 14:36:18,846-08 WARN 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (o
rg.ovirt.thread.pool-6-thread-34) [78d8b38c] EVENT_ID: 
VM_MIGRATION_TRYING_RERUN(128), Correlation ID: e39
9da53-cd31-401c-bf63-16b118b8884c, Job ID: 
4db6bd87-0da4-4358-acae-dc453c813969, Call Stack: null, Custom
ID: null, Custom Event ID: -1, Message: Failed to migrate VM 
csapi1.test.j2noc.com to Host ovirt1.test.j2n

oc.com . Trying to migrate to another Host.


ovirt-engine-tools-4.1.8.2-1.el7.centos.noarch
glusterfs-3.8.15-2.el7.x86_64
vdsm-4.19.43-1.el7.centos.x86_64
libvirt-daemon-3.2.0-14.el7_4.7.x86_64

Let me know what logs would be useful in troubleshooting this.

Thanks!


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

Re: [ovirt-users] oVirt 2018 Survey

[~Stack~]

Greetings,
FYI, your Ubuntu options are antiquated.

12.10, 13.04, 13.10 are all unsupported.

12.04 is only in extended security maintenance.

I believe the options should be 12.04, 14.04, 16.04, and 17.10 (latest
non-LTS).

~Stack~


On 01/16/2018 02:33 AM, Sandro Bonazzola wrote:
> As we continue to develop oVirt 4.2 and future releases, the Development
> and Integration teams at Red Hat would value 
> insights on how you are deploying the oVirt environment. Please help us
> to hit the mark by completing this short survey. Survey will close on
> February 1st.
> 
> Here's the link to the survey: https://goo.gl/forms/cAKWAR8RD7rGrVhE2
> 
> Thanks,
> -- 
> 
> SANDRO BONAZZOLA
> 
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
> 
> Red Hat EMEA 
> 
>   
> TRIED. TESTED. TRUSTED. 
> 
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 




signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Ovirt 4.2 Windows guest tools

[Alex K]

Hi all,

Is the ISO at
http://plain.resources.ovirt.org/pub/ovirt-4.2/iso/oVirt-toolsSetup/4.2-1.el7.centos/
the  latest guest tools? I'm interested for Windows 2016 and Windows 10.

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

[ovirt-users] 4.1.8: Run Once does not allow me to choose a CD Image to attach

[Derek Atkins]

Hi,

I upgraded from 4.0.6 to 4.1.8.  I had created a VM in 4.0.6 but had
never started it nor had I ever run it before I upgraded.  I then
upgraded to 4.1.8 (which went very smoothly), but then I tried to use
the Run Once function to boot up and attach an ISO Image.  However when
I select Run Once, then Boot Options, the "Attach CD" option is
unchecked and wont let me select it like I could in 4.0.6.  If I try to
select the checkbox I see the popup flash but the box remains unchecked.

Is this a bug/regression in 4.1.8?

I did clear my browser cache thinking that might be it, but no, that
didn't help.

The only thing I could do was Edit the VM, go to Boot options, select it
there (which I could do) and then choose the ISO.  THEN I could run it
with the CD attached.

Thanks,

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Problems with some vms

[Endre Karlson]

Hi, all logs are located here: https://www.dropbox.com/
sh/3qzmwe76rkt09fk/AABzM9rJKbH5SBPWc31Npxhma?dl=0 for the mounts

additionally we replaced a broken disk that is now resynced.

2018-01-15 11:17 GMT+01:00 Gobinda Das :

> Hi Endre,
>  Mount logs will be in below format inside  /var/log/glusterfs :
>
>  /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_engine.log
> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_data.log
> /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_vmstore.log
>
> On Mon, Jan 15, 2018 at 11:57 AM, Endre Karlson 
> wrote:
>
>> Hi.
>>
>> What are the gluster mount logs ?
>>
>> I have these gluster logs.
>> cli.log  etc-glusterfs-glusterd.vol.log  glfsheal-engine.log
>> glusterd.lognfs.log
>> rhev-data-center-mnt-glusterSD-ovirt0:_engine.log
>> rhev-data-center-mnt-glusterSD-ovirt3:_iso.log
>> cmd_history.log  glfsheal-data.log   glfsheal-iso.log
>>  glustershd.log  rhev-data-center-mnt-glusterSD-ovirt0:_data.log
>> rhev-data-center-mnt-glusterSD-ovirt0:_iso.log statedump.log
>>
>>
>> I am running version
>> glusterfs-server-3.12.4-1.el7.x86_64
>> glusterfs-geo-replication-3.12.4-1.el7.x86_64
>> libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64
>> glusterfs-libs-3.12.4-1.el7.x86_64
>> glusterfs-api-3.12.4-1.el7.x86_64
>> python2-gluster-3.12.4-1.el7.x86_64
>> glusterfs-client-xlators-3.12.4-1.el7.x86_64
>> glusterfs-cli-3.12.4-1.el7.x86_64
>> glusterfs-events-3.12.4-1.el7.x86_64
>> glusterfs-rdma-3.12.4-1.el7.x86_64
>> vdsm-gluster-4.20.9.3-1.el7.centos.noarch
>> glusterfs-3.12.4-1.el7.x86_64
>> glusterfs-fuse-3.12.4-1.el7.x86_64
>>
>> // Endre
>>
>> 2018-01-15 6:11 GMT+01:00 Gobinda Das :
>>
>>> Hi Endre,
>>>  Can you please provide glusterfs mount logs?
>>>
>>> On Mon, Jan 15, 2018 at 6:16 AM, Darrell Budic 
>>> wrote:
>>>
 What version of gluster are you running? I’ve seen a few of these since
 moving my storage cluster to 12.3, but still haven’t been able to determine
 what’s causing it. Seems to be happening most often on VMs that haven’t
 been switches over to libgfapi mounts yet, but even one of those has paused
 once so far. They generally restart fine from the GUI, and nothing seems to
 need healing.

 --
 *From:* Endre Karlson 
 *Subject:* [ovirt-users] Problems with some vms
 *Date:* January 14, 2018 at 12:55:45 PM CST
 *To:* users

 Hi, we are getting some errors with some of our vms in a 3 node server
 setup.

 2018-01-14 15:01:44,015+0100 INFO  (libvirt/events) [virt.vm]
 (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop device
 virtio-disk0  error eother (vm:4880)

 We are running glusterfs for shared storage.

 I have tried setting global maintenance on the first server and then
 issuing a 'hosted-engine --vm-start' but that leads to nowhere.
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users



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


>>>
>>>
>>> --
>>> Thanks,
>>> Gobinda
>>> +91-9019047912 <+91%2090190%2047912>
>>>
>>
>>
>
>
> --
> Thanks,
> Gobinda
> +91-9019047912 <+91%2090190%2047912>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] oVirt 4.x - RestAPI - Backup - How to Image Inactive Disk

[Zip]

Hi All,

I have created a bash script that uses curl and the REST API based on the
docs that I could find.

I have the script working all the way up until the VM-ToBeBackedUp-Disk is
attached to the VM-RunningTheBackupScript with the mention of the Snapshot.

Example:



   https://-myFQDN-/ovirt-engine/api/vms/-UUID-OF-VM-RunningTheBackupScript/dis
kattachments/

The above results in an attached disk to my VM-RunningTheBackupScript.

The question I have is how to I image that disk from the
VM-RunningTheBackupScript?

The VM-RunningTheBackupScript is running Debian8 and that VM cannot see the
attached disk as it is Inactive.

I have reviewed many of the older scripts out there and it looks trivial,
however everything I have tried has no joy ;/

If anyone on the list knows of the required magic, please advise ;)

* If I have to go to using python etc, I will, but trying to avoid it if
possible. Either way, I need some examples of how to proceed.

Some links I have reviewed:

https://www.ovirt.org/develop/api/design/backup-api/
http://200.1.19.60/ovirt-engine/docs/manual/en-US/html/Administration_Guide/
sect-Backing_Up_and_Restoring_Virtual_Machines_Using_the_Backup_and_Restore_
API.html
https://markmc.fedorapeople.org/rhevm-api/en-US/html-single/index.html
https://github.com/voidloop/ovirt-bash-backup/blob/master/backupvm.sh
https://github.com/laravot/backuprestoreapi/blob/master/example.py


Thanks

Zip


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

Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

[Derek Atkins]

Hi,

I upgraded to EL7.4 / oVirt 4.1.8 last night.
I must say it was easier than expected, so kudos to all the devs.
I did have a few hiccups along the way, mostly of my own making.
The one main hiccup is that the ovirt-40-dependencies package links to a
CentOS repo that no longer exists, and that caused lots of pain.  I had to
manually disable two repos to get the upgrade to work.
Note:  Nowhere in the docs does it say to remove the ovirt-release40
package, either before OR after the upgrade!

Having said that, my ovirt host now reports:

# bash spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux
3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  YES
> STATUS:  NOT VULNERABLE  (106 opcodes found, which is >= 70, heuristic
to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available:  YES
* The SPEC_CTRL CPUID feature bit is set:  YES
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  YES
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  NOT VULNERABLE  (IBRS mitigates the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
* Checking if we're running under Xen PV (64 bits):  NO
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Do I need to enabke IBRS for User space?
If so, how would that be done?

Thanks!

-derek

On Mon, January 15, 2018 1:10 pm, Yaniv Kaul wrote:
> On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins  wrote:
>
>> Thanks.
>>
>> I guess it still boils down to updating to 7.4.  :(
>>
>> In the short term, will Ovirt 4.0 continue to run in 7.4?  Or MUST I
>>
>
> We don't know, but I would assume NO. Every minor release of EL required
> some small adjustments to expected and unexpected changes in the platform.
> We have worked with 4.1 to support 7.3 and then 7.4, I would not presume
> 4.0 works with it.
> Y.
>
>
>> upgrade both the OS and ovirt simultaneously?  My time is very short
>> over
>> the next few weeks (I'm moving) so I'd like to get as much bang for the
>> buck with as little down time as possible.  I can't spend 12 hours of my
>> time working to repair a botched upgrade from 4.0 to 4.1 or 4.2.
>>
>> Thanks again!
>>
>> -derek
>>
>> On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote:
>> > If you see that after the update of your OS dmesg shows RED alert in
>> > the spectra check script in the second position then you should follow
>> > the intel's read.me.
>> > As in readme described on Centos 7.4:
>> > rsync  -Pa intel-ucode /lib/firmware/
>> > On the recent kernels(>2.6.xx) the dd method does not work, dont do
>> that.
>> > To confirm that microcode loaded:
>> > dmesg | grep micro
>> > look for the release dates.
>> > But I beleve that v4 should be already in the microcode_ctl package of
>> > the CentOS7.4 ( in my case 2650v2 was not inside, but the  v3 and v4
>> > were there)
>> > I have a script to enable or disable the protection so you can see the
>> > performance impact on your case:
>> > https://arm2armcos.blogspot.de/2018/01/lustrefs-big-
>> performance-hit-on-lfs.html
>> >
>> >
>> >
>> > On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins  wrote:
>> >> Arman,
>> >>
>> >> Thanks for the info...  And sorry for taking so long to reply.  It's
>> >> been a busy weekend.
>> >>
>> >> First, thank you for the links.  Useful information.
>> >>
>> >> However, could you define "recent"?  My system is from Q3 2016.  Is
>> that
>> >> considered recent enough to not need a bios updte?
>> >>
>> >> My /proc/cpuinfo reports:
>> >> model name  : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
>> >>
>> >> I downloaded the microcode.tgz file, which is dated Jan 8.  I noticed
>> >> that the microcode_ctl package in my repo is dated Jan 4, which
>> implies
>> >> it probably does NOT contain the Jan 8 tgz from Intel.  It LOOKS like
>> I
>> >> can just replace the intel-ucode files with those from the tgz, but
>> I'm
>> >> not sure what, if anything, I need to do with the microcode.dat file
>> in
>> >> the tgz?
>> >>
>> >> Thanks,
>> >>
>> >> -derek
>> >>
>> >> Arman Khalatyan  writes:
>> >>
>> >>> if you have recent supermicro you dont need to update the bios,
>> >>>
>> >>> Some tests:
>> >>> Crack test:
>> >>> https://github.com/IAIK/meltdown
>> >>>
>> >>> Check test:
>> >>> https://github.com/speed47/spectre-meltdown-checker
>> >>>
>> >>> the intel microcodes  you 

Re: [ovirt-users] oVirt 4.2.1 rc1 and upload iso to data domain test

[Gianluca Cecchi]

On Tue, Jan 16, 2018 at 2:30 PM, Gianluca Cecchi 
wrote:

>
>
> On Tue, Jan 16, 2018 at 2:21 PM, Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> On Tue, Jan 16, 2018 at 6:48 AM, Fred Rolland 
>> wrote:
>>
>>> Hi,
>>> I will look into it.
>>>
>>> Is it also not working also for non-iso images?
>>>
>>> Thanks,
>>> Fred
>>>
>>>
>> Hello,
>> I get the same with a disk.
>> I have tried with a raw disk of size 1Gb.
>> When I upload I can set the size (why?) while with the iso image I could
>> not.
>> The disk is recognized as "data" in upload window (the iso fie was
>> correctly recognized as "iso"), but in image-proxy.log I get
>>
>> (Thread-42 ) INFO 2018-01-16 14:15:50,530 web:95:web:(log_start) START
>> [192.168.150.101] GET /info/
>> (Thread-42 ) INFO 2018-01-16 14:15:50,532 web:102:web:(log_finish) FINISH
>> [192.168.150.101] GET /info/: [200] 20 (0.00s)
>> (Thread-43 ) INFO 2018-01-16 14:16:12,659 web:95:web:(log_start) START
>> [192.168.150.105] PUT /tickets/
>> (Thread-43 ) INFO 2018-01-16 14:16:12,661 auth2:170:auth2:(add_signed_ticket)
>> Adding new ticket: > 4744-8a58-f1948afa20b7', url=u'https://ovirt01.localdomain.local:54322'
>> at 0x7f048c03c610>
>> (Thread-43 ) INFO 2018-01-16 14:16:12,662 web:102:web:(log_finish) FINISH
>> [192.168.150.105] PUT /tickets/: [200] 0 (0.00s)
>> (Thread-44 ) INFO 2018-01-16 14:16:13,800 web:95:web:(log_start) START
>> [192.168.150.101] OPTIONS /images/81569ab3-1b92-4744-
>> 8a58-f1948afa20b7
>> (Thread-44 ) INFO 2018-01-16 14:16:13,814 web:102:web:(log_finish) FINISH
>> [192.168.150.101] OPTIONS /images/81569ab3-1b92-47
>> 44-8a58-f1948afa20b7: [204] 0 (0.02s)
>> (Thread-45 ) INFO 2018-01-16 14:16:13,876 web:95:web:(log_start) START
>> [192.168.150.101] PUT /images/81569ab3-1b92-4744-8a58
>> -f1948afa20b7
>> (Thread-45 ) WARNING 2018-01-16 14:16:13,877 web:112:web:(log_error)
>> ERROR [192.168.150.101] PUT /images/81569ab3-1b92-4744-8a58-f1948afa20b7:
>> [401] Not authorized (0.00s)
>>
>> Gianluca
>>
>
>
> BTW:
> I don't know if its is in some way related with the upload problems, but
> in my engine .log I see these kind of messages every 5 or such seconds:
>
> 2018-01-16 14:27:38,428+01 INFO  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand]
> (DefaultQuartzScheduler3) [61e72c38] START, 
> GlusterServersListVDSCommand(HostName
> = ovirt02.localdomain.local, VdsIdVDSCommandParametersBase:
> {hostId='cb9cc605-fceb-4689-ad35-43ba883f4556'}), log id: 65e60794
> 2018-01-16 14:27:38,858+01 INFO  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand]
> (DefaultQuartzScheduler3) [61e72c38] FINISH, GlusterServersListVDSCommand,
> return: [192.168.150.103/24:CONNECTED, ovirt03.localdomain.local:CONNECTED,
> ovirt01.localdomain.local:CONNECTED], log id: 65e60794
> 2018-01-16 14:27:38,867+01 INFO  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
> (DefaultQuartzScheduler3) [61e72c38] START, 
> GlusterVolumesListVDSCommand(HostName
> = ovirt02.localdomain.local, GlusterVolumesListVDSParameter
> s:{hostId='cb9cc605-fceb-4689-ad35-43ba883f4556'}), log id: 6e01993d
> 2018-01-16 14:27:39,221+01 WARN  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler3) [61e72c38] Could not associate brick
> 'ovirt02.localdomain.local:/gluster/brick1/engine' of volume
> '6e2bd1d7-9c8e-4c54-9d85-f36e1b871771' with correct network as no gluster
> network found in cluster '582badbe-0080-0197-013b-01c6'
> 2018-01-16 14:27:39,231+01 WARN  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler3) [61e72c38] Could not associate brick
> 'ovirt02.localdomain.local:/gluster/brick2/data' of volume
> '2238c6db-48c5-4071-8929-879cedcf39bf' with correct network as no gluster
> network found in cluster '582badbe-0080-0197-013b-01c6'
> 2018-01-16 14:27:39,253+01 WARN  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler3) [61e72c38] Could not associate brick
> 'ovirt02.localdomain.local:/gluster/brick4/iso' of volume
> '28f99f11-3529-43a1-895c-abf1c66884ab' with correct network as no gluster
> network found in cluster '582badbe-0080-0197-013b-01c6'
> 2018-01-16 14:27:39,255+01 INFO  
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
> (DefaultQuartzScheduler3) [61e72c38] FINISH, GlusterVolumesListVDSCommand,
> return: {2238c6db-48c5-4071-8929-879cedcf39bf=org.ovirt.engine.
> core.common.businessentities.gluster.GlusterVolumeEntity@aa6e9a1e,
> df0ccd1d-5de6-42b8-a163-ec65c3698da3=org.ovirt.engine.
> core.common.businessentities.gluster.GlusterVolumeEntity@31c29088,
> 6e2bd1d7-9c8e-4c54-9d85-f36e1b871771=org.ovirt.engine.
> core.common.businessentities.gluster.GlusterVolumeEntity@ae82860f,
> 28f99f11-3529-43a1-895c-abf1c66884ab=org.ovirt.engine.
> core.common.businessentities.gluster.GlusterVolumeEntity@1b6a11e5}, log
> 

Re: [ovirt-users] hosted-engine unknow stale-data

[Artem Tambovskiy]

Hi Martin,

Thanks for feedback.

All hosts and hosted-engine running 4.1.8 release.
The strange thing : I can see that host ID is set to 1 on both hosts at
/etc/ovirt-hosted-engine/hosted-engine.conf file.
I have no idea how this happen, the only thing I have changed recently is
that I have changed mnt_options in order to add backup-volfile-servers
by using hosted-engine --set-shared-config command

Both agent and broker are running on second host

[root@ovirt2 ovirt-hosted-engine-ha]# ps -ef | grep ovirt-ha-
vdsm  42331  1 26 14:40 ?00:31:35 /usr/bin/python
/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker --no-daemon
vdsm  42332  1  0 14:40 ?00:00:16 /usr/bin/python
/usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent --no-daemon

but I saw some tracebacks during the broker start

[root@ovirt2 ovirt-hosted-engine-ha]# systemctl status ovirt-ha-broker -l
● ovirt-ha-broker.service - oVirt Hosted Engine High Availability
Communications Broker
   Loaded: loaded (/usr/lib/systemd/system/ovirt-ha-broker.service;
enabled; vendor preset: disabled)
   Active: active (running) since Tue 2018-01-16 14:40:15 MSK; 1h 58min ago
 Main PID: 42331 (ovirt-ha-broker)
   CGroup: /system.slice/ovirt-ha-broker.service
   └─42331 /usr/bin/python
/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker --no-daemon

Jan 16 14:40:15 ovirt2.telia.ru systemd[1]: Started oVirt Hosted Engine
High Availability Communications Broker.
Jan 16 14:40:15 ovirt2.telia.ru systemd[1]: Starting oVirt Hosted Engine
High Availability Communications Broker...
Jan 16 14:40:16 ovirt2.telia.ru ovirt-ha-broker[42331]: ovirt-ha-broker
ovirt_hosted_engine_ha.broker.listener.ConnectionHandler ERROR Error
handling request, data: 'set-storage-domain FilesystemBackend
dom_type=glusterfs sd_uuid=4a7f8717-9bb0-4d80-8016-498fa4b88162'
Traceback (most
recent call last):
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py",
line 166, in handle
data)
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/listener.py",
line 299, in _dispatch

.set_storage_domain(client, sd_type, **options)
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/storage_broker.py",
line 66, in set_storage_domain

self._backends[client].connect()
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
line 462, in connect
self._dom_type)
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
line 107, in get_domain_path
" in
{1}".format(sd_uuid, parent))

BackendFailureException: path to storage domain
4a7f8717-9bb0-4d80-8016-498fa4b88162 not found in
/rhev/data-center/mnt/glusterSD



I have tried to issue hosted-engine --connect-storage on second host
followed by agent & broker restart
But there is no any visible improvements.

Regards,
Artem







On Tue, Jan 16, 2018 at 4:18 PM, Martin Sivak  wrote:

> Hi everybody,
>
> there are couple of things to check here.
>
> - what version of hosted engine agent is this? The logs look like
> coming from 4.1
> - what version of engine is used?
> - check the host ID in /etc/ovirt-hosted-engine/hosted-engine.conf on
> both hosts, the numbers must be different
> - it looks like the agent or broker on host 2 is not active (or there
> would be a report)
> - the second host does not see data from the first host (unknown
> stale-data), wait for a minute and check again, then check the storage
> connection
>
> And then the general troubleshooting:
>
> - put hosted engine in global maintenance mode (and check that it is
> visible from the other host using he --vm-status)
> - mount storage domain (hosted-engine --connect-storage)
> - check sanlock client status to see if proper lockspaces are present
>
> Best regards
>
> Martin Sivak
>
> On Tue, Jan 16, 2018 at 1:16 PM, Derek Atkins  wrote:
> > Why are both hosts reporting as ovirt 1?
> > Look at the hostname fields to see what mean.
> >
> > -derek
> > Sent using my mobile device. Please excuse any typos.
> >
> > On January 16, 2018 7:11:09 AM Artem Tambovskiy <
> artem.tambovs...@gmail.com>
> > wrote:
> >>
> >> Hello,
> >>
> >> Yes, I followed exactly the same procedure while reinstalling the hosts
> >> (the only difference that I have SSH key configured instead of the
> >> password).
> >>
> >> Just reinstalled the second host one more time, after 20 min the host
> >> still haven't reached active 

Re: [ovirt-users] oVirt 4.2.1 rc1 and upload iso to data domain test

[Gianluca Cecchi]

On Tue, Jan 16, 2018 at 2:21 PM, Gianluca Cecchi 
wrote:

> On Tue, Jan 16, 2018 at 6:48 AM, Fred Rolland  wrote:
>
>> Hi,
>> I will look into it.
>>
>> Is it also not working also for non-iso images?
>>
>> Thanks,
>> Fred
>>
>>
> Hello,
> I get the same with a disk.
> I have tried with a raw disk of size 1Gb.
> When I upload I can set the size (why?) while with the iso image I could
> not.
> The disk is recognized as "data" in upload window (the iso fie was
> correctly recognized as "iso"), but in image-proxy.log I get
>
> (Thread-42 ) INFO 2018-01-16 14:15:50,530 web:95:web:(log_start) START
> [192.168.150.101] GET /info/
> (Thread-42 ) INFO 2018-01-16 14:15:50,532 web:102:web:(log_finish) FINISH
> [192.168.150.101] GET /info/: [200] 20 (0.00s)
> (Thread-43 ) INFO 2018-01-16 14:16:12,659 web:95:web:(log_start) START
> [192.168.150.105] PUT /tickets/
> (Thread-43 ) INFO 2018-01-16 14:16:12,661 auth2:170:auth2:(add_signed_ticket)
> Adding new ticket:  4744-8a58-f1948afa20b7', url=u'https://ovirt01.localdomain.local:54322'
> at 0x7f048c03c610>
> (Thread-43 ) INFO 2018-01-16 14:16:12,662 web:102:web:(log_finish) FINISH
> [192.168.150.105] PUT /tickets/: [200] 0 (0.00s)
> (Thread-44 ) INFO 2018-01-16 14:16:13,800 web:95:web:(log_start) START
> [192.168.150.101] OPTIONS /images/81569ab3-1b92-4744-
> 8a58-f1948afa20b7
> (Thread-44 ) INFO 2018-01-16 14:16:13,814 web:102:web:(log_finish) FINISH
> [192.168.150.101] OPTIONS /images/81569ab3-1b92-47
> 44-8a58-f1948afa20b7: [204] 0 (0.02s)
> (Thread-45 ) INFO 2018-01-16 14:16:13,876 web:95:web:(log_start) START
> [192.168.150.101] PUT /images/81569ab3-1b92-4744-8a58
> -f1948afa20b7
> (Thread-45 ) WARNING 2018-01-16 14:16:13,877 web:112:web:(log_error) ERROR
> [192.168.150.101] PUT /images/81569ab3-1b92-4744-8a58-f1948afa20b7: [401]
> Not authorized (0.00s)
>
> Gianluca
>


BTW:
I don't know if its is in some way related with the upload problems, but in
my engine .log I see these kind of messages every 5 or such seconds:

2018-01-16 14:27:38,428+01 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand]
(DefaultQuartzScheduler3) [61e72c38] START,
GlusterServersListVDSCommand(HostName = ovirt02.localdomain.local,
VdsIdVDSCommandParametersBase:{hostId='cb9cc605-fceb-4689-ad35-43ba883f4556'}),
log id: 65e60794
2018-01-16 14:27:38,858+01 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand]
(DefaultQuartzScheduler3) [61e72c38] FINISH, GlusterServersListVDSCommand,
return: [192.168.150.103/24:CONNECTED, ovirt03.localdomain.local:CONNECTED,
ovirt01.localdomain.local:CONNECTED], log id: 65e60794
2018-01-16 14:27:38,867+01 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(DefaultQuartzScheduler3) [61e72c38] START,
GlusterVolumesListVDSCommand(HostName = ovirt02.localdomain.local,
GlusterVolumesListVDSParameters:{hostId='cb9cc605-fceb-4689-ad35-43ba883f4556'}),
log id: 6e01993d
2018-01-16 14:27:39,221+01 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
(DefaultQuartzScheduler3) [61e72c38] Could not associate brick
'ovirt02.localdomain.local:/gluster/brick1/engine' of volume
'6e2bd1d7-9c8e-4c54-9d85-f36e1b871771' with correct network as no gluster
network found in cluster '582badbe-0080-0197-013b-01c6'
2018-01-16 14:27:39,231+01 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
(DefaultQuartzScheduler3) [61e72c38] Could not associate brick
'ovirt02.localdomain.local:/gluster/brick2/data' of volume
'2238c6db-48c5-4071-8929-879cedcf39bf' with correct network as no gluster
network found in cluster '582badbe-0080-0197-013b-01c6'
2018-01-16 14:27:39,253+01 WARN
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
(DefaultQuartzScheduler3) [61e72c38] Could not associate brick
'ovirt02.localdomain.local:/gluster/brick4/iso' of volume
'28f99f11-3529-43a1-895c-abf1c66884ab' with correct network as no gluster
network found in cluster '582badbe-0080-0197-013b-01c6'
2018-01-16 14:27:39,255+01 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(DefaultQuartzScheduler3) [61e72c38] FINISH, GlusterVolumesListVDSCommand,
return:
{2238c6db-48c5-4071-8929-879cedcf39bf=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@aa6e9a1e,
df0ccd1d-5de6-42b8-a163-ec65c3698da3=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@31c29088,
6e2bd1d7-9c8e-4c54-9d85-f36e1b871771=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@ae82860f,
28f99f11-3529-43a1-895c-abf1c66884ab=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@1b6a11e5},
log id: 6e01993d

Actualy te gluster network seems ok.

Eg

[root@ovirt01 glusterfs]# gluster volume info data

Volume Name: data
Type: Replicate
Volume ID: 2238c6db-48c5-4071-8929-879cedcf39bf
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3

Re: [ovirt-users] oVirt 4.2.1 rc1 and upload iso to data domain test

[Gianluca Cecchi]

On Tue, Jan 16, 2018 at 6:48 AM, Fred Rolland  wrote:

> Hi,
> I will look into it.
>
> Is it also not working also for non-iso images?
>
> Thanks,
> Fred
>
>
Hello,
I get the same with a disk.
I have tried with a raw disk of size 1Gb.
When I upload I can set the size (why?) while with the iso image I could
not.
The disk is recognized as "data" in upload window (the iso fie was
correctly recognized as "iso"), but in image-proxy.log I get

(Thread-42 ) INFO 2018-01-16 14:15:50,530 web:95:web:(log_start) START
[192.168.150.101] GET /info/
(Thread-42 ) INFO 2018-01-16 14:15:50,532 web:102:web:(log_finish) FINISH
[192.168.150.101] GET /info/: [200] 20 (0.00s)
(Thread-43 ) INFO 2018-01-16 14:16:12,659 web:95:web:(log_start) START
[192.168.150.105] PUT /tickets/
(Thread-43 ) INFO 2018-01-16 14:16:12,661
auth2:170:auth2:(add_signed_ticket) Adding new ticket: https://ovirt01.localdomain.local:54322' at
0x7f048c03c610>
(Thread-43 ) INFO 2018-01-16 14:16:12,662 web:102:web:(log_finish) FINISH
[192.168.150.105] PUT /tickets/: [200] 0 (0.00s)
(Thread-44 ) INFO 2018-01-16 14:16:13,800 web:95:web:(log_start) START
[192.168.150.101] OPTIONS /images/81569ab3-1b92-4744-
8a58-f1948afa20b7
(Thread-44 ) INFO 2018-01-16 14:16:13,814 web:102:web:(log_finish) FINISH
[192.168.150.101] OPTIONS /images/81569ab3-1b92-47
44-8a58-f1948afa20b7: [204] 0 (0.02s)
(Thread-45 ) INFO 2018-01-16 14:16:13,876 web:95:web:(log_start) START
[192.168.150.101] PUT /images/81569ab3-1b92-4744-8a58
-f1948afa20b7
(Thread-45 ) WARNING 2018-01-16 14:16:13,877 web:112:web:(log_error) ERROR
[192.168.150.101] PUT /images/81569ab3-1b92-4744-8a58-f1948afa20b7: [401]
Not authorized (0.00s)

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

Re: [ovirt-users] hosted-engine unknow stale-data

[Martin Sivak]

Hi everybody,

there are couple of things to check here.

- what version of hosted engine agent is this? The logs look like
coming from 4.1
- what version of engine is used?
- check the host ID in /etc/ovirt-hosted-engine/hosted-engine.conf on
both hosts, the numbers must be different
- it looks like the agent or broker on host 2 is not active (or there
would be a report)
- the second host does not see data from the first host (unknown
stale-data), wait for a minute and check again, then check the storage
connection

And then the general troubleshooting:

- put hosted engine in global maintenance mode (and check that it is
visible from the other host using he --vm-status)
- mount storage domain (hosted-engine --connect-storage)
- check sanlock client status to see if proper lockspaces are present

Best regards

Martin Sivak

On Tue, Jan 16, 2018 at 1:16 PM, Derek Atkins  wrote:
> Why are both hosts reporting as ovirt 1?
> Look at the hostname fields to see what mean.
>
> -derek
> Sent using my mobile device. Please excuse any typos.
>
> On January 16, 2018 7:11:09 AM Artem Tambovskiy 
> wrote:
>>
>> Hello,
>>
>> Yes, I followed exactly the same procedure while reinstalling the hosts
>> (the only difference that I have SSH key configured instead of the
>> password).
>>
>> Just reinstalled the second host one more time, after 20 min the host
>> still haven't reached active score of 3400 (Hosted Engine HA:Not Active) and
>> I still don't see crown icon for this host.
>>
>> hosted-engine --vm-status  from ovirt1 host
>>
>> [root@ovirt1 ~]# hosted-engine --vm-status
>>
>>
>> --== Host 1 status ==--
>>
>> conf_on_shared_storage : True
>> Status up-to-date  : True
>> Hostname   : ovirt1.telia.ru
>> Host ID: 1
>> Engine status  : {"health": "good", "vm": "up",
>> "detail": "up"}
>> Score  : 3400
>> stopped: False
>> Local maintenance  : False
>> crc32  : 3f94156a
>> local_conf_timestamp   : 349144
>> Host timestamp : 349144
>> Extra metadata (valid at timestamp):
>> metadata_parse_version=1
>> metadata_feature_version=1
>> timestamp=349144 (Tue Jan 16 15:03:45 2018)
>> host-id=1
>> score=3400
>> vm_conf_refresh_time=349144 (Tue Jan 16 15:03:45 2018)
>> conf_on_shared_storage=True
>> maintenance=False
>> state=EngineUp
>> stopped=False
>>
>>
>> --== Host 2 status ==--
>>
>> conf_on_shared_storage : True
>> Status up-to-date  : False
>> Hostname   : ovirt1.telia.ru
>> Host ID: 2
>> Engine status  : unknown stale-data
>> Score  : 0
>> stopped: True
>> Local maintenance  : False
>> crc32  : c7037c03
>> local_conf_timestamp   : 7530
>> Host timestamp : 7530
>> Extra metadata (valid at timestamp):
>> metadata_parse_version=1
>> metadata_feature_version=1
>> timestamp=7530 (Fri Jan 12 16:10:12 2018)
>> host-id=2
>> score=0
>> vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
>> conf_on_shared_storage=True
>> maintenance=False
>> state=AgentStopped
>> stopped=True
>>
>>
>> hosted-engine --vm-status output from ovirt2 host
>>
>> [root@ovirt2 ovirt-hosted-engine-ha]# hosted-engine --vm-status
>>
>>
>> --== Host 1 status ==--
>>
>> conf_on_shared_storage : True
>> Status up-to-date  : False
>> Hostname   : ovirt1.telia.ru
>> Host ID: 1
>> Engine status  : unknown stale-data
>> Score  : 3400
>> stopped: False
>> Local maintenance  : False
>> crc32  : 6d3606f1
>> local_conf_timestamp   : 349264
>> Host timestamp : 349264
>> Extra metadata (valid at timestamp):
>> metadata_parse_version=1
>> metadata_feature_version=1
>> timestamp=349264 (Tue Jan 16 15:05:45 2018)
>> host-id=1
>> score=3400
>> vm_conf_refresh_time=349264 (Tue Jan 16 15:05:45 2018)
>> conf_on_shared_storage=True
>> maintenance=False
>> state=EngineUp
>> stopped=False
>>
>>
>> --== Host 2 status ==--
>>
>> conf_on_shared_storage : True
>> Status up-to-date  : False
>> Hostname   : ovirt1.telia.ru
>> Host ID: 2
>> Engine status  : unknown stale-data
>> Score  : 0
>> 

Re: [ovirt-users] hosted-engine unknow stale-data

[Derek Atkins]

Why are both hosts reporting as ovirt 1?
Look at the hostname fields to see what mean.

-derek
Sent using my mobile device. Please excuse any typos.



On January 16, 2018 7:11:09 AM Artem Tambovskiy 
 wrote:



Hello,

Yes, I followed exactly the same procedure while reinstalling the hosts
(the only difference that I have SSH key configured instead of the
password).

Just reinstalled the second host one more time, after 20 min the host still
haven't reached active score of 3400 (Hosted Engine HA:Not Active) and I
still don't see crown icon for this host.

hosted-engine --vm-status  from ovirt1 host

[root@ovirt1 ~]# hosted-engine --vm-status


--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : True
Hostname   : ovirt1.telia.ru
Host ID: 1
Engine status  : {"health": "good", "vm": "up",
"detail": "up"}
Score  : 3400
stopped: False
Local maintenance  : False
crc32  : 3f94156a
local_conf_timestamp   : 349144
Host timestamp : 349144
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=349144 (Tue Jan 16 15:03:45 2018)
host-id=1
score=3400
vm_conf_refresh_time=349144 (Tue Jan 16 15:03:45 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True


hosted-engine --vm-status output from ovirt2 host

[root@ovirt2 ovirt-hosted-engine-ha]# hosted-engine --vm-status


--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 1
Engine status  : unknown stale-data
Score  : 3400
stopped: False
Local maintenance  : False
crc32  : 6d3606f1
local_conf_timestamp   : 349264
Host timestamp : 349264
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=349264 (Tue Jan 16 15:05:45 2018)
host-id=1
score=3400
vm_conf_refresh_time=349264 (Tue Jan 16 15:05:45 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True


Also I saw some log messages in webGUI about time drift like

"Host ovirt2.telia.ru has time-drift of 5305 seconds while maximum
configured value is 300 seconds." that is a bit weird as haven't touched
any time settings since I installed the cluster.
both host have the same time and timezone (MSK) but hosted engine lives in
UTC timezone. Is it mandatory to have everything in sync and in the same
timezone?

Regards,
Artem






On Tue, Jan 16, 2018 at 2:20 PM, Kasturi Narra  wrote:


Hello,

 I now see that your hosted engine is up and running. Can you let me
know how did you try reinstalling the host? Below is the 

Re: [ovirt-users] hosted-engine unknow stale-data

[Artem Tambovskiy]

Hello,

Yes, I followed exactly the same procedure while reinstalling the hosts
(the only difference that I have SSH key configured instead of the
password).

Just reinstalled the second host one more time, after 20 min the host still
haven't reached active score of 3400 (Hosted Engine HA:Not Active) and I
still don't see crown icon for this host.

hosted-engine --vm-status  from ovirt1 host

[root@ovirt1 ~]# hosted-engine --vm-status


--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : True
Hostname   : ovirt1.telia.ru
Host ID: 1
Engine status  : {"health": "good", "vm": "up",
"detail": "up"}
Score  : 3400
stopped: False
Local maintenance  : False
crc32  : 3f94156a
local_conf_timestamp   : 349144
Host timestamp : 349144
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=349144 (Tue Jan 16 15:03:45 2018)
host-id=1
score=3400
vm_conf_refresh_time=349144 (Tue Jan 16 15:03:45 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True


hosted-engine --vm-status output from ovirt2 host

[root@ovirt2 ovirt-hosted-engine-ha]# hosted-engine --vm-status


--== Host 1 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 1
Engine status  : unknown stale-data
Score  : 3400
stopped: False
Local maintenance  : False
crc32  : 6d3606f1
local_conf_timestamp   : 349264
Host timestamp : 349264
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=349264 (Tue Jan 16 15:05:45 2018)
host-id=1
score=3400
vm_conf_refresh_time=349264 (Tue Jan 16 15:05:45 2018)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False


--== Host 2 status ==--

conf_on_shared_storage : True
Status up-to-date  : False
Hostname   : ovirt1.telia.ru
Host ID: 2
Engine status  : unknown stale-data
Score  : 0
stopped: True
Local maintenance  : False
crc32  : c7037c03
local_conf_timestamp   : 7530
Host timestamp : 7530
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=7530 (Fri Jan 12 16:10:12 2018)
host-id=2
score=0
vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True


Also I saw some log messages in webGUI about time drift like

"Host ovirt2.telia.ru has time-drift of 5305 seconds while maximum
configured value is 300 seconds." that is a bit weird as haven't touched
any time settings since I installed the cluster.
both host have the same time and timezone (MSK) but hosted engine lives in
UTC timezone. Is it mandatory to have everything in sync and in the same
timezone?

Regards,
Artem






On Tue, Jan 16, 2018 at 2:20 PM, Kasturi Narra  wrote:

> Hello,
>
>  I now see that your hosted engine is up and running. Can you let me
> know how did you try reinstalling the host? Below is the procedure which is
> used and hope you did not miss any step while reinstalling. If no, can you
> try reinstalling again and see if that works ?
>
> 1) Move the host to maintenance
> 2) click on reinstall
> 3) provide the password
> 4) 

Re: [ovirt-users] Shutdown all VM's command line

[Yaniv Kaul]

On Thu, Jan 11, 2018 at 1:47 PM, Giorgio Biacchi 
wrote:

> On 01/11/2018 11:44 AM, Kapetanakis Giannis wrote:
>
>> On 10/01/18 22:11, Wesley Stewart wrote:
>>
>>> Marcelo,
>>>
>>> I would greatly appreciate seeing a script!  It would be an excellent
>>> chance for me to learn a bit about using ovirt from the command line as
>>> well!
>>>
>>
>> I'm using something like this with ovirt-shell
>>
>> vm_shutdown:
>> #!/bin/sh
>> LOG=/root/ovirt/vm_shutdown_log
>> echo `date` >> $LOG
>> /usr/bin/ovirt-shell -f /root/ovirt/vm_shutdown_script >> $LOG
>> echo "" >> $LOG
>>
>> vm_shutdown_script:
>> list vms --kwargs status-state=up|grep name | sed s/'name
>>  :'/'action vm'/ | sed -e 's/$/ shutdown/' > /root/ovirt/new_vm_shutdown_sc
>> ript
>> file /root/ovirt/new_vm_shutdown_script
>>
>> new_vm_shutdown_script now lists entries like this:
>> action vm vm1 shutdown
>> action vm vm2 shutdown
>> etc.
>>
>> G
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
> You can use python SDK.
>
> Somthing like this should work
>
> #!/usr/bin/env python
>
> import ovirtsdk4 as sdk
>
> ovaddress = ""
> username="admin@internal"
> password="*"
>
> connection = sdk.Connection(
>   url=ovaddress,
>   username=username,
>   password=password,
>   ca_file='ca.crt',
>   insecure=True
> )
>
> system_service = connection.system_service()
> vms_service = system_service.vms_service()
> vms = vms_service.list()
>

I think it's better to do it for all VMs that are in 'Up' state?


>
> for vm in vms:
> vm_service = vms_service.vm_service(vm.id)
> vm_service.shutdown()
>

 And here I suggest adding a check (after some time?) that all VMs are
actually down, and if not, exit with an error?
Y.


> connection.close()
>
> --
> gb
>
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Shutdown all VM's command line

[Giulio Casella]

Il 16/01/2018 02:02, Wesley Stewart ha scritto:
I am using the default certificates.   Took me a second to find out 
where they are stored, but after pointing directly to it, everything is 
working like a champ.


If I remember correctly, if you use option "insecure=True", you can omit 
ca_file option:


connection = sdk.Connection(
  url=ovaddress,
  username=username,
  password=password,
  insecure=True
)


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

[ovirt-users] oVirt 2018 Survey

[Sandro Bonazzola]

As we continue to develop oVirt 4.2 and future releases, the Development
and Integration teams at Red Hat would value
insights on how you are deploying the oVirt environment. Please help us to
hit the mark by completing this short survey. Survey will close on February
1st.

Here's the link to the survey: https://goo.gl/forms/cAKWAR8RD7rGrVhE2

Thanks,
-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

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

Re: [ovirt-users] [solved] Error while upgrading engine from 4.1.8 to 4.2

[Luca 'remix_tj' Lorenzetto]

On Tue, Jan 16, 2018 at 9:20 AM, Sandro Bonazzola  wrote:
>
>
>
> 2018-01-12 17:39 GMT+01:00 Luca 'remix_tj' Lorenzetto 
> :
>>
>> Hello,
>>
>> i just completed the upgrade of my engine appliance from 4.1.8 to 4.2.0.1.
>
>
> This is interesting, since we released ovirt-engine-4.2.0.2 on GA, not 
> 4.2.0.1.
> Can you detail how did you get 4.2.0.1?
>

Hello Sandro,

it's a typo. The version is 4.2.0.2-1.el7.centos as you reported.

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 , 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [solved] Error while upgrading engine from 4.1.8 to 4.2

[Sandro Bonazzola]

2018-01-12 17:39 GMT+01:00 Luca 'remix_tj' Lorenzetto <
lorenzetto.l...@gmail.com>:

> Hello,
>
> i just completed the upgrade of my engine appliance from 4.1.8 to 4.2.0.1.
>

This is interesting, since we released ovirt-engine-4.2.0.2 on GA, not
4.2.0.1.
Can you detail how did you get 4.2.0.1?




>
> I would like to share the only error i've encountered while upgrading
> and running engine-setup:
>
> [ INFO  ] Creating/refreshing Engine database schema
> [ ERROR ] schema.sh: FATAL: Cannot execute sql command:
> --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_
> 02_0140_add_max_memory_constraint.sql
> [ ERROR ] Failed to execute stage 'Misc configuration': Engine schema
> refresh failed
>
>
> After some search i found out that is an error linked to a bad
> configuration of one (or more) vm having "Memory Size" value set with
> an higher value than "Maximum Memory".
> In my case the vm with that error was HostedEngine.
>

Adding Simone to let him know about this.


>
> Editing the vm configuration by setting an appropriate value allowed
> me to run again engine-setup with success.
>

Adding Meital, Marina and Derek to let them know.



>
> 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 , <
> lorenzetto.l...@gmail.com>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

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

Re: [ovirt-users] ovirt-guest-agent on atomic ?

[Sandro Bonazzola]

2018-01-15 18:43 GMT+01:00 Nathanaël Blanchet :

> Hi all, I didn't find any working ovirt-guest-agent for atomic7, and it is
> a requirement for launching atomic from vagrant-ovirt4 plugin.
> I tried installing ovirt-guest-agent inside, I tried installing
> ovirtguestagent/centos7-atomic, but I had no success
>
> Does any official project exist for it?
>

Adding Tomas, the Guest Agent maintainer.
I'm aware of
https://github.com/projectatomic/atomic-system-containers/tree/master/ovirt-guest-agent-centos
https://github.com/projectatomic/atomic-system-containers/tree/master/ovirt-guest-agent-fedora

which should translate to the following containers:

https://hub.docker.com/r/ovirtguestagent/centos7-atomic/
https://hub.docker.com/r/ovirtguestagent/fedora-atomic/

I see that 1.0.14 is missing there, so maybe Tomas can align the release
there.




>
> --
> Nathanaël Blanchet
>
> Supervision réseau
> Pôle Infrastrutures Informatiques
> 227 avenue Professeur-Jean-Louis-Viala
> 
> 34193 MONTPELLIER CEDEX 5
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

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