[ovirt-users] Re: Gluster quorum

[Sahina Bose]

Thanks for reporting this. https://gerrit.ovirt.org/91375 fixes this. I've
re-opened bug https://bugzilla.redhat.com/show_bug.cgi?id=1574508

On Thu, May 17, 2018 at 10:12 PM, Demeter Tibor  wrote:

> Hi,
>
> 4.2.4-0.0.master.20180515183442.git00e1340.el7.centos
>
> Firstly, I did a yum update "ovirt-*-setup*"
> second, I have ran engine-setup to upgrade.
>
> I didn't remove the old repos, just installed the nightly repo.
>
> Thank you again,
>
> Regards,
>
> Tibor
>
> - 2018. máj.. 17., 15:02, Sahina Bose  írta:
>
> It doesn't look like the patch was applied. Still see the same error in
> engine.log
> "Error while refreshing brick statuses for volume 'volume1' of cluster
> 'C6220': null"\
>
> Did you use engine-setup to upgrade? What's the version of ovirt-engine
> currently installed?
>
> On Thu, May 17, 2018 at 5:10 PM, Demeter Tibor 
> wrote:
>
>> Hi,
>>
>> sure,
>>
>> Thank you for your time!
>>
>> R
>> Tibor
>>
>> - 2018. máj.. 17., 12:19, Sahina Bose  írta:
>>
>> [+users]
>>
>> Can you provide the engine.log to see why the monitoring is not working
>> here. thanks!
>>
>> On Wed, May 16, 2018 at 2:08 PM, Demeter Tibor 
>> wrote:
>>
>>> Hi,
>>>
>>> Meanwhile, I did the upgrade engine, but the gluster state is same on my
>>> first node.
>>> I've attached some screenshot of my problem.
>>>
>>> Thanks
>>>
>>> Tibor
>>>
>>>
>>>
>>> - 2018. máj.. 16., 10:16, Demeter Tibor  írta
>>> Hi,
>>>
>>>
>>> If 4.3.4 will release, i just have to remove the nightly repo and update
>>> to stable?
>>>
>>> I'm sorry for my terrible English, I try to explain what was my problem
>>> with update.
>>> I'm upgraded from 4.1.8.
>>>
>>> I followed up the official hosted-engine update documentation, that was
>>> not clear me, because it has referenced to a lot of old thing (i think).
>>> https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide/
>>> https://www.ovirt.org/documentation/how-to/hosted-
>>> engine/#upgrade-hosted-engine
>>>
>>> Maybe it need to update, because I had a lot of question under upgrade
>>> and I was not sure in all of necessary steps. For example, If I need to
>>> installing the new, 4.2 repo on the hosts, then need to remove the old repo
>>> from that?
>>> Why I need to do a" yum update -y" on hosts, meanwhile there is an
>>> "Updatehost" menu in the GUI? So, maybe it outdated.
>>> Since upgrade hosted engine, and the first node, I have problems with
>>> gluster. It seems to working fine if you check it from console "gluster
>>> volume status, etc" but not on the Gui, because now it yellow, and the
>>> brick reds in the first node.
>>>
>>> Previously I did a mistake with glusterfs, my gluster config was wrong.
>>> I have corrected them, but it did not helped to me,gluster bricks are reds
>>> on my first node yet
>>>
>>>
>>> Now I try to upgrade to nightly, but I'm affraid, because it a living,
>>> productive system, and I don't have downtime. I hope it will help me.
>>>
>>> Thanks for all,
>>>
>>> Regards,
>>> Tibor Demeter
>>>
>>>
>>>
>>> - 2018. máj.. 16., 9:58, Sahina Bose  írta:
>>>
>>>
>>>
>>> On Wed, May 16, 2018 at 1:19 PM, Demeter Tibor 
>>> wrote:
>>>
 Hi,

 is it a different, unstable repo? I have a productive cluster, how is
 safe that?
 I don't have any experience with nightly build. How can I use this? It
 have to install to the engine VM or all of my hosts?
 Thanks in advance for help me..

>>>
>>> Only on the engine VM.
>>>
>>> Regarding stability - it passes CI so relatively stable, beyond that
>>> there are no guarantees.
>>>
>>> What's the specific problem you're facing with update? Can you elaborate?
>>>
>>>
 Regards,

 Tibor

 - 2018. máj.. 15., 9:58, Demeter Tibor  írta:

 Hi,

 Could you explain how can I use this patch?

 R,
 Tibor


 - 2018. máj.. 14., 11:18, Demeter Tibor  írta:

 Hi,

 Sorry for my question, but can you tell me please how can I use this
 patch?

 Thanks,
 Regards,
 Tibor
 - 2018. máj.. 14., 10:47, Sahina Bose  írta:



 On Sat, May 12, 2018 at 1:14 PM, Demeter Tibor 
 wrote:

> Hi,
>
> Could someone help me please ? I can't finish my upgrade process.
>

 https://gerrit.ovirt.org/91164 should fix the error you're facing.

 Can you elaborate why this is affecting the upgrade process?


> Thanks
> R
> Tibor
>
>
>
> - 2018. máj.. 10., 12:51, Demeter Tibor 
> írta:
>
> Hi,
>
> I've attached the vdsm and supervdsm logs. But I don't have engine.log
> here, because that is on hosted engine vm. Should I send that ?
>

[ovirt-users] Re: Hosted Engine Setup error (oVirt v4.2.3)

[ovirt]

Yesterday, that install failed because I did not have the required 60GB  
for /var.


Today, I started from scratch & re-installed the oVirt nodes.
That install also failed.
I've attached the logs via dropbox link
https://www.dropbox.com/s/mnhn5bpuqlsr8ir/ovirt-hosted-engine-setup.zip?dl=0

On 2018-05-17 01:55, ov...@fateknollogee.com wrote:

Some good news...
Hosted Engine Deployment "preparing the vm" completed.
I used a simpler password.
When I got the previous errors, my password was 12 characters (upper,
lower case & numbers) long with a %% (double percent) before and after
the characters.
I guess it didn't like the double percent!!!
Let me continue, I will report back.

On 2018-05-17 00:30, Simone Tiraboschi wrote:

On Thu, May 17, 2018 at 9:16 AM,  wrote:


More info:
From my ovirt node (host) I can ping 192.168.124.198
If I try to connect via ssh root@192.168.124.198, it asks for a
password.
The password I used during the hosted engine setup does not work.


Can you please try with a different more robust password?
The log file is under /var/log/ovirt-hosted-engine-setup


On 2018-05-16 22:27, ov...@fateknollogee.com wrote:
I will get the logs.

Here is the exact error message:
[ ERROR ] fatal: [ovirt-engine.fateknollogee.com [1]]: UNREACHABLE!
=>
{"changed": false, "msg": "Failed to connect to the host via ssh:
Warning: Permanently added
'ovirt-engine.fateknollogee.com [1],192.168.124.198' (ECDSA) to the
list
of known hosts.\r\nPermission denied
(publickey,gssapi-keyex,gssapi-with-mic,password).\r\n",
"unreachable": true}

On 2018-05-16 07:04, Simone Tiraboschi wrote:
On Wed, May 16, 2018 at 3:36 PM,  wrote:

Simone, unfortunately I deleted that install after it failed.
I can re-run the install based on the df -h (see previous post) or I
can change disks & increase the size of /var then re-run the
install.
What do you think?
The error I was getting said it could not find the hosted engine at
vibr0 on 192.168.xxx.xx

On my opinion you could simply retry.
Please share your log file it fails again.

On 2018-05-16 06:30, Simone Tiraboschi wrote:

On Wed, May 16, 2018 at 3:25 PM,  wrote:

This is what I had.
Does this look correct?

Yes, I think so.

can you please share your hosted-engine-setup log file to understand
where it's failing?

[root@ovirt-node1 ~]# df -h
Filesystem
Size  Used Avail Use% Mounted on
/dev/mapper/onn_ovirt--node1-ovirt--node--ng--4.2.3--0.20180515.0+1
14G  1.8G   12G  14% /
devtmpfs
32G 0   32G   0% /dev
tmpfs
32G  8.0K   32G   1% /dev/shm
tmpfs
32G   18M   32G   1% /run
tmpfs
32G 0   32G   0% /sys/fs/cgroup
/dev/sda1
976M  207M  702M  23% /boot
/dev/mapper/onn_ovirt--node1-home
976M  2.6M  907M   1% /home
/dev/mapper/onn_ovirt--node1-tmp
976M  2.8M  906M   1% /tmp
/dev/mapper/onn_ovirt--node1-var
15G  112M   14G   1% /var
/dev/mapper/onn_ovirt--node1-var_log
7.8G   42M  7.3G   1% /var/log
/dev/mapper/onn_ovirt--node1-var_log_audit
2.0G  6.3M  1.8G   1% /var/log/audit
/dev/mapper/onn_ovirt--node1-var_crash
9.8G   37M  9.2G   1% /var/crash
tmpfs
6.3G 0  6.3G   0% /run/user/0

On 2018-05-16 06:14, Simone Tiraboschi wrote:
On Wed, May 16, 2018 at 2:52 PM,  wrote:



https://www.ovirt.org/documentation/install-guide/chap-System_Requirements/

[2]
[1]
[1]
[1] says:
Important: If you are also installing the oVirt Engine Virtual
Appliance for self-hosted engine installation, the /var partition
must be at least 60 GB.

The appliance disk is shipped as a qcow2 image: 4 GB should be
enough.

Back to the drawing board, I certainly failed to read that!!

On 2018-05-16 02:37, Andrea Dell'Amico wrote:
On 16 May 2018, at 09:42, Simone Tiraboschi 
wrote:

On Tue, May 15, 2018 at 6:31 PM,   wrote:

Engine network config error

Following this blog post:



https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/

[3]
[2]
[2]
[2]

[1]

I get an error saying the hosted engine setup is "trying" to use
vibr0 (192.168.xxx.x) even though I have the bridge interface set
to "eno1"

Regardless of whether the Edit Hosts File is checked or unchecked,
it overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x

The same thing happens whether I set the engine IP to Static or
DHCP (I don't have DNS, I'm using static entries in /etc/hosts).

Any ideas it "insists" on using "vibr0" instead of "eno1"?

Hi,
up to this point is absolutely fine: in the new node zero deployment
flow, hosted-engine-setup bootstraps a local VM with an engine there
to use that engine to configure the rest of the system (storage,
network...).
That bootstrap VM runs over default natted libvirt network, that's
why you see vibr0 and 192.168.xxx.x at that stage.

If you are facing any issue, it's definitively not there.

Yes, the blog post describes the 4.2.{0,1} behaviour while the local
VM is a change introduced in 4.2.2.
I faced a similar error 

[ovirt-users] Re: VM interface bonding (LACP)

[Doug Ingham]

 Very handy to know! Cheers!

I've been running a couple of tests over the past few days & it seems,
counter to what I said earlier, the proxy's interfering with the LACP
balancing too, as it rewrites the origin. Duh. *facepalm*

It skipped my mind that all our logs use the x-forwarded headers, so I
overlooked than one!

I'm going to test a new config on the reverse proxy to round-robin the
outbound IPs. We'll find out tomorrow if the VIF really isn't limited to
the reported 1Gbit.

Thanks


On 14 May 2018 at 17:45, Yaniv Kaul  wrote:

>
>
> On Mon, May 14, 2018, 11:33 PM Chris Adams  wrote:
>
>> Once upon a time, Doug Ingham  said:
>> >  Correct!
>> >
>> >  | Single 1Gbit virtual interface
>> >  |
>> > VM  Host  Switch stack
>> >|
>> >|--- 4x 1Gbit interfaces bonded over LACP
>> >
>> > The traffic for all of the VMs is distributed across the host's 4 bonded
>> > links, however each VM is limited to the 1Gbit of its own virtual
>> > interface. In the case of my proxy, all web traffic is routed through
>> it,
>> > so its single Gbit interface has become a bottleneck.
>>
>> It was my understanding that the virtual interface showing up as 1 gig
>> was just a reporting thing (something has to be put in the speed field).
>> I don't think the virtual interface is actually limited to 1 gig, the
>> server will just pass packets as fast as it can.
>>
>
> Absolutely right.
> Y.
>
>
>> --
>> Chris Adams 
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>


-- 
Doug
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: oVirt 4.2.3. iso question

[ovirt]

Anyone have any idea why this is like this?
I just did a clean install & this issue still exists.

On 2018-05-16 13:10, ov...@fateknollogee.com wrote:

ONBOOT was already set to "yes"
I still need to restart the network service after a reboot.

On 2018-05-16 12:26, Joshua Blake wrote:

Hello,

The SSH service should automatically start on boot. In your network
configuration file in /etc/sysconfig/network-scripts/, do you have the
line 'ONBOOT=yes'?

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Unable to start VM on host with OVS networking

[Jonathan Dieter]

I have a production ovirt setup that's gone through multiple updates over the 
years.  At some point when 4.0 or 4.1 came out, I switched from legacy 
networking to OVS, and everything worked perfectly until I upgraded to 4.2.  
Since I upgraded to 4.2, I've been getting messages that the networks were all 
out of sync, but everything continued working properly.

Today I tracked down the network sync problem, fixed it on one of my three 
hosts, and then attempted to start a VM on the host.  It refused to start with 
the error message: "Unable to add bridge ovirtmgmt port vnet0: Operation not 
supported".  From what I can tell, the xml being generated is still for the old 
legacy network.  I completely reinstalled the node, using the latest 4.2.3 node 
ISO image, and it still doesn't work.

In the cluster, the switch type is "OVS (Experimental)" (and this option can't 
be changed, apparently), the compatibility version is 4.2, the firewall type is 
firewalld and there's no "Default Network Provider".

I suspect that my upgrades have somehow left my system in half OVS/half legacy 
mode, but I'm not sure how to move it all the way to OVS mode and I don't want 
to mess with the other two hosts until I'm sure I've got it figured out.

My (compressed) vdsm.log is at https://www.lesbg.com/jdieter/vdsm.log.xz and my 
(compressed) supervdsm.log is at https://www.lesbg.com/jdieter/supervdsm.log.xz.

If anyone could point me in the right direction to get this fixed, I'd sure 
appreciate it.

Jonathan
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Changing resolution of console on Mint guest running on Ovirt 4.2

[pascal]

I keep getting an error:  Could not set configuration for CRTC 63. 

I checked that I have spice-agent and spice-agentd running. Also 
qemu-guest-agent. lspci shows that I have a QXL adapter. xrandr -q shows that I 
have many different config available. but none work.  

What am I missing?

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
Virtual-0 connected primary 1024x768+0+0 0mm x 0mm
   1024x768  59.95*+
   1920x1200 59.95  
   1920x1080 60.00  
   1600x1200 59.95  
   1680x1050 60.00  
   1400x1050 60.00  
   1280x1024 59.95  
   1440x900  59.99  
   1280x960  59.99  
   1280x854  59.95  
   1280x800  59.96  
   1280x720  59.97  
   1152x768  59.95  
   800x600   59.96  
   848x480   59.94  
   720x480   59.94  
   640x480   59.94  
Virtual-1 disconnected
V
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: oVirt setup help

[Justin Zygmont]

Shouldn’t really matter, but if you don’t have more than 1 server you’ll have 
trouble doing upgrades and no way to access if the engine screws up or can’t 
start, etc.


From: Lakhwinder Rai [mailto:rai.lakhwin...@ymail.com]
Sent: Tuesday, May 15, 2018 9:02 AM
To: users@ovirt.org
Subject: [ovirt-users] oVirt setup help


Hello guy's, I am planning to set up home lab with ovirt.I am confused with 
hardware selection.
Anybody has a same setup ,Any suggestion will be appreciated.

Thanks
Lakhwinder Rai
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: oVirt reports using Grafana

[Vincent Royer]

These are the same issues I ran into.  I did get it working, look up my
post history and you'll find some solutions to the errors

On Thu, May 17, 2018, 1:01 AM Sandro Bonazzola,  wrote:

> Shirly, can you please update the blog post pointing to an updated
> documentation page?
>
> 2018-05-17 9:35 GMT+02:00 Karli Sjöberg :
>
>> Heya!
>>
>> I've been whishing for reports in oVirt ever since the old 'Jasper
>> Reports' was removed. For an Enterprise, having pretty graphs to look
>> at is a must.
>>
>> Searching the subject, I've found this[*] and have managed to get it
>> installed OK but having issues trying to follow the guide setting it
>> up.
>>
>> First of all, I think the guide should have at least mentioned that
>> 'pg_hba.conf' needs to be edited for the read only user to be able to
>> connect to the database, I scratched my head around that for a while
>> before I got it.
>>
>> When I first type in the query example, I got syntax errors:
>> 'pq: syntax error at or near "$"'. I continued anyways since I figured
>> it would be solved at a later point, which turned out to be true, since
>> the next step is to use the "Templating feature" to add variables.
>>
>> Unfortunately this doesn't go so well, even though I followed the
>> instructions very carefully. After hitting save on the first variable I
>> am rewarded with the error message:
>> 'Template variables could not be initialized: pq: column "en_us" does
>> not exist.'
>>
>> Are the queries stated in the guide still correct? This is for
>> 'user_locale':
>> "SELECT DISTINCT language_code from enum_translator"
>>
>> [*]:https://www.ovirt.org/blog/2018/01/ovirt-report-using-grafana/
>>
>> TIA
>> /K
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>>
>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Gluster quorum

[Demeter Tibor]

Hi, 

4.2.4-0.0.master.20180515183442.git00e1340.el7.centos 

Firstly, I did a yum update "ovirt-*-setup*" 
second, I have ran engine-setup to upgrade. 

I didn't remove the old repos, just installed the nightly repo. 

Thank you again, 

Regards, 

Tibor 

- 2018. máj.. 17., 15:02, Sahina Bose  írta: 

> It doesn't look like the patch was applied. Still see the same error in
> engine.log
> "Error while refreshing brick statuses for volume 'volume1' of cluster 
> 'C6220':
> null"\

> Did you use engine-setup to upgrade? What's the version of ovirt-engine
> currently installed?

> On Thu, May 17, 2018 at 5:10 PM, Demeter Tibor < [ mailto:tdeme...@itsmart.hu 
> |
> tdeme...@itsmart.hu ] > wrote:

>> Hi,

>> sure,

>> Thank you for your time!

>> R
>> Tibor

>> - 2018. máj.. 17., 12:19, Sahina Bose < [ mailto:sab...@redhat.com |
>> sab...@redhat.com ] > írta:

>>> [+users]

>>> Can you provide the engine.log to see why the monitoring is not working 
>>> here.
>>> thanks!

>>> On Wed, May 16, 2018 at 2:08 PM, Demeter Tibor < [ 
>>> mailto:tdeme...@itsmart.hu |
>>> tdeme...@itsmart.hu ] > wrote:

 Hi,

 Meanwhile, I did the upgrade engine, but the gluster state is same on my 
 first
 node.
 I've attached some screenshot of my problem.

 Thanks

 Tibor

 - 2018. máj.. 16., 10:16, Demeter Tibor < [ mailto:tdeme...@itsmart.hu 
 |
 tdeme...@itsmart.hu ] > írta Hi,

