[ovirt-users] Re: ovirt-node: freshly installed node: network interfaces not visible

[etienne . charlier]

Hello Ales,

Thanks for the answer !

I tried multiple time to refresh capabilities... without success

For the record, the tab named "Host Devices" is also empty 

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

[ovirt-users] Re: ovirt-node: freshly installed node: network interfaces not visible

[Ales Musil]

On Mon, May 28, 2018 at 3:50 PM, 
wrote:

> Hello,
>
> I'm deploying a test cluster to get used to the ovirt product.
> My ovirt ( 4.2.2) engine is deployed in a vmware virtual machine.
>
> I'm busy deploying 5 hosts using the ovirt-node iso.
>
> I have issue with the additional physical network interface ( used for vm
> trafic and iSCSI)
>
> In ovirt manager I can't see the physical network interfaces. It's thus
> not possible to assign logical network to physical interfaces and my hosts
> stays in "non operational" status.
>
> How should  I configure the additional interfaces in the  ovirt-node
> installer to have them recognized ?
>
> I somehow managed to configure one host and I can see a comment line in
> /etc/sysconfig/network-script/ifcfg-... saying vdsm has acquired the
> interface
> No Such line in the ifcfg-* file in non operational hosts
>
> Any idea ?
> Etienne
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/XZO4THOPXNKQQDBJB7NBYRY5JLLNMQY5/
>

Hello Etienne,

have you tried to refresh capabilities on this host? It can be done via UI:
Compute -> Hosts -> Desired host -> Managment -> Refresh Capabilities.

Let me know if it helps.

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
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7NULNFW7UGVSQDMXANR4WITCVJUQCAOX/

[ovirt-users] Re: oVirt: single host install

[Sahina Bose]

On Tue, May 22, 2018 at 12:17 AM, Justin Zygmont 
wrote:

>
>
> -Original Message-
> From: Derek Atkins [mailto:warl...@mit.edu]
> Sent: Monday, May 21, 2018 8:33 AM
> To: Simone Tiraboschi 
> Cc: users ; ov...@fateknollogee.com
> Subject: [ovirt-users] Re: oVirt: single host install
>
> Hi,
>
> Simone Tiraboschi  writes:
>
> > On Mon, May 21, 2018 at 7:49 AM,  wrote:
> >
> > Use case: small sites with a minimum number of vm's.
> >
> > Is there such a thing as a single host install?
> >
> > In the past we had the all-in-one mode but we deprecated it.
> > Now the suggested mode is hosted-engine since you could expand it
> > adding other hosts in the future.
> >
>
> Sounds like "local storage" is useless then?
>
> I am running in this configuration and have had little problem.  I
> migrated from an old vmware-server platform, and, modulo a few hiccups
> along the way and a few false starts as I was installing ovirt, it's been
> pretty stable for me!
>
> Did you use NFS for all storage domains?
>
>
> > Is it valid for production use?
> >
> > With a single host the upgrades will become more intrusive: without
> > the capability to migrate your VMs on other hosts at upgrade time, you
> > will be required to bring down everything.
> >
>
> This is true -- I have to bring everything down when I want to upgrade the
> system, especially the host itself.  So I don't upgrade as often as I might
> if I had multiple hosts where I could migrate.
>
> How can you do it without a second host and importing with a temporary
> storage domain?
>
>
> > What kind of storage?
> >
> > NFS in loopback could be problematic, I'd suggest gluster in replica 1
> > or iSCSI.
>
> I'm running loopback NFS and I've not encountered any issues.  I've been
> running this way since 2016-10-22.  I did not understand Gluster enough and
> wasn't sure how I could make a "replica 1" -- everything seemed to imply
> you *NEEDED* 3 gluster hosts.  So I went with what I knew -- NFS.
>

We did add support for single node gluster volume in 4.2 - see
https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Single_node_hyperconverged/


> This might be problematic if I move forward to a multi-host platform as
> I'll have to "migrate" my storage -- specifically for hosted-engine --
> which IIRC requires a re-install (or some other drastic measure).
>
> -derek
>
> --
>Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>Member, MIT Student Information Processing Board  (SIPB)
>URL: https://urldefense.proofpoint.com/v2/url?u=http-3A__web.mit.
> edu_warlord_&d=DwIGaQ&c=Vxt5e0Osvvt2gflwSlsJ5DmPGcPvTRKLJyp031rXjhg&r=
> FiPhL0Cl1ymZlnTyAIIL75tE4L0reHcDdD-7wUtUGHA&m=
> aceiPp0tdZww5F1VjIbEi55JnMpkWzYlKSpsa56bcG8&s=
> Sxh76egRoJB5MNDdFRR9NubIiPK1tqZlSyW9tt4XzRQ&e=PP-ASEL-IA N1NWH
>warl...@mit.eduPGP key available
> ___
> 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
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/B6VS3NG6Y6BQYV2TWUF56TBWHZ7SSARJ/

[ovirt-users] Re: Gluster problems, cluster performance issues

[Sahina Bose]

[Adding gluster-users to look at the heal issue]

On Tue, May 29, 2018 at 9:17 AM, Jim Kusznir  wrote:

> Hello:
>
> I've been having some cluster and gluster performance issues lately.  I
> also found that my cluster was out of date, and was trying to apply updates
> (hoping to fix some of these), and discovered the ovirt 4.1 repos were
> taken completely offline.  So, I was forced to begin an upgrade to 4.2.
> According to docs I found/read, I needed only add the new repo, do a yum
> update, reboot, and be good on my hosts (did the yum update, the
> engine-setup on my hosted engine).  Things seemed to work relatively well,
> except for a gluster sync issue that showed up.
>
> My cluster is a 3 node hyperconverged cluster.  I upgraded the hosted
> engine first, then engine 3.  When engine 3 came back up, for some reason
> one of my gluster volumes would not sync.  Here's sample output:
>
> [root@ovirt3 ~]# gluster volume heal data-hdd info
> Brick 172.172.1.11:/gluster/brick3/data-hdd
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-
> 7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-
> f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-
> b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-
> d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-
> 6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-
> 0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-
> e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-
> b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2
> Status: Connected
> Number of entries: 8
>
> Brick 172.172.1.12:/gluster/brick3/data-hdd
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-
> 7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-
> f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-
> 0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-
> b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-
> d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-
> e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-
> b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-
> 6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b
> Status: Connected
> Number of entries: 8
>
> Brick 172.172.1.13:/gluster/brick3/data-hdd
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-
> 0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-
> e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-
> b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-
> 6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-
> f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-
> 7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-
> b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba
> /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-
> d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625
> Status: Connected
> Number of entries: 8
>
> -
> Its been in this state for a couple days now, and bandwidth monitoring
> shows no appreciable data moving.  I've tried repeatedly commanding a full
> heal from all three clusters in the node.  Its always the same files that
> need healing.
>
> When running gluster volume heal data-hdd statistics, I see sometimes
> different information, but always some number of "heal failed" entries.  It
> shows 0 for split brain.
>
> I'm not quite sure what to do.  I suspect it may be due to nodes 1 and 2
> still being on the older ovirt/gluster release, but I'm afraid to upgrade
> and reboot them until I have a good gluster sync (don't need to create a
> split brain issue).  How do I proceed with this?
>
> Second issue: I've been experiencing VERY POOR performance on most of my
> VMs.

[ovirt-users] Gluster problems, cluster performance issues

[Jim Kusznir]

Hello:

I've been having some cluster and gluster performance issues lately.  I
also found that my cluster was out of date, and was trying to apply updates
(hoping to fix some of these), and discovered the ovirt 4.1 repos were
taken completely offline.  So, I was forced to begin an upgrade to 4.2.
According to docs I found/read, I needed only add the new repo, do a yum
update, reboot, and be good on my hosts (did the yum update, the
engine-setup on my hosted engine).  Things seemed to work relatively well,
except for a gluster sync issue that showed up.

My cluster is a 3 node hyperconverged cluster.  I upgraded the hosted
engine first, then engine 3.  When engine 3 came back up, for some reason
one of my gluster volumes would not sync.  Here's sample output:

[root@ovirt3 ~]# gluster volume heal data-hdd info
Brick 172.172.1.11:/gluster/brick3/data-hdd
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2
Status: Connected
Number of entries: 8

Brick 172.172.1.12:/gluster/brick3/data-hdd
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b
Status: Connected
Number of entries: 8

Brick 172.172.1.13:/gluster/brick3/data-hdd
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba
/cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625
Status: Connected
Number of entries: 8

-
Its been in this state for a couple days now, and bandwidth monitoring
shows no appreciable data moving.  I've tried repeatedly commanding a full
heal from all three clusters in the node.  Its always the same files that
need healing.

When running gluster volume heal data-hdd statistics, I see sometimes
different information, but always some number of "heal failed" entries.  It
shows 0 for split brain.

I'm not quite sure what to do.  I suspect it may be due to nodes 1 and 2
still being on the older ovirt/gluster release, but I'm afraid to upgrade
and reboot them until I have a good gluster sync (don't need to create a
split brain issue).  How do I proceed with this?

Second issue: I've been experiencing VERY POOR performance on most of my
VMs.  To the tune that logging into a windows 10 vm via remote desktop can
take 5 minutes, launching quickbooks inside said vm can easily take 10
minutes.  On some linux VMs, I get random messages like this:
Message from syslogd@unifi at May 28 20:39:23 ...
 kernel:[6171996.308904] NMI watchdog: BUG: soft lo

[ovirt-users] Re: cache and viodiskcache parameters in documentation

[stefanos]

Thank you Yaniv for the clarification.

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

[ovirt-users] Re: Failure to import a VM

[Arik Hadas]

On Mon, May 28, 2018 at 7:55 PM, Aziz  wrote:

> Hi All,
>
> I'm getting an error when trying to import an OVA file to my oVirt. It
> seems that a JAVA command is failing with an exception :
>
> Here are the logs from the engine.log file, while importing the OVA file.
>
> 2018-05-28 16:47:09,491Z ERROR 
> [org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand]
> (EE-ManagedThreadFactory-engine-Thread-19767) 
> [e0306ff3-db73-4030-924b-57d86023db28]
> Command 'org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand'
> failed: For input string: ""
> 2018-05-28 16:47:09,491Z ERROR 
> [org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand]
> (EE-ManagedThreadFactory-engine-Thread-19767) 
> [e0306ff3-db73-4030-924b-57d86023db28]
> Exception: java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> [rt.jar:1.8.0_171]
> at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_171]
> at 
> org.ovirt.engine.core.utils.MacAddressRangeUtils.macToLong(MacAddressRangeUtils.java:124)
> [utils.jar:]
> at org.ovirt.engine.core.bll.network.macpool.MacPoolUsingRanges.
> isMacInRange(MacPoolUsingRanges.java:193) [bll.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_171]
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_171]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_171]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_171]
> at org.ovirt.engine.core.utils.lock.LockedObjectFactory$
> LockingInvocationHandler.invoke(LockedObjectFactory.java:66) [utils.jar:]
> at com.sun.proxy.$Proxy187.isMacInRange(Unknown Source)
> at java.util.function.Predicate.lambda$negate$1(Predicate.java:80)
> [rt.jar:1.8.0_171]
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> [rt.jar:1.8.0_171]
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> [rt.jar:1.8.0_171]
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> [rt.jar:1.8.0_171]
> at java.util.ArrayList$ArrayListSpliterator.
> forEachRemaining(ArrayList.java:1382) [rt.jar:1.8.0_171]
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> [rt.jar:1.8.0_171]
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> [rt.jar:1.8.0_171]
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [rt.jar:1.8.0_171]
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [rt.jar:1.8.0_171]
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [rt.jar:1.8.0_171]
> at org.ovirt.engine.core.bll.network.vm.ExternalVmMacsFinder.
> findExternalMacAddresses(ExternalVmMacsFinder.java:37) [bll.jar:]
> at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.
> reportExternalMacs(ImportVmCommandBase.java:512) [bll.jar:]
> at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.
> addVmInterfaces(ImportVmCommandBase.java:640) [bll.jar:]
> at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.lambda$
> addVmToDb$2(ImportVmCommandBase.java:533) [bll.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.
> executeInNewTransaction(TransactionSupport.java:202) [utils.jar:]
> at org.ovirt.engine.core.bll.exportimport.
> ImportVmCommandBase.addVmToDb(ImportVmCommandBase.java:529) [bll.jar:]
> at org.ovirt.engine.core.bll.exportimport.
> ImportVmFromExternalProviderCommand.addVmToDb(
> ImportVmFromExternalProviderCommand.java:364) [bll.jar:]
> at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.
> executeVmCommand(ImportVmCommandBase.java:474) [bll.jar:]
> at org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:161)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1133)
> [bll.jar:]
> at org.ovirt.engine.core.bll.CommandBase.
> executeActionInTransactionScope(CommandBase.java:1285) [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1934)
> [bll.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.
> executeInSuppressed(TransactionSupport.java:164) [utils.jar:]
> at org.ovirt.engine.core.utils.transaction.TransactionSupport.
> executeInScope(TransactionSupport.java:103) [utils.jar:]
> at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1345)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:400)
> [bll.jar:]
> at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRu
> nner.executeValidatedCommand(PrevalidatingMultipleActionsRunner.java:204)
> [bll.jar:]
> at org.ov

[ovirt-users] Re: [ovirt-announce] CVE-2018-3639 - Important - oVirt - Speculative Store Bypass

[Yaniv Kaul]

On Mon, May 28, 2018 at 3:40 PM, Nathanaël Blanchet 
wrote:

> XP has reached is end of life in may 14 and Microsoft decided to release
> an exceptionnal update because of a critical leak last year... so all is
> possible when it is about criticity!
>

All is indeed possible. We always welcome contribution to the oVirt
project, and you can send patches that backport the 4.2 patches to 4.1 and
build it.
Y.

> https://www.microsoft.com/en-us/download/details.aspx?id=18770
>
> Le 28/05/2018 à 14:23, Sandro Bonazzola a écrit :
>
>
>
> 2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet :
>
>> Hello,
>>
>> Will a 4.1.9.x security update be released for those who can't migrate to
>> 4.2.3.7 for any reasons?
>>
> No. oVirt 4.1 reached end of life with 4.1.9 https://lists.ovirt.org/
> pipermail/announce/2018-January/000383.html
> Please consider updating to 4.2 as soon as practical / possible.
>
>
>
>>
>> Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
>>
>> As you may have already heard, an industry-wide issue was found in the
>> way many modern microprocessor designs have implemented speculative
>> execution of Load & Store instructions.
>> This issue is well described by CVE-2018-3639 announce available at
>> https://access.redhat.com/security/cve/cve-2018-3639.
>>
>> oVirt team has released right now an update of ovirt-engine to version
>> 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security
>> issue.
>>
>> If you are running oVirt on Red Hat Enterprise Linux, please apply
>> updates described in https://access.redhat.com/security/cve/cve-2018-3639
>> .
>>
>> If you are running oVirt on CentOS Linux please apply updated described
>> by:
>> CESA-2018:1629 Important CentOS 7 kernel Security Update
>> 
>>
>> CESA-2018:1632 Important CentOS 7 libvirt Security Update
>> 
>> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update
>> 
>>
>> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update
>> 
>>
>>
>> An update for qemu-kvm-ev has been also tagged for release and announced
>> with
>> CESA-2018:1655 Important: qemu-kvm-ev security update
>> 
>> but due to some issues in CentOS release process for Virt SIG content, it
>> is not yet available on mirrors.
>> We are working with CentOS community to get the packages signed and
>> published as soon as possible.
>> In the meanwhile you can still get the update package by enabling the
>> test repository https://buildlogs.centos.org/centos/7/virt/x86_64
>> /kvm-common/ on your systems or manually installing the package from the
>> repository.
>>
>> If you're running oVirt on a different Linux distribution, please check
>> with your vendor for available updates.
>>
>> Please note that to fully mitigate this vulnerability, system
>> administrators must apply both hardware “microcode” updates and software
>> patches that enable new functionality.
>> At this time, microprocessor microcode will be delivered by the
>> individual manufacturers.
>>
>> The oVirt team recommends end users and systems administrator to apply
>> any available updates as soon as practical.
>>
>> Thanks,
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>> 
>>
>>
>> ___
>> Announce mailing list -- annou...@ovirt.org
>> To unsubscribe send an email to announce-le...@ovirt.org
>>
>>
>> --
>> Nathanaël Blanchet
>>
>> Supervision réseau
>> Pôle Infrastrutures Informatiques227 avenue Professeur-Jean-Louis-Viala 
>> 
>> 34193 MONTPELLIER CEDEX 5
>> Tél. 33 (0)4 67 54 84 55
>> Fax  33 (0)4 67 54 84 14blanc...@abes.fr
>>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
>
>
> --
> Nathanaël Blanchet
>
> Supervision réseau
> Pôle Infrastrutures Informatiques
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5 
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14blanc...@abes.fr
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org

[ovirt-users] Re: cache and viodiskcache parameters in documentation

[Yaniv Kaul]

On Mon, May 28, 2018 at 5:18 PM,  wrote:

> Hi,
>
> on chapter 6.13.1 "Live Migration Prerequisites" [1] of the RHV 4.2
> Virtual Machine Management Guide, there is written:
> 
>
> At a minimum, for successful live migration of virtual machines to be
> possible:
> [...]
> The migrating virtual machine must not have the cache!=none custom
> property set.
> 
>
> However I can't find any custom property called "cache" under Edit Virtual
> Machine --> Custom Properties but only "viodiskcache". As a matter of fact,
> Appendix A of the same guide [2] reports the following statement: "If
> viodiskcache is enabled, the virtual machine cannot be live migrated" that
> suggest viodiskcache as the correct parameter.
>
> Are the two statements contradictory?
>

cache != none is a developer terminology for stating that it has to be
none. So if it's defined to anything, migration is not possible. So they
are the same.
Y.


>
> Thank you.
> Stefano Stagnaro
>
> [1] https://access.redhat.com/documentation/en-us/red_hat_
> virtualization/4.2/html/virtual_machine_management_
> guide/sect-migrating_virtual_machines_between_hosts#Live_
> migration_prerequisites
> [2] https://access.redhat.com/documentation/en-us/red_hat_
> virtualization/4.2/html/virtual_machine_management_
> guide/appe-reference_settings_in_administration_portal_and_
> user_portal_windows#Virtual_Machine_Custom_Properties_settings_explained
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/4N3MS5TRH3GTSREOCH2MIXY2IUXGY35H/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OIU6S4225WW53LTIU47YFG43FJPSMHYH/

[ovirt-users] Re: Bad volume specification

[Bryan Sockel]

Permissions all seem to be correct, path is accessible, can run other vm's 
off the same storage domain.

Thank You,

From: "Oliver Riesener (oliver.riese...@hs-bremen.de)" 

To: Bryan Sockel 
Cc: "users@ovirt.org" 
Date: Sun, 27 May 2018 15:38:32 +0200
Subject: [ovirt-users] Re: Bad volume specification

Hi,

check what wrong with your **PATH**:

permissions, lvm, device-mapper, NFS, iSCSI, etc.

Am 27.05.2018 um 15:28 schrieb Bryan Sockel :

 'path': 
'/rhev/data-center/9e7d643c-592d-11e8-82eb-005056b41d15/2b79768f-a329-4eab-81e0-120a81ac8906/images/ec7a3258-7a99-4813-aa7d-dceb727a1975/8f4ddee4-68b3-48e9-be27-0231557f5218'___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/G2CSVVM5BPSBMCS4VBC35IHNZUMQJW3D/

[ovirt-users] Failure to import a VM

[Aziz]

Hi All,

I'm getting an error when trying to import an OVA file to my oVirt. It
seems that a JAVA command is failing with an exception :

Here are the logs from the engine.log file, while importing the OVA file.

2018-05-28 16:47:09,491Z ERROR
[org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand]
(EE-ManagedThreadFactory-engine-Thread-19767)
[e0306ff3-db73-4030-924b-57d86023db28] Command
'org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand' failed: For
input string: ""
2018-05-28 16:47:09,491Z ERROR
[org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand]
(EE-ManagedThreadFactory-engine-Thread-19767)
[e0306ff3-db73-4030-924b-57d86023db28] Exception:
java.lang.NumberFormatException: For input string: ""
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
[rt.jar:1.8.0_171]
at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_171]
at
org.ovirt.engine.core.utils.MacAddressRangeUtils.macToLong(MacAddressRangeUtils.java:124)
[utils.jar:]
at
org.ovirt.engine.core.bll.network.macpool.MacPoolUsingRanges.isMacInRange(MacPoolUsingRanges.java:193)
[bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_171]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[rt.jar:1.8.0_171]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_171]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_171]
at
org.ovirt.engine.core.utils.lock.LockedObjectFactory$LockingInvocationHandler.invoke(LockedObjectFactory.java:66)
[utils.jar:]
at com.sun.proxy.$Proxy187.isMacInRange(Unknown Source)
at java.util.function.Predicate.lambda$negate$1(Predicate.java:80)
[rt.jar:1.8.0_171]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
[rt.jar:1.8.0_171]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
[rt.jar:1.8.0_171]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
[rt.jar:1.8.0_171]
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
[rt.jar:1.8.0_171]
at
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
[rt.jar:1.8.0_171]
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
[rt.jar:1.8.0_171]
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
[rt.jar:1.8.0_171]
at
java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
[rt.jar:1.8.0_171]
at
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
[rt.jar:1.8.0_171]
at
org.ovirt.engine.core.bll.network.vm.ExternalVmMacsFinder.findExternalMacAddresses(ExternalVmMacsFinder.java:37)
[bll.jar:]
at
org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.reportExternalMacs(ImportVmCommandBase.java:512)
[bll.jar:]
at
org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.addVmInterfaces(ImportVmCommandBase.java:640)
[bll.jar:]
at
org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.lambda$addVmToDb$2(ImportVmCommandBase.java:533)
[bll.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202)
[utils.jar:]
at
org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.addVmToDb(ImportVmCommandBase.java:529)
[bll.jar:]
at
org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand.addVmToDb(ImportVmFromExternalProviderCommand.java:364)
[bll.jar:]
at
org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.executeVmCommand(ImportVmCommandBase.java:474)
[bll.jar:]
at
org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:161)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1133)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1285)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1934)
[bll.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164)
[utils.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103)
[utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1345)
[bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:400)
[bll.jar:]
at
org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.executeValidatedCommand(PrevalidatingMultipleActionsRunner.java:204)
[bll.jar:]
at
org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.runCommands(PrevalidatingMultipleActionsRunner.java:176)
[bll.jar:]
at
org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.lambda$invokeCommands$3(PrevalidatingMultipleActionsRunner.java:182)
[bll.jar:]
at
or