> If 4.3.4 will release, i just have to remove the nightly repo and update 
> to
> stable?

> I'm sorry for my terrible English, I try to explain what was my problem 
> with
> update.
> I'm upgraded from 4.1.8.

> I followed up the official hosted-engine update documentation, that was 
> not
> clear me, because it has referenced to a lot of old thing (i think).
> [ https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide/ |
> https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide/ ]
> [
> https://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
> |
> https://www.ovirt.org/documentation/how-to/hosted-engine/#upgrade-hosted-engine
> ]

> Maybe it need to update, because I had a lot of question under upgrade 
> and I was
> not sure in all of necessary steps. For example, If I need to installing 
> the
> new, 4.2 repo on the hosts, then need to remove the old repo from that?
> Why I need to do a" yum update -y" on hosts, meanwhile there is an 
> "Updatehost"
> menu in the GUI? So, maybe it outdated.
> Since upgrade hosted engine, and the first node, I have problems with 
> gluster.
> It seems to working fine if you check it from console "gluster volume 
> status,
> etc" but not on the Gui, because now it yellow, and the brick reds in the 
> first
> node.

> Previously I did a mistake with glusterfs, my gluster config was wrong. I 
> have
> corrected them, but it did not helped to me,gluster bricks are reds on my 
> first
> node yet

> Now I try to upgrade to nightly, but I'm affraid, because it a living,
> productive system, and I don't have downtime. I hope it will help me.

> Thanks for all,

> Regards,
> Tibor Demeter

> - 2018. máj.. 16., 9:58, Sahina Bose < [ mailto:sab...@redhat.com |
> sab...@redhat.com ] > írta:

>> On Wed, May 16, 2018 at 1:19 PM, Demeter Tibor < [ 
>> mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > wrote:

>>> Hi,

>>> is it a different, unstable repo? I have a productive cluster, how is 
>>> safe that?
>>> I don't have any experience with nightly build. How can I use this? It 
>>> have to
>>> install to the engine VM or all of my hosts?
>>> Thanks in advance for help me..

>> Only on the engine VM.

>> Regarding stability - it passes CI so relatively stable, beyond that 
>> there are
>> no guarantees.

>> What's the specific problem you're facing with update? Can you elaborate?

>>> Regards,

>>> Tibor

>>> - 2018. máj.. 15., 9:58, Demeter Tibor < [ 
>>> mailto:tdeme...@itsmart.hu |
>>> tdeme...@itsmart.hu ] > írta:

 Hi,

 Could you explain how can I use this patch?

 R,
 Tibor

 - 2018. máj.. 14., 11:18, Demeter Tibor < [ 
 mailto:tdeme...@itsmart.hu |
 tdeme...@itsmart.hu ] > írta:

> Hi,

> Sorry for my question, but can you tell me please how can I use this 
> patch?

> Thanks,
> Regards,
> Tibor
> - 2018. máj.. 14., 10:47, Sahina Bose < [ 
> mailto:sab...@redhat.com |
> sab...@redhat.com ] > írta:

>> On Sat, May 12, 2018 at 1:14 PM, Demeter Tibor < [ 
>> mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > wrote:

>>> Hi,

>>> Could someone help me please ? I can't 

[ovirt-users] User & Roles

[Simon Coter]

Hi,

I'm looking how-to create roles/users and give them access to specific
datacenter/host(s).
I looked on the documentation but I hadn't been able to find the proper
section; anyone that can give me an help ?
Thanks

Simon
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: problem to delete snapshot

[Benny Zlotnik]

Could be this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1555116

Adding Ala

On Thu, May 17, 2018 at 5:00 PM, Marcelo Leandro 
wrote:

> Error in engine.log.
>
>
> 2018-05-17 10:58:56,766-03 INFO  
> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand]
> (default task-31) [c4fc9663-51c1-4442-ba1b-01e4efe8c62c] Lock Acquired to
> object 
> 'EngineLock:{exclusiveLocks='[f120d81e-db65-44b8-b239-95d8ba3e0e31=VM]',
> sharedLocks=''}'
> 2018-05-17 10:58:56,923-03 ERROR 
> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand]
> (default task-31) [c4fc9663-51c1-4442-ba1b-01e4efe8c62c] Error during
> ValidateFailure.: java.lang.NullPointerException
> at org.ovirt.engine.core.bll.validator.storage.StorageDomainValidator.
> getTotalSizeForMerge(StorageDomainValidator.java:121) [bll.jar:]
> at org.ovirt.engine.core.bll.validator.storage.StorageDomainValidator.
> hasSpaceForMerge(StorageDomainValidator.java:207) [bll.jar:]
> at org.ovirt.engine.core.bll.validator.storage.
> MultipleStorageDomainsValidator.lambda$allDomainsHaveSpaceForMerge$0(
> MultipleStorageDomainsValidator.java:128) [bll.jar:]
> at org.ovirt.engine.core.bll.validator.storage.
> MultipleStorageDomainsValidator.validOrFirstFailure(
> MultipleStorageDomainsValidator.java:190) [bll.jar:]
> at org.ovirt.engine.core.bll.validator.storage.
> MultipleStorageDomainsValidator.allDomainsHaveSpaceForMerge(
> MultipleStorageDomainsValidator.java:125) [bll.jar:]
> at org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand.
> validateStorageDomains(RemoveSnapshotCommand.java:381) [bll.jar:]
> at org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand.validate(
> RemoveSnapshotCommand.java:359) [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:840)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:390)
> [bll.jar:]
> at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.
> execute(DefaultBackendActionExecutor.java:13) [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:516)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:498)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451)
> [bll.jar:]
> at sun.reflect.GeneratedMethodAccessor1100.invoke(Unknown Source)
> [:1.8.0_161]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161]
> at org.jboss.as.ee.component.ManagedReferenceMethodIntercep
> tor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.
> proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.
> delegateInterception(Jsr299BindingsInterceptor.java:70)
> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.
> doMethodInterception(Jsr299BindingsInterceptor.java:80)
> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(
> Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.
> jar:10.1.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.
> processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.
> proceed(InterceptorContext.java:437)
> at org.ovirt.engine.core.bll.interceptors.
> CorrelationIdTrackerInterceptor.aroundInvoke(
> CorrelationIdTrackerInterceptor.java:13) [bll.jar:]
> at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
> [:1.8.0_161]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMetho
> dInterceptor.processInvocation(ManagedReferenceLifecycleMetho
> dInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.
> ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(
> InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.
> proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivat
> ionInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at 

[ovirt-users] Re: VM's disk stuck in migrating state

[Benny Zlotnik]

Sorry, I forgot it's ISCSI, it's a bit different

In my case it would look something like:
2018-05-17 17:30:12,740+0300 DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain': '3e541b2d-
2a49-4eb8-ae4b-aa9acee228c6', 'voltype': 'INTERNAL', 'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 0, 'image':
'dd6b5ae0-196e-4879-b076-a0a8d8a1dfde', 'ctime': '1526566607', 'disktype':
'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children':
[], 'pool': '', 'capacity': '1073741824', 'uuid':
u'221c45e1-7f65-42c8-afc3-0ccc1d6fc148', 'truesize': '1073741824', 'type':
'PREALLOCATED', 'lease': {'path':
'/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases', 'owners
': [], 'version': None, 'offset': 109051904}} (__init__:355)

I then look for 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 in sanlock.log:
2018-05-17 17:30:12 20753 [3335]: s10:r14 resource
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb
8-ae4b-aa9acee228c6/leases:109051904 for 2,11,31496

So the resource would be:
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
and the pid is 31496

running
$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offsetlockspace
   resource  timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 020753 0001 0004 5
...

If the vdsm pid changed (and it probably did) it will be different, so I
acquire it for the new pid
$ sanlock client acquire -r
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
-p 32265
acquire pid 32265

Then I can see the timestamp changed
$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offsetlockspace
   resource  timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 021210 0001 0005 6

And then I release it:
$ sanlock client release -r
3e541b2d-2a49-4eb8-ae4b-aa9acee228c6:221c45e1-7f65-42c8-afc3-0ccc1d6fc148:/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
-p 32265
release pid 32265
release done 0

$ sanlock direct dump
/dev/3e541b2d-2a49-4eb8-ae4b-aa9acee228c6/leases:109051904
  offsetlockspace
   resource  timestamp  own  gen lver
 3e541b2d-2a49-4eb8-ae4b-aa9acee228c6
 221c45e1-7f65-42c8-afc3-0ccc1d6fc148 00 0001 0005 6

The timestamp is zeroed and the lease is free


On Thu, May 17, 2018 at 3:38 PM,  wrote:

> This is vdsm 4.19.45. I grepped the disk uuid in /var/log/sanlock.log but
> unfortunately no entry there...
>
>
> El 2018-05-17 13:11, Benny Zlotnik escribió:
>
>> Which vdsm version are you using?
>>
>> You can try looking for the image uuid in /var/log/sanlock.log
>>
>> On Thu, May 17, 2018 at 2:40 PM,  wrote:
>>
>> Thanks.
>>>
>>> I've been able to see the line in the log, however, the format
>>> differs slightly from yours.
>>>
>>>   2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6)
>>> [jsonrpc.JsonRpcServer] Calling 'Volume.getInfo' in bridge with
>>> {u'storagepoolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63',
>>> u'imageID': u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID':
>>> u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID':
>>> u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556)
>>> 2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6)
>>> [jsonrpc.JsonRpcServer] Return 'Volume.getInfo' in bridge with
>>> {'status': 'OK', 'domain': '1876ab86-216f-4a37-a36b-2b5d99fcaad0',
>>> 'voltype': 'INTERNAL', 'description': 'None', 'parent':
>>> 'ea9a0182-329f-4b8f-abe3-e894de95dac0', 'format': 'COW',
>>> 'generation': 1, 'image': 'b4013aba-a936-4a54-bb14-670d3a8b7c38',
>>> 'ctime': '1526470759', 'disktype': '2', 'legality': 'LEGAL',
>>> 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool':
>>> '', 'capacity': '21474836480', 'uuid':
>>> u'c2cfbb02-9981-4fb7-baea-7257a824145c', 'truesize': '1073741824',
>>> 'type': 'SPARSE', 'lease': {'owners': [8], 'version': 1L}}
>>> (__init__:582)
>>>
>>> As you can see, there's no path field there.
>>>
>>> How should I procceed?
>>>
>>> El 2018-05-17 12:01, Benny Zlotnik escribió:
>>> vdsm-client replaces vdsClient, take a look
>>> here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html
>>> [1]
>>> [4]
>>>
>>> On Thu, May 17, 2018 at 1:57 PM,  wrote:
>>>
>>> The issue is present in the logs:
>>>
>>>   2018-05-17 11:50:44,822+01 INFO
>>> [org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller]
>>> (DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e]
>>> Command CopyData id: 

[ovirt-users] Re: problem to delete snapshot

[Marcelo Leandro]

Error in engine.log.


2018-05-17 10:58:56,766-03 INFO
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand] (default
task-31) [c4fc9663-51c1-4442-ba1b-01e4efe8c62c] Lock Acquired to object
'EngineLock:{exclusiveLocks='[f120d81e-db65-44b8-b239-95d8ba3e0e31=VM]',
sharedLocks=''}'
2018-05-17 10:58:56,923-03 ERROR
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand] (default
task-31) [c4fc9663-51c1-4442-ba1b-01e4efe8c62c] Error during
ValidateFailure.: java.lang.NullPointerException
at
org.ovirt.engine.core.bll.validator.storage.StorageDomainValidator.getTotalSizeForMerge(StorageDomainValidator.java:121)
[bll.jar:]
at
org.ovirt.engine.core.bll.validator.storage.StorageDomainValidator.hasSpaceForMerge(StorageDomainValidator.java:207)
[bll.jar:]
at
org.ovirt.engine.core.bll.validator.storage.MultipleStorageDomainsValidator.lambda$allDomainsHaveSpaceForMerge$0(MultipleStorageDomainsValidator.java:128)
[bll.jar:]
at
org.ovirt.engine.core.bll.validator.storage.MultipleStorageDomainsValidator.validOrFirstFailure(MultipleStorageDomainsValidator.java:190)
[bll.jar:]
at
org.ovirt.engine.core.bll.validator.storage.MultipleStorageDomainsValidator.allDomainsHaveSpaceForMerge(MultipleStorageDomainsValidator.java:125)
[bll.jar:]
at
org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand.validateStorageDomains(RemoveSnapshotCommand.java:381)
[bll.jar:]
at
org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand.validate(RemoveSnapshotCommand.java:359)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:840)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:390)
[bll.jar:]
at
org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:516)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:498)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451)
[bll.jar:]
at sun.reflect.GeneratedMethodAccessor1100.invoke(Unknown Source)
[:1.8.0_161]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_161]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161]
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13)
[bll.jar:]
at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source)
[:1.8.0_161]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_161]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161]
at
org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89)
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
[wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at
org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
[weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
at
org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
[wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at
org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

[ovirt-users] Re: oVirt 4.1 upgrade hosted-engine

[dlotarev]

Information about packages
Host A:
# rpm -qa|grep -E 'virt|qemu|vdsm'|sort -n
centos-release-qemu-ev-1.0-2.el7.noarch
centos-release-virt-common-1-1.el7.centos.noarch
collectd-virt-5.8.0-2.el7.x86_64
fence-virt-0.3.2-12.el7.x86_64
fence-virtd-0.3.2-12.el7.x86_64
fence-virtd-libvirt-0.3.2-12.el7.x86_64
fence-virtd-multicast-0.3.2-12.el7.x86_64
fence-virtd-serial-0.3.2-12.el7.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
libgovirt-0.3.3-5.el7.x86_64
libvirt-3.2.0-14.el7_4.7.x86_64
libvirt-client-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-config-network-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-config-nwfilter-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-interface-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-lxc-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-network-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-nodedev-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-nwfilter-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-qemu-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-secret-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-core-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-disk-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-logical-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-mpath-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-rbd-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-driver-storage-scsi-3.2.0-14.el7_4.7.x86_64
libvirt-daemon-kvm-3.2.0-14.el7_4.7.x86_64
libvirt-glib-1.0.0-1.el7.x86_64
libvirt-libs-3.2.0-14.el7_4.7.x86_64
libvirt-lock-sanlock-3.2.0-14.el7_4.7.x86_64
libvirt-python-3.2.0-3.el7_4.1.x86_64
ovirt-engine-appliance-4.1-20171211.1.el7.centos.noarch
ovirt-engine-sdk-python-3.6.9.1-1.el7.centos.noarch
ovirt-host-deploy-1.6.7-1.el7.centos.noarch
ovirt-hosted-engine-ha-2.1.8-1.el7.centos.noarch
ovirt-hosted-engine-setup-2.1.4-1.el7.centos.noarch
ovirt-imageio-common-1.0.0-1.el7.noarch
ovirt-imageio-daemon-1.0.0-1.el7.noarch
ovirt-release41-4.1.8-1.el7.centos.noarch
ovirt-setup-lib-1.1.4-1.el7.centos.noarch
ovirt-vmconsole-1.0.4-1.el7.centos.noarch
ovirt-vmconsole-host-1.0.4-1.el7.centos.noarch
qemu-img-ev-2.9.0-16.el7_4.13.1.x86_64
qemu-kvm-common-ev-2.9.0-16.el7_4.13.1.x86_64
qemu-kvm-ev-2.9.0-16.el7_4.13.1.x86_64
qemu-kvm-tools-ev-2.9.0-16.el7_4.13.1.x86_64
vdsm-4.19.43-1.el7.centos.x86_64
vdsm-api-4.19.43-1.el7.centos.noarch
vdsm-cli-4.19.43-1.el7.centos.noarch
vdsm-client-4.19.43-1.el7.centos.noarch
vdsm-gluster-4.19.43-1.el7.centos.noarch
vdsm-hook-nestedvt-4.19.43-1.el7.centos.noarch
vdsm-hook-vmfex-dev-4.19.43-1.el7.centos.noarch
vdsm-jsonrpc-4.19.43-1.el7.centos.noarch
vdsm-python-4.19.43-1.el7.centos.noarch
vdsm-xmlrpc-4.19.43-1.el7.centos.noarch
vdsm-yajsonrpc-4.19.43-1.el7.centos.noarch
virt-v2v-1.36.3-6.el7_4.3.x86_64
virt-viewer-5.0-7.el7.x86_64
virt-what-1.13-10.el7.x86_64

Host B:
centos-release-qemu-ev-1.0-3.el7.centos.noarch
centos-release-virt-common-1-1.el7.centos.noarch
collectd-virt-5.8.0-3.el7.x86_64
fence-virt-0.3.2-13.el7.x86_64
fence-virtd-0.3.2-13.el7.x86_64
fence-virtd-multicast-0.3.2-13.el7.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
libgovirt-0.3.3-6.el7.x86_64
libvirt-client-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-config-network-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-config-nwfilter-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-interface-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-lxc-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-network-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-nodedev-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-nwfilter-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-qemu-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-secret-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-core-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-disk-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-gluster-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-iscsi-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-logical-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-mpath-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-rbd-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-driver-storage-scsi-3.9.0-14.el7_5.2.x86_64
libvirt-daemon-kvm-3.9.0-14.el7_5.2.x86_64
libvirt-glib-1.0.0-1.el7.x86_64
libvirt-libs-3.9.0-14.el7_5.2.x86_64
libvirt-lock-sanlock-3.9.0-14.el7_5.2.x86_64
libvirt-python-3.9.0-1.el7.x86_64
ovirt-engine-sdk-python-3.6.9.1-1.el7.centos.noarch
ovirt-host-deploy-1.6.7-1.el7.centos.noarch
ovirt-hosted-engine-ha-2.1.8-1.el7.centos.noarch
ovirt-hosted-engine-setup-2.1.4-1.el7.centos.noarch
ovirt-imageio-common-1.0.0-1.el7.noarch
ovirt-imageio-daemon-1.0.0-1.el7.noarch
ovirt-release41-4.1.9-1.el7.centos.noarch
ovirt-setup-lib-1.1.4-1.el7.centos.noarch

[ovirt-users] Re: vGPU VM not starting

[Callum Smith]

Dear All,

Similar issues with a clean install

https://www.dropbox.com/s/jf9pwapohn5dq5p/vdsm.gpu2.log?dl=0

Above is the dropbox of the log of the clean install. This VM has a custom 
"mdev_type" of "nvidia-53" which relates to a specific GRID P40-24Q instance. 
Even looking in /sys/class/mdev_bus/*/ you see that there has been correctly a 
vGPU slice created as part of the boot of the machine, but still you get this 
error:

2018-05-17 14:19:42,757+0100 INFO  (vm/1bc9dae8) [root] 
/usr/libexec/vdsm/hooks/before_vm_start/50_vfio_mdev: rc=1 err=vgpu: No device 
with type nvidia-53 is available.
 (hooks:110)
2018-05-17 14:19:42,873+0100 INFO  (vm/1bc9dae8) [root] 
/usr/libexec/vdsm/hooks/before_vm_start/50_vhostmd: rc=0 err= (hooks:110)
2018-05-17 14:19:42,874+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed 
(vm:943)

Thanks all for your input.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 14:05, Callum Smith 
> wrote:

Dear Yaniv,

Please see my most recent response:
https://www.dropbox.com/s/hlymmf9d6rn12tq/vdsm.vgpu.log?dl=0

I'm doing a clean install of the host right now to see if doing the exact same 
procedure a second time produces different results (this way lies madness, but 
we have excited bosses about vGPUs on oVirt).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 14:02, Yaniv Kaul 
> wrote:

It'd be easier if you could share the complete vdsm log.
Perhaps file a bug and we can investigate it?
Y.

On Thu, May 17, 2018 at 11:25 AM, Callum Smith 
> wrote:
Some information that appears to be from around the time of installation to the 
cluster:

WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -X 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -F 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -L 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -D POSTROUTING 
-o vnet0 -j libvirt-O-vnet0' failed: Illegal target name 'libvirt-O-vnet0'.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X HI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F HI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X FI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F FI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:20, Callum Smith 
> wrote:

PS. some other WARN's that come up on the host:

WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.org.qemu.guest_agent.0
 already removed
vdsm
WARN Attempting to remove a non existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN Attempting to remove a non existing network: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.ovirt-guest-agent.0
 already removed
vdsm
WARN Attempting to add an existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:16, Callum Smith 
> wrote:

OVN Network provider is used, and the node is running 4.2.3 (specifically 
2018051606 clean install last night).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 07:47, Ales Musil 
> wrote:



On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
Dear All,

Our vGPU installation is progressing, though the VM is failing to start.

2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] 

[ovirt-users] Re: oVirt 4.1 upgrade hosted-engine

[dlotarev]

Upgraded qemu-kvm-tools-ev  to 2.10.0 doesnt helped in my problem.
I want to ask community oVirt 4.1.9 compatible with qemu 2.10 or not?
Another one line from messages:
May 17 18:10:49 ovirt-h1 libvirtd: 2018-05-17 13:10:49.881+: 3638: error : 
virNetClientProgramDispatchError:177 : internal error: cannot execute command 
QEMU «cont»: Failed to lock byte 100

Thank you
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Upgrade from 4.1.9 to 4.2.3 fails to upgrade postgresql

[Alessandro De Salvo]

Hi Ian,
I had the very same problem, but the upgrade was complaining for a
different locale.
Try to add the following line at the beginning of the
file /opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup, after the
initial comments and before the code:


export PGSETUP_INITDB_OPTIONS="--lc-collate=en_GB.UTF-8"

Once done, please try again to run engine-setup, thus the upgrade.
You might need to add more options to PGSETUP_INITDB_OPTIONS, in case
the upgrade procedure still complains.
Cheers,

Alessandro


On Wed, 2018-05-16 at 22:32 +, Ian Fraser wrote:
> Hi, 
> 
> Could someone please provide advice on a production oVirt instance
> that fails to upgrade to 4.2.3?
> 
>  
> 
> Engine and hosts are all running CentOS 7
> 
>  
> 
> As per the upgrade instructions in the release notes I run:
> 
> # yum install
> http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm
> 
> # yum update "ovirt-*-setup*"
> 
> # engine-setup
> 
>  
> 
> Then I answer the questions and it fails with:
> 
> …
> 
> [ INFO  ] Upgrading PostgreSQL
> 
> [ ERROR ] Failed to execute stage 'Misc configuration': Command
> '/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to
> execute
> 
> [ INFO  ] Yum Performing yum transaction rollback
> 
> [ INFO  ] Rolling back to the previous PostgreSQL instance
> (postgresql).
> 
> [ INFO  ] Stage: Clean up
> 
>   Log file is located
> at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180516231622-3giicb.log
> 
> [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/20180516231735-setup.conf'
> 
> [ INFO  ] Stage: Pre-termination
> 
> [ INFO  ] Stage: Termination
> 
> [ ERROR ] Execution of setup failed
> 
>  
> 
>  
> 
> When I check  /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log:
> 
>  
> 
> Performing Consistency Checks
> 
> -
> 
> Checking cluster versions   ok
> 
> Checking database user is the install user  ok
> 
> Checking database connection settings   ok
> 
> Checking for prepared transactions  ok
> 
> Checking for reg* system OID user data typesok
> 
> Checking for contrib/isn with bigint-passing mismatch   ok
> 
> Checking for invalid "line" user columnsok
> 
> Creating dump of global objects ok
> 
> Creating dump of database schemas
> 
>   engine
> 
>   ovirt_engine_history
> 
>   postgres
> 
>   template1
> 
> ok
> 
>  
> 
> lc_collate values for database "postgres" do not match:  old
> "en_GB.UTF-8", new "en_US.UTF-8"
> 
> Failure, exiting
> 
>  
> 
>  
> 
> I have tried running the script here:
> https://gist.github.com/turboladen/6790847 and rerunning engine-setup
> but it fails with the same error.
> 
>  
> 
> Can anyone offer any other suggestions?
> 
>  
> 
> Best regards
> 
>  
> 
> Ian Fraser
> 
>  
> 
> Systems Administrator | Agency Sector Management (UK) Limited |
> www.asm.org.uk
> 
> [t] +44 (0)1784 242200 | [f] +44 (0)1784 242012 | [e]
> ian.fra...@asm.org.uk
> 
> Registered in England No. 2053849 | Registered address: Ashford House
> 41-45 Church Road  Ashford  Middx  TW15 2TQ
> 
> Follow us on twitter @asmukltd
> 
>  
> 
> 
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: ovirt with multiple engines

[Yaniv Kaul]

On Wed, May 16, 2018 at 7:26 PM, Michael Watters 
wrote:

> Is it possible to have multiple engines with different versions of ovirt
> running in the same cluster?  I am working on a plan to upgrade our
> ovirt cluster to the 4.2 release however we would like to have a
> rollback plan in case there are issues with the new engine.
>

If this is on a production-level setup, you anyway should have a
contingency plan if anything goes bad to the engine.
I recommend automated engine setup along with regular engine backup.
You can then take a backup prior to upgrade.

Y.


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: vGPU VM not starting

[Callum Smith]

Dear Yaniv,

Please see my most recent response:
https://www.dropbox.com/s/hlymmf9d6rn12tq/vdsm.vgpu.log?dl=0

I'm doing a clean install of the host right now to see if doing the exact same 
procedure a second time produces different results (this way lies madness, but 
we have excited bosses about vGPUs on oVirt).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 14:02, Yaniv Kaul 
> wrote:

It'd be easier if you could share the complete vdsm log.
Perhaps file a bug and we can investigate it?
Y.

On Thu, May 17, 2018 at 11:25 AM, Callum Smith 
> wrote:
Some information that appears to be from around the time of installation to the 
cluster:

WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -X 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -F 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -L 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -D POSTROUTING 
-o vnet0 -j libvirt-O-vnet0' failed: Illegal target name 'libvirt-O-vnet0'.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X HI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F HI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X FI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F FI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:20, Callum Smith 
> wrote:

PS. some other WARN's that come up on the host:

WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.org.qemu.guest_agent.0
 already removed
vdsm
WARN Attempting to remove a non existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN Attempting to remove a non existing network: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.ovirt-guest-agent.0
 already removed
vdsm
WARN Attempting to add an existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:16, Callum Smith 
> wrote:

OVN Network provider is used, and the node is running 4.2.3 (specifically 
2018051606 clean install last night).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 07:47, Ales Musil 
> wrote:



On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
Dear All,

Our vGPU installation is progressing, though the VM is failing to start.

2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed 
(vm:943)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in 
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in 
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
libvirtError: Cannot get interface MTU on '': No such device

That's the specific error, some other information. It seems the GPU 
'allocation' of uuid against the nvidia-xx mdev type is proceeding correctly, 
and the device is being created by the VM instantiation but the VM does not 
succeed in going up with this error. Any other logs or information relevant to 
help diagnose?

Regards,
Callum

--

Callum Smith
Research Computing 

[ovirt-users] Unable to start VM after 4.2 upgrade

[Ernest Beinrohr]

Hi, I updated my engine and 1 host to 4.2 from 4.1 and now I cannot 
start a VM and get this error:


"UnsupportedType: Unsupported {} for ioTune".

My other 6 4.1 hosts are able to start VM normally with the new 4.2 engine.


My VM has this inside: total_bytes_sec="0" total_iops_sec="0" write_bytes_sec="0" 
write_iops_sec="100"/>


error:

1.
   2018-05-17 14:30:38,006+0200 ERROR (vm/0d53dd5d) [virt.vm]
   (vmId='0d53dd5d-ef16-4763-bbdc-2dc173087bf5') The vm start process
   failed (vm:943)
2.
   Traceback (most recent call last):
3.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   872, in _startUnderlyingVm
4.
    self._run()
5.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   2882, in _run
6.
    self._domDependentInit()
7.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   2458, in _domDependentInit
8.
    self._vmDependentInit()
9.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   2495, in _vmDependentInit
10.
    self._sync_metadata()
11.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   5158, in _sync_metadata
12.
    self._md_desc.dump(self._dom)
13.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 509, in dump
14.
    md_xml = self._build_xml()
15.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 721, in _build_xml
16.
    md_elem = self._build_tree(namespace, namespace_uri)
17.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 711, in _build_tree
18.
    dev_elem = _dump_device(metadata_obj, data)
19.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 800, in _dump_device
20.
    elems.append(_dump_device_spec_params(md_obj, value))
21.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 866, in _dump_device_spec_params
22.
    spec_params_elem = md_obj.dump(_SPEC_PARAMS, **value)
23.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 229, in dump
24.
    _keyvalue_to_elem(self._add_ns(key), value, elem)
25.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 916, in _keyvalue_to_elem
26.
    raise UnsupportedType(key, value)
27.
   UnsupportedType: Unsupported {} for ioTune
28.
   2018-05-17 14:30:38,006+0200 INFO (vm/0d53dd5d) [virt.vm]
   (vmId='0d53dd5d-ef16-4763-bbdc-2dc173087bf5') Changed state to Down:
   Unsupported {} for ioTune (code=1) (vm:1683)
29.
   2018-05-17 14:30:38,007+0200 ERROR (vm/0d53dd5d) [root] FINISH
   thread  failed
   (concurrent:201)
30.
   Traceback (most recent call last):
31.
  File
   "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line
   194, in run
32.
    ret = func(*args, **kwargs)
33.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   944, in _startUnderlyingVm
34.
    self.setDownStatus(ERROR, vmexitreason.GENERIC_ERROR, str(e))
35.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   1685, in setDownStatus
36.
    self._update_metadata()
37.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   5145, in _update_metadata
38.
    self._sync_metadata()
39.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line
   5158, in _sync_metadata
40.
    self._md_desc.dump(self._dom)
41.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 509, in dump
42.
    md_xml = self._build_xml()
43.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 721, in _build_xml
44.
    md_elem = self._build_tree(namespace, namespace_uri)
45.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 711, in _build_tree
46.
    dev_elem = _dump_device(metadata_obj, data)
47.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 800, in _dump_device
48.
    elems.append(_dump_device_spec_params(md_obj, value))
49.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 866, in _dump_device_spec_params
50.
    spec_params_elem = md_obj.dump(_SPEC_PARAMS, **value)
51.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 229, in dump
52.
    _keyvalue_to_elem(self._add_ns(key), value, elem)
53.
  File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py",
   line 916, in _keyvalue_to_elem
54.
    raise UnsupportedType(key, value)
55.
   UnsupportedType: Unsupported {} for ioTune
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] oVirt setup help

[Lakhwinder Rai]

Hello guy's, I am planning to set up home lab with ovirt.I am confused with 
hardware selection.Anybody has a same setup ,Any suggestion will be appreciated.
Thanks
Lakhwinder Rai___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Hosted Engine Setup error (v4.2.3)

[ovirt]

Engine network config error

Following this blog post: 
https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/


I get an error saying the hosted engine setup is "trying" to use vibr0 
(192.168.xxx.x) even though I have the bridge interface set to "eno1"


Regardless of whether the Edit Hosts File is checked or unchecked, it 
overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x


The same thing happens whether I set the engine IP to Static or DHCP (I 
don't have DNS, I'm using static entries in /etc/hosts).


Any ideas it "insists" on using "vibr0" instead of "eno1"?

**also posted this on IRC
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: vGPU VM not starting

[Yaniv Kaul]

It'd be easier if you could share the complete vdsm log.
Perhaps file a bug and we can investigate it?
Y.

On Thu, May 17, 2018 at 11:25 AM, Callum Smith  wrote:

> Some information that appears to be from around the time of installation
> to the cluster:
>
> WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -X
> libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -F
> libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -L
> libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -D
> POSTROUTING -o vnet0 -j libvirt-O-vnet0' failed: Illegal target name
> 'libvirt-O-vnet0'.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X HI-vnet0' failed:
> ip6tables: No chain/target/match by that name.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F HI-vnet0' failed:
> ip6tables: No chain/target/match by that name.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X FI-vnet0' failed:
> ip6tables: No chain/target/match by that name.
> firewalld
> WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F FI-vnet0' failed:
> ip6tables: No chain/target/match by that name.
> firewalld
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 17 May 2018, at 09:20, Callum Smith  wrote:
>
> PS. some other WARN's that come up on the host:
>
> WARN File: /var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-
> 9103-5805100648d0.org.qemu.guest_agent.0 already removed
> vdsm
> WARN Attempting to remove a non existing net user:
> ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
> vdsm
> WARN Attempting to remove a non existing network:
> ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
> vdsm
> WARN File: /var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-
> 9103-5805100648d0.ovirt-guest-agent.0 already removed
> vdsm
> WARN Attempting to add an existing net user: ovirtmgmt/1bc9dae8-a0ea-44b3-
> 9103-5805100648d0
> vdsm
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 17 May 2018, at 09:16, Callum Smith  wrote:
>
> OVN Network provider is used, and the node is running 4.2.3 (specifically
> 2018051606 clean install last night).
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 17 May 2018, at 07:47, Ales Musil  wrote:
>
>
>
> On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
>
>> Dear All,
>>
>> Our vGPU installation is progressing, though the VM is failing to start.
>>
>> 2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm]
>> (vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process
>> failed (vm:943)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in
>> _startUnderlyingVm
>> self._run()
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in
>> _run
>> dom.createWithFlags(flags)
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py",
>> line 130, in wrapper
>> ret = f(*args, **kwargs)
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line
>> 92, in wrapper
>> return func(inst, *args, **kwargs)
>>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in
>> createWithFlags
>> if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
>> failed', dom=self)
>> libvirtError: Cannot get interface MTU on '': No such device
>>
>> That's the specific error, some other information. It seems the GPU
>> 'allocation' of uuid against the nvidia-xx mdev type is proceeding
>> correctly, and the device is being created by the VM instantiation but the
>> VM does not succeed in going up with this error. Any other logs or
>> information relevant to help diagnose?
>>
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of Oxford
>> e. cal...@well.ox.ac.uk
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>>
>>
> Hi Callum,
>
> can you share your version of the setup?
>
> Also do you use OVS switch type in the cluster?
>
> Regards,
> Ales.
>
>
> --
> ALES MUSIL
> INTERN - rhv network
> Red Hat EMEA 
>
> amu...@redhat.com   IM: amusil
> 
>
> 

[ovirt-users] Re: Gluster quorum

[Sahina Bose]

It doesn't look like the patch was applied. Still see the same error in
engine.log
"Error while refreshing brick statuses for volume 'volume1' of cluster
'C6220': null"\

Did you use engine-setup to upgrade? What's the version of ovirt-engine
currently installed?

On Thu, May 17, 2018 at 5:10 PM, Demeter Tibor  wrote:

> Hi,
>
> sure,
>
> Thank you for your time!
>
> R
> Tibor
>
> - 2018. máj.. 17., 12:19, Sahina Bose  írta:
>
> [+users]
>
> Can you provide the engine.log to see why the monitoring is not working
> here. thanks!
>
> On Wed, May 16, 2018 at 2:08 PM, Demeter Tibor 
> wrote:
>
>> Hi,
>>
>> Meanwhile, I did the upgrade engine, but the gluster state is same on my
>> first node.
>> I've attached some screenshot of my problem.
>>
>> Thanks
>>
>> Tibor
>>
>>
>>
>> - 2018. máj.. 16., 10:16, Demeter Tibor  írtaHi,
>>
>>
>> If 4.3.4 will release, i just have to remove the nightly repo and update
>> to stable?
>>
>> I'm sorry for my terrible English, I try to explain what was my problem
>> with update.
>> I'm upgraded from 4.1.8.
>>
>> I followed up the official hosted-engine update documentation, that was
>> not clear me, because it has referenced to a lot of old thing (i think).
>> https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide/
>> https://www.ovirt.org/documentation/how-to/hosted-
>> engine/#upgrade-hosted-engine
>>
>> Maybe it need to update, because I had a lot of question under upgrade
>> and I was not sure in all of necessary steps. For example, If I need to
>> installing the new, 4.2 repo on the hosts, then need to remove the old repo
>> from that?
>> Why I need to do a" yum update -y" on hosts, meanwhile there is an
>> "Updatehost" menu in the GUI? So, maybe it outdated.
>> Since upgrade hosted engine, and the first node, I have problems with
>> gluster. It seems to working fine if you check it from console "gluster
>> volume status, etc" but not on the Gui, because now it yellow, and the
>> brick reds in the first node.
>>
>> Previously I did a mistake with glusterfs, my gluster config was wrong. I
>> have corrected them, but it did not helped to me,gluster bricks are reds on
>> my first node yet
>>
>>
>> Now I try to upgrade to nightly, but I'm affraid, because it a living,
>> productive system, and I don't have downtime. I hope it will help me.
>>
>> Thanks for all,
>>
>> Regards,
>> Tibor Demeter
>>
>>
>>
>> - 2018. máj.. 16., 9:58, Sahina Bose  írta:
>>
>>
>>
>> On Wed, May 16, 2018 at 1:19 PM, Demeter Tibor 
>> wrote:
>>
>>> Hi,
>>>
>>> is it a different, unstable repo? I have a productive cluster, how is
>>> safe that?
>>> I don't have any experience with nightly build. How can I use this? It
>>> have to install to the engine VM or all of my hosts?
>>> Thanks in advance for help me..
>>>
>>
>> Only on the engine VM.
>>
>> Regarding stability - it passes CI so relatively stable, beyond that
>> there are no guarantees.
>>
>> What's the specific problem you're facing with update? Can you elaborate?
>>
>>
>>> Regards,
>>>
>>> Tibor
>>>
>>> - 2018. máj.. 15., 9:58, Demeter Tibor  írta:
>>>
>>> Hi,
>>>
>>> Could you explain how can I use this patch?
>>>
>>> R,
>>> Tibor
>>>
>>>
>>> - 2018. máj.. 14., 11:18, Demeter Tibor  írta:
>>>
>>> Hi,
>>>
>>> Sorry for my question, but can you tell me please how can I use this
>>> patch?
>>>
>>> Thanks,
>>> Regards,
>>> Tibor
>>> - 2018. máj.. 14., 10:47, Sahina Bose  írta:
>>>
>>>
>>>
>>> On Sat, May 12, 2018 at 1:14 PM, Demeter Tibor 
>>> wrote:
>>>
 Hi,

 Could someone help me please ? I can't finish my upgrade process.

>>>
>>> https://gerrit.ovirt.org/91164 should fix the error you're facing.
>>>
>>> Can you elaborate why this is affecting the upgrade process?
>>>
>>>
 Thanks
 R
 Tibor



 - 2018. máj.. 10., 12:51, Demeter Tibor  írta:

 Hi,

 I've attached the vdsm and supervdsm logs. But I don't have engine.log
 here, because that is on hosted engine vm. Should I send that ?

 Thank you

 Regards,

 Tibor
 - 2018. máj.. 10., 12:30, Sahina Bose  írta:

 There's a bug here. Can you log one attaching this engine.log and also
 vdsm.log & supervdsm.log from n3.itsmart.cloud

 On Thu, May 10, 2018 at 3:35 PM, Demeter Tibor 
 wrote:

> Hi,
>
> I found this:
>
>
> 2018-05-10 03:24:19,096+02 INFO  [org.ovirt.engine.core.
> vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand]
> (DefaultQuartzScheduler7) [43f4eaec] FINISH, 
> GetGlusterVolumeAdvancedDetailsVDSCommand,
> return: org.ovirt.engine.core.common.businessentities.gluster.
> GlusterVolumeAdvancedDetails@ca97448e, log 

[ovirt-users] Re: hosted-engine deploy not use FQDN

[Phillip Bailey]

Hi,

Have you attempted to complete setup without entering the FQDN? If it
fails, could you please provide logs?

If it completes successfully, you will need to edit the engine config [1]
before you'll be able to access the engine by its IP address.

-Phillip Bailey

[1]
https://www.ovirt.org/documentation/how-to/networking/changing-engine-hostname/#are-you-sure-you-need-this

On Thu, May 17, 2018 at 3:32 AM,  wrote:

> Hi
>
> I deploy hosted-engine by #hosted-engine --deploy,   but I do not use
> FQDN,  I want to visit engine directly by ip
>
> besides, I  have not  DNS server, I want to skip setup  Engine VM FQDN，
> because my project can not to setup /etc/hosts
>
>
>  Please provide the FQDN you would like to use for the engine appliance.
>   Note: This will be the FQDN of the engine VM you are now going
> to launch,
>   it should not point to the base host or to any other existing
> machine.
>   Engine VM FQDN: (leave it empty to skip):  []:
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Self-Hosted engine deploy fails but hosted-engine --vm-status shows engine in good health

[Sumit Bharadia]

found below in engine.log on engine VM

2018-05-17 11:03:57,739+01 ERROR
[org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring]
(EE-ManagedThreadFactory-engineScheduled-Thread-78) [6768004b] Exception::
org.springframework.dao.DataIntegrityViolationException:
CallableStatementCallback; SQL [{call insertvmdevice(?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?)}]; ERROR: insert or update on table "vm_device"
violates foreign key constraint "fk_vm_device_vm_static"
  Detail: Key (vm_id)=(114581bb-7fef-4b08-8e3c-85dd5a9e680b) is not present
in table "vm_static".
...
...
...
2018-05-17 11:03:59,957+01 ERROR
[org.ovirt.engine.core.bll.pm.FenceProxyLocator]
(EE-ManagedThreadFactory-engineScheduled-Thread-44) [2bf8b18f] Can not run
fence action on host 'ovirt', no suitable proxy host was found.
...
...
...
2018-05-17 11:20:00,093+01 ERROR
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient]
(EE-ManagedThreadFactory-engine-Thread-2) [1a833057] Exception during
connection
...
...
...
2018-05-17 11:20:00,386+01 ERROR
[org.ovirt.engine.core.vdsbroker.HostDevListByCapsVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-2) [1a833057] Command
'HostDevListByCapsVDSCommand(HostName = ovirt,
VdsIdAndVdsVDSCommandParametersBase:{hostId='1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99',
vds='Host[ovirt,1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99]'})' execution failed:
java.net.UnknownHostException: ovirt: Name or service not known
...
...
...
2018-05-17 11:20:03,287+01 ERROR
[org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient]
(EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Exception during
connection
2018-05-17 11:20:03,292+01 ERROR
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
(EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Unable to
RefreshCapabilities: UnknownHostException: ovirt
2018-05-17 11:20:03,294+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Command
'org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand'
return value
'org.ovirt.engine.core.vdsbroker.vdsbroker.VDSInfoReturn@46e3da89'
2018-05-17 11:20:03,294+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-14) [] HostName = ovirt
2018-05-17 11:20:03,297+01 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Command
'GetCapabilitiesAsyncVDSCommand(HostName = ovirt,
VdsIdAndVdsVDSCommandParametersBase:{hostId='1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99',
vds='Host[ovirt,1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99]'})' execution failed:
java.net.UnknownHostException: ovirt
2018-05-17 11:20:03,316+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-15) [] EVENT_ID:
VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt command
GetCapabilitiesAsyncVDS failed: Connection issue ovirt
2018-05-17 11:20:03,317+01 ERROR
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
(EE-ManagedThreadFactory-engineScheduled-Thread-15) [] Unable to
RefreshCapabilities: VDSNetworkException: VDSGenericException:
VDSNetworkException: Connection issue ovirt
...
...
...


and then above 5 error messages are keep repeating.

What does this mean? And how do I resolve this?



On 17 May 2018 at 12:59, Simone Tiraboschi  wrote:

>
>
> On Thu, May 17, 2018 at 12:37 PM, <03ce...@gmail.com> wrote:
>
>> I am setting up self-hosted engine (4.2) on centos 7.4.
>>
>> The setup runs all the way through and creates the local VM, but fails on
>> task "Wait for the local bootstrap VM to be down at engine eyes".
>>
>> But if I then run hosted-engine --vm-start, it comes back up and shows it
>> is in good health, but when I do an api call with curl, it shows me that
>> the host is in 'non responsive' state! I cannot deploy any VM on the engine
>> VM, the ssh connection fails.
>>
>> How and what could have caused it, where can i find more detailed
>> information related to this error/status of engine vm ?
>>
>
> you have setup logs in /var/log/ovirt-hosted-engine-setup
>
>
>>
>> Thanks
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

This is vdsm 4.19.45. I grepped the disk uuid in /var/log/sanlock.log 
but unfortunately no entry there...


El 2018-05-17 13:11, Benny Zlotnik escribió:

Which vdsm version are you using?

You can try looking for the image uuid in /var/log/sanlock.log

On Thu, May 17, 2018 at 2:40 PM,  wrote:


Thanks.

I've been able to see the line in the log, however, the format
differs slightly from yours.

  2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer] Calling 'Volume.getInfo' in bridge with
{u'storagepoolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63',
u'imageID': u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID':
u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID':
u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556)
2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer] Return 'Volume.getInfo' in bridge with
{'status': 'OK', 'domain': '1876ab86-216f-4a37-a36b-2b5d99fcaad0',
'voltype': 'INTERNAL', 'description': 'None', 'parent':
'ea9a0182-329f-4b8f-abe3-e894de95dac0', 'format': 'COW',
'generation': 1, 'image': 'b4013aba-a936-4a54-bb14-670d3a8b7c38',
'ctime': '1526470759', 'disktype': '2', 'legality': 'LEGAL',
'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool':
'', 'capacity': '21474836480', 'uuid':
u'c2cfbb02-9981-4fb7-baea-7257a824145c', 'truesize': '1073741824',
'type': 'SPARSE', 'lease': {'owners': [8], 'version': 1L}}
(__init__:582)

As you can see, there's no path field there.

How should I procceed?

El 2018-05-17 12:01, Benny Zlotnik escribió:
vdsm-client replaces vdsClient, take a look
here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html
[1]
[4]

On Thu, May 17, 2018 at 1:57 PM,  wrote:

The issue is present in the logs:

  2018-05-17 11:50:44,822+01 INFO 
[org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller]
(DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e]
Command CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the
volume lease is not FREE - the job is running

I tried setting the log level to debug but it seems I have not a
vdsm-client command. All I have is a vdsm-tool command. Is it
equivalent?

Thanks

El 2018-05-17 11:49, Benny Zlotnik escribió:
By the way, please verify it's the same issue, you should see "the
volume lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik

wrote:

I see because I am on debug level, you need to enable it in order
to
see 

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [2]
[1]

[3]

On Thu, 17 May 2018, 13:10 ,  wrote:

Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry
I can
find grepping by Volume.getInfo is like this:

   2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer]
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)

I cannot find a line like yours... any other way on how to obtain
those
parameters. This is an iSCSI based storage FWIW (both source and
destination of the movement).

Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:
In the vdsm log you will find the volumeInfo log which looks
like
this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK',
'domain':
'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',
'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':



 u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e




b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',


'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0. [3] [2]



[1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease


Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource



5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0


for 2,9,5049

Then you can use this command to unlock, the pid in this case
is 5049

sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik

wrote:

I believe you've hit this
bug: 

[ovirt-users] Re: Hosts : Upgrade failed - 4.2.3

[Nicolas Ecarnot]

Le 16/05/2018 à 12:55, Fred Rolland a écrit :

It looks you still have 4.1 repos...


Yes.

I thought Ansible was in charge of disabling oldest repos.

Is does not seem to be the case, is it?

--
Nicolas ECARNOT
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: ovirt 4.2 failed deploy

[Phillip Bailey]

Hi Alex,

I'm sorry we weren't able to help you get 4.2 up and running in time.
Definitely let us know if you encounter any issues on your next attempt.
Your feedback is greatly appreciated!

-Phillip Bailey

On Wed, May 16, 2018 at 9:36 AM, Alex K  wrote:

> Hi,
>
> I am sorry I don't have this setup available anymore.
> I had to provide a quick solution and went with 4.1 version.
>
> I will see if I can reproduce this on next build.
>
> Thanx,
> Alex
>
> On Wed, May 16, 2018 at 5:38 AM, Phillip Bailey 
> wrote:
>
>> Alex,
>>
>> I haven't run into any issues with ovirt-ha-agent. I'm adding Simone who
>> may have a better idea of what could be causing the problem. Could you
>> provide any logs you have available from that deployment? Also, could you
>> please run "journalctl -u ovirt-ha-agent" on that host and provide the
>> output?
>>
>> Thanks!
>>
>> -Phillip Bailey
>>
>> On Tue, May 15, 2018 at 9:22 AM, Alex K  wrote:
>>
>>> Hi Philip,
>>>
>>> I finally was not able to complete it.
>>> The ovirt ha agent at host was not starting for some reason.
>>> It could be because I ran a hosted-engine-cleanup earlier.
>>> So I need to repeat from scratch to be able to reproduce/verify.
>>>
>>> Alex
>>>
>>>
>>>
>>> On Tue, May 15, 2018 at 2:48 PM, Phillip Bailey 
>>> wrote:
>>>
 Alex,

 I'm glad to hear you were able to get everything running! Please let us
 know if you have any issues going forward.

 Best regards,

 -Phillip Bailey

 On Tue, May 15, 2018 at 4:59 AM, Alex K 
 wrote:

> I overcame this with:
>
> run at host:
>
> /usr/sbin/ovirt-hosted-engine-cleanup
>
> Redeployed then engine
> engine-setup
>
> This time was ok.
>
> Thanx,
> Alex
>
> On Tue, May 15, 2018 at 10:51 AM, Alex K 
> wrote:
>
>> Hi,
>>
>> Thanx for the feedback.
>>
>> *getent ahostsv4 v0.mydomain*
>>
>> gives:
>>
>> 172.16.30.10STREAM v0
>> 172.16.30.10DGRAM
>> 172.16.30.10RAW
>>
>> which means that
>>
>> *getent ahostsv4 v0.mydomain | grep v0.mydomain*
>>
>> gives null
>>
>> I overcame this by using the flag *--noansible* to proceed with the
>> python way and it did succeed.
>>
>> Now I am stuck at engine-setup create CA step. It never finishes and
>> I see several errors at setup log (grep -iE 'error|fail' ):
>>
>> 2018-05-15 03:40:03,749-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-05-15 03:40:03,751-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV CORE/failOnPrioOverride=bool:'True'
>> 2018-05-15 03:40:04,338-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-05-15 03:40:04,339-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV CORE/failOnPrioOverride=bool:'True'
>> 2018-05-15 03:40:04,532-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV OVESETUP_CORE/failOnDulicatedC
>> onstant=bool:'False'
>> 2018-05-15 03:40:04,809-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV OVESETUP_PROVISIONING/postgres
>> ExtraConfigItems=tuple:'({'ok':  at
>> 0x7ff1630b9578>, 'check_on_use': True, 'needed_on_create': True, 'key':
>> 'autovacuum_vacuum_scale_factor', 'expected': 0.01, 'error_msg':
>> '{key} required to be at most {expected}'}, {'ok':  at
>> 0x7ff1630b9a28>, 'check_on_use': True, 'needed_on_create': True, 'key':
>> 'autovacuum_analyze_scale_factor', 'expected': 0.075, 'error_msg':
>> '{key} required to be at most {expected}'}, {'ok':  at
>> 0x7ff163099410>, 'check_on_use': True, 'needed_on_create': True, 'key':
>> 'autovacuum_max_workers', 'expected': 6, 'error_msg': '{key} required to 
>> be
>> at least {expected}'}, {'ok':  at 0x7ff163099488>,
>> 'check_on_use': True, 'needeOperationalError: FATAL:  *password
>> authentication failed for user "engine"*
>> FATAL:  password authentication failed for user "engine"
>> 2018-05-15 03:40:11,408-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-05-15 03:40:11,417-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV CORE/failOnPrioOverride=bool:'True'
>> 2018-05-15 03:40:11,441-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV OVESETUP_CORE/failOnDulicatedC
>> onstant=bool:'False'
>> 2018-05-15 03:40:11,457-0400 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV OVESETUP_PROVISIONING/postgres
>> ExtraConfigItems=tuple:'({'ok':  at
>> 0x7ff1630b9578>, 'check_on_use': True, 'needed_on_create': True, 'key':
>> 'autovacuum_vacuum_scale_factor', 'expected': 0.01, 'error_msg':
>> '{key} required to 

[ovirt-users] Re: VM's disk stuck in migrating state

[Benny Zlotnik]

Which vdsm version are you using?

You can try looking for the image uuid in /var/log/sanlock.log

On Thu, May 17, 2018 at 2:40 PM,  wrote:

> Thanks.
>
> I've been able to see the line in the log, however, the format differs
> slightly from yours.
>
>   2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
> Calling 'Volume.getInfo' in bridge with {u'storagepoolID':
> u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'imageID':
> u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID':
> u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID':
> u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556)
> 2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
> Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
> '1876ab86-216f-4a37-a36b-2b5d99fcaad0', 'voltype': 'INTERNAL',
> 'description': 'None', 'parent': 'ea9a0182-329f-4b8f-abe3-e894de95dac0',
> 'format': 'COW', 'generation': 1, 'image': 
> 'b4013aba-a936-4a54-bb14-670d3a8b7c38',
> 'ctime': '1526470759', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0',
> 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity':
> '21474836480', 'uuid': u'c2cfbb02-9981-4fb7-baea-7257a824145c',
> 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [8],
> 'version': 1L}} (__init__:582)
>
> As you can see, there's no path field there.
>
> How should I procceed?
>
> El 2018-05-17 12:01, Benny Zlotnik escribió:
>
>> vdsm-client replaces vdsClient, take a look
>> here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html
>> [4]
>>
>> On Thu, May 17, 2018 at 1:57 PM,  wrote:
>>
>> The issue is present in the logs:
>>>
>>>   2018-05-17 11:50:44,822+01 INFO
>>> [org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller]
>>> (DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e]
>>> Command CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the
>>> volume lease is not FREE - the job is running
>>>
>>> I tried setting the log level to debug but it seems I have not a
>>> vdsm-client command. All I have is a vdsm-tool command. Is it
>>> equivalent?
>>>
>>> Thanks
>>>
>>> El 2018-05-17 11:49, Benny Zlotnik escribió:
>>> By the way, please verify it's the same issue, you should see "the
>>> volume lease is not FREE - the job is running" in the engine log
>>>
>>> On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik
>>> 
>>> wrote:
>>>
>>> I see because I am on debug level, you need to enable it in order
>>> to
>>> see
>>>
>>> https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [1]
>>>
>>> [3]
>>>
>>> On Thu, 17 May 2018, 13:10 ,  wrote:
>>>
>>> Hi,
>>>
>>> Thanks. I've checked vdsm logs on all my hosts but the only entry
>>> I can
>>> find grepping by Volume.getInfo is like this:
>>>
>>>2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
>>> [jsonrpc.JsonRpcServer]
>>> RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)
>>>
>>> I cannot find a line like yours... any other way on how to obtain
>>> those
>>> parameters. This is an iSCSI based storage FWIW (both source and
>>> destination of the movement).
>>>
>>> Thanks.
>>>
>>> El 2018-05-17 10:01, Benny Zlotnik escribió:
>>> In the vdsm log you will find the volumeInfo log which looks
>>> like
>>> this:
>>>
>>> 2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)
>>> [jsonrpc.JsonRpcServer]
>>> Return 'Volume.getInfo' in bridge with {'status': 'OK',
>>> 'domain':
>>> '5c4d2216-
>>> 2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',
>>> 'description':
>>> '{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
>>> '---
>>> -', 'format': 'RAW', 'generation': 3, 'image':
>>> 'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
>>> 'disktype': 'DATA', '
>>> legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
>>> 'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
>>> u'7190913d-320c-4fc9-
>>> a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
>>> {'path':
>>>
>>
>>  u'/rhev/data-center/mnt/10.35.0.233:_root_storage__
>> domains_sd1/5c4d2216-2e
>>
>>
>>>
>>
>> b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-
>> 6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',
>>
>> 'owners': [1], 'version': 8L, 'o
>>> ffset': 0}} (__init__:355)
>>>
>>> The lease path in my case is:
>>> /rhev/data-center/mnt/10.35.0. [2]
>>>
>>
>>
>> [1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5
>> f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/71909
>> 13d-320c-4fc9-a5b3-c55b26aa30f4.lease
>>
>> Then you can look in /var/log/sanlock.log
>>>
>>> 2018-05-17 11:35:18 243132 [14847]: s2:r9 resource
>>>
>>
>>
>> 5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-
>> a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_
>> storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/
>> images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-
>> 

[ovirt-users] Re: Self-Hosted engine deploy fails but hosted-engine --vm-status shows engine in good health

[Simone Tiraboschi]

On Thu, May 17, 2018 at 12:37 PM, <03ce...@gmail.com> wrote:

> I am setting up self-hosted engine (4.2) on centos 7.4.
>
> The setup runs all the way through and creates the local VM, but fails on
> task "Wait for the local bootstrap VM to be down at engine eyes".
>
> But if I then run hosted-engine --vm-start, it comes back up and shows it
> is in good health, but when I do an api call with curl, it shows me that
> the host is in 'non responsive' state! I cannot deploy any VM on the engine
> VM, the ssh connection fails.
>
> How and what could have caused it, where can i find more detailed
> information related to this error/status of engine vm ?
>

you have setup logs in /var/log/ovirt-hosted-engine-setup


>
> Thanks
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

Thanks.

I've been able to see the line in the log, however, the format differs 
slightly from yours.


  2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer] 
Calling 'Volume.getInfo' in bridge with {u'storagepoolID': 
u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'imageID': 
u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID': 
u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID': 
u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556)
2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer] 
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain': 
'1876ab86-216f-4a37-a36b-2b5d99fcaad0', 'voltype': 'INTERNAL', 
'description': 'None', 'parent': 'ea9a0182-329f-4b8f-abe3-e894de95dac0', 
'format': 'COW', 'generation': 1, 'image': 
'b4013aba-a936-4a54-bb14-670d3a8b7c38', 'ctime': '1526470759', 
'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': 
'1073741824', 'children': [], 'pool': '', 'capacity': '21474836480', 
'uuid': u'c2cfbb02-9981-4fb7-baea-7257a824145c', 'truesize': 
'1073741824', 'type': 'SPARSE', 'lease': {'owners': [8], 'version': 1L}} 
(__init__:582)


As you can see, there's no path field there.

How should I procceed?

El 2018-05-17 12:01, Benny Zlotnik escribió:

vdsm-client replaces vdsClient, take a look
here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html
[4]

On Thu, May 17, 2018 at 1:57 PM,  wrote:


The issue is present in the logs:

  2018-05-17 11:50:44,822+01 INFO 
[org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller]
(DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e]
Command CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the
volume lease is not FREE - the job is running

I tried setting the log level to debug but it seems I have not a
vdsm-client command. All I have is a vdsm-tool command. Is it
equivalent?

Thanks

El 2018-05-17 11:49, Benny Zlotnik escribió:
By the way, please verify it's the same issue, you should see "the
volume lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik

wrote:

I see because I am on debug level, you need to enable it in order
to
see 

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [1]
[3]

On Thu, 17 May 2018, 13:10 ,  wrote:

Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry
I can
find grepping by Volume.getInfo is like this:

   2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer]
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)

I cannot find a line like yours... any other way on how to obtain
those
parameters. This is an iSCSI based storage FWIW (both source and
destination of the movement).

Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:
In the vdsm log you will find the volumeInfo log which looks
like
this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)
[jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK',
'domain':
'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',
'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':


 
u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e







b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',


'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0. [2]



[1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease


Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource



5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0


for 2,9,5049

Then you can use this command to unlock, the pid in this case
is 5049

sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik

wrote:

I believe you've hit this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [3] [2]


 [1]


You can try to release the lease manually using the

 sanlock client


command (there's an example in the comments on the bug), 
once the lease is free the job will fail and the disk can be

 unlock


On Thu, May 17, 2018 at 11:05 AM,  wrote:

[ovirt-users] Re: ovirt engine frequently rebooting/changing host

[Yedidyah Bar David]

On Thu, May 17, 2018 at 1:34 PM, Bernhard Dick  wrote:
> Hi,
>
> Am 17.05.2018 um 07:30 schrieb Yedidyah Bar David:
>>
>> On Wed, May 16, 2018 at 5:38 PM, Bernhard Dick  wrote:
>>>
>>> Hi,
>>>
>>> Am 07.05.2018 um 11:23 schrieb Yedidyah Bar David:


 [...]
>
>
> It seems to work quite well, but after some hours I get many status
> update
> mails from the ovirt engine which are either going to EngineStop or
> EngeineForceStop. Sometimes the host where the engine runs is switched.
> After some of those reboots there is silence for some hours before it
> is
> starting over. Can you tell me where I should look at to fix that
> problem?



 You can check, on all hosts, /var/log/ovirt-hosted-engine-ha/* .
>>>
>>>
>>> thanks, that helped. Our gateway does not always respond to ping-requests
>>> so
>>> I changed the penality score accordingly.
>>
>>
>> How? In the code?
>
> I changed the value for "gateway-score-penalty" in
> /etc/ovirt-hosted-engine-ha/agent.conf .

I see. Adding Martin for review.
-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Upgrade from 4.1.9 to 4.2.3 fails to upgrade postgresql

[Yedidyah Bar David]

Thanks, Marcelo and Ian,

I already got a setup log:

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

Will fix soon.

Sorry.

On Thu, May 17, 2018 at 12:50 PM, Marcelo Leandro  wrote:
> Hello,
> I had the same error, but for me only worked when I created a new
> instalation , run engine-setup for create a new database , after I runed
> engine-cleanup to clear the instalation and restore a full backup  , all the
> language of SO is english.
>
> Marcelo Leandro
>
> Em qui, 17 de mai de 2018 06:14, Yedidyah Bar David 
> escreveu:
>>
>> On Thu, May 17, 2018 at 1:32 AM, Ian Fraser  wrote:
>> > Hi,
>> >
>> > Could someone please provide advice on a production oVirt instance that
>> > fails to upgrade to 4.2.3?
>> >
>> >
>> >
>> > Engine and hosts are all running CentOS 7
>> >
>> >
>> >
>> > As per the upgrade instructions in the release notes I run:
>> >
>> > # yum install
>> > http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm
>> >
>> > # yum update "ovirt-*-setup*"
>> >
>> > # engine-setup
>> >
>> >
>> >
>> > Then I answer the questions and it fails with:
>> >
>> > …
>> >
>> > [ INFO  ] Upgrading PostgreSQL
>> >
>> > [ ERROR ] Failed to execute stage 'Misc configuration': Command
>> > '/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to
>> > execute
>> >
>> > [ INFO  ] Yum Performing yum transaction rollback
>> >
>> > [ INFO  ] Rolling back to the previous PostgreSQL instance (postgresql).
>> >
>> > [ INFO  ] Stage: Clean up
>> >
>> >   Log file is located at
>> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20180516231622-3giicb.log
>> >
>> > [ INFO  ] Generating answer file
>> > '/var/lib/ovirt-engine/setup/answers/20180516231735-setup.conf'
>> >
>> > [ INFO  ] Stage: Pre-termination
>> >
>> > [ INFO  ] Stage: Termination
>> >
>> > [ ERROR ] Execution of setup failed
>> >
>> >
>> >
>> >
>> >
>> > When I check  /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log:
>> >
>> >
>> >
>> > Performing Consistency Checks
>> >
>> > -
>> >
>> > Checking cluster versions   ok
>> >
>> > Checking database user is the install user  ok
>> >
>> > Checking database connection settings   ok
>> >
>> > Checking for prepared transactions  ok
>> >
>> > Checking for reg* system OID user data typesok
>> >
>> > Checking for contrib/isn with bigint-passing mismatch   ok
>> >
>> > Checking for invalid "line" user columnsok
>> >
>> > Creating dump of global objects ok
>> >
>> > Creating dump of database schemas
>> >
>> >   engine
>> >
>> >   ovirt_engine_history
>> >
>> >   postgres
>> >
>> >   template1
>> >
>> > ok
>> >
>> >
>> >
>> > lc_collate values for database "postgres" do not match:  old
>> > "en_GB.UTF-8",
>> > new "en_US.UTF-8"
>>
>> Sounds again like:
>>
>> https://bugzilla.redhat.com/1528371
>>
>> That's really weird.
>>
>> Can you please check/share engine-setup log, so we can see that we
>> actually passed the correct options to postgresql-setup?
>>
>> Also, if at all possible, please provide complete reproduction steps.
>>
>> See this for what I personally used to verify the fix for above bug,
>> at the time:
>>
>>
>> https://gerrit.ovirt.org/#/c/88234/2/common/upgrade-suites/test-scenarios-before-upgrade/001_initialize_engine.py
>>
>> But can't be sure it reproduces the original bug (although the error
>> was the same), nor if your case is different and how.
>>
>> Thanks!
>>
>> >
>> > Failure, exiting
>> >
>> >
>> >
>> >
>> >
>> > I have tried running the script here:
>> > https://gist.github.com/turboladen/6790847 and rerunning engine-setup
>> > but it
>> > fails with the same error.
>> >
>> >
>> >
>> > Can anyone offer any other suggestions?
>> >
>> >
>> >
>> > Best regards
>> >
>> >
>> >
>> > Ian Fraser
>> >
>> >
>> >
>> > Systems Administrator | Agency Sector Management (UK) Limited |
>> > www.asm.org.uk
>> >
>> > [t] +44 (0)1784 242200 | [f] +44 (0)1784 242012 | [e]
>> > ian.fra...@asm.org.uk
>> >
>> > Registered in England No. 2053849 | Registered address: Ashford House
>> > 41-45
>> > Church Road  Ashford  Middx  TW15 2TQ
>> >
>> > Follow us on twitter @asmukltd
>> >
>> >
>> >
>> >
>> > ___
>> > Users mailing list -- users@ovirt.org
>> > To unsubscribe send an email to users-le...@ovirt.org
>> >
>>
>>
>>
>> --
>> Didi
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org



-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

The issue is present in the logs:

  2018-05-17 11:50:44,822+01 INFO  
[org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller] 
(DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e] Command 
CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the volume lease is 
not FREE - the job is running


I tried setting the log level to debug but it seems I have not a 
vdsm-client command. All I have is a vdsm-tool command. Is it 
equivalent?


Thanks

El 2018-05-17 11:49, Benny Zlotnik escribió:

By the way, please verify it's the same issue, you should see "the
volume lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik 
wrote:


I see because I am on debug level, you need to enable it in order to
see 

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [3]

On Thu, 17 May 2018, 13:10 ,  wrote:


Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry
I can
find grepping by Volume.getInfo is like this:

   2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer]
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)

I cannot find a line like yours... any other way on how to obtain
those
parameters. This is an iSCSI based storage FWIW (both source and
destination of the movement).

Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:

In the vdsm log you will find the volumeInfo log which looks

like

this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6)

[jsonrpc.JsonRpcServer]

Return 'Volume.getInfo' in bridge with {'status': 'OK',

'domain':

'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL',

'description':

'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':






u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e







b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',

'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0.





[1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease


Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource






5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0

for 2,9,5049

Then you can use this command to unlock, the pid in this case

is 5049


sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik



wrote:


I believe you've hit this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [2]

[1]


You can try to release the lease manually using the

sanlock client

command (there's an example in the comments on the bug), 
once the lease is free the job will fail and the disk can be

unlock


On Thu, May 17, 2018 at 11:05 AM,  wrote:


Hi,

We're running oVirt 4.1.9 (I know it's not the recommended
version, but we can't upgrade yet) and recently we had an

issue

with a Storage Domain while a VM was moving a disk. The

Storage

Domain went down for a few minutes, then it got back.

However, the disk's state has stuck in a 'Migrating: 10%'

state

(see ss-2.png).

I run the 'unlock_entity.sh' script to try to unlock the

disk,

with these parameters:

 # PGPASSWORD=...
/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t

disk -u

engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38

The disk's state changed to 'OK', but the actual state still
states it's migrating (see ss-1.png).

Calling the script with -t all doesn't make a difference

either.


Currently, the disk is unmanageable: cannot be deactivated,

moved

or copied, as it says there's a copying operation running

already.


Could someone provide a way to unlock this disk? I don't mind
modifying a value directly into the database, I just need the
copying process cancelled.

Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org




Links:
--
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [2]




Links:
--
[1] http://10.35.0.
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
[3] https://www.ovirt.org/develop/developer-guide/vdsm/log-files/

[ovirt-users] Re: VM's disk stuck in migrating state

[Benny Zlotnik]

By the way, please verify it's the same issue, you should see "the volume
lease is not FREE - the job is running" in the engine log

On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik  wrote:

> I see because I am on debug level, you need to enable it in order to see
>
> https://www.ovirt.org/develop/developer-guide/vdsm/log-files/
>
> On Thu, 17 May 2018, 13:10 ,  wrote:
>
>> Hi,
>>
>> Thanks. I've checked vdsm logs on all my hosts but the only entry I can
>> find grepping by Volume.getInfo is like this:
>>
>>2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
>> RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)
>>
>> I cannot find a line like yours... any other way on how to obtain those
>> parameters. This is an iSCSI based storage FWIW (both source and
>> destination of the movement).
>>
>> Thanks.
>>
>> El 2018-05-17 10:01, Benny Zlotnik escribió:
>> > In the vdsm log you will find the volumeInfo log which looks like
>> > this:
>> >
>> > 2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
>> > Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
>> > '5c4d2216-
>> > 2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL', 'description':
>> > '{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
>> > '---
>> > -', 'format': 'RAW', 'generation': 3, 'image':
>> > 'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
>> > 'disktype': 'DATA', '
>> > legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
>> > 'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
>> > u'7190913d-320c-4fc9-
>> > a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
>> > {'path':
>> > u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_
>> sd1/5c4d2216-2e
>> > b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-
>> b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',
>> > 'owners': [1], 'version': 8L, 'o
>> > ffset': 0}} (__init__:355)
>> >
>> > The lease path in my case is:
>> > /rhev/data-center/mnt/10.35.0.233:_root_storage__domains_
>> sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-
>> fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease
>> >
>> > Then you can look in /var/log/sanlock.log
>> >
>> > 2018-05-17 11:35:18 243132 [14847]: s2:r9 resource
>> > 5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-
>> 4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_
>> root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-
>> d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/
>> 7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0
>> > for 2,9,5049
>> >
>> > Then you can use this command to unlock, the pid in this case is 5049
>> >
>> > sanlock client release -r RESOURCE -p pid
>> >
>> > On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik 
>> > wrote:
>> >
>> >> I believe you've hit this
>> >> bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [1]
>> >>
>> >> You can try to release the lease manually using the sanlock client
>> >> command (there's an example in the comments on the bug),
>> >> once the lease is free the job will fail and the disk can be unlock
>> >>
>> >> On Thu, May 17, 2018 at 11:05 AM,  wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> We're running oVirt 4.1.9 (I know it's not the recommended
>> >>> version, but we can't upgrade yet) and recently we had an issue
>> >>> with a Storage Domain while a VM was moving a disk. The Storage
>> >>> Domain went down for a few minutes, then it got back.
>> >>>
>> >>> However, the disk's state has stuck in a 'Migrating: 10%' state
>> >>> (see ss-2.png).
>> >>>
>> >>> I run the 'unlock_entity.sh' script to try to unlock the disk,
>> >>> with these parameters:
>> >>>
>> >>>  # PGPASSWORD=...
>> >>> /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t disk -u
>> >>> engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38
>> >>>
>> >>> The disk's state changed to 'OK', but the actual state still
>> >>> states it's migrating (see ss-1.png).
>> >>>
>> >>> Calling the script with -t all doesn't make a difference either.
>> >>>
>> >>> Currently, the disk is unmanageable: cannot be deactivated, moved
>> >>> or copied, as it says there's a copying operation running already.
>> >>>
>> >>> Could someone provide a way to unlock this disk? I don't mind
>> >>> modifying a value directly into the database, I just need the
>> >>> copying process cancelled.
>> >>>
>> >>> Thanks.
>> >>> ___
>> >>> Users mailing list -- users@ovirt.org
>> >>> To unsubscribe send an email to users-le...@ovirt.org
>> >
>> >
>> >
>> > Links:
>> > --
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Self-Hosted engine deploy fails but hosted-engine --vm-status shows engine in good health

[03ce007]

I am setting up self-hosted engine (4.2) on centos 7.4. 

The setup runs all the way through and creates the local VM, but fails on task 
"Wait for the local bootstrap VM to be down at engine eyes". 

But if I then run hosted-engine --vm-start, it comes back up and shows it is in 
good health, but when I do an api call with curl, it shows me that the host is 
in 'non responsive' state! I cannot deploy any VM on the engine VM, the ssh 
connection fails. 

How and what could have caused it, where can i find more detailed information 
related to this error/status of engine vm ?

Thanks
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: ovirt engine frequently rebooting/changing host

[Bernhard Dick]

Hi,

Am 17.05.2018 um 07:30 schrieb Yedidyah Bar David:

On Wed, May 16, 2018 at 5:38 PM, Bernhard Dick  wrote:

Hi,

Am 07.05.2018 um 11:23 schrieb Yedidyah Bar David:


[...]


It seems to work quite well, but after some hours I get many status
update
mails from the ovirt engine which are either going to EngineStop or
EngeineForceStop. Sometimes the host where the engine runs is switched.
After some of those reboots there is silence for some hours before it is
starting over. Can you tell me where I should look at to fix that
problem?



You can check, on all hosts, /var/log/ovirt-hosted-engine-ha/* .


thanks, that helped. Our gateway does not always respond to ping-requests so
I changed the penality score accordingly.


How? In the code?
I changed the value for "gateway-score-penalty" in 
/etc/ovirt-hosted-engine-ha/agent.conf .


  Regards
Bernhard
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[Benny Zlotnik]

I see because I am on debug level, you need to enable it in order to see

https://www.ovirt.org/develop/developer-guide/vdsm/log-files/

On Thu, 17 May 2018, 13:10 ,  wrote:

> Hi,
>
> Thanks. I've checked vdsm logs on all my hosts but the only entry I can
> find grepping by Volume.getInfo is like this:
>
>2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
> RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)
>
> I cannot find a line like yours... any other way on how to obtain those
> parameters. This is an iSCSI based storage FWIW (both source and
> destination of the movement).
>
> Thanks.
>
> El 2018-05-17 10:01, Benny Zlotnik escribió:
> > In the vdsm log you will find the volumeInfo log which looks like
> > this:
> >
> > 2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
> > Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
> > '5c4d2216-
> > 2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL', 'description':
> > '{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
> > '---
> > -', 'format': 'RAW', 'generation': 3, 'image':
> > 'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
> > 'disktype': 'DATA', '
> > legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
> > 'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
> > u'7190913d-320c-4fc9-
> > a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
> > {'path':
> > u'/rhev/data-center/mnt/10.35.0.233:
> _root_storage__domains_sd1/5c4d2216-2e
> >
> b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',
> > 'owners': [1], 'version': 8L, 'o
> > ffset': 0}} (__init__:355)
> >
> > The lease path in my case is:
> > /rhev/data-center/mnt/10.35.0.
> 233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease
> >
> > Then you can look in /var/log/sanlock.log
> >
> > 2018-05-17 11:35:18 243132 [14847]: s2:r9 resource
> >
> 5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:
> _root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0
> > for 2,9,5049
> >
> > Then you can use this command to unlock, the pid in this case is 5049
> >
> > sanlock client release -r RESOURCE -p pid
> >
> > On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik 
> > wrote:
> >
> >> I believe you've hit this
> >> bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [1]
> >>
> >> You can try to release the lease manually using the sanlock client
> >> command (there's an example in the comments on the bug),
> >> once the lease is free the job will fail and the disk can be unlock
> >>
> >> On Thu, May 17, 2018 at 11:05 AM,  wrote:
> >>
> >>> Hi,
> >>>
> >>> We're running oVirt 4.1.9 (I know it's not the recommended
> >>> version, but we can't upgrade yet) and recently we had an issue
> >>> with a Storage Domain while a VM was moving a disk. The Storage
> >>> Domain went down for a few minutes, then it got back.
> >>>
> >>> However, the disk's state has stuck in a 'Migrating: 10%' state
> >>> (see ss-2.png).
> >>>
> >>> I run the 'unlock_entity.sh' script to try to unlock the disk,
> >>> with these parameters:
> >>>
> >>>  # PGPASSWORD=...
> >>> /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t disk -u
> >>> engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38
> >>>
> >>> The disk's state changed to 'OK', but the actual state still
> >>> states it's migrating (see ss-1.png).
> >>>
> >>> Calling the script with -t all doesn't make a difference either.
> >>>
> >>> Currently, the disk is unmanageable: cannot be deactivated, moved
> >>> or copied, as it says there's a copying operation running already.
> >>>
> >>> Could someone provide a way to unlock this disk? I don't mind
> >>> modifying a value directly into the database, I just need the
> >>> copying process cancelled.
> >>>
> >>> Thanks.
> >>> ___
> >>> Users mailing list -- users@ovirt.org
> >>> To unsubscribe send an email to users-le...@ovirt.org
> >
> >
> >
> > Links:
> > --
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Gluster quorum

[Sahina Bose]

[+users]

Can you provide the engine.log to see why the monitoring is not working
here. thanks!

On Wed, May 16, 2018 at 2:08 PM, Demeter Tibor  wrote:

> Hi,
>
> Meanwhile, I did the upgrade engine, but the gluster state is same on my
> first node.
> I've attached some screenshot of my problem.
>
> Thanks
>
> Tibor
>
>
>
> - 2018. máj.. 16., 10:16, Demeter Tibor  írtaHi,
>
>
> If 4.3.4 will release, i just have to remove the nightly repo and update
> to stable?
>
> I'm sorry for my terrible English, I try to explain what was my problem
> with update.
> I'm upgraded from 4.1.8.
>
> I followed up the official hosted-engine update documentation, that was
> not clear me, because it has referenced to a lot of old thing (i think).
> https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide/
> https://www.ovirt.org/documentation/how-to/hosted-
> engine/#upgrade-hosted-engine
>
> Maybe it need to update, because I had a lot of question under upgrade and
> I was not sure in all of necessary steps. For example, If I need to
> installing the new, 4.2 repo on the hosts, then need to remove the old repo
> from that?
> Why I need to do a" yum update -y" on hosts, meanwhile there is an
> "Updatehost" menu in the GUI? So, maybe it outdated.
> Since upgrade hosted engine, and the first node, I have problems with
> gluster. It seems to working fine if you check it from console "gluster
> volume status, etc" but not on the Gui, because now it yellow, and the
> brick reds in the first node.
>
> Previously I did a mistake with glusterfs, my gluster config was wrong. I
> have corrected them, but it did not helped to me,gluster bricks are reds on
> my first node yet
>
>
> Now I try to upgrade to nightly, but I'm affraid, because it a living,
> productive system, and I don't have downtime. I hope it will help me.
>
> Thanks for all,
>
> Regards,
> Tibor Demeter
>
>
>
> - 2018. máj.. 16., 9:58, Sahina Bose  írta:
>
>
>
> On Wed, May 16, 2018 at 1:19 PM, Demeter Tibor 
> wrote:
>
>> Hi,
>>
>> is it a different, unstable repo? I have a productive cluster, how is
>> safe that?
>> I don't have any experience with nightly build. How can I use this? It
>> have to install to the engine VM or all of my hosts?
>> Thanks in advance for help me..
>>
>
> Only on the engine VM.
>
> Regarding stability - it passes CI so relatively stable, beyond that there
> are no guarantees.
>
> What's the specific problem you're facing with update? Can you elaborate?
>
>
>> Regards,
>>
>> Tibor
>>
>> - 2018. máj.. 15., 9:58, Demeter Tibor  írta:
>>
>> Hi,
>>
>> Could you explain how can I use this patch?
>>
>> R,
>> Tibor
>>
>>
>> - 2018. máj.. 14., 11:18, Demeter Tibor  írta:
>>
>> Hi,
>>
>> Sorry for my question, but can you tell me please how can I use this
>> patch?
>>
>> Thanks,
>> Regards,
>> Tibor
>> - 2018. máj.. 14., 10:47, Sahina Bose  írta:
>>
>>
>>
>> On Sat, May 12, 2018 at 1:14 PM, Demeter Tibor 
>> wrote:
>>
>>> Hi,
>>>
>>> Could someone help me please ? I can't finish my upgrade process.
>>>
>>
>> https://gerrit.ovirt.org/91164 should fix the error you're facing.
>>
>> Can you elaborate why this is affecting the upgrade process?
>>
>>
>>> Thanks
>>> R
>>> Tibor
>>>
>>>
>>>
>>> - 2018. máj.. 10., 12:51, Demeter Tibor  írta:
>>>
>>> Hi,
>>>
>>> I've attached the vdsm and supervdsm logs. But I don't have engine.log
>>> here, because that is on hosted engine vm. Should I send that ?
>>>
>>> Thank you
>>>
>>> Regards,
>>>
>>> Tibor
>>> - 2018. máj.. 10., 12:30, Sahina Bose  írta:
>>>
>>> There's a bug here. Can you log one attaching this engine.log and also
>>> vdsm.log & supervdsm.log from n3.itsmart.cloud
>>>
>>> On Thu, May 10, 2018 at 3:35 PM, Demeter Tibor 
>>> wrote:
>>>
 Hi,

 I found this:


 2018-05-10 03:24:19,096+02 INFO  [org.ovirt.engine.core.
 vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand]
 (DefaultQuartzScheduler7) [43f4eaec] FINISH, 
 GetGlusterVolumeAdvancedDetailsVDSCommand,
 return: org.ovirt.engine.core.common.businessentities.gluster.
 GlusterVolumeAdvancedDetails@ca97448e, log id: 347435ae
 2018-05-10 03:24:19,097+02 ERROR 
 [org.ovirt.engine.core.bll.gluster.GlusterSyncJob]
 (DefaultQuartzScheduler7) [43f4eaec] Error while refreshing brick statuses
 for volume 'volume2' of cluster 'C6220': null
 2018-05-10 03:24:19,097+02 INFO  
 [org.ovirt.engine.core.bll.lock.InMemoryLockManager]
 (DefaultQuartzScheduler8) [7715ceda] Failed to acquire lock and wait lock
 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-0339=GLUSTER]',
 sharedLocks=''}'
 2018-05-10 03:24:19,104+02 INFO  [org.ovirt.engine.core.
 

[ovirt-users] oVirt 4.1 upgrade hosted-engine

[dlotarev]

Hi! I have a two nodes (A and B), and running vm HostedEngine on host A.

After upgrade host B to latest release CentOS (7.5.1804), i trying to upgrade 
host A, but i cannot migrate HostedEngine to host B for next upgrade CentOS. 
Another VMs migrated to Host B w/o problems.
In logs on host A i have following lines:
May 17 12:58:16 ovirt-h1 libvirtd: 2018-05-17 07:58:16.728+: 3637: error : 
virNetClientProgramDispatchError:177 : internal error: cannot execute command 
QEMU «cont»: Failed to lock byte 100
May 17 12:58:38 ovirt-h1 journal: ovirt-ha-agent 
ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Migration failed: 
{u'status': {'message': 'Done', 'code': 0}, u'progress': 100}

Please explain me what is my mistake?

P.S I found, that host B have a missmatch in version of packages:
# rpm -aq|grep qemu|sort -n
centos-release-qemu-ev-1.0-2.el7.noarch
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
libvirt-daemon-driver-qemu-3.9.0-14.el7_5.2.x86_64
qemu-img-ev-2.10.0-21.el7_5.2.1.x86_64
qemu-kvm-common-ev-2.10.0-21.el7_5.2.1.x86_64
qemu-kvm-ev-2.10.0-21.el7_5.2.1.x86_64
qemu-kvm-tools-ev-2.9.0-16.el7_4.14.1.x86_64

Package qemu-kvm-tools-ev has version 2.9.0, while another packages of qemu has 
2.10 version.
Thank you so much for response.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[nicolas]

Hi,

Thanks. I've checked vdsm logs on all my hosts but the only entry I can 
find grepping by Volume.getInfo is like this:


  2018-05-17 10:14:54,892+0100 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] 
RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539)


I cannot find a line like yours... any other way on how to obtain those 
parameters. This is an iSCSI based storage FWIW (both source and 
destination of the movement).


Thanks.

El 2018-05-17 10:01, Benny Zlotnik escribió:

In the vdsm log you will find the volumeInfo log which looks like
this:

2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain':
'5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL', 'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244',
'disktype': 'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824',
'children': [], 'pool': '', 'capacity': '1073741824', 'uuid':
u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease':
{'path':
u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e
b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',
'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is: 
/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease

Then you can look in /var/log/sanlock.log

2018-05-17 11:35:18 243132 [14847]: s2:r9 resource
5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0
for 2,9,5049

Then you can use this command to unlock, the pid in this case is 5049

sanlock client release -r RESOURCE -p pid

On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik 
wrote:


I believe you've hit this
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [1]

You can try to release the lease manually using the sanlock client
command (there's an example in the comments on the bug), 
once the lease is free the job will fail and the disk can be unlock

On Thu, May 17, 2018 at 11:05 AM,  wrote:


Hi,

We're running oVirt 4.1.9 (I know it's not the recommended
version, but we can't upgrade yet) and recently we had an issue
with a Storage Domain while a VM was moving a disk. The Storage
Domain went down for a few minutes, then it got back.

However, the disk's state has stuck in a 'Migrating: 10%' state
(see ss-2.png).

I run the 'unlock_entity.sh' script to try to unlock the disk,
with these parameters:

 # PGPASSWORD=...
/usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t disk -u
engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38

The disk's state changed to 'OK', but the actual state still
states it's migrating (see ss-1.png).

Calling the script with -t all doesn't make a difference either.

Currently, the disk is unmanageable: cannot be deactivated, moved
or copied, as it says there's a copying operation running already.

Could someone provide a way to unlock this disk? I don't mind
modifying a value directly into the database, I just need the
copying process cancelled.

Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org




Links:
--
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Upgrade from 4.1.9 to 4.2.3 fails to upgrade postgresql

[Marcelo Leandro]

Hello,
I had the same error, but for me only worked when I created a new
instalation , run engine-setup for create a new database , after I runed
engine-cleanup to clear the instalation and restore a full backup  , all
the language of SO is english.

Marcelo Leandro

Em qui, 17 de mai de 2018 06:14, Yedidyah Bar David 
escreveu:

> On Thu, May 17, 2018 at 1:32 AM, Ian Fraser  wrote:
> > Hi,
> >
> > Could someone please provide advice on a production oVirt instance that
> > fails to upgrade to 4.2.3?
> >
> >
> >
> > Engine and hosts are all running CentOS 7
> >
> >
> >
> > As per the upgrade instructions in the release notes I run:
> >
> > # yum install
> http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm
> >
> > # yum update "ovirt-*-setup*"
> >
> > # engine-setup
> >
> >
> >
> > Then I answer the questions and it fails with:
> >
> > …
> >
> > [ INFO  ] Upgrading PostgreSQL
> >
> > [ ERROR ] Failed to execute stage 'Misc configuration': Command
> > '/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to execute
> >
> > [ INFO  ] Yum Performing yum transaction rollback
> >
> > [ INFO  ] Rolling back to the previous PostgreSQL instance (postgresql).
> >
> > [ INFO  ] Stage: Clean up
> >
> >   Log file is located at
> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20180516231622-3giicb.log
> >
> > [ INFO  ] Generating answer file
> > '/var/lib/ovirt-engine/setup/answers/20180516231735-setup.conf'
> >
> > [ INFO  ] Stage: Pre-termination
> >
> > [ INFO  ] Stage: Termination
> >
> > [ ERROR ] Execution of setup failed
> >
> >
> >
> >
> >
> > When I check  /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log:
> >
> >
> >
> > Performing Consistency Checks
> >
> > -
> >
> > Checking cluster versions   ok
> >
> > Checking database user is the install user  ok
> >
> > Checking database connection settings   ok
> >
> > Checking for prepared transactions  ok
> >
> > Checking for reg* system OID user data typesok
> >
> > Checking for contrib/isn with bigint-passing mismatch   ok
> >
> > Checking for invalid "line" user columnsok
> >
> > Creating dump of global objects ok
> >
> > Creating dump of database schemas
> >
> >   engine
> >
> >   ovirt_engine_history
> >
> >   postgres
> >
> >   template1
> >
> > ok
> >
> >
> >
> > lc_collate values for database "postgres" do not match:  old
> "en_GB.UTF-8",
> > new "en_US.UTF-8"
>
> Sounds again like:
>
> https://bugzilla.redhat.com/1528371
>
> That's really weird.
>
> Can you please check/share engine-setup log, so we can see that we
> actually passed the correct options to postgresql-setup?
>
> Also, if at all possible, please provide complete reproduction steps.
>
> See this for what I personally used to verify the fix for above bug,
> at the time:
>
>
> https://gerrit.ovirt.org/#/c/88234/2/common/upgrade-suites/test-scenarios-before-upgrade/001_initialize_engine.py
>
> But can't be sure it reproduces the original bug (although the error
> was the same), nor if your case is different and how.
>
> Thanks!
>
> >
> > Failure, exiting
> >
> >
> >
> >
> >
> > I have tried running the script here:
> > https://gist.github.com/turboladen/6790847 and rerunning engine-setup
> but it
> > fails with the same error.
> >
> >
> >
> > Can anyone offer any other suggestions?
> >
> >
> >
> > Best regards
> >
> >
> >
> > Ian Fraser
> >
> >
> >
> > Systems Administrator | Agency Sector Management (UK) Limited |
> > www.asm.org.uk
> >
> > [t] +44 (0)1784 242200 | [f] +44 (0)1784 242012 | [e]
> ian.fra...@asm.org.uk
> >
> > Registered in England No. 2053849 | Registered address: Ashford House
> 41-45
> > Church Road  Ashford  Middx  TW15 2TQ
> >
> > Follow us on twitter @asmukltd
> >
> >
> >
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> >
>
>
>
> --
> Didi
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: VM's disk stuck in migrating state

[Benny Zlotnik]

In the vdsm log you will find the volumeInfo log which looks like this:
2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer]
Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain': '5c4d2216-
2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL', 'description':
'{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent':
'---
-', 'format': 'RAW', 'generation': 3, 'image':
'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244', 'disktype':
'DATA', '
legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children':
[], 'pool': '', 'capacity': '1073741824', 'uuid': u'7190913d-320c-4fc9-
a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease': {'path':
u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e
b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease',
'owners': [1], 'version': 8L, 'o
ffset': 0}} (__init__:355)

The lease path in my case is:
/rhev/data-center/mnt/10.35.0.233:
_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease

Then you can look in /var/log/sanlock.log
2018-05-17 11:35:18 243132 [14847]: s2:r9 resource
5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0
for 2,9,5049

Then you can use this command to unlock, the pid in this case is 5049

sanlock client release -r RESOURCE -p pid


On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik  wrote:

> I believe you've hit this bug: https://bugzilla.redhat.c
> om/show_bug.cgi?id=1565040
>
> You can try to release the lease manually using the sanlock client command
> (there's an example in the comments on the bug),
> once the lease is free the job will fail and the disk can be unlock
>
> On Thu, May 17, 2018 at 11:05 AM,  wrote:
>
>> Hi,
>>
>> We're running oVirt 4.1.9 (I know it's not the recommended version, but
>> we can't upgrade yet) and recently we had an issue with a Storage Domain
>> while a VM was moving a disk. The Storage Domain went down for a few
>> minutes, then it got back.
>>
>> However, the disk's state has stuck in a 'Migrating: 10%' state (see
>> ss-2.png).
>>
>> I run the 'unlock_entity.sh' script to try to unlock the disk, with these
>> parameters:
>>
>>  # PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh
>> -t disk -u engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38
>>
>> The disk's state changed to 'OK', but the actual state still states it's
>> migrating (see ss-1.png).
>>
>> Calling the script with -t all doesn't make a difference either.
>>
>> Currently, the disk is unmanageable: cannot be deactivated, moved or
>> copied, as it says there's a copying operation running already.
>>
>> Could someone provide a way to unlock this disk? I don't mind modifying a
>> value directly into the database, I just need the copying process cancelled.
>>
>> Thanks.
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>>
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: vGPU VM not starting

[Callum Smith]

In an attempt not to mislead you guys as well, there appears to be a separate, 
vGPU specific, issue.

https://www.dropbox.com/s/hlymmf9d6rn12tq/vdsm.vgpu.log?dl=0

I've uploaded the full vdsm.log to dropbox. Most recently I tried unmounting 
alll network devices from the VM and booting it and i get a different issue 
around the vGPU:

2018-05-17 09:48:24,806+0100 INFO  (vm/1bc9dae8) [root] 
/usr/libexec/vdsm/hooks/before_vm_start/50_hos
tedengine: rc=0 err= (hooks:110)
2018-05-17 09:48:24,953+0100 INFO  (vm/1bc9dae8) [root] 
/usr/libexec/vdsm/hooks/before_vm_start/50_vfi
o_mdev: rc=1 err=vgpu: No device with type nvidia-61 is available.
 (hooks:110)
2018-05-17 09:48:25,069+0100 INFO  (vm/1bc9dae8) [root] 
/usr/libexec/vdsm/hooks/before_vm_start/50_vho
stmd: rc=0 err= (hooks:110)
2018-05-17 09:48:25,070+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0
') The vm start process failed (vm:943)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in 
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2862, in _run
self._custom)
  File "/usr/lib/python2.7/site-packages/vdsm/common/hooks.py", line 153, in 
before_vm_start
return _runHooksDir(domxml, 'before_vm_start', vmconf=vmconf)
  File "/usr/lib/python2.7/site-packages/vdsm/common/hooks.py", line 120, in 
_runHooksDir
raise exception.HookError(err)
HookError: Hook Error: ('',)

Despite the nvidia-61 being an option on the GPU: https://pastebin.com/bucw21DG

So I think we have two issues here, one relating to the network and one to GPU.

Thanks all for your rapid and very useful help!

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:28, Ales Musil 
> wrote:

Seems like some vdsm problem with xml generation.

+Francesco

On Thu, May 17, 2018 at 10:20 AM, Callum Smith 
> wrote:
PS. some other WARN's that come up on the host:

WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.org.qemu.guest_agent.0
 already removed
vdsm
WARN Attempting to remove a non existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN Attempting to remove a non existing network: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.ovirt-guest-agent.0
 already removed
vdsm
WARN Attempting to add an existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:16, Callum Smith 
> wrote:

OVN Network provider is used, and the node is running 4.2.3 (specifically 
2018051606 clean install last night).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 07:47, Ales Musil 
> wrote:



On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
Dear All,

Our vGPU installation is progressing, though the VM is failing to start.

2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed 
(vm:943)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in 
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in 
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
libvirtError: Cannot get interface MTU on '': No such device

That's the specific error, some other information. It seems the GPU 
'allocation' of uuid against the nvidia-xx mdev type is proceeding correctly, 
and the device is being created by the VM instantiation but the VM does not 
succeed in going up with this error. Any other logs or information relevant to 
help diagnose?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

[ovirt-users] Re: Hosted Engine Setup error (oVirt v4.2.3)

[ovirt]

Some good news...
Hosted Engine Deployment "preparing the vm" completed.
I used a simpler password.
When I got the previous errors, my password was 12 characters (upper, 
lower case & numbers) long with a %% (double percent) before and after 
the characters.

I guess it didn't like the double percent!!!
Let me continue, I will report back.

On 2018-05-17 00:30, Simone Tiraboschi wrote:

On Thu, May 17, 2018 at 9:16 AM,  wrote:


More info:
From my ovirt node (host) I can ping 192.168.124.198
If I try to connect via ssh root@192.168.124.198, it asks for a
password.
The password I used during the hosted engine setup does not work.


Can you please try with a different more robust password?
The log file is under /var/log/ovirt-hosted-engine-setup


On 2018-05-16 22:27, ov...@fateknollogee.com wrote:
I will get the logs.

Here is the exact error message:
[ ERROR ] fatal: [ovirt-engine.fateknollogee.com [1]]: UNREACHABLE!
=>
{"changed": false, "msg": "Failed to connect to the host via ssh:
Warning: Permanently added
'ovirt-engine.fateknollogee.com [1],192.168.124.198' (ECDSA) to the
list
of known hosts.\r\nPermission denied
(publickey,gssapi-keyex,gssapi-with-mic,password).\r\n",
"unreachable": true}

On 2018-05-16 07:04, Simone Tiraboschi wrote:
On Wed, May 16, 2018 at 3:36 PM,  wrote:

Simone, unfortunately I deleted that install after it failed.
I can re-run the install based on the df -h (see previous post) or I
can change disks & increase the size of /var then re-run the
install.
What do you think?
The error I was getting said it could not find the hosted engine at
vibr0 on 192.168.xxx.xx

On my opinion you could simply retry.
Please share your log file it fails again.

On 2018-05-16 06:30, Simone Tiraboschi wrote:

On Wed, May 16, 2018 at 3:25 PM,  wrote:

This is what I had.
Does this look correct?

Yes, I think so.

can you please share your hosted-engine-setup log file to understand
where it's failing?

[root@ovirt-node1 ~]# df -h
Filesystem
Size  Used Avail Use% Mounted on
/dev/mapper/onn_ovirt--node1-ovirt--node--ng--4.2.3--0.20180515.0+1
14G  1.8G   12G  14% /
devtmpfs
32G 0   32G   0% /dev
tmpfs
32G  8.0K   32G   1% /dev/shm
tmpfs
32G   18M   32G   1% /run
tmpfs
32G 0   32G   0% /sys/fs/cgroup
/dev/sda1
976M  207M  702M  23% /boot
/dev/mapper/onn_ovirt--node1-home
976M  2.6M  907M   1% /home
/dev/mapper/onn_ovirt--node1-tmp
976M  2.8M  906M   1% /tmp
/dev/mapper/onn_ovirt--node1-var
15G  112M   14G   1% /var
/dev/mapper/onn_ovirt--node1-var_log
7.8G   42M  7.3G   1% /var/log
/dev/mapper/onn_ovirt--node1-var_log_audit
2.0G  6.3M  1.8G   1% /var/log/audit
/dev/mapper/onn_ovirt--node1-var_crash
9.8G   37M  9.2G   1% /var/crash
tmpfs
6.3G 0  6.3G   0% /run/user/0

On 2018-05-16 06:14, Simone Tiraboschi wrote:
On Wed, May 16, 2018 at 2:52 PM,  wrote:



https://www.ovirt.org/documentation/install-guide/chap-System_Requirements/

[2]
[1]
[1]
[1] says:
Important: If you are also installing the oVirt Engine Virtual
Appliance for self-hosted engine installation, the /var partition
must be at least 60 GB.

The appliance disk is shipped as a qcow2 image: 4 GB should be
enough.

Back to the drawing board, I certainly failed to read that!!

On 2018-05-16 02:37, Andrea Dell'Amico wrote:
On 16 May 2018, at 09:42, Simone Tiraboschi 
wrote:

On Tue, May 15, 2018 at 6:31 PM,   wrote:

Engine network config error

Following this blog post:



https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/

[3]
[2]
[2]
[2]

[1]

I get an error saying the hosted engine setup is "trying" to use
vibr0 (192.168.xxx.x) even though I have the bridge interface set
to "eno1"

Regardless of whether the Edit Hosts File is checked or unchecked,
it overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x

The same thing happens whether I set the engine IP to Static or
DHCP (I don't have DNS, I'm using static entries in /etc/hosts).

Any ideas it "insists" on using "vibr0" instead of "eno1"?

Hi,
up to this point is absolutely fine: in the new node zero deployment
flow, hosted-engine-setup bootstraps a local VM with an engine there
to use that engine to configure the rest of the system (storage,
network...).
That bootstrap VM runs over default natted libvirt network, that's
why you see vibr0 and 192.168.xxx.x at that stage.

If you are facing any issue, it's definitively not there.

Yes, the blog post describes the 4.2.{0,1} behaviour while the local
VM is a change introduced in 4.2.2.
I faced a similar error and in my case the VM creation failed
because
there was not enough space in /var/tmp. It wasn’t a problem
before,
because the engine VM was created directly on top of a gluster
volume.

Andrea
--
Andrea Dell'Amico
http://adellam. sevenseas.org/ [4] [3] [3] [3] [2]

Links:
--
[1]

[ovirt-users] Re: VM's disk stuck in migrating state

[Benny Zlotnik]

I believe you've hit this bug: https://bugzilla.redhat.c
om/show_bug.cgi?id=1565040

You can try to release the lease manually using the sanlock client command
(there's an example in the comments on the bug),
once the lease is free the job will fail and the disk can be unlock

On Thu, May 17, 2018 at 11:05 AM,  wrote:

> Hi,
>
> We're running oVirt 4.1.9 (I know it's not the recommended version, but we
> can't upgrade yet) and recently we had an issue with a Storage Domain while
> a VM was moving a disk. The Storage Domain went down for a few minutes,
> then it got back.
>
> However, the disk's state has stuck in a 'Migrating: 10%' state (see
> ss-2.png).
>
> I run the 'unlock_entity.sh' script to try to unlock the disk, with these
> parameters:
>
>  # PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh
> -t disk -u engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38
>
> The disk's state changed to 'OK', but the actual state still states it's
> migrating (see ss-1.png).
>
> Calling the script with -t all doesn't make a difference either.
>
> Currently, the disk is unmanageable: cannot be deactivated, moved or
> copied, as it says there's a copying operation running already.
>
> Could someone provide a way to unlock this disk? I don't mind modifying a
> value directly into the database, I just need the copying process cancelled.
>
> Thanks.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Upgrade from 4.1.9 to 4.2.3 fails to upgrade postgresql

[Yedidyah Bar David]

On Thu, May 17, 2018 at 1:32 AM, Ian Fraser  wrote:
> Hi,
>
> Could someone please provide advice on a production oVirt instance that
> fails to upgrade to 4.2.3?
>
>
>
> Engine and hosts are all running CentOS 7
>
>
>
> As per the upgrade instructions in the release notes I run:
>
> # yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm
>
> # yum update "ovirt-*-setup*"
>
> # engine-setup
>
>
>
> Then I answer the questions and it fails with:
>
> …
>
> [ INFO  ] Upgrading PostgreSQL
>
> [ ERROR ] Failed to execute stage 'Misc configuration': Command
> '/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to execute
>
> [ INFO  ] Yum Performing yum transaction rollback
>
> [ INFO  ] Rolling back to the previous PostgreSQL instance (postgresql).
>
> [ INFO  ] Stage: Clean up
>
>   Log file is located at
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20180516231622-3giicb.log
>
> [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/20180516231735-setup.conf'
>
> [ INFO  ] Stage: Pre-termination
>
> [ INFO  ] Stage: Termination
>
> [ ERROR ] Execution of setup failed
>
>
>
>
>
> When I check  /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log:
>
>
>
> Performing Consistency Checks
>
> -
>
> Checking cluster versions   ok
>
> Checking database user is the install user  ok
>
> Checking database connection settings   ok
>
> Checking for prepared transactions  ok
>
> Checking for reg* system OID user data typesok
>
> Checking for contrib/isn with bigint-passing mismatch   ok
>
> Checking for invalid "line" user columnsok
>
> Creating dump of global objects ok
>
> Creating dump of database schemas
>
>   engine
>
>   ovirt_engine_history
>
>   postgres
>
>   template1
>
> ok
>
>
>
> lc_collate values for database "postgres" do not match:  old "en_GB.UTF-8",
> new "en_US.UTF-8"

Sounds again like:

https://bugzilla.redhat.com/1528371

That's really weird.

Can you please check/share engine-setup log, so we can see that we
actually passed the correct options to postgresql-setup?

Also, if at all possible, please provide complete reproduction steps.

See this for what I personally used to verify the fix for above bug,
at the time:

https://gerrit.ovirt.org/#/c/88234/2/common/upgrade-suites/test-scenarios-before-upgrade/001_initialize_engine.py

But can't be sure it reproduces the original bug (although the error
was the same), nor if your case is different and how.

Thanks!

>
> Failure, exiting
>
>
>
>
>
> I have tried running the script here:
> https://gist.github.com/turboladen/6790847 and rerunning engine-setup but it
> fails with the same error.
>
>
>
> Can anyone offer any other suggestions?
>
>
>
> Best regards
>
>
>
> Ian Fraser
>
>
>
> Systems Administrator | Agency Sector Management (UK) Limited |
> www.asm.org.uk
>
> [t] +44 (0)1784 242200 | [f] +44 (0)1784 242012 | [e] ian.fra...@asm.org.uk
>
> Registered in England No. 2053849 | Registered address: Ashford House  41-45
> Church Road  Ashford  Middx  TW15 2TQ
>
> Follow us on twitter @asmukltd
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>



-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: vGPU VM not starting

[Ales Musil]

Seems like some vdsm problem with xml generation.

+Francesco

On Thu, May 17, 2018 at 10:20 AM, Callum Smith  wrote:

> PS. some other WARN's that come up on the host:
>
> WARN File: /var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-
> 9103-5805100648d0.org.qemu.guest_agent.0 already removed
> vdsm
> WARN Attempting to remove a non existing net user:
> ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
> vdsm
> WARN Attempting to remove a non existing network:
> ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
> vdsm
> WARN File: /var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-
> 9103-5805100648d0.ovirt-guest-agent.0 already removed
> vdsm
> WARN Attempting to add an existing net user: ovirtmgmt/1bc9dae8-a0ea-44b3-
> 9103-5805100648d0
> vdsm
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 17 May 2018, at 09:16, Callum Smith  wrote:
>
> OVN Network provider is used, and the node is running 4.2.3 (specifically
> 2018051606 clean install last night).
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 17 May 2018, at 07:47, Ales Musil  wrote:
>
>
>
> On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
>
>> Dear All,
>>
>> Our vGPU installation is progressing, though the VM is failing to start.
>>
>> 2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm]
>> (vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process
>> failed (vm:943)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in
>> _startUnderlyingVm
>> self._run()
>>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in
>> _run
>> dom.createWithFlags(flags)
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py",
>> line 130, in wrapper
>> ret = f(*args, **kwargs)
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line
>> 92, in wrapper
>> return func(inst, *args, **kwargs)
>>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in
>> createWithFlags
>> if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
>> failed', dom=self)
>> libvirtError: Cannot get interface MTU on '': No such device
>>
>> That's the specific error, some other information. It seems the GPU
>> 'allocation' of uuid against the nvidia-xx mdev type is proceeding
>> correctly, and the device is being created by the VM instantiation but the
>> VM does not succeed in going up with this error. Any other logs or
>> information relevant to help diagnose?
>>
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of Oxford
>> e. cal...@well.ox.ac.uk
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>>
>>
> Hi Callum,
>
> can you share your version of the setup?
>
> Also do you use OVS switch type in the cluster?
>
> Regards,
> Ales.
>
>
> --
> ALES MUSIL
> INTERN - rhv network
> Red Hat EMEA 
>
> amu...@redhat.com   IM: amusil
> 
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
>
>


-- 

ALES MUSIL
INTERN - rhv network

Red Hat EMEA 


amu...@redhat.com   IM: amusil

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: vGPU VM not starting

[Callum Smith]

Some information that appears to be from around the time of installation to the 
cluster:

WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -X 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -F 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -L 
libvirt-O-vnet0' failed: Chain 'libvirt-O-vnet0' doesn't exist.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ebtables --concurrent -t nat -D POSTROUTING 
-o vnet0 -j libvirt-O-vnet0' failed: Illegal target name 'libvirt-O-vnet0'.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X HI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F HI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -X FI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld
WARNING: COMMAND_FAILED: '/usr/sbin/ip6tables -w2 -w -F FI-vnet0' failed: 
ip6tables: No chain/target/match by that name.
firewalld

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:20, Callum Smith 
> wrote:

PS. some other WARN's that come up on the host:

WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.org.qemu.guest_agent.0
 already removed
vdsm
WARN Attempting to remove a non existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN Attempting to remove a non existing network: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.ovirt-guest-agent.0
 already removed
vdsm
WARN Attempting to add an existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:16, Callum Smith 
> wrote:

OVN Network provider is used, and the node is running 4.2.3 (specifically 
2018051606 clean install last night).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 07:47, Ales Musil 
> wrote:



On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
Dear All,

Our vGPU installation is progressing, though the VM is failing to start.

2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed 
(vm:943)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in 
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in 
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
libvirtError: Cannot get interface MTU on '': No such device

That's the specific error, some other information. It seems the GPU 
'allocation' of uuid against the nvidia-xx mdev type is proceeding correctly, 
and the device is being created by the VM instantiation but the VM does not 
succeed in going up with this error. Any other logs or information relevant to 
help diagnose?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org


Hi Callum,

can you share your version of the setup?

Also do you use OVS switch type in the cluster?

Regards,
Ales.


--
ALES MUSIL
INTERN - rhv network
Red Hat EMEA


amu...@redhat.com   IM: amusil

[https://www.redhat.com/files/brand/email/sig-redhat.png]

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 

[ovirt-users] Re: vGPU VM not starting

[Callum Smith]

PS. some other WARN's that come up on the host:

WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.org.qemu.guest_agent.0
 already removed
vdsm
WARN Attempting to remove a non existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN Attempting to remove a non existing network: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm
WARN File: 
/var/lib/libvirt/qemu/channels/1bc9dae8-a0ea-44b3-9103-5805100648d0.ovirt-guest-agent.0
 already removed
vdsm
WARN Attempting to add an existing net user: 
ovirtmgmt/1bc9dae8-a0ea-44b3-9103-5805100648d0
vdsm

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 09:16, Callum Smith 
> wrote:

OVN Network provider is used, and the node is running 4.2.3 (specifically 
2018051606 clean install last night).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 07:47, Ales Musil 
> wrote:



On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
Dear All,

Our vGPU installation is progressing, though the VM is failing to start.

2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed 
(vm:943)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in 
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in 
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
libvirtError: Cannot get interface MTU on '': No such device

That's the specific error, some other information. It seems the GPU 
'allocation' of uuid against the nvidia-xx mdev type is proceeding correctly, 
and the device is being created by the VM instantiation but the VM does not 
succeed in going up with this error. Any other logs or information relevant to 
help diagnose?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org


Hi Callum,

can you share your version of the setup?

Also do you use OVS switch type in the cluster?

Regards,
Ales.


--
ALES MUSIL
INTERN - rhv network
Red Hat EMEA


amu...@redhat.com   IM: amusil

[https://www.redhat.com/files/brand/email/sig-redhat.png]

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Fwd: vGPU VM not starting

[Callum Smith]

OVN Network provider is used, and the node is running 4.2.3 (specifically 
2018051606 clean install last night).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 17 May 2018, at 07:47, Ales Musil 
> wrote:



On Thu, May 17, 2018 at 12:01 AM, Callum Smith 
> wrote:
Dear All,

Our vGPU installation is progressing, though the VM is failing to start.

2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] 
(vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed 
(vm:943)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in 
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in 
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
libvirtError: Cannot get interface MTU on '': No such device

That's the specific error, some other information. It seems the GPU 
'allocation' of uuid against the nvidia-xx mdev type is proceeding correctly, 
and the device is being created by the VM instantiation but the VM does not 
succeed in going up with this error. Any other logs or information relevant to 
help diagnose?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org


Hi Callum,

can you share your version of the setup?

Also do you use OVS switch type in the cluster?

Regards,
Ales.


--
ALES MUSIL
INTERN - rhv network
Red Hat EMEA


amu...@redhat.com   IM: amusil

[https://www.redhat.com/files/brand/email/sig-redhat.png]

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] VM's disk stuck in migrating state

[nicolas]

Hi,

We're running oVirt 4.1.9 (I know it's not the recommended version, but 
we can't upgrade yet) and recently we had an issue with a Storage Domain 
while a VM was moving a disk. The Storage Domain went down for a few 
minutes, then it got back.


However, the disk's state has stuck in a 'Migrating: 10%' state (see 
ss-2.png).


I run the 'unlock_entity.sh' script to try to unlock the disk, with 
these parameters:


 # PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh 
-t disk -u engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38


The disk's state changed to 'OK', but the actual state still states it's 
migrating (see ss-1.png).


Calling the script with -t all doesn't make a difference either.

Currently, the disk is unmanageable: cannot be deactivated, moved or 
copied, as it says there's a copying operation running already.


Could someone provide a way to unlock this disk? I don't mind modifying 
a value directly into the database, I just need the copying process 
cancelled.


Thanks.___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Upgrade from 4.1.9 to 4.2.3 fails to upgrade postgresql

[Ian Fraser]

Hi,
Could someone please provide advice on a production oVirt instance that fails 
to upgrade to 4.2.3?

Engine and hosts are all running CentOS 7

As per the upgrade instructions in the release notes I run:
# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm
# yum update "ovirt-*-setup*"
# engine-setup

Then I answer the questions and it fails with:
...
[ INFO  ] Upgrading PostgreSQL
[ ERROR ] Failed to execute stage 'Misc configuration': Command 
'/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to execute
[ INFO  ] Yum Performing yum transaction rollback
[ INFO  ] Rolling back to the previous PostgreSQL instance (postgresql).
[ INFO  ] Stage: Clean up
  Log file is located at 
/var/log/ovirt-engine/setup/ovirt-engine-setup-20180516231622-3giicb.log
[ INFO  ] Generating answer file 
'/var/lib/ovirt-engine/setup/answers/20180516231735-setup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed


When I check  /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log:

Performing Consistency Checks
-
Checking cluster versions   ok
Checking database user is the install user  ok
Checking database connection settings   ok
Checking for prepared transactions  ok
Checking for reg* system OID user data typesok
Checking for contrib/isn with bigint-passing mismatch   ok
Checking for invalid "line" user columnsok
Creating dump of global objects ok
Creating dump of database schemas
  engine
  ovirt_engine_history
  postgres
  template1
ok

lc_collate values for database "postgres" do not match:  old "en_GB.UTF-8", new 
"en_US.UTF-8"
Failure, exiting


I have tried running the script here: 
https://gist.github.com/turboladen/6790847 and rerunning engine-setup but it 
fails with the same error.

Can anyone offer any other suggestions?

Best regards

Ian Fraser

Systems Administrator | Agency Sector Management (UK) Limited | www.asm.org.uk
[t] +44 (0)1784 242200 | [f] +44 (0)1784 242012 | [e] ian.fra...@asm.org.uk
Registered in England No. 2053849 | Registered address: Ashford House  41-45 
Church Road  Ashford  Middx  TW15 2TQ
Follow us on twitter @asmukltd

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: oVirt reports using Grafana

[Sandro Bonazzola]

Shirly, can you please update the blog post pointing to an updated
documentation page?

2018-05-17 9:35 GMT+02:00 Karli Sjöberg :

> Heya!
>
> I've been whishing for reports in oVirt ever since the old 'Jasper
> Reports' was removed. For an Enterprise, having pretty graphs to look
> at is a must.
>
> Searching the subject, I've found this[*] and have managed to get it
> installed OK but having issues trying to follow the guide setting it
> up.
>
> First of all, I think the guide should have at least mentioned that
> 'pg_hba.conf' needs to be edited for the read only user to be able to
> connect to the database, I scratched my head around that for a while
> before I got it.
>
> When I first type in the query example, I got syntax errors:
> 'pq: syntax error at or near "$"'. I continued anyways since I figured
> it would be solved at a later point, which turned out to be true, since
> the next step is to use the "Templating feature" to add variables.
>
> Unfortunately this doesn't go so well, even though I followed the
> instructions very carefully. After hitting save on the first variable I
> am rewarded with the error message:
> 'Template variables could not be initialized: pq: column "en_us" does
> not exist.'
>
> Are the queries stated in the guide still correct? This is for
> 'user_locale':
> "SELECT DISTINCT language_code from enum_translator"
>
> [*]:https://www.ovirt.org/blog/2018/01/ovirt-report-using-grafana/
>
> TIA
> /K
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

sbona...@redhat.com


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] hosted-engine deploy not use FQDN

[dhy336]

Hi 
I deploy hosted-engine by #hosted-engine --deploy,   but I do not use FQDN,  I 
want to visit engine directly by ip
besides, I  have not  DNS server, I want to skip setup  Engine VM FQDN， because 
my project can not to setup /etc/hosts

 Please provide the FQDN you would like to use for the engine appliance.
  Note: This will be the FQDN of the engine VM you are now going to launch, 
 it should not point to the base host or to any other existing machine. 
 Engine VM FQDN: (leave it empty to skip):  []: 

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] oVirt reports using Grafana

[Karli Sjöberg]

Heya!

I've been whishing for reports in oVirt ever since the old 'Jasper
Reports' was removed. For an Enterprise, having pretty graphs to look
at is a must.

Searching the subject, I've found this[*] and have managed to get it
installed OK but having issues trying to follow the guide setting it
up.

First of all, I think the guide should have at least mentioned that
'pg_hba.conf' needs to be edited for the read only user to be able to
connect to the database, I scratched my head around that for a while
before I got it.

When I first type in the query example, I got syntax errors:
'pq: syntax error at or near "$"'. I continued anyways since I figured
it would be solved at a later point, which turned out to be true, since
the next step is to use the "Templating feature" to add variables.

Unfortunately this doesn't go so well, even though I followed the
instructions very carefully. After hitting save on the first variable I
am rewarded with the error message:
'Template variables could not be initialized: pq: column "en_us" does
not exist.'

Are the queries stated in the guide still correct? This is for
'user_locale':
"SELECT DISTINCT language_code from enum_translator"

[*]:https://www.ovirt.org/blog/2018/01/ovirt-report-using-grafana/

TIA
/K
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: Hosted Engine Setup error (oVirt v4.2.3)

[Simone Tiraboschi]

On Thu, May 17, 2018 at 9:16 AM,  wrote:

> More info:
> From my ovirt node (host) I can ping 192.168.124.198
> If I try to connect via ssh root@192.168.124.198, it asks for a password.
> The password I used during the hosted engine setup does not work.
>
>
Can you please try with a different more robust password?
The log file is under /var/log/ovirt-hosted-engine-setup


>
> On 2018-05-16 22:27, ov...@fateknollogee.com wrote:
>
>> I will get the logs.
>>
>> Here is the exact error message:
>> [ ERROR ] fatal: [ovirt-engine.fateknollogee.com]: UNREACHABLE! =>
>> {"changed": false, "msg": "Failed to connect to the host via ssh:
>> Warning: Permanently added
>> 'ovirt-engine.fateknollogee.com,192.168.124.198' (ECDSA) to the list
>> of known hosts.\r\nPermission denied
>> (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n",
>> "unreachable": true}
>>
>> On 2018-05-16 07:04, Simone Tiraboschi wrote:
>>
>>> On Wed, May 16, 2018 at 3:36 PM,  wrote:
>>>
>>> Simone, unfortunately I deleted that install after it failed.
 I can re-run the install based on the df -h (see previous post) or I
 can change disks & increase the size of /var then re-run the
 install.
 What do you think?
 The error I was getting said it could not find the hosted engine at
 vibr0 on 192.168.xxx.xx

>>>
>>> On my opinion you could simply retry.
>>> Please share your log file it fails again.
>>>
>>> On 2018-05-16 06:30, Simone Tiraboschi wrote:

 On Wed, May 16, 2018 at 3:25 PM,  wrote:

 This is what I had.
 Does this look correct?

 Yes, I think so.

 can you please share your hosted-engine-setup log file to understand
 where it's failing?

 [root@ovirt-node1 ~]# df -h
 Filesystem
 Size  Used Avail Use% Mounted on
 /dev/mapper/onn_ovirt--node1-ovirt--node--ng--4.2.3--0.20180515.0+1
 14G  1.8G   12G  14% /
 devtmpfs
 32G 0   32G   0% /dev
 tmpfs
 32G  8.0K   32G   1% /dev/shm
 tmpfs
 32G   18M   32G   1% /run
 tmpfs
 32G 0   32G   0% /sys/fs/cgroup
 /dev/sda1
 976M  207M  702M  23% /boot
 /dev/mapper/onn_ovirt--node1-home
 976M  2.6M  907M   1% /home
 /dev/mapper/onn_ovirt--node1-tmp
 976M  2.8M  906M   1% /tmp
 /dev/mapper/onn_ovirt--node1-var
 15G  112M   14G   1% /var
 /dev/mapper/onn_ovirt--node1-var_log
 7.8G   42M  7.3G   1% /var/log
 /dev/mapper/onn_ovirt--node1-var_log_audit
 2.0G  6.3M  1.8G   1% /var/log/audit
 /dev/mapper/onn_ovirt--node1-var_crash
 9.8G   37M  9.2G   1% /var/crash
 tmpfs
 6.3G 0  6.3G   0% /run/user/0

 On 2018-05-16 06:14, Simone Tiraboschi wrote:
 On Wed, May 16, 2018 at 2:52 PM,  wrote:


 https://www.ovirt.org/documentation/install-guide/chap-
>>> System_Requirements/
>>>
 [1]
 [1]
 [1] says:
 Important: If you are also installing the oVirt Engine Virtual
 Appliance for self-hosted engine installation, the /var partition
 must be at least 60 GB.

 The appliance disk is shipped as a qcow2 image: 4 GB should be
 enough.

 Back to the drawing board, I certainly failed to read that!!

 On 2018-05-16 02:37, Andrea Dell'Amico wrote:
 On 16 May 2018, at 09:42, Simone Tiraboschi 
 wrote:

 On Tue, May 15, 2018 at 6:31 PM,   wrote:

 Engine network config error

 Following this blog post:


 https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt
>>> -4-2-and-gluster-storage/
>>>
 [2]
 [2]
 [2]

 [1]

 I get an error saying the hosted engine setup is "trying" to use
 vibr0 (192.168.xxx.x) even though I have the bridge interface set
 to "eno1"

 Regardless of whether the Edit Hosts File is checked or unchecked,
 it overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x

 The same thing happens whether I set the engine IP to Static or
 DHCP (I don't have DNS, I'm using static entries in /etc/hosts).

 Any ideas it "insists" on using "vibr0" instead of "eno1"?

 Hi,
 up to this point is absolutely fine: in the new node zero deployment
 flow, hosted-engine-setup bootstraps a local VM with an engine there
 to use that engine to configure the rest of the system (storage,
 network...).
 That bootstrap VM runs over default natted libvirt network, that's
 why you see vibr0 and 192.168.xxx.x at that stage.

 If you are facing any issue, it's definitively not there.

 Yes, the blog post describes the 4.2.{0,1} behaviour while the local
 VM is a change introduced in 4.2.2.
 I faced a similar error and in my case the VM creation failed
 because
 there was not enough space in /var/tmp. It wasn’t a problem
 before,
 

[ovirt-users] Re: Hosted Engine Setup error (oVirt v4.2.3)

[ovirt]

More info:
From my ovirt node (host) I can ping 192.168.124.198
If I try to connect via ssh root@192.168.124.198, it asks for a 
password.

The password I used during the hosted engine setup does not work.

On 2018-05-16 22:27, ov...@fateknollogee.com wrote:

I will get the logs.

Here is the exact error message:
[ ERROR ] fatal: [ovirt-engine.fateknollogee.com]: UNREACHABLE! =>
{"changed": false, "msg": "Failed to connect to the host via ssh:
Warning: Permanently added
'ovirt-engine.fateknollogee.com,192.168.124.198' (ECDSA) to the list
of known hosts.\r\nPermission denied
(publickey,gssapi-keyex,gssapi-with-mic,password).\r\n",
"unreachable": true}

On 2018-05-16 07:04, Simone Tiraboschi wrote:

On Wed, May 16, 2018 at 3:36 PM,  wrote:


Simone, unfortunately I deleted that install after it failed.
I can re-run the install based on the df -h (see previous post) or I
can change disks & increase the size of /var then re-run the
install.
What do you think?
The error I was getting said it could not find the hosted engine at
vibr0 on 192.168.xxx.xx


On my opinion you could simply retry.
Please share your log file it fails again.


On 2018-05-16 06:30, Simone Tiraboschi wrote:

On Wed, May 16, 2018 at 3:25 PM,  wrote:

This is what I had.
Does this look correct?

Yes, I think so.

can you please share your hosted-engine-setup log file to understand
where it's failing?

[root@ovirt-node1 ~]# df -h
Filesystem
Size  Used Avail Use% Mounted on
/dev/mapper/onn_ovirt--node1-ovirt--node--ng--4.2.3--0.20180515.0+1
14G  1.8G   12G  14% /
devtmpfs
32G 0   32G   0% /dev
tmpfs
32G  8.0K   32G   1% /dev/shm
tmpfs
32G   18M   32G   1% /run
tmpfs
32G 0   32G   0% /sys/fs/cgroup
/dev/sda1
976M  207M  702M  23% /boot
/dev/mapper/onn_ovirt--node1-home
976M  2.6M  907M   1% /home
/dev/mapper/onn_ovirt--node1-tmp
976M  2.8M  906M   1% /tmp
/dev/mapper/onn_ovirt--node1-var
15G  112M   14G   1% /var
/dev/mapper/onn_ovirt--node1-var_log
7.8G   42M  7.3G   1% /var/log
/dev/mapper/onn_ovirt--node1-var_log_audit
2.0G  6.3M  1.8G   1% /var/log/audit
/dev/mapper/onn_ovirt--node1-var_crash
9.8G   37M  9.2G   1% /var/crash
tmpfs
6.3G 0  6.3G   0% /run/user/0

On 2018-05-16 06:14, Simone Tiraboschi wrote:
On Wed, May 16, 2018 at 2:52 PM,  wrote:



https://www.ovirt.org/documentation/install-guide/chap-System_Requirements/

[1]
[1]
[1] says:
Important: If you are also installing the oVirt Engine Virtual
Appliance for self-hosted engine installation, the /var partition
must be at least 60 GB.

The appliance disk is shipped as a qcow2 image: 4 GB should be
enough.

Back to the drawing board, I certainly failed to read that!!

On 2018-05-16 02:37, Andrea Dell'Amico wrote:
On 16 May 2018, at 09:42, Simone Tiraboschi 
wrote:

On Tue, May 15, 2018 at 6:31 PM,   wrote:

Engine network config error

Following this blog post:



https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/

[2]
[2]
[2]

[1]

I get an error saying the hosted engine setup is "trying" to use
vibr0 (192.168.xxx.x) even though I have the bridge interface set
to "eno1"

Regardless of whether the Edit Hosts File is checked or unchecked,
it overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x

The same thing happens whether I set the engine IP to Static or
DHCP (I don't have DNS, I'm using static entries in /etc/hosts).

Any ideas it "insists" on using "vibr0" instead of "eno1"?

Hi,
up to this point is absolutely fine: in the new node zero deployment
flow, hosted-engine-setup bootstraps a local VM with an engine there
to use that engine to configure the rest of the system (storage,
network...).
That bootstrap VM runs over default natted libvirt network, that's
why you see vibr0 and 192.168.xxx.x at that stage.

If you are facing any issue, it's definitively not there.

Yes, the blog post describes the 4.2.{0,1} behaviour while the local
VM is a change introduced in 4.2.2.
I faced a similar error and in my case the VM creation failed
because
there was not enough space in /var/tmp. It wasn’t a problem
before,
because the engine VM was created directly on top of a gluster
volume.

Andrea
--
Andrea Dell'Amico
http://adellam. sevenseas.org/ [3] [3] [3] [2]

Links:
--
[1]


https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/

[2]
[2]
[2]
[2] http://sevenseas.org/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

Links:
--
[1]


https://www.ovirt.org/documentation/install-guide/chap-System_Requirements/

[1]
[1]
[2]


https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-gluster-storage/

[2]
[2]
[3] http://sevenseas.org/

Links:
--
[1]


https://www.ovirt.org/documentation/install-guide/chap-System_Requirements/

[1]
[2]

[ovirt-users] Fwd: vGPU VM not starting

[Ales Musil]

On Thu, May 17, 2018 at 12:01 AM, Callum Smith  wrote:

> Dear All,
>
> Our vGPU installation is progressing, though the VM is failing to start.
>
> 2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm]
> (vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed
> (vm:943)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in
> _startUnderlyingVm
> self._run()
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in
> _run
> dom.createWithFlags(flags)
>   File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py",
> line 130, in wrapper
> ret = f(*args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line
> 92, in wrapper
> return func(inst, *args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in
> createWithFlags
> if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
> dom=self)
> libvirtError: Cannot get interface MTU on '': No such device
>
> That's the specific error, some other information. It seems the GPU
> 'allocation' of uuid against the nvidia-xx mdev type is proceeding
> correctly, and the device is being created by the VM instantiation but the
> VM does not succeed in going up with this error. Any other logs or
> information relevant to help diagnose?
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
>
Hi Callum,

can you share your version of the setup?

Also do you use OVS switch type in the cluster?

Regards,
Ales.


-- 

ALES MUSIL
INTERN - rhv network

Red Hat EMEA 


amu...@redhat.com   IM: amusil

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: [ovirt-devel] Re: Mailing-Lists upgrade

[Duck]

Quack,

On 05/08/2018 10:46 PM, Marc Dequènes (Duck) wrote:

> I added redirects for /mailman, /mailman/listinfo and
> /mailman/listinfo/. Do you see anything missing or not working?

My regexs were too broad and broke two API entries. That's what caused
the problem with the archives.

Pending messages have been archived. UI stats 9recent posts and so on)
are updated regularly but it may not reflect the current status instantly.

I'm monitoring the logs and will close the upstream bug when I'm sure
there is nothing else.

\_o<



signature.asc
Description: OpenPGP digital signature
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

[ovirt-users] Re: ovirt with multiple engines

[Maor Lipchuk]

On Thu, May 17, 2018 at 2:00 AM, Nir Soffer  wrote:

> On Wed, May 16, 2018 at 7:37 PM Michael Watters 
> wrote:
>
>> Is it possible to have multiple engines with different versions of ovirt
>> running in the same cluster?  I am working on a plan to upgrade our
>> ovirt cluster to the 4.2 release however we would like to have a
>> rollback plan in case there are issues with the new engine.
>>
>
> You can run multiple engines, each on a different host (or vm). Then
> you can remove entities from one engine and add them to the other.
> If something goes wrong, you can move the entities back to the orignal
> engine.
>
> I think the new DR support can make this process easy and robust,
> but not sure it works with older engine versions.
>

DR supports engine 4.2 and above, but the usecase is a bit different than
what's described.
You can try to use replicated storage domains in the new setup, and then
try to register those VMs and upgrade them to cluster 4.2
If any problem will occur you can shutdown the hosts in the new setup and
start the old setup back again.


>
> Adding Maor to add more info on this direction.
>
> I think that hosted engine upgrade flow may also be useful, dumping
> engine database on the old engine, and restoring it to a new engine,
> and it may work better for upgrading between different versions.
>
> Simone is the expert in this area.
>
> Nir
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org