[ovirt-users] second deploy hosted engine, engine VM is shut dwon

[dhy336]

HiI first deploy hosted engine is failed， then deploy hosted engine, after 
ansible run "name: Add host ovirt_hosts:"(bootstrap_local_vm.yml), engine VM is 
shut dwon, why to shutown engine VM?___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q6FOBLUAV46IRPJYSRBKZFGTPW4CT4LN/

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Kevin Wolf]

Am 28.05.2018 um 16:06 hat Tomáš Golembiovský geschrieben:
> 
> On Mon, 28 May 2018 13:37:59 +0200
> Kevin Wolf  wrote:
> 
> > Am 28.05.2018 um 12:27 hat Arik Hadas geschrieben:
> > > On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf  wrote:
> > >   
> > > > [ Adding qemu-block ]
> > > >
> > > > Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben:  
> > > > > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer  
> > > > > wrote:
> > > > >  
> > > > > > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko <  
> > > > m.vrgo...@activevideo.com>  
> > > > > > wrote:
> > > > > >  
> > > > > >> Dear Nir,
> > > > > >>
> > > > > >> Thank you for quick reply.
> > > > > >>
> > > > > >> Ok, why it will not work?
> > > > > >>  
> > > > > >
> > > > > > Because the image has a backing file which is not accessible to 
> > > > > > oVirt.
> > > > > >
> > > > > >  
> > > > > >> I used qemu+tcp connection, via import method through engine admin 
> > > > > >> UI.
> > > > > >>
> > > > > >> Images was imported and converted according logs, still “backing 
> > > > > >> file”
> > > > > >> invalid entry remained.
> > > > > >>
> > > > > >> Also, I did use same method before, connecting to plain “libvirt 
> > > > > >> kvm”
> > > > > >> host, import and conversion went smooth, no backend file.
> > > > > >>
> > > > > >> Image format is qcow(2) which is supported by oVirt.
> > > > > >>
> > > > > >> What am I missing? Should I use different method?
> > > > > >>  
> > > > > >
> > > > > > I guess this is not a problem on your side, but a bug in our side.
> > > > > >
> > > > > > Either we should block the operation that cannot work, or fix the  
> > > > process  
> > > > > > so we don't refer to non-existing image.
> > > > > >
> > > > > > When importing we have 2 options:
> > > > > >
> > > > > > - import the entire chain,  importing all images in the chain,  
> > > > converting  
> > > > > >  each image to oVirt volume, and updating the backing file of each  
> > > > layer  
> > > > > > to point to the oVirt image.
> > > > > >
> > > > > > - import the current state of the image into a new image, using 
> > > > > > either  
> > > > raw  
> > > > > > or qcow2, but without any backing file.
> > > > > >
> > > > > > Arik, do you know why we create qcow2 file with invalid backing 
> > > > > > file?
> > > > > >  
> > > > >
> > > > > It seems to be a result of a bit naive behavior of the kvm2ovirt 
> > > > > module
> > > > > that tries to download only the top-level volume the VM uses, 
> > > > > assuming  
> > > > each  
> > > > > of the disks to be imported is comprised of a single volume.
> > > > >
> > > > > Maybe it's time to finally asking QEMU guys to provide a way to 
> > > > > consume  
> > > > the  
> > > > > 'collapsed' form of a chain of volumes as a stream if that's not  
> > > > available  
> > > > > yet? ;) It can also boost the recently added process of exporting VMs 
> > > > > as
> > > > > OVAs...  
> > > >
> > > > Not sure which operation we're talking about on the QEMU level, but
> > > > generally the "collapsed" view is the normal thing because that's what
> > > > guests see.
> > > >
> > > > For example, if you use 'qemu-img convert', you have to pass options to
> > > > specifically disable it and convert only a single layer if you want to
> > > > keep using backing files instead of getting a standalone image that
> > > > contains everything.
> > > >  
> > > 
> > > Yeah, some context was missing. Sorry about that.
> > > 
> > > Let me demonstrate briefly the flow for OVA:
> > > Let's say that we have a VM that is based on a template and has one disk
> > > and one snapshot, so its volume-chain would be:
> > > T -> S -> V
> > > (V is the volume the VM writes to, S is the backing file of V and T is the
> > > backing file of S).
> > > When exporting that VM to an OVA file we want the produced tar file to be
> > > comprised of:
> > > (1) OVF configuration
> > > (2) single disk volume (preferably qcow).
> > > 
> > > So we need to collapse T, S, V into a single volume.
> > > Sure, we can do 'qemu-img convert'. That's what we do now in oVirt 4.2:
> > > (a) qemu-img convert produces a 'temporary' collapsed volume
> > > (b) make a tar file of the OVf configuration and that 'temporary' volume
> > > (c) delete the temporary volume
> > > 
> > > But the fact that we produce that 'temporary' volume obviously slows down
> > > the entire operation.
> > > It would be much better if we could "open" a stream that we can read from
> > > the 'collapsed' form of that chain and stream it directly into the
> > > appropriate tar file entry, without extra writes to the storage device.
> > > 
> > > Few months ago people from the oVirt-storage team checked the qemu toolset
> > > and replied that this capability is not yet provided, therefore we
> > > implemented the workaround described above. Apparently, the desired 
> > > ability
> > > can also be useful for the flow discussed in this thread so it worth 
> > > asking
> > > for it again :)  
> > 
> > I think real streaming is 

[ovirt-users] Reference architecture for oVirt Gluster HCI

[Karli Sjöberg]

Hey!As above title suggests, I would like to know if there are any specific ones for HCI? I know there are for Gluster but I haven't found any specific for HCI, commonly smaller 1U systems for- lets say- a three node HCI cluster?TIA/K___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/A7JOYLMENNXOHMIQF5AVG5RWBLWAVNVK/

[ovirt-users] cache and viodiskcache parameters in documentation

[stefanos]

Hi,

on chapter 6.13.1 "Live Migration Prerequisites" [1] of the RHV 4.2 Virtual 
Machine Management Guide, there is written:


At a minimum, for successful live migration of virtual machines to be possible:
[...]
The migrating virtual machine must not have the cache!=none custom property 
set. 


However I can't find any custom property called "cache" under Edit Virtual 
Machine --> Custom Properties but only "viodiskcache". As a matter of fact, 
Appendix A of the same guide [2] reports the following statement: "If 
viodiskcache is enabled, the virtual machine cannot be live migrated" that 
suggest viodiskcache as the correct parameter.

Are the two statements contradictory?

Thank you.
Stefano Stagnaro

[1] 
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/virtual_machine_management_guide/sect-migrating_virtual_machines_between_hosts#Live_migration_prerequisites
[2] 
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/virtual_machine_management_guide/appe-reference_settings_in_administration_portal_and_user_portal_windows#Virtual_Machine_Custom_Properties_settings_explained
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4N3MS5TRH3GTSREOCH2MIXY2IUXGY35H/

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Tomáš Golembiovský]

On Mon, 28 May 2018 13:37:59 +0200
Kevin Wolf  wrote:

> Am 28.05.2018 um 12:27 hat Arik Hadas geschrieben:
> > On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf  wrote:
> >   
> > > [ Adding qemu-block ]
> > >
> > > Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben:  
> > > > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer  wrote:
> > > >  
> > > > > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko <  
> > > m.vrgo...@activevideo.com>  
> > > > > wrote:
> > > > >  
> > > > >> Dear Nir,
> > > > >>
> > > > >> Thank you for quick reply.
> > > > >>
> > > > >> Ok, why it will not work?
> > > > >>  
> > > > >
> > > > > Because the image has a backing file which is not accessible to oVirt.
> > > > >
> > > > >  
> > > > >> I used qemu+tcp connection, via import method through engine admin 
> > > > >> UI.
> > > > >>
> > > > >> Images was imported and converted according logs, still “backing 
> > > > >> file”
> > > > >> invalid entry remained.
> > > > >>
> > > > >> Also, I did use same method before, connecting to plain “libvirt kvm”
> > > > >> host, import and conversion went smooth, no backend file.
> > > > >>
> > > > >> Image format is qcow(2) which is supported by oVirt.
> > > > >>
> > > > >> What am I missing? Should I use different method?
> > > > >>  
> > > > >
> > > > > I guess this is not a problem on your side, but a bug in our side.
> > > > >
> > > > > Either we should block the operation that cannot work, or fix the  
> > > process  
> > > > > so we don't refer to non-existing image.
> > > > >
> > > > > When importing we have 2 options:
> > > > >
> > > > > - import the entire chain,  importing all images in the chain,  
> > > converting  
> > > > >  each image to oVirt volume, and updating the backing file of each  
> > > layer  
> > > > > to point to the oVirt image.
> > > > >
> > > > > - import the current state of the image into a new image, using 
> > > > > either  
> > > raw  
> > > > > or qcow2, but without any backing file.
> > > > >
> > > > > Arik, do you know why we create qcow2 file with invalid backing file?
> > > > >  
> > > >
> > > > It seems to be a result of a bit naive behavior of the kvm2ovirt module
> > > > that tries to download only the top-level volume the VM uses, assuming  
> > > each  
> > > > of the disks to be imported is comprised of a single volume.
> > > >
> > > > Maybe it's time to finally asking QEMU guys to provide a way to consume 
> > > >  
> > > the  
> > > > 'collapsed' form of a chain of volumes as a stream if that's not  
> > > available  
> > > > yet? ;) It can also boost the recently added process of exporting VMs as
> > > > OVAs...  
> > >
> > > Not sure which operation we're talking about on the QEMU level, but
> > > generally the "collapsed" view is the normal thing because that's what
> > > guests see.
> > >
> > > For example, if you use 'qemu-img convert', you have to pass options to
> > > specifically disable it and convert only a single layer if you want to
> > > keep using backing files instead of getting a standalone image that
> > > contains everything.
> > >  
> > 
> > Yeah, some context was missing. Sorry about that.
> > 
> > Let me demonstrate briefly the flow for OVA:
> > Let's say that we have a VM that is based on a template and has one disk
> > and one snapshot, so its volume-chain would be:
> > T -> S -> V
> > (V is the volume the VM writes to, S is the backing file of V and T is the
> > backing file of S).
> > When exporting that VM to an OVA file we want the produced tar file to be
> > comprised of:
> > (1) OVF configuration
> > (2) single disk volume (preferably qcow).
> > 
> > So we need to collapse T, S, V into a single volume.
> > Sure, we can do 'qemu-img convert'. That's what we do now in oVirt 4.2:
> > (a) qemu-img convert produces a 'temporary' collapsed volume
> > (b) make a tar file of the OVf configuration and that 'temporary' volume
> > (c) delete the temporary volume
> > 
> > But the fact that we produce that 'temporary' volume obviously slows down
> > the entire operation.
> > It would be much better if we could "open" a stream that we can read from
> > the 'collapsed' form of that chain and stream it directly into the
> > appropriate tar file entry, without extra writes to the storage device.
> > 
> > Few months ago people from the oVirt-storage team checked the qemu toolset
> > and replied that this capability is not yet provided, therefore we
> > implemented the workaround described above. Apparently, the desired ability
> > can also be useful for the flow discussed in this thread so it worth asking
> > for it again :)  
> 
> I think real streaming is unlikely to happen because most image formats
> that QEMU supports aren't made that way. If there is a compelling
> reason, we can consider it, but it would work only with very few target
> formats and as such would have to be separate from existing commands.
> 
> As for OVA files, I think it might be useful to have a tar block driver
> instead which would allow you to open a file inside a 

[ovirt-users] ovirt-node: freshly installed node: network interfaces not visible

[etienne . charlier]

Hello,

I'm deploying a test cluster to get used to the ovirt product.
My ovirt ( 4.2.2) engine is deployed in a vmware virtual machine.

I'm busy deploying 5 hosts using the ovirt-node iso.

I have issue with the additional physical network interface ( used for vm 
trafic and iSCSI)

In ovirt manager I can't see the physical network interfaces. It's thus not 
possible to assign logical network to physical interfaces and my hosts stays in 
"non operational" status.

How should  I configure the additional interfaces in the  ovirt-node installer 
to have them recognized ?

I somehow managed to configure one host and I can see a comment line in 
/etc/sysconfig/network-script/ifcfg-... saying vdsm has acquired the 
interface
No Such line in the ifcfg-* file in non operational hosts

Any idea ?
Etienne

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

[ovirt-users] Re: ovirt guest agent epel 6 and rhevm in the name

[Gianluca Cecchi]

On Mon, May 28, 2018 at 2:52 PM, Gianluca Cecchi 
wrote:

> Hello,
> I have updated one test environment to 4.2 (it was in 4.1.9)
> I have a guest in Oracle Linux 6 and epel 6 repo enabled.
> After powering down and start the VM, I saw the exclamation mark regarding
> ovirt-guest-agent latest version needed.
>
> On the VM the process was dead and I took the time of updatng it
> from ovirt-guest-agent-1.0.12-4.el6.noarch
> to ovirt-guest-agent-1.0.13-2.el6.noarch
>
> and start the agent.
> All seems ok; no exclamation mark now and I see the ip addresses of the
> guest in 4.2 web admin gui.
>
>

Actually, after comparing better timestamps, the ERROR line is related to
the old version of ovirt-guest-agent (1.0.12-4) and it was indeed that
version that caused the agent to die:

# service ovirt-guest-agent status
ovirt-guest-agent dead but pid file exists
#

After updating to 1.0.13-2 and starting the agent, all is ok and the only
lines in agent log file are:

MainThread::INFO::2018-05-28
14:57:22,417::ovirt-guest-agent::59::root::Starting oVirt guest agent
CredServer::INFO::2018-05-28
14:57:22,495::CredServer::258::root::CredServer is running...
Dummy-1::INFO::2018-05-28
14:57:22,496::OVirtAgentLogic::321::root::Received an external command:
refresh...
Dummy-1::INFO::2018-05-28
14:57:22,917::OVirtAgentLogic::321::root::Received an external command:
lock-screen...

Sorry for the noise,

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

[ovirt-users] Re: Gluster quorum

[Demeter Tibor]

Hi, 
Ok I will try it. 

In this case, is it possible to remove and re-add a host that member of HA 
gluster ? This is an another task, but I need to separate my gluster network 
from my ovirtmgmt network. 
What is the recommended way for do this? 

It is not important now, but I need to do in future. 

I will attach my engine.log after upgrade my host. 

Thanks, 
Regards. 

Tibor 

- 2018. máj.. 28., 14:44, Sahina Bose  írta: 

> On Mon, May 28, 2018 at 4:47 PM, Demeter Tibor < [ mailto:tdeme...@itsmart.hu 
> |
> tdeme...@itsmart.hu ] > wrote:

>> Dear Sahina,

>> Yes, exactly. I can check that check box, but I don't know how is safe that. 
>> Is
>> it safe?

> It is safe - if you can ensure that only one host is put into maintenance at a
> time.

>> I want to upgrade all of my host. If it will done, then the monitoring will 
>> work
>> perfectly?

> If it does not please provide engine.log again once you've upgraded all the
> hosts.

>> Thanks.
>> R.

>> Tibor

>> - 2018. máj.. 28., 10:09, Sahina Bose < [ mailto:sab...@redhat.com |
>> sab...@redhat.com ] > írta:

>>> On Mon, May 28, 2018 at 1:06 PM, Demeter Tibor < [ 
>>> mailto:tdeme...@itsmart.hu |
>>> tdeme...@itsmart.hu ] > wrote:

 Hi,

 Somebody could answer to my question please?
 It is very important for me, I could no finish my upgrade process (from 
 4.1 to
 4.2) since 9th May!

>>> Can you explain how the upgrade process is blocked due to the monitoring?
>>> If it's because you cannot move the host to maintenance, can you try with 
>>> the
>>> option "Ignore quorum checks" enabled?

 Meanwhile - I don't know why - one of my two gluster volume seems UP 
 (green) on
 the GUI. So, now only one is down.

 I need help. What can I do?

 Thanks in advance,

 Regards,

 Tibor

 - 2018. máj.. 23., 21:09, Demeter Tibor < [ mailto:tdeme...@itsmart.hu 
 |
 tdeme...@itsmart.hu ] > írta:

> Hi,

> I've updated again to the latest version, but there are no changes. All of
> bricks on my first node are down in the GUI (in console are ok)
> An Interesting thing, the "Self-Heal info" column show "OK" for all hosts 
> and
> all bricks, but "Space used" column is zero for all hosts/bricks.
> Can I force remove and re-add my host to cluster awhile it is a gluster 
> member?
> Is it safe ?
> What can I do?

> I haven't update other hosts while gluster not working fine, or the GUI 
> does not
> detect . So my other hosts is remained 4.1 yet :(

> Thanks in advance,

> Regards

> Tibor

> - 2018. máj.. 23., 14:45, Denis Chapligin < [ 
> mailto:dchap...@redhat.com |
> dchap...@redhat.com ] > írta:

>> Hello!

>> On Tue, May 22, 2018 at 11:10 AM, Demeter Tibor < [ 
>> mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > wrote:

>>> Is there any changes with this bug?

>>> Still I haven't finish my upgrade process that i've started on 9th may:(

>>> Please help me if you can.

>> Looks like all required patches are already merged, so could you please 
>> to
>> update your engine again to the latest night build?

> ___
> Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ]
> To unsubscribe send an email to [ mailto:users-le...@ovirt.org |
> users-le...@ovirt.org ]

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

[ovirt-users] ovirt guest agent epel 6 and rhevm in the name

[Gianluca Cecchi]

Hello,
I have updated one test environment to 4.2 (it was in 4.1.9)
I have a guest in Oracle Linux 6 and epel 6 repo enabled.
After powering down and start the VM, I saw the exclamation mark regarding
ovirt-guest-agent latest version needed.

On the VM the process was dead and I took the time of updatng it
from ovirt-guest-agent-1.0.12-4.el6.noarch
to ovirt-guest-agent-1.0.13-2.el6.noarch

and start the agent.
All seems ok; no exclamation mark now and I see the ip addresses of the
guest in 4.2 web admin gui.

But in log of ovirt-guest-agent I see:

MainThread::ERROR::2018-05-28
14:34:55,711::ovirt-guest-agent::140::root::Unhandled exception in oVirt
guest agent!
Traceback (most recent call last):
  File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 134, in

agent.run(daemon, pidfile)
  File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in run
self.agent = LinuxVdsAgent(config)
  File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 466, in
__init__
AgentLogicBase.__init__(self, config)
  File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in
__init__
self.vio = VirtIoChannel(config.get("virtio", "device"))
  File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 151, in
__init__
self._stream = VirtIoStream(vport_name)
  File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 132, in
__init__
self._vport = os.open(vport_name, os.O_RDWR)
OSError: [Errno 2] No such file or directory:
'/dev/virtio-ports/com.redhat.rhevm.vdsm'
MainThread::INFO::2018-05-28
14:42:45,535::ovirt-guest-agent::59::root::Starting oVirt guest agent

The status of files under the indicated directory is:

# ll /dev/virtio-ports/
total 0
lrwxrwxrwx 1 root root 11 May 28 14:34 com.redhat.spice.0 -> ../vport0p3
lrwxrwxrwx 1 root root 11 May 28 14:34 org.qemu.guest_agent.0 -> ../vport0p2
lrwxrwxrwx 1 root root 11 May 28 14:42 ovirt-guest-agent.0 -> ../vport0p1
#

Anything to be done at my side at guest/host configuration level?

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

[ovirt-users] Re: Gluster quorum

[Sahina Bose]

On Mon, May 28, 2018 at 4:47 PM, Demeter Tibor  wrote:

> Dear Sahina,
>
> Yes, exactly. I can check that check box, but I don't know how is safe
> that. Is it safe?
>

It is safe - if you can ensure that only one host is put into maintenance
at a time.

>
> I want to upgrade all of my host. If it will done, then the monitoring
> will work perfectly?
>

If it does not please provide engine.log again once you've upgraded all the
hosts.


> Thanks.
> R.
>
> Tibor
>
>
>
> - 2018. máj.. 28., 10:09, Sahina Bose  írta:
>
>
>
> On Mon, May 28, 2018 at 1:06 PM, Demeter Tibor 
> wrote:
>
>> Hi,
>>
>> Somebody could answer to my question please?
>> It is very important for me, I could no finish my upgrade process (from
>> 4.1 to 4.2) since 9th May!
>>
>
> Can you explain how the upgrade process is blocked due to the monitoring?
> If it's because you cannot move the host to maintenance, can you try with
> the option "Ignore quorum checks" enabled?
>
>
>> Meanwhile - I don't know why - one of my two gluster volume seems UP
>> (green) on the GUI. So, now only one is down.
>>
>> I need help. What can I do?
>>
>> Thanks in advance,
>>
>> Regards,
>>
>> Tibor
>>
>>
>> - 2018. máj.. 23., 21:09, Demeter Tibor  írta:
>>
>> Hi,
>>
>> I've updated again to the latest version, but there are no changes. All
>> of bricks on my first node are down in the GUI (in console are ok)
>> An Interesting thing, the "Self-Heal info" column show "OK" for all hosts
>> and all bricks, but "Space used" column is zero for all hosts/bricks.
>> Can I force remove and re-add my host to cluster awhile it is a gluster
>> member? Is it safe ?
>> What can I do?
>>
>> I haven't update other hosts while gluster not working fine, or the GUI
>> does not detect . So my other hosts is remained 4.1 yet :(
>>
>> Thanks in advance,
>>
>> Regards
>>
>> Tibor
>>
>> - 2018. máj.. 23., 14:45, Denis Chapligin  írta:
>>
>> Hello!
>>
>> On Tue, May 22, 2018 at 11:10 AM, Demeter Tibor 
>> wrote:
>>
>>>
>>> Is there any changes with this bug?
>>>
>>> Still I haven't finish my upgrade process that i've started on 9th may:(
>>>
>>> Please help me if you can.
>>>
>>>
>>
>> Looks like all required patches are already merged, so could you please
>> to update your engine again to the latest night build?
>>
>>
>> ___
>> 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
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
>> guidelines/
>> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
>> message/MRAAPZSRIXLAJZBV6TRDXXK7R2ISPSDK/
>>
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/A6FFC37LB6CNDTXW2PYFLIYRW7OVFRYW/

[ovirt-users] Re: [ovirt-announce] CVE-2018-3639 - Important - oVirt - Speculative Store Bypass

[Nathanaël Blanchet]

XP has reached is end of life in may 14 and Microsoft decided to release 
an exceptionnal update because of a critical leak last year... so all is 
possible when it is about criticity!


https://www.microsoft.com/en-us/download/details.aspx?id=18770


Le 28/05/2018 à 14:23, Sandro Bonazzola a écrit :



2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet >:


Hello,

Will a 4.1.9.x security update be released for those who can't
migrate to 4.2.3.7 for any reasons?

No. oVirt 4.1 reached end of life with 4.1.9 
https://lists.ovirt.org/pipermail/announce/2018-January/000383.html

Please consider updating to 4.2 as soon as practical / possible.


Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :

As you may have already heard, an industry-wide issue was found
in the way many modern microprocessor designs have implemented
speculative execution of Load & Store instructions.
This issue is well described by CVE-2018-3639 announce available
at https://access.redhat.com/security/cve/cve-2018-3639
.

oVirt team has released right now an update of ovirt-engine to
version 4.2.3.7 which add support for SSBD CPUs in order to
mitigate the security issue.

If you are running oVirt on Red Hat Enterprise Linux, please
apply updates described in
https://access.redhat.com/security/cve/cve-2018-3639
.

If you are running oVirt on CentOS Linux please apply updated
described by:
CESA-2018:1629 Important CentOS 7 kernel Security Update

CESA-2018:1632 Important CentOS 7 libvirt Security

Update
CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security

Update
CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security

Update

An update for qemu-kvm-ev has been also tagged for release and
announced with
CESA-2018:1655 Important: qemu-kvm-ev security update

but due to some issues in CentOS release process for Virt SIG
content, it is not yet available on mirrors.
We are working with CentOS community to get the packages signed
and published as soon as possible.
In the meanwhile you can still get the update package by enabling
the test repository
https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/

on your systems or manually installing the package from the
repository.

If you're running oVirt on a different Linux distribution, please
check with your vendor for available updates.

Please note that to fully mitigate this vulnerability, system
administrators must apply both hardware “microcode” updates and
software patches that enable new functionality.
At this time, microprocessor microcode will be delivered by the
individual manufacturers.

The oVirt team recommends end users and systems administrator to
apply any available updates as soon as practical.

Thanks,
-- 


SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA 

sbona...@redhat.com 

  




___
Announce mailing list --annou...@ovirt.org 
To unsubscribe send an email toannounce-le...@ovirt.org 



-- 
Nathanaël Blanchet


Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala


34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr   





--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA 

sbona...@redhat.com 

  




--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduc

[ovirt-users] Re: [ovirt-announce] CVE-2018-3639 - Important - oVirt - Speculative Store Bypass

[Sandro Bonazzola]

2018-05-28 14:07 GMT+02:00 Nathanaël Blanchet :

> Hello,
>
> Will a 4.1.9.x security update be released for those who can't migrate to
> 4.2.3.7 for any reasons?
>
No. oVirt 4.1 reached end of life with 4.1.9
https://lists.ovirt.org/pipermail/announce/2018-January/000383.html
Please consider updating to 4.2 as soon as practical / possible.



>
> Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
>
> As you may have already heard, an industry-wide issue was found in the way
> many modern microprocessor designs have implemented speculative execution
> of Load & Store instructions.
> This issue is well described by CVE-2018-3639 announce available at
> https://access.redhat.com/security/cve/cve-2018-3639.
>
> oVirt team has released right now an update of ovirt-engine to version
> 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security
> issue.
>
> If you are running oVirt on Red Hat Enterprise Linux, please apply updates
> described in https://access.redhat.com/security/cve/cve-2018-3639.
>
> If you are running oVirt on CentOS Linux please apply updated described by:
> CESA-2018:1629 Important CentOS 7 kernel Security Update
> 
> CESA-2018:1632 Important CentOS 7 libvirt Security Update
> 
> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update
> 
> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update
> 
>
> An update for qemu-kvm-ev has been also tagged for release and announced
> with
> CESA-2018:1655 Important: qemu-kvm-ev security update
> 
> but due to some issues in CentOS release process for Virt SIG content, it
> is not yet available on mirrors.
> We are working with CentOS community to get the packages signed and
> published as soon as possible.
> In the meanwhile you can still get the update package by enabling the test
> repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/
> on your systems or manually installing the package from the repository.
>
> If you're running oVirt on a different Linux distribution, please check
> with your vendor for available updates.
>
> Please note that to fully mitigate this vulnerability, system
> administrators must apply both hardware “microcode” updates and software
> patches that enable new functionality.
> At this time, microprocessor microcode will be delivered by the individual
> manufacturers.
>
> The oVirt team recommends end users and systems administrator to apply any
> available updates as soon as practical.
>
> Thanks,
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
>
>
> ___
> Announce mailing list -- annou...@ovirt.org
> To unsubscribe send an email to announce-le...@ovirt.org
>
>
> --
> Nathanaël Blanchet
>
> Supervision réseau
> Pôle Infrastrutures Informatiques227 avenue Professeur-Jean-Louis-Viala 
> 
> 34193 MONTPELLIER CEDEX 5 
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14blanc...@abes.fr
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA 

sbona...@redhat.com


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

[ovirt-users] Re: [ovirt-announce] CVE-2018-3639 - Important - oVirt - Speculative Store Bypass

[Nathanaël Blanchet]

Hello,

Will a 4.1.9.x security update be released for those who can't migrate 
to 4.2.3.7 for any reasons?



Le 23/05/2018 à 16:57, Sandro Bonazzola a écrit :
As you may have already heard, an industry-wide issue was found in the 
way many modern microprocessor designs have implemented speculative 
execution of Load & Store instructions.
This issue is well described by CVE-2018-3639 announce available at 
https://access.redhat.com/security/cve/cve-2018-3639.


oVirt team has released right now an update of ovirt-engine to version 
4.2.3.7 which add support for SSBD CPUs in order to mitigate the 
security issue.


If you are running oVirt on Red Hat Enterprise Linux, please apply 
updates described in https://access.redhat.com/security/cve/cve-2018-3639.


If you are running oVirt on CentOS Linux please apply updated 
described by:
CESA-2018:1629 Important CentOS 7 kernel Security Update 

CESA-2018:1632 Important CentOS 7 libvirt Security 
Update
CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security 
Update
CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security 
Update


An update for qemu-kvm-ev has been also tagged for release and 
announced with
CESA-2018:1655 Important: qemu-kvm-ev security update 

but due to some issues in CentOS release process for Virt SIG content, 
it is not yet available on mirrors.
We are working with CentOS community to get the packages signed and 
published as soon as possible.
In the meanwhile you can still get the update package by enabling the 
test repository 
https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ on your 
systems or manually installing the package from the repository.


If you're running oVirt on a different Linux distribution, please 
check with your vendor for available updates.


Please note that to fully mitigate this vulnerability, system 
administrators must apply both hardware “microcode” updates and 
software patches that enable new functionality.
At this time, microprocessor microcode will be delivered by the 
individual manufacturers.


The oVirt team recommends end users and systems administrator to apply 
any available updates as soon as practical.


Thanks,
--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA 

sbona...@redhat.com 

  




___
Announce mailing list -- annou...@ovirt.org
To unsubscribe send an email to announce-le...@ovirt.org


--
Nathanaël Blanchet

Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr

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

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Vrgotic, Marko]

Bug submitted:

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

Kind regards,

Marko


On 25/05/2018, 16:57, "Tomáš Golembiovský"  wrote:

On Fri, 25 May 2018 12:13:33 +
"Vrgotic, Marko"  wrote:

> 
> 
> On 25/05/2018, 12:29, "Tomáš Golembiovský"  wrote:
> 
> Hi,
> 
> On Fri, 25 May 2018 08:11:13 +
> "Vrgotic, Marko"  wrote:
> 
> > Dear Nir, Arik and Richard,
> > 
> > I hope discussion will continue somewhere where i am able to join 
as watcher at least.
> 
> please open a bug on VDSM. This is something we need to deal with 
during
> import -- or at least prevent users from importing.
>[Marko] Where? Email to users@ovirt.org? Do you need me to provide 
more information than in this email or additional information?
Here in Bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm

Including the info you had in your first email should be enough for now.

>If possible, go with "deal with", instead of just 
preventing. My team very much enjoys oVirt platform and its functionality and 
we would love to see it grow further, internally and externally.

Could you please elaborate on your specific use-case here? Where did the
backing image came from? Snapshots, use of templates, ...?


> 
> > I have not seen any communication since Nir’s proposal. Please, if 
possible allow me to somehow track in which direction you are leaning.
> > 
> > In the meantime, as experienced engineers, do you have any 
suggestion how I could “workaround” current problem?
> > 
> > Rebasing image using qemu-img to remove backing file did not help 
(VM was able to start, but No Boot Device) and I think now that is due to image 
having functional dependency of base image.
> 
> What do you mean by rebasing? On which backing image did you rebase 
it?
>[Marko] It was using unsafe mode - just wanted to see what results 
will I get if I remove the backing file (inexperienced move). This action 
result in being able to start the VM, but ending up in No Bootable Device.

I guess you ended up with a disk full of holes in it and boot sector was
one of the missing pieces.

Tomas

> 
> I'm not too familiar with openstack, but I'd suggest doing a 
'qemu-img convert' on the disk in openstack to squash the backing change into 
new (and complete) image, assign this new disk to your VM and import it to 
oVirt.
> [Marko] Thank you. We will test it and check the result.
> 
> Tomas
> 
> > 
> > Like with VMs in oVrt, where template can not be deleted if there 
are still VMs existing, which were created from that template.
> > 
> > Please advise
> > 
> > — — —
> > Met vriendelijke groet / Best regards,
> > 
> > Marko Vrgotic
> > Sr. System Engineer
> > ActiveVideo
> > 
> > Tel. +31 (0)35 677 4131
> > email: m.vrgo...@activevideo.com
> > skype: av.mvrgotic.se
> > www.activevideo.com
> > 
> > From: Vrgotic, Marko
> > Sent: Thursday, May 24, 2018 5:26:30 PM
> > To: Nir Soffer
> > Cc: users@ovirt.org; Richard W.M. Jones; Arik Hadas
> > Subject: Re: [ovirt-users] Libvirt ERROR cannot access backing file 
after importing VM from OpenStack
> > 
> > Dear Nir,
> > 
> > I believe i understand now. The image imported is not base image, 
but required backing file to be able to work properly.
> > 
> > Maybe silly move, but i have tried to “solve/workaround” around the 
problem by rebasing image to remove backing file dependency, but it’s clear now 
why I than saw that “no bootable device found” during imported VM boot.
> > 
> > I support you suggestion to solve the import by either importing 
complete chain or recreating image so in a way it’s independent from former 
chain.
> > 
> > If you decide to go this way, please let me know which issue to 
track and if you need any more data provided from me.
> > 
> > I still need to solve problem with 200+ VM wanting to move to oVirt.
> > 
> > Kindly awaiting further updates.
> > 
> > — — —
> > Met vriendelijke groet / Best regards,
> > 
> > Marko Vrgotic
> > Sr. System Engineer
> > ActiveVideo
> > 
> > Tel. +31 (0)35 677 4131
> > email: m.vrgo...@activevideo.com
> > skype: av.mvrgotic.se
> > www.activevideo.com
> > 
> > From: Nir Soffer 
> > Sent: Thursday, May 24, 2018 5:13:47 PM
> > To: Vrgotic, M

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Kevin Wolf]

Am 28.05.2018 um 12:27 hat Arik Hadas geschrieben:
> On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf  wrote:
> 
> > [ Adding qemu-block ]
> >
> > Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben:
> > > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer  wrote:
> > >
> > > > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko <
> > m.vrgo...@activevideo.com>
> > > > wrote:
> > > >
> > > >> Dear Nir,
> > > >>
> > > >> Thank you for quick reply.
> > > >>
> > > >> Ok, why it will not work?
> > > >>
> > > >
> > > > Because the image has a backing file which is not accessible to oVirt.
> > > >
> > > >
> > > >> I used qemu+tcp connection, via import method through engine admin UI.
> > > >>
> > > >> Images was imported and converted according logs, still “backing file”
> > > >> invalid entry remained.
> > > >>
> > > >> Also, I did use same method before, connecting to plain “libvirt kvm”
> > > >> host, import and conversion went smooth, no backend file.
> > > >>
> > > >> Image format is qcow(2) which is supported by oVirt.
> > > >>
> > > >> What am I missing? Should I use different method?
> > > >>
> > > >
> > > > I guess this is not a problem on your side, but a bug in our side.
> > > >
> > > > Either we should block the operation that cannot work, or fix the
> > process
> > > > so we don't refer to non-existing image.
> > > >
> > > > When importing we have 2 options:
> > > >
> > > > - import the entire chain,  importing all images in the chain,
> > converting
> > > >  each image to oVirt volume, and updating the backing file of each
> > layer
> > > > to point to the oVirt image.
> > > >
> > > > - import the current state of the image into a new image, using either
> > raw
> > > > or qcow2, but without any backing file.
> > > >
> > > > Arik, do you know why we create qcow2 file with invalid backing file?
> > > >
> > >
> > > It seems to be a result of a bit naive behavior of the kvm2ovirt module
> > > that tries to download only the top-level volume the VM uses, assuming
> > each
> > > of the disks to be imported is comprised of a single volume.
> > >
> > > Maybe it's time to finally asking QEMU guys to provide a way to consume
> > the
> > > 'collapsed' form of a chain of volumes as a stream if that's not
> > available
> > > yet? ;) It can also boost the recently added process of exporting VMs as
> > > OVAs...
> >
> > Not sure which operation we're talking about on the QEMU level, but
> > generally the "collapsed" view is the normal thing because that's what
> > guests see.
> >
> > For example, if you use 'qemu-img convert', you have to pass options to
> > specifically disable it and convert only a single layer if you want to
> > keep using backing files instead of getting a standalone image that
> > contains everything.
> >
> 
> Yeah, some context was missing. Sorry about that.
> 
> Let me demonstrate briefly the flow for OVA:
> Let's say that we have a VM that is based on a template and has one disk
> and one snapshot, so its volume-chain would be:
> T -> S -> V
> (V is the volume the VM writes to, S is the backing file of V and T is the
> backing file of S).
> When exporting that VM to an OVA file we want the produced tar file to be
> comprised of:
> (1) OVF configuration
> (2) single disk volume (preferably qcow).
> 
> So we need to collapse T, S, V into a single volume.
> Sure, we can do 'qemu-img convert'. That's what we do now in oVirt 4.2:
> (a) qemu-img convert produces a 'temporary' collapsed volume
> (b) make a tar file of the OVf configuration and that 'temporary' volume
> (c) delete the temporary volume
> 
> But the fact that we produce that 'temporary' volume obviously slows down
> the entire operation.
> It would be much better if we could "open" a stream that we can read from
> the 'collapsed' form of that chain and stream it directly into the
> appropriate tar file entry, without extra writes to the storage device.
> 
> Few months ago people from the oVirt-storage team checked the qemu toolset
> and replied that this capability is not yet provided, therefore we
> implemented the workaround described above. Apparently, the desired ability
> can also be useful for the flow discussed in this thread so it worth asking
> for it again :)

I think real streaming is unlikely to happen because most image formats
that QEMU supports aren't made that way. If there is a compelling
reason, we can consider it, but it would work only with very few target
formats and as such would have to be separate from existing commands.

As for OVA files, I think it might be useful to have a tar block driver
instead which would allow you to open a file inside a tar archive (you
could then also directly run an OVA without extracting it first). We
probably wouldn't be able to support resizing images there, but that
should be okay.

If you can create a tar file that reserves space for the image file
without actually writing it, a possible workaround today would be using
the offset/size runtime options of the raw driver to convert directly
into

[ovirt-users] Re: Gluster quorum

[Demeter Tibor]

Dear Sahina, 

Yes, exactly. I can check that check box, but I don't know how is safe that. Is 
it safe? 

I want to upgrade all of my host. If it will done, then the monitoring will 
work perfectly? 

Thanks. 
R. 

Tibor 

- 2018. máj.. 28., 10:09, Sahina Bose  írta: 

> On Mon, May 28, 2018 at 1:06 PM, Demeter Tibor < [ mailto:tdeme...@itsmart.hu 
> |
> tdeme...@itsmart.hu ] > wrote:

>> Hi,

>> Somebody could answer to my question please?
>> It is very important for me, I could no finish my upgrade process (from 4.1 
>> to
>> 4.2) since 9th May!

> Can you explain how the upgrade process is blocked due to the monitoring?
> If it's because you cannot move the host to maintenance, can you try with the
> option "Ignore quorum checks" enabled?

>> Meanwhile - I don't know why - one of my two gluster volume seems UP (green) 
>> on
>> the GUI. So, now only one is down.

>> I need help. What can I do?

>> Thanks in advance,

>> Regards,

>> Tibor

>> - 2018. máj.. 23., 21:09, Demeter Tibor < [ mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > írta:

>>> Hi,

>>> I've updated again to the latest version, but there are no changes. All of
>>> bricks on my first node are down in the GUI (in console are ok)
>>> An Interesting thing, the "Self-Heal info" column show "OK" for all hosts 
>>> and
>>> all bricks, but "Space used" column is zero for all hosts/bricks.
>>> Can I force remove and re-add my host to cluster awhile it is a gluster 
>>> member?
>>> Is it safe ?
>>> What can I do?

>>> I haven't update other hosts while gluster not working fine, or the GUI 
>>> does not
>>> detect . So my other hosts is remained 4.1 yet :(

>>> Thanks in advance,

>>> Regards

>>> Tibor

>>> - 2018. máj.. 23., 14:45, Denis Chapligin < [ 
>>> mailto:dchap...@redhat.com |
>>> dchap...@redhat.com ] > írta:

 Hello!

 On Tue, May 22, 2018 at 11:10 AM, Demeter Tibor < [ 
 mailto:tdeme...@itsmart.hu |
 tdeme...@itsmart.hu ] > wrote:

> Is there any changes with this bug?

> Still I haven't finish my upgrade process that i've started on 9th may:(

> Please help me if you can.

 Looks like all required patches are already merged, so could you please to
 update your engine again to the latest night build?

>>> ___
>>> Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ]
>>> To unsubscribe send an email to [ mailto:users-le...@ovirt.org |
>>> users-le...@ovirt.org ]

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

[ovirt-users] Re: oVirt hosted-engine-setup issues with getting host facts

[Simone Tiraboschi]

On Mon, May 28, 2018 at 11:44 AM, Mariusz Kozakowski <
mariusz.kozakow...@dsg.dk> wrote:

> On Fri, 2018-05-25 at 11:21 +0200, Simone Tiraboschi wrote:
>
>
>
>
> On Fri, May 25, 2018 at 9:20 AM, Mariusz Kozakowski <
> mariusz.kozakow...@dsg.dk> wrote:
>
> On Thu, 2018-05-24 at 14:11 +0200, Simone Tiraboschi wrote:
>
> To better understand what it's happening you have to check host-deploy
> logs; they are available under /var/log/ovirt-engine/host-deploy/ on your
> engine VM.
>
>
> Unfortunately there is no logs under that directory. It's empty.
>
>
> So it probably failed to reach the host due to a name resolution issue or
> something like that.
> Can you please double check it in /var/log/ovirt-engine/engine.log on the
> engine VM ?
>
>
>
> Thanks - it helped a bit. At least now we have logs for host-deploy, but
> still no success.
>
> Few parts I found in engine log:
>
> 2018-05-28 11:07:39,473+02 ERROR 
> [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
> (EE-ManagedThreadFactory-engine-Thread-1) [1a4cf85e] Exception:
> org.ovirt.engine.core.common.errors.EngineException: EngineException:
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> VDSGenericException: VDSNetworkException: Message timeout which can be
> caused by communication issues (Failed with error VDS_NETWORK_ERROR and
> code 5022)
>
>
> 2018-05-28 11:07:39,485+02 ERROR 
> [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
> (EE-ManagedThreadFactory-engine-Thread-1) [1a4cf85e] Host installation
> failed for host '098c3c99-921d-46f0-bdba-86370a2dc895',
> 'host01.redacted': Failed to configure management network on the host
>


The issue is on network configuration:
you have to check /var/log/vdsm/vdsm.log and /var/log/vdsm/supervdsm.log to
understand why it failed.



>
> 2018-05-28 11:20:04,705+02 INFO  
> [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-37) [5ba0ae45] Running
> command: SetNonOperationalVdsCommand internal: true. Entities affected
> :  ID: 098c3c99-921d-46f0-bdba-86370a2dc895 Type: VDS
> 2018-05-28 11:20:04,711+02 INFO  
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-37) [5ba0ae45] START,
> SetVdsStatusVDSCommand(HostName = host01.redacted,
> SetVdsStatusVDSCommandParameters:{hostId='098c3c99-921d-46f0-bdba-86370a2dc895',
> status='NonOperational', nonOperationalReason='NETWORK_UNREACHABLE',
> stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 11ebbdeb
> 2018-05-28 11:20:04,715+02 INFO  
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-37) [5ba0ae45] FINISH,
> SetVdsStatusVDSCommand, log id: 11ebbdeb
> 2018-05-28 11:20:04,769+02 ERROR 
> [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-37) [5ba0ae45] Host
> 'host01.redacted' is set to Non-Operational, it is missing the following
> networks: 'ovirtmgmt'
> 2018-05-28 11:20:04,786+02 WARN  [org.ovirt.engine.core.
> dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-37)
> [5ba0ae45] EVENT_ID: VDS_SET_NONOPERATIONAL_NETWORK(519), Host
> host01.redacted does not comply with the cluster Default networks, the
> following networks are missing on host: 'ovirtmgmt'
> 2018-05-28 11:20:04,807+02 INFO  [org.ovirt.engine.core.bll.
> HandleVdsCpuFlagsOrClusterChangedCommand] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-37)
> [7937fb47] Running command: HandleVdsCpuFlagsOrClusterChangedCommand
> internal: true. Entities affected :  ID: 098c3c99-921d-46f0-bdba-86370a2dc895
> Type: VDS
> 2018-05-28 11:20:04,814+02 INFO  [org.ovirt.engine.core.
> dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-37)
> [7937fb47] EVENT_ID: VDS_DETECTED(13), Status of host host01.redacted was
> set to NonOperational.
> 2018-05-28 11:20:04,833+02 INFO  
> [org.ovirt.engine.core.bll.HandleVdsVersionCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-37) [4c10675c] Running
> command: HandleVdsVersionCommand internal: true. Entities affected :  ID:
> 098c3c99-921d-46f0-bdba-86370a2dc895 Type: VDS
> 2018-05-28 11:20:04,837+02 INFO  [org.ovirt.engine.core.
> vdsbroker.monitoring.HostMonitoring] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-37)
> [4c10675c] Host 'host01.redacted'(098c3c99-921d-46f0-bdba-86370a2dc895)
> is already in NonOperational status for reason 'NETWORK_UNREACHABLE'.
> SetNonOperationalVds command is skipped.
>
> Full log as attachment.
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/mess

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Arik Hadas]

On Mon, May 28, 2018 at 11:25 AM, Kevin Wolf  wrote:

> [ Adding qemu-block ]
>
> Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben:
> > On Thu, May 24, 2018 at 6:13 PM, Nir Soffer  wrote:
> >
> > > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko <
> m.vrgo...@activevideo.com>
> > > wrote:
> > >
> > >> Dear Nir,
> > >>
> > >> Thank you for quick reply.
> > >>
> > >> Ok, why it will not work?
> > >>
> > >
> > > Because the image has a backing file which is not accessible to oVirt.
> > >
> > >
> > >> I used qemu+tcp connection, via import method through engine admin UI.
> > >>
> > >> Images was imported and converted according logs, still “backing file”
> > >> invalid entry remained.
> > >>
> > >> Also, I did use same method before, connecting to plain “libvirt kvm”
> > >> host, import and conversion went smooth, no backend file.
> > >>
> > >> Image format is qcow(2) which is supported by oVirt.
> > >>
> > >> What am I missing? Should I use different method?
> > >>
> > >
> > > I guess this is not a problem on your side, but a bug in our side.
> > >
> > > Either we should block the operation that cannot work, or fix the
> process
> > > so we don't refer to non-existing image.
> > >
> > > When importing we have 2 options:
> > >
> > > - import the entire chain,  importing all images in the chain,
> converting
> > >  each image to oVirt volume, and updating the backing file of each
> layer
> > > to point to the oVirt image.
> > >
> > > - import the current state of the image into a new image, using either
> raw
> > > or qcow2, but without any backing file.
> > >
> > > Arik, do you know why we create qcow2 file with invalid backing file?
> > >
> >
> > It seems to be a result of a bit naive behavior of the kvm2ovirt module
> > that tries to download only the top-level volume the VM uses, assuming
> each
> > of the disks to be imported is comprised of a single volume.
> >
> > Maybe it's time to finally asking QEMU guys to provide a way to consume
> the
> > 'collapsed' form of a chain of volumes as a stream if that's not
> available
> > yet? ;) It can also boost the recently added process of exporting VMs as
> > OVAs...
>
> Not sure which operation we're talking about on the QEMU level, but
> generally the "collapsed" view is the normal thing because that's what
> guests see.
>
> For example, if you use 'qemu-img convert', you have to pass options to
> specifically disable it and convert only a single layer if you want to
> keep using backing files instead of getting a standalone image that
> contains everything.
>

Yeah, some context was missing. Sorry about that.

Let me demonstrate briefly the flow for OVA:
Let's say that we have a VM that is based on a template and has one disk
and one snapshot, so its volume-chain would be:
T -> S -> V
(V is the volume the VM writes to, S is the backing file of V and T is the
backing file of S).
When exporting that VM to an OVA file we want the produced tar file to be
comprised of:
(1) OVF configuration
(2) single disk volume (preferably qcow).

So we need to collapse T, S, V into a single volume.
Sure, we can do 'qemu-img convert'. That's what we do now in oVirt 4.2:
(a) qemu-img convert produces a 'temporary' collapsed volume
(b) make a tar file of the OVf configuration and that 'temporary' volume
(c) delete the temporary volume

But the fact that we produce that 'temporary' volume obviously slows down
the entire operation.
It would be much better if we could "open" a stream that we can read from
the 'collapsed' form of that chain and stream it directly into the
appropriate tar file entry, without extra writes to the storage device.

Few months ago people from the oVirt-storage team checked the qemu toolset
and replied that this capability is not yet provided, therefore we
implemented the workaround described above. Apparently, the desired ability
can also be useful for the flow discussed in this thread so it worth asking
for it again :)


>
> Kevin
>
> >
> > >
> > > Nir
> > >
> > >
> > >>
> > >> Kindly awaiting your reply.
> > >>
> > >> — — —
> > >> Met vriendelijke groet / Best regards,
> > >>
> > >> Marko Vrgotic
> > >> Sr. System Engineer
> > >> ActiveVideo
> > >>
> > >> Tel. +31 (0)35 677 4131 <+31%2035%20677%204131>
> > >> email: m.vrgo...@activevideo.com
> > >> skype: av.mvrgotic.se
> > >> www.activevideo.com
> > >> --
> > >> *From:* Nir Soffer 
> > >> *Sent:* Thursday, May 24, 2018 4:09:40 PM
> > >> *To:* Vrgotic, Marko
> > >> *Cc:* users@ovirt.org; Richard W.M. Jones; Arik Hadas
> > >> *Subject:* Re: [ovirt-users] Libvirt ERROR cannot access backing file
> > >> after importing VM from OpenStack
> > >>
> > >>
> > >>
> > >> On Thu, May 24, 2018 at 5:05 PM Vrgotic, Marko <
> m.vrgo...@activevideo.com>
> > >> wrote:
> > >>
> > >> Dear oVirt team,
> > >>
> > >>
> > >>
> > >> When trying to start imported VM, it fails with following message:
> > >>
> > >>
> > >>
> > >> ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.
> AuditLogDirector

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Vrgotic, Marko]

Apologies for delay,

I am reporting a bug atm.

Will send the bug number id afterwards.



On 25/05/2018, 16:57, "Tomáš Golembiovský"  wrote:

On Fri, 25 May 2018 12:13:33 +
"Vrgotic, Marko"  wrote:

> 
> 
> On 25/05/2018, 12:29, "Tomáš Golembiovský"  wrote:
> 
> Hi,
> 
> On Fri, 25 May 2018 08:11:13 +
> "Vrgotic, Marko"  wrote:
> 
> > Dear Nir, Arik and Richard,
> > 
> > I hope discussion will continue somewhere where i am able to join 
as watcher at least.
> 
> please open a bug on VDSM. This is something we need to deal with 
during
> import -- or at least prevent users from importing.
>[Marko] Where? Email to users@ovirt.org? Do you need me to provide 
more information than in this email or additional information?
Here in Bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm

Including the info you had in your first email should be enough for now.

>If possible, go with "deal with", instead of just 
preventing. My team very much enjoys oVirt platform and its functionality and 
we would love to see it grow further, internally and externally.

Could you please elaborate on your specific use-case here? Where did the
backing image came from? Snapshots, use of templates, ...?


> 
> > I have not seen any communication since Nir’s proposal. Please, if 
possible allow me to somehow track in which direction you are leaning.
> > 
> > In the meantime, as experienced engineers, do you have any 
suggestion how I could “workaround” current problem?
> > 
> > Rebasing image using qemu-img to remove backing file did not help 
(VM was able to start, but No Boot Device) and I think now that is due to image 
having functional dependency of base image.
> 
> What do you mean by rebasing? On which backing image did you rebase 
it?
>[Marko] It was using unsafe mode - just wanted to see what results 
will I get if I remove the backing file (inexperienced move). This action 
result in being able to start the VM, but ending up in No Bootable Device.

I guess you ended up with a disk full of holes in it and boot sector was
one of the missing pieces.

Tomas

> 
> I'm not too familiar with openstack, but I'd suggest doing a 
'qemu-img convert' on the disk in openstack to squash the backing change into 
new (and complete) image, assign this new disk to your VM and import it to 
oVirt.
> [Marko] Thank you. We will test it and check the result.
> 
> Tomas
> 
> > 
> > Like with VMs in oVrt, where template can not be deleted if there 
are still VMs existing, which were created from that template.
> > 
> > Please advise
> > 
> > — — —
> > Met vriendelijke groet / Best regards,
> > 
> > Marko Vrgotic
> > Sr. System Engineer
> > ActiveVideo
> > 
> > Tel. +31 (0)35 677 4131
> > email: m.vrgo...@activevideo.com
> > skype: av.mvrgotic.se
> > www.activevideo.com
> > 
> > From: Vrgotic, Marko
> > Sent: Thursday, May 24, 2018 5:26:30 PM
> > To: Nir Soffer
> > Cc: users@ovirt.org; Richard W.M. Jones; Arik Hadas
> > Subject: Re: [ovirt-users] Libvirt ERROR cannot access backing file 
after importing VM from OpenStack
> > 
> > Dear Nir,
> > 
> > I believe i understand now. The image imported is not base image, 
but required backing file to be able to work properly.
> > 
> > Maybe silly move, but i have tried to “solve/workaround” around the 
problem by rebasing image to remove backing file dependency, but it’s clear now 
why I than saw that “no bootable device found” during imported VM boot.
> > 
> > I support you suggestion to solve the import by either importing 
complete chain or recreating image so in a way it’s independent from former 
chain.
> > 
> > If you decide to go this way, please let me know which issue to 
track and if you need any more data provided from me.
> > 
> > I still need to solve problem with 200+ VM wanting to move to oVirt.
> > 
> > Kindly awaiting further updates.
> > 
> > — — —
> > Met vriendelijke groet / Best regards,
> > 
> > Marko Vrgotic
> > Sr. System Engineer
> > ActiveVideo
> > 
> > Tel. +31 (0)35 677 4131
> > email: m.vrgo...@activevideo.com
> > skype: av.mvrgotic.se
> > www.activevideo.com
> > 
> > From: Nir Soffer 
> > Sent: Thursday, May 24, 2018 5:13:47 PM
> > To: Vrgotic, M

[ovirt-users] Does ovirt engine itself support high scalability

[simiam]

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

[ovirt-users] Re: CentOS7 Install Failure to Shutdown

[jvdwege]

Matthew Wimpelberg schreef op 2018-05-28 00:30:

I have ovirt 4.2.3.5-1.el7.centos installed and am unable to cleanly
reboot the host machine.  The only way I can reboot is to press and
hold the power button which causes an unclean shutdown of the engine
vm.  I can upload logs if necessary I'm just not sure where to upload
them to.
Is the engine VM still running on the host when you try to reboot the 
host?
Because if thats the case then I would suspect that it wouldn't work 
because of mounts and/or locks.
Can you migrate the engine to another host and then try to shutdown the 
problematic host or is it an AllInOne install?


Could you explain a bit more how your setup is done?

Regards,

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

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Kevin Wolf]

[ Adding qemu-block ]

Am 27.05.2018 um 10:36 hat Arik Hadas geschrieben:
> On Thu, May 24, 2018 at 6:13 PM, Nir Soffer  wrote:
> 
> > On Thu, May 24, 2018 at 6:06 PM Vrgotic, Marko 
> > wrote:
> >
> >> Dear Nir,
> >>
> >> Thank you for quick reply.
> >>
> >> Ok, why it will not work?
> >>
> >
> > Because the image has a backing file which is not accessible to oVirt.
> >
> >
> >> I used qemu+tcp connection, via import method through engine admin UI.
> >>
> >> Images was imported and converted according logs, still “backing file”
> >> invalid entry remained.
> >>
> >> Also, I did use same method before, connecting to plain “libvirt kvm”
> >> host, import and conversion went smooth, no backend file.
> >>
> >> Image format is qcow(2) which is supported by oVirt.
> >>
> >> What am I missing? Should I use different method?
> >>
> >
> > I guess this is not a problem on your side, but a bug in our side.
> >
> > Either we should block the operation that cannot work, or fix the process
> > so we don't refer to non-existing image.
> >
> > When importing we have 2 options:
> >
> > - import the entire chain,  importing all images in the chain, converting
> >  each image to oVirt volume, and updating the backing file of each layer
> > to point to the oVirt image.
> >
> > - import the current state of the image into a new image, using either raw
> > or qcow2, but without any backing file.
> >
> > Arik, do you know why we create qcow2 file with invalid backing file?
> >
> 
> It seems to be a result of a bit naive behavior of the kvm2ovirt module
> that tries to download only the top-level volume the VM uses, assuming each
> of the disks to be imported is comprised of a single volume.
> 
> Maybe it's time to finally asking QEMU guys to provide a way to consume the
> 'collapsed' form of a chain of volumes as a stream if that's not available
> yet? ;) It can also boost the recently added process of exporting VMs as
> OVAs...

Not sure which operation we're talking about on the QEMU level, but
generally the "collapsed" view is the normal thing because that's what
guests see.

For example, if you use 'qemu-img convert', you have to pass options to
specifically disable it and convert only a single layer if you want to
keep using backing files instead of getting a standalone image that
contains everything.

Kevin

> 
> >
> > Nir
> >
> >
> >>
> >> Kindly awaiting your reply.
> >>
> >> — — —
> >> Met vriendelijke groet / Best regards,
> >>
> >> Marko Vrgotic
> >> Sr. System Engineer
> >> ActiveVideo
> >>
> >> Tel. +31 (0)35 677 4131 <+31%2035%20677%204131>
> >> email: m.vrgo...@activevideo.com
> >> skype: av.mvrgotic.se
> >> www.activevideo.com
> >> --
> >> *From:* Nir Soffer 
> >> *Sent:* Thursday, May 24, 2018 4:09:40 PM
> >> *To:* Vrgotic, Marko
> >> *Cc:* users@ovirt.org; Richard W.M. Jones; Arik Hadas
> >> *Subject:* Re: [ovirt-users] Libvirt ERROR cannot access backing file
> >> after importing VM from OpenStack
> >>
> >>
> >>
> >> On Thu, May 24, 2018 at 5:05 PM Vrgotic, Marko 
> >> wrote:
> >>
> >> Dear oVirt team,
> >>
> >>
> >>
> >> When trying to start imported VM, it fails with following message:
> >>
> >>
> >>
> >> ERROR 
> >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> >> (ForkJoinPool-1-worker-2) [] EVENT_ID: VM_DOWN_ERROR(119), VM
> >> instance-0673 is down with error. Exit message: Cannot access backing
> >> file 
> >> '/var/lib/nova/instances/_base/2f4f8c5fc11bb83bcab03f4c829ddda4da8c0bce'
> >> of storage file '/rhev/data-center/mnt/glusterSD/aws-gfs-01.awesome.
> >> lan:_gv0__he/2607c265-248c-40ad-b020-f3756454839e/images/
> >> 816ac00f-ba98-4827-b5c8-42a8ba496089/8ecfcd5b-db67-4c23-9869-0e20d7553aba'
> >> (as uid:107, gid:107): No such file or directory.
> >>
> >>
> >>
> >> Platform details:
> >>
> >> Ovirt SHE
> >>
> >> Version 4.2.2.6-1.el7.centos
> >>
> >> GlusterFS, unmanaged by oVirt.
> >>
> >>
> >>
> >> VM is imported & converted from OpenStack, according to log files,
> >> successfully (one WARN, related to different MAC address):
> >>
> >> 2018-05-24 12:03:31,028+02 INFO  [org.ovirt.engine.core.
> >> vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default
> >> task-29) [cc5931a2-1af5-4d65-b0b3-362588db9d3f] FINISH,
> >> GetVmsNamesFromExternalProviderVDSCommand, return: [VM
> >> [instance-0001f94c], VM [instance-00078f6a], VM [instance-0814], VM
> >> [instance-0001f9ac], VM [instance-01ff], VM [instance-0001f718], VM
> >> [instance-0673], VM [instance-0001ecf2], VM [instance-00078d38]], log
> >> id: 7f178a5e
> >>
> >> 2018-05-24 12:48:33,722+02 INFO  [org.ovirt.engine.core.
> >> vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default
> >> task-8) [103d56e1-7449-4853-ae50-48ee94d43d77] FINISH,
> >> GetVmsNamesFromExternalProviderVDSCommand, return: [VM
> >> [instance-0001f94c], VM [instance-00078f6a], VM [instance-0814], VM
> >> [instance-0001f9ac], VM [instance-01ff], VM [instance-0001f718],

[ovirt-users] Re: Gluster quorum

[Sahina Bose]

On Mon, May 28, 2018 at 1:06 PM, Demeter Tibor  wrote:

> Hi,
>
> Somebody could answer to my question please?
> It is very important for me, I could no finish my upgrade process (from
> 4.1 to 4.2) since 9th May!
>

Can you explain how the upgrade process is blocked due to the monitoring?
If it's because you cannot move the host to maintenance, can you try with
the option "Ignore quorum checks" enabled?


> Meanwhile - I don't know why - one of my two gluster volume seems UP
> (green) on the GUI. So, now only one is down.
>
> I need help. What can I do?
>
> Thanks in advance,
>
> Regards,
>
> Tibor
>
>
> - 2018. máj.. 23., 21:09, Demeter Tibor  írta:
>
> Hi,
>
> I've updated again to the latest version, but there are no changes. All of
> bricks on my first node are down in the GUI (in console are ok)
> An Interesting thing, the "Self-Heal info" column show "OK" for all hosts
> and all bricks, but "Space used" column is zero for all hosts/bricks.
> Can I force remove and re-add my host to cluster awhile it is a gluster
> member? Is it safe ?
> What can I do?
>
> I haven't update other hosts while gluster not working fine, or the GUI
> does not detect . So my other hosts is remained 4.1 yet :(
>
> Thanks in advance,
>
> Regards
>
> Tibor
>
> - 2018. máj.. 23., 14:45, Denis Chapligin  írta:
>
> Hello!
>
> On Tue, May 22, 2018 at 11:10 AM, Demeter Tibor 
> wrote:
>
>>
>> Is there any changes with this bug?
>>
>> Still I haven't finish my upgrade process that i've started on 9th may:(
>>
>> Please help me if you can.
>>
>>
>
> Looks like all required patches are already merged, so could you please to
> update your engine again to the latest night build?
>
>
> ___
> 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
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/MRAAPZSRIXLAJZBV6TRDXXK7R2ISPSDK/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OLDBXYCQZCJJ4KFDYRTE6VTH4L4OB5VQ/

[ovirt-users] Re: Gluster quorum

[Demeter Tibor]

Hi, 

Somebody could answer to my question please? 
It is very important for me, I could no finish my upgrade process (from 4.1 to 
4.2) since 9th May! 

Meanwhile - I don't know why - one of my two gluster volume seems UP (green) on 
the GUI. So, now only one is down. 

I need help. What can I do? 

Thanks in advance, 

Regards, 

Tibor 

- 2018. máj.. 23., 21:09, Demeter Tibor  írta: 

> Hi,

> I've updated again to the latest version, but there are no changes. All of
> bricks on my first node are down in the GUI (in console are ok)
> An Interesting thing, the "Self-Heal info" column show "OK" for all hosts and
> all bricks, but "Space used" column is zero for all hosts/bricks.
> Can I force remove and re-add my host to cluster awhile it is a gluster 
> member?
> Is it safe ?
> What can I do?

> I haven't update other hosts while gluster not working fine, or the GUI does 
> not
> detect . So my other hosts is remained 4.1 yet :(

> Thanks in advance,

> Regards

> Tibor

> - 2018. máj.. 23., 14:45, Denis Chapligin  írta:

>> Hello!

>> On Tue, May 22, 2018 at 11:10 AM, Demeter Tibor < [ 
>> mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > wrote:

>>> Is there any changes with this bug?

>>> Still I haven't finish my upgrade process that i've started on 9th may:(

>>> Please help me if you can.

>> Looks like all required patches are already merged, so could you please to
>> update your engine again to the latest night build?

> ___
> 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
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MRAAPZSRIXLAJZBV6TRDXXK7R2ISPSDK/