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

[Sam McLeod]

Did you get anywhere with this?

I'm having quite a similar issue with ovirt 4.2 on CentOS 7:

Deployment output: https://paste.fedoraproject.org/paste/j8G7EVHBoW4JK7orp-mD8A 

SQL errors: https://paste.fedoraproject.org/paste/tYNtxsVHMCETwWBMuM2wyg 



___
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/XA5XJ5EA7XANIYBDOUX3QCOLFGLFUE63/

[ovirt-users] Re: Gluster clients intermittently hang until first gluster server in a Replica 1 Arbiter 1 cluster is rebooted, server error: 0-management: Unlocking failed & client error: bailing out

[Sam McLeod]

Sorry, please ignore, incorrect mailing list (doh!)

--
Sam McLeod (protoporpoise on IRC)
https://twitter.com/s_mcleod
https://smcleod.net

Words are my own opinions and do not necessarily represent those of my
employer or partners.


On Mon, 3 Sep 2018, at 12:30 PM, Sam McLeod wrote:
> We've got an odd problem where clients are blocked from writing to
> Gluster volumes until the first node of the Gluster cluster is
> rebooted.> 
> I suspect I've either configured something incorrectly with the
> arbiter / replica configuration of the volumes, or there is some sort
> of bug in the gluster client-server connection that we're triggering.> 
> I was wondering if anyone has seen this or could point me in the right
> direction?> 
> 
> *Environment:*
>  * Typology: 3 node cluster, replica 2, arbiter 1 (third node is
>metadata only).
>  * Version: Client and Servers both running 4.1.3, both on CentOS 7,
>kernel 4.18.x, (Xen) VMs with relatively fast networked SSD storage
>backing them, XFS.
>  * Client: Native Gluster FUSE client mounting via the kubernetes
>provider> 
> *Problem:*
>  * Seemingly randomly some clients will be blocked / are unable to
>write to what should be a highly available gluster volume.
>  * The client gluster logs show it failing to do new file operations
>across various volumes and all three nodes of the gluster.
>  * The server gluster (or OS) logs do not show any warnings or errors.
>  * The client recovers and is able to write to volumes again after the
>first node of the gluster cluster is rebooted.
>  * Until the first node of the gluster cluster is rebooted, the client
>fails to write to the volume that is (or should be) available on
>the second node (a replica) and third node (an arbiter only node).> 
> *What 'fixes' the issue:*
>  * Although the clients (kubernetes hosts) connect to all 3 nodes of
>the Gluster cluster - restarting the first gluster node always
>unblocks the IO and allows the client to continue writing.
>  * Stopping and starting the glusterd service on the gluster server is
>not enough to fix the issue, nor is restarting its networking.
>  * This suggests to me that the volume is unavailable for writing for
>some reason and restarting the first node in the cluster either
>clears some sort of TCP sessions between the client-server or
>between the server-server replication.> 
> *Expected behaviour:*
> 
>  * If the first gluster node / server had failed or was blocked from
>performing operations for some reason (which it doesn't seem it
>is), I'd expect the clients to access data from the second gluster
>node and write metadata to the third gluster node as well as it's
>an arbiter / metadata only node.
>  * If for some reason the a gluster node was not able to serve
>connections to clients, I'd expect to see errors in the volume,
>glusterd or brick log files (there are none on the first gluster
>node).
>  * If the first gluster node was for some reason blocking IO on a
>volume, I'd expect that node either to show as unhealthy or
>unavailable in the gluster peer status or gluster volume status.> 
> 
> *Client gluster errors:*
> 
>  * staging_static in this example is a volume name.
>  * You can see the client trying to connect to the second and third
>nodes of the gluster cluster and failing (unsure as to why?)
>  * The server side logs on the first gluster node do not show any
>errors or problems, but the second / third node show errors in the
>glusterd.log when trying to 'unlock' the 0-management volume on the
>first node.> 
> 
> *On a gluster client* (a kubernetes host using the kubernetes
> connector which uses the native fuse client) when its blocked from
> writing but the gluster appears healthy (other than the errors
> mentioned later):> 
> [2018-09-02 15:33:22.750874] E [rpc-clnt.c:184:call_bail] 
> 0-staging_static-client-
> 2: bailing out frame type(GlusterFS 4.x v1) op(INODELK(29)) xid =
> 0x1cce sent = 2018-09-02 15:03:22.417773. timeout = 1800 for  third gluster node>:49154> [2018-09-02 15:33:22.750989] E [MSGID: 114031] 
> [client-rpc-
> fops_v2.c:1306:client4_0_inodelk_cbk] 0-staging_static-client-2:
> remote operation failed [Transport endpoint is not connected]> [2018-09-02 
> 16:03:23.097905] E [rpc-clnt.c:184:call_bail] 0-staging_static-client-
> 1: bailing out frame type(GlusterFS 4.x v1) op(INODELK(29)) xid =
> 0x2e21 sent = 2018-09-02 15:33:22.765751. timeout = 1800 for  second gluster node>:49154> [2018-09-02 16:03:23.097988] E [MSGID: 114031] 
> [client-rpc-
> fops_v2.c:1306:client4_0_inodelk_cbk] 0-s

[ovirt-users] Gluster clients intermittently hang until first gluster server in a Replica 1 Arbiter 1 cluster is rebooted, server error: 0-management: Unlocking failed & client error: bailing out fra

[Sam McLeod]

7:server_submit_reply] 
(-->/usr/lib64/glusterfs/4.1.2/xlator/debug/io-stats.so(+0x1fd14) 
[0x7f8470319d14] 
-->/usr/lib64/glusterfs/4.1.2/xlator/protocol/server.so(+0x5f24a) 
[0x7f846bdde24a] 
-->/usr/lib64/glusterfs/4.1.2/xlator/protocol/server.so(+0xafce) 
[0x7f846bd89fce] ) 0-: Reply submission failed
[2018-09-03 01:58:35.129191] E [rpcsvc.c:1378:rpcsvc_submit_generic] 
0-rpc-service: failed to submit message (XID: 0x3fc6, Program: GlusterFS 4.x 
v1, ProgVers: 400, Proc: 29) to rpc-transport (tcp.staging_static-server)
[2018-09-03 01:58:35.129219] E [server.c:137:server_submit_reply] 
(-->/usr/lib64/glusterfs/4.1.2/xlator/debug/io-stats.so(+0x1fd14) 
[0x7f8470319d14] 
-->/usr/lib64/glusterfs/4.1.2/xlator/protocol/server.so(+0x5f24a) 
[0x7f846bdde24a] 
-->/usr/lib64/glusterfs/4.1.2/xlator/protocol/server.so(+0xafce) 
[0x7f846bd89fce] ) 0-: Reply submission failed



Gluster volume information:


# gluster volume info staging_static

Volume Name: staging_static
Type: Replicate
Volume ID: 7f3b8e91-afea-4fc6-be83-3399a089b6f3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: :/mnt/gluster-storage/staging_static
Brick2: :/mnt/gluster-storage/staging_static
Brick3: :/mnt/gluster-storage/staging_static (arbiter)
Options Reconfigured:
storage.fips-mode-rchecksum: true
cluster.self-heal-window-size: 16
cluster.shd-wait-qlength: 4096
cluster.shd-max-threads: 8
performance.cache-min-file-size: 2KB
performance.rda-cache-limit: 1GB
network.inode-lru-limit: 5
server.outstanding-rpc-limit: 256
transport.listen-backlog: 2048
performance.write-behind-window-size: 512MB
performance.stat-prefetch: true
performance.io-thread-count: 16
performance.client-io-threads: true
performance.cache-size: 1GB
performance.cache-refresh-timeout: 60
performance.cache-invalidation: true
cluster.use-compound-fops: true
cluster.readdir-optimize: true
cluster.lookup-optimize: true
cluster.favorite-child-policy: size
cluster.eager-lock: true
client.event-threads: 4
nfs.disable: on
transport.address-family: inet
diagnostics.brick-log-level: ERROR
diagnostics.client-log-level: ERROR
features.cache-invalidation-timeout: 300
features.cache-invalidation: true
network.ping-timeout: 15
performance.cache-max-file-size: 3MB
performance.md-cache-timeout: 300
server.event-threads: 4

Thanks in advance,

--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod

Words are my own opinions and do not necessarily represent those of my employer 
or partners.

___
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/VYM3KLQ5LMYSVBDUWINO337VUVAQC7OE/

[ovirt-users] Re: Upgrade from 4.1 to 4.2.3 failed

[Sam McLeod]

Hi John,

Gluster 3.8 is very old and has not been supported for quite some time.
It's recommended to use Gluster 3.12.

See https://www.gluster.org/release-schedule/ 
<https://www.gluster.org/release-schedule/>

Thanks,
--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod

Words are my own opinions and do not necessarily represent those of my employer 
or partners.

> On 15 May 2018, at 9:32 am, John Florian  wrote:
> 
> When I run engine-setup, I get this error:
> 
> [ ERROR ] Yum [u'Errors were encountered while downloading packages.', 
> u'gdeploy-2.0.6-1.el7.noarch: failure: gdeploy-2.0.6-1.el7.noarch.rpm from 
> ovirt-4.1-centos-gluster38: [Errno 256] No more mirrors to 
> try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm:
>  [Errno 14] HTTP Error 404 - Not Found']
> [ ERROR ] Failed to execute stage 'Package installation': [u'Errors were 
> encountered while downloading packages.', u'gdeploy-2.0.6-1.el7.noarch: 
> failure: gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: 
> [Errno 256] No more mirrors to 
> try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeploy-2.0.6-1.el7.noarch.rpm:
>  [Errno 14] HTTP Error 404 - Not Found']
> 
> If I go exploring with my browser, it doesn't appear that 
> http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8 
> <http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8> exists any 
> more.  The oldest there is 3.10.  I didn't see any mention of needing to 
> revise this repo config, but I obviously must have missed something.
> 
> -- 
> John Florian
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org

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

[ovirt-users] Re: Package conflicts with release of oVirt 4.2.3 and CentOS 7.5 (cockpit packages required by ovirt)

[Sam McLeod]

It’s ok, these things happen - IMO the system fails the people far more than 
the people fail the system.

The effort all the contributors put in often goes unrewarded and unmentioned, 
while slip-ups are awfully visible.

Please remember how much we (the community and users) do appreciate the hard 
work contributors and maintainers put in to maintaining ovirt and related 
projects.

--
Sam McLeod

> On 14 May 2018, at 17:08, Sandro Bonazzola  wrote:
> 
> Everything should be fixed today starting around 11 utc. Packages from virt 
> sig has been signed after centos 7.5 GA but being Thursday afternoon the 
> publishing of the packages has been delayed to Monday morning. Very bad 
> timing for releasing centos. 
> 
> Il lun 14 mag 2018, 08:55 Eduardo Mayoral  ha scritto:
>> Same thing here. I thought of excluding cockpit* from the update for now, 
>> but that is not an option as cockpit-storaged update is required because of 
>> the transition from storaged to udisks. :-(
>> 
>> 
>> Ideas?
>> 
>>> On 14/05/18 01:34, Sam McLeod wrote:
>>> Howdy all,
>>> 
>>> I've again been hit by packaging conflicts with the release of 
>>> oVirt 4.2.3 and CentOS 7.5.
>>> 
>>> The error I'm getting when running yum upgrade then accepting the list of 
>>> packages to upgrade is:
>>> 
>>> Transaction check error:
>>>   file /usr/share/cockpit/networkmanager/manifest.json from install of 
>>> cockpit-system-160-3.el7.centos.noarch conflicts with file from package 
>>> cockpit-networkmanager-160-1.el7.centos.noarch
>>> 
>>> * Both these packages are provided as part of centos extras, this leaves me 
>>> wondering if this repo is expected to be disabled when oVirt is installed?
>>> 
>>> * If that is the case, there should probably be some clear documentation on 
>>> what yum repos should not ever be enabled when using oVirt as it seems 
>>> package conflicts are very common - thoughts?
>>> 
>>> 
>>> The two packages:
>>> 
>>> # yum info cockpit-system-160-3.el7.centos.noarch
>>> Loaded plugins: fastestmirror, package_upload, priorities, product-id, 
>>> protectbase, rpm-warm-cache, search-disabled-repos, subscription-manager, 
>>> versionlock
>>> This system is not registered with an entitlement server. You can use 
>>> subscription-manager to register.
>>> Loading mirror speeds from cached hostfile
>>> 0 packages excluded due to repository protections
>>> Available Packages
>>> Name: cockpit-system
>>> Arch: noarch
>>> Version : 160
>>> Release : 3.el7.centos
>>> Size: 1.1 M
>>> Repo: extras/7/x86_64
>>> Summary : Cockpit admin interface package for configuring and 
>>> troubleshooting a system
>>> URL : http://cockpit-project.org/
>>> License : LGPLv2+
>>> Description : This package contains the Cockpit shell and system 
>>> configuration interfaces.
>>> 
>>>  # yum info cockpit-networkmanager-160-1.el7.centos.noarch
>>> Loaded plugins: fastestmirror, package_upload, priorities, product-id, 
>>> protectbase, rpm-warm-cache, search-disabled-repos, subscription-manager, 
>>> versionlock
>>> This system is not registered with an entitlement server. You can use 
>>> subscription-manager to register.
>>> Loading mirror speeds from cached hostfile
>>> 0 packages excluded due to repository protections
>>> Installed Packages
>>> Name: cockpit-networkmanager
>>> Arch: noarch
>>> Version : 160
>>> Release : 1.el7.centos
>>> Size: 114 k
>>> Repo: installed
>>> From repo   : extras
>>> Summary : Cockpit user interface for networking, using NetworkManager
>>> URL : http://cockpit-project.org/
>>> License : LGPLv2+
>>> Description : The Cockpit component for managing networking.  This package 
>>> uses NetworkManager.
>>> 
>>> 
>>> --
>>> Sam McLeod (protoporpoise on IRC)
>>> https://smcleod.net
>>> https://twitter.com/s_mcleod
>>> 
>>> Words are my own opinions and do not necessarily represent those of my 
>>> employer or partners.
>>> 
>>> 
>>> 
>>> ___
>>> 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

[ovirt-users] Re: Package conflicts with release of oVirt 4.2.3 and CentOS 7.5 (cockpit packages required by ovirt)

[Sam McLeod]

Not surprised.

We’ve had a LOT of problems since the CentOS 7.5 release last week.

It’s been quite a headache fixing everything *sigh*.

--
Sam McLeod

> On 14 May 2018, at 17:08, Sandro Bonazzola  wrote:
> 
> Everything should be fixed today starting around 11 utc. Packages from virt 
> sig has been signed after centos 7.5 GA but being Thursday afternoon the 
> publishing of the packages has been delayed to Monday morning. Very bad 
> timing for releasing centos. 
> 
> Il lun 14 mag 2018, 08:55 Eduardo Mayoral  ha scritto:
>> Same thing here. I thought of excluding cockpit* from the update for now, 
>> but that is not an option as cockpit-storaged update is required because of 
>> the transition from storaged to udisks. :-(
>> 
>> 
>> Ideas?
>> 
>>> On 14/05/18 01:34, Sam McLeod wrote:
>>> Howdy all,
>>> 
>>> I've again been hit by packaging conflicts with the release of 
>>> oVirt 4.2.3 and CentOS 7.5.
>>> 
>>> The error I'm getting when running yum upgrade then accepting the list of 
>>> packages to upgrade is:
>>> 
>>> Transaction check error:
>>>   file /usr/share/cockpit/networkmanager/manifest.json from install of 
>>> cockpit-system-160-3.el7.centos.noarch conflicts with file from package 
>>> cockpit-networkmanager-160-1.el7.centos.noarch
>>> 
>>> * Both these packages are provided as part of centos extras, this leaves me 
>>> wondering if this repo is expected to be disabled when oVirt is installed?
>>> 
>>> * If that is the case, there should probably be some clear documentation on 
>>> what yum repos should not ever be enabled when using oVirt as it seems 
>>> package conflicts are very common - thoughts?
>>> 
>>> 
>>> The two packages:
>>> 
>>> # yum info cockpit-system-160-3.el7.centos.noarch
>>> Loaded plugins: fastestmirror, package_upload, priorities, product-id, 
>>> protectbase, rpm-warm-cache, search-disabled-repos, subscription-manager, 
>>> versionlock
>>> This system is not registered with an entitlement server. You can use 
>>> subscription-manager to register.
>>> Loading mirror speeds from cached hostfile
>>> 0 packages excluded due to repository protections
>>> Available Packages
>>> Name: cockpit-system
>>> Arch: noarch
>>> Version : 160
>>> Release : 3.el7.centos
>>> Size: 1.1 M
>>> Repo: extras/7/x86_64
>>> Summary : Cockpit admin interface package for configuring and 
>>> troubleshooting a system
>>> URL : http://cockpit-project.org/
>>> License : LGPLv2+
>>> Description : This package contains the Cockpit shell and system 
>>> configuration interfaces.
>>> 
>>>  # yum info cockpit-networkmanager-160-1.el7.centos.noarch
>>> Loaded plugins: fastestmirror, package_upload, priorities, product-id, 
>>> protectbase, rpm-warm-cache, search-disabled-repos, subscription-manager, 
>>> versionlock
>>> This system is not registered with an entitlement server. You can use 
>>> subscription-manager to register.
>>> Loading mirror speeds from cached hostfile
>>> 0 packages excluded due to repository protections
>>> Installed Packages
>>> Name: cockpit-networkmanager
>>> Arch: noarch
>>> Version : 160
>>> Release : 1.el7.centos
>>> Size: 114 k
>>> Repo: installed
>>> From repo   : extras
>>> Summary : Cockpit user interface for networking, using NetworkManager
>>> URL : http://cockpit-project.org/
>>> License : LGPLv2+
>>> Description : The Cockpit component for managing networking.  This package 
>>> uses NetworkManager.
>>> 
>>> 
>>> --
>>> Sam McLeod (protoporpoise on IRC)
>>> https://smcleod.net
>>> https://twitter.com/s_mcleod
>>> 
>>> Words are my own opinions and do not necessarily represent those of my 
>>> employer or partners.
>>> 
>>> 
>>> 
>>> ___
>>> 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

[ovirt-users] Package conflicts with release of oVirt 4.2.3 and CentOS 7.5 (cockpit packages required by ovirt)

[Sam McLeod]

Howdy all,

I've again been hit by packaging conflicts with the release of oVirt 4.2.3 and 
CentOS 7.5.

The error I'm getting when running yum upgrade then accepting the list of 
packages to upgrade is:

Transaction check error:
  file /usr/share/cockpit/networkmanager/manifest.json from install of 
cockpit-system-160-3.el7.centos.noarch conflicts with file from package 
cockpit-networkmanager-160-1.el7.centos.noarch

* Both these packages are provided as part of centos extras, this leaves me 
wondering if this repo is expected to be disabled when oVirt is installed?

* If that is the case, there should probably be some clear documentation on 
what yum repos should not ever be enabled when using oVirt as it seems package 
conflicts are very common - thoughts?


The two packages:

# yum info cockpit-system-160-3.el7.centos.noarch
Loaded plugins: fastestmirror, package_upload, priorities, product-id, 
protectbase, rpm-warm-cache, search-disabled-repos, subscription-manager, 
versionlock
This system is not registered with an entitlement server. You can use 
subscription-manager to register.
Loading mirror speeds from cached hostfile
0 packages excluded due to repository protections
Available Packages
Name: cockpit-system
Arch: noarch
Version : 160
Release : 3.el7.centos
Size: 1.1 M
Repo: extras/7/x86_64
Summary : Cockpit admin interface package for configuring and 
troubleshooting a system
URL : http://cockpit-project.org/
License : LGPLv2+
Description : This package contains the Cockpit shell and system configuration 
interfaces.

 # yum info cockpit-networkmanager-160-1.el7.centos.noarch
Loaded plugins: fastestmirror, package_upload, priorities, product-id, 
protectbase, rpm-warm-cache, search-disabled-repos, subscription-manager, 
versionlock
This system is not registered with an entitlement server. You can use 
subscription-manager to register.
Loading mirror speeds from cached hostfile
0 packages excluded due to repository protections
Installed Packages
Name: cockpit-networkmanager
Arch: noarch
Version : 160
Release : 1.el7.centos
Size: 114 k
Repo: installed
From repo   : extras
Summary : Cockpit user interface for networking, using NetworkManager
URL : http://cockpit-project.org/
License : LGPLv2+
Description : The Cockpit component for managing networking.  This package uses 
NetworkManager.


--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod

Words are my own opinions and do not necessarily represent those of my employer 
or partners.

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

Re: [ovirt-users] Cannot install ovirt-hosted-engine-setup as package has file conflicts in its dependancies

[Sam McLeod]

Release notes make me excited - alas, I must have missed this!

Might be worth adding to the installation pre-reqs, I'll consider doing a MR.

Thanks again,

--
Sam McLeod
Please respond via email when possible.
https://smcleod.net
https://twitter.com/s_mcleod

> On 30 Apr 2018, at 4:57 pm, Nico De Ranter  
> wrote:
> 
> Yep, that's what I did after hitting my head on the same thing.  It's so 
> boring to read release notes upfront ;-)
> 
> Nico
> 
> On Mon, Apr 30, 2018 at 8:55 AM, Sam McLeod  <mailto:mailingli...@smcleod.net>> wrote:
> Thanks for the tip Nico - I hadn't spotted that.
> 
> We use EPEL for a number of packages across our hosts, I'm guessing a proper 
> workaround for us might be to only enable it for individual packages.
> 
> Thanks again!
> 
> --
> Sam McLeod
> Please respond via email when possible.
> https://smcleod.net <https://smcleod.net/>
> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
> 
>> On 30 Apr 2018, at 4:53 pm, Nico De Ranter > <mailto:nico.deran...@esaturnus.com>> wrote:
>> 
>> Do not install the EPEL repository.  See also the remark in the release 
>> notes about this
>> 
>> https://ovirt.org/release/4.2.0/#epel 
>> <https://ovirt.org/release/4.2.0/#epel>
>> 
>> Do a clean install of CentOS, install oVirt. Afterwards get anything extra 
>> from epel if required.
>> 
>> Nico
>> 
>> On Mon, Apr 30, 2018 at 1:35 AM, Sam McLeod > <mailto:mailingli...@smcleod.net>> wrote:
>> This started occurring on all new oVirt installs I've attempted to do on 
>> minimal CentOS 7 since 27/4.
>> 
>> I logged a bug for this on Bugzilla last week: 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1572434 
>> <https://bugzilla.redhat.com/show_bug.cgi?id=1572434>
>> 
>> The package ovirt-hosted-engine-setup depends on collectd, collectd-disk and 
>> collectd-write_http.
>> 
>> ovirt-hosted-engine-setup depends on the two collectd plugins which are 
>> provided by the ovirt-4.2-centos-opstools repo - but those two packages seem 
>> to provide files that are already included in the standard collectd package 
>> from epel (which the package also depends on).
>> 
>> Additionally, this conflict is not picked up until the packages are at the 
>> install phase, resulting in:
>> 
>> Transaction check error:
>>   file /usr/lib64/collectd/disk.so conflicts between attempted installs of 
>> collectd-disk-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64
>>   file /usr/lib64/collectd/write_http.so conflicts between attempted 
>> installs of collectd-write_http-5.8.0-3.el7.x86_64 and 
>> collectd-5.8.0-3.el7.x86_64
>> 
>> ---
>> 
>> root@s1-b2:~ 1 # yum info collectd-write_http
>> Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
>> versionlock
>> Loading mirror speeds from cached hostfile
>>  * ovirt-4.2-epel: fedora.melbourneitmirror.net 
>> <http://fedora.melbourneitmirror.net/>
>> 0 packages excluded due to repository protections
>> Available Packages
>> Name: collectd-write_http
>> Arch: x86_64
>> Version : 5.8.0
>> Release : 3.el7
>> Size: 33 k
>> Repo: ovirt-4.2-centos-opstools/x86_64
>> Summary : HTTP output plugin for collectd
>> URL : https://collectd.org/ <https://collectd.org/>
>> License : MIT and GPLv2
>> Description : This plugin can send data to Redis.
>> 
>> root@s1-b2:~  # yum info collectd-disk-5.8.0-3.el7.x86_64
>> Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
>> versionlock
>> Loading mirror speeds from cached hostfile
>>  * ovirt-4.2-epel: fedora.melbourneitmirror.net 
>> <http://fedora.melbourneitmirror.net/>
>> 0 packages excluded due to repository protections
>> Available Packages
>> Name: collectd-disk
>> Arch: x86_64
>> Version : 5.8.0
>> Release : 3.el7
>> Size: 26 k
>> Repo: ovirt-4.2-centos-opstools/x86_64
>> Summary : Disk plugin for collectd
>> URL : https://collectd.org/ <https://collectd.org/>
>> License : MIT and GPLv2
>> Description : This plugin collects statistics of harddisk and, where 
>> supported, partitions.
>> 
>> root@s1-b2:~  # yum info collectd-5.8.0-3.el7.x86_64
>> Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
>> versionlock
>> Loading mirror speeds from cached hostfile
>>  *

Re: [ovirt-users] Cannot install ovirt-hosted-engine-setup as package has file conflicts in its dependancies

[Sam McLeod]

Thanks for the tip Nico - I hadn't spotted that.

We use EPEL for a number of packages across our hosts, I'm guessing a proper 
workaround for us might be to only enable it for individual packages.

Thanks again!

--
Sam McLeod
Please respond via email when possible.
https://smcleod.net
https://twitter.com/s_mcleod

> On 30 Apr 2018, at 4:53 pm, Nico De Ranter  
> wrote:
> 
> Do not install the EPEL repository.  See also the remark in the release notes 
> about this
> 
> https://ovirt.org/release/4.2.0/#epel 
> <https://ovirt.org/release/4.2.0/#epel>
> 
> Do a clean install of CentOS, install oVirt. Afterwards get anything extra 
> from epel if required.
> 
> Nico
> 
> On Mon, Apr 30, 2018 at 1:35 AM, Sam McLeod  <mailto:mailingli...@smcleod.net>> wrote:
> This started occurring on all new oVirt installs I've attempted to do on 
> minimal CentOS 7 since 27/4.
> 
> I logged a bug for this on Bugzilla last week: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1572434 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1572434>
> 
> The package ovirt-hosted-engine-setup depends on collectd, collectd-disk and 
> collectd-write_http.
> 
> ovirt-hosted-engine-setup depends on the two collectd plugins which are 
> provided by the ovirt-4.2-centos-opstools repo - but those two packages seem 
> to provide files that are already included in the standard collectd package 
> from epel (which the package also depends on).
> 
> Additionally, this conflict is not picked up until the packages are at the 
> install phase, resulting in:
> 
> Transaction check error:
>   file /usr/lib64/collectd/disk.so conflicts between attempted installs of 
> collectd-disk-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64
>   file /usr/lib64/collectd/write_http.so conflicts between attempted installs 
> of collectd-write_http-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64
> 
> ---
> 
> root@s1-b2:~ 1 # yum info collectd-write_http
> Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
> versionlock
> Loading mirror speeds from cached hostfile
>  * ovirt-4.2-epel: fedora.melbourneitmirror.net 
> <http://fedora.melbourneitmirror.net/>
> 0 packages excluded due to repository protections
> Available Packages
> Name: collectd-write_http
> Arch: x86_64
> Version : 5.8.0
> Release : 3.el7
> Size: 33 k
> Repo: ovirt-4.2-centos-opstools/x86_64
> Summary : HTTP output plugin for collectd
> URL : https://collectd.org/ <https://collectd.org/>
> License : MIT and GPLv2
> Description : This plugin can send data to Redis.
> 
> root@s1-b2:~  # yum info collectd-disk-5.8.0-3.el7.x86_64
> Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
> versionlock
> Loading mirror speeds from cached hostfile
>  * ovirt-4.2-epel: fedora.melbourneitmirror.net 
> <http://fedora.melbourneitmirror.net/>
> 0 packages excluded due to repository protections
> Available Packages
> Name: collectd-disk
> Arch: x86_64
> Version : 5.8.0
> Release : 3.el7
> Size: 26 k
> Repo: ovirt-4.2-centos-opstools/x86_64
> Summary : Disk plugin for collectd
> URL : https://collectd.org/ <https://collectd.org/>
> License : MIT and GPLv2
> Description : This plugin collects statistics of harddisk and, where 
> supported, partitions.
> 
> root@s1-b2:~  # yum info collectd-5.8.0-3.el7.x86_64
> Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
> versionlock
> Loading mirror speeds from cached hostfile
>  * ovirt-4.2-epel: fedora.melbourneitmirror.net 
> <http://fedora.melbourneitmirror.net/>
> 0 packages excluded due to repository protections
> Available Packages
> Name: collectd
> Arch: x86_64
> Version : 5.8.0
> Release : 3.el7
> Size: 711 k
> Repo: epel
> Summary : Statistics collection daemon for filling RRD files
> URL : https://collectd.org/ <https://collectd.org/>
> License : GPLv2
> Description : collectd is a daemon which collects system performance 
> statistics periodically
> : and provides mechanisms to store the values in a variety of 
> ways,
> : for example in RRD files.
> 
> 
> --
> Sam McLeod
> Please respond via email when possible.
> https://smcleod.net <https://smcleod.net/>
> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
> 
> ___
> Users mailing list
> Users@ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Cannot install ovirt-hosted-engine-setup as package has file conflicts in its dependancies

[Sam McLeod]

This started occurring on all new oVirt installs I've attempted to do on 
minimal CentOS 7 since 27/4.

I logged a bug for this on Bugzilla last week: 
https://bugzilla.redhat.com/show_bug.cgi?id=1572434 
<https://bugzilla.redhat.com/show_bug.cgi?id=1572434>

The package ovirt-hosted-engine-setup depends on collectd, collectd-disk and 
collectd-write_http.

ovirt-hosted-engine-setup depends on the two collectd plugins which are 
provided by the ovirt-4.2-centos-opstools repo - but those two packages seem to 
provide files that are already included in the standard collectd package from 
epel (which the package also depends on).

Additionally, this conflict is not picked up until the packages are at the 
install phase, resulting in:

Transaction check error:
  file /usr/lib64/collectd/disk.so conflicts between attempted installs of 
collectd-disk-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64
  file /usr/lib64/collectd/write_http.so conflicts between attempted installs 
of collectd-write_http-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64

---

root@s1-b2:~ 1 # yum info collectd-write_http
Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
versionlock
Loading mirror speeds from cached hostfile
 * ovirt-4.2-epel: fedora.melbourneitmirror.net
0 packages excluded due to repository protections
Available Packages
Name: collectd-write_http
Arch: x86_64
Version : 5.8.0
Release : 3.el7
Size: 33 k
Repo: ovirt-4.2-centos-opstools/x86_64
Summary : HTTP output plugin for collectd
URL : https://collectd.org/ <https://collectd.org/>
License : MIT and GPLv2
Description : This plugin can send data to Redis.

root@s1-b2:~  # yum info collectd-disk-5.8.0-3.el7.x86_64
Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
versionlock
Loading mirror speeds from cached hostfile
 * ovirt-4.2-epel: fedora.melbourneitmirror.net
0 packages excluded due to repository protections
Available Packages
Name: collectd-disk
Arch: x86_64
Version : 5.8.0
Release : 3.el7
Size: 26 k
Repo: ovirt-4.2-centos-opstools/x86_64
Summary : Disk plugin for collectd
URL : https://collectd.org/ <https://collectd.org/>
License : MIT and GPLv2
Description : This plugin collects statistics of harddisk and, where supported, 
partitions.

root@s1-b2:~  # yum info collectd-5.8.0-3.el7.x86_64
Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, 
versionlock
Loading mirror speeds from cached hostfile
 * ovirt-4.2-epel: fedora.melbourneitmirror.net
0 packages excluded due to repository protections
Available Packages
Name: collectd
Arch: x86_64
Version : 5.8.0
Release : 3.el7
Size: 711 k
Repo: epel
Summary : Statistics collection daemon for filling RRD files
URL : https://collectd.org/ <https://collectd.org/>
License : GPLv2
Description : collectd is a daemon which collects system performance statistics 
periodically
: and provides mechanisms to store the values in a variety of ways,
: for example in RRD files.


--
Sam McLeod
Please respond via email when possible.
https://smcleod.net
https://twitter.com/s_mcleod

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

Re: [ovirt-users] ovirt-live 4.2 - missing stable ISO? + Networking question - when to setup host & in NM or ifcfg?

[Sam McLeod]

> On 10 Jan 2018, at 19:27, Yaniv Kaul  <mailto:yk...@redhat.com>> wrote:
> 
>> On Wed, Jan 10, 2018 at 8:35 AM, Sam McLeod > <mailto:mailingli...@smcleod.net>> wrote:
>> I'm trying to find the stable / current oVirt-live ISO to download.
>> 
>> According to the official documentation, it looks like there is only the 
>> legacy 4.1 ISO, or nightly / unstable builds of 4.2(.2?)?
>> 
>> SRC: https://www.ovirt.org/download/ovirt-live/ 
>> <https://www.ovirt.org/download/ovirt-live/>
>> 
>> I'm hoping we have deprecated it. For demo purposes, you could set up 
>> ovirt-system-tests[1]. For an all-in-one you could either install the Engine 
>> and the hypervisor on the same physical host, or a self-hosted-engine with a 
>> single physical node.


I just realised where I was getting confused, I simply was mixing up 'oVirt 
live' and 'oVirt node', both of which also have a very similar looking 
documentation page.

I've submitted a MR to clarify that oVirt live is deprecated, and to add a link 
to oVirt node: https://github.com/oVirt/ovirt-site/pull/1478
>> 
>> Example diagram of infrastructure: https://i.imgur.com/U4hCP3a.png 
>> <https://i.imgur.com/U4hCP3a.png>
>> 
>> With iSCSI, I prefer multipathing, but I see why you'd want bond, if it's 
>> used for other traffic as well.

Indeed, this interface acts as a 20Gbit LACP bond to the core switches passing 
not just iSCSI traffic over a specific VLAN but providing other VLANs / 
networks to servers.

>> Y.
>> 
>> [1] ovirt-system-tests.readthedocs.io/en/latest/ 
>> <http://ovirt-system-tests.readthedocs.io/en/latest/> 
>>  


--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod

Words are my own opinions and do not necessarily represent those of my employer 
or partners.

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

Re: [ovirt-users] ovirt-live 4.2 - missing stable ISO? + Networking question - when to setup host & in NM or ifcfg?

[Sam McLeod]

Excellent responses, I think you really covered everything quite well there.

I’d heard some contradictory information from various sources so wasn’t quite 
sure what to believe.

I’ve already contributed one (tiny) documentation patch that was merged in 
yesterday - if we go ahead with ovirt from XenServer - I’ll definitely be 
contributing more, you have my word on that.

Thanks again for your time.

--
Sam McLeod (protoporpoise on IRC)

> On 10 Jan 2018, at 19:27, Yaniv Kaul  wrote:
> 
> 
> 
>> On Wed, Jan 10, 2018 at 8:35 AM, Sam McLeod  wrote:
>> I'm trying to find the stable / current oVirt-live ISO to download.
>> 
>> According to the official documentation, it looks like there is only the 
>> legacy 4.1 ISO, or nightly / unstable builds of 4.2(.2?)?
>> 
>> SRC: https://www.ovirt.org/download/ovirt-live/
> 
> I'm hoping we have deprecated it. For demo purposes, you could set up 
> ovirt-system-tests[1]. For an all-in-one you could either install the Engine 
> and the hypervisor on the same physical host, or a self-hosted-engine with a 
> single physical node.
>  
>> 
>> ---
>> 
>> Alternatively, if one is to deploy the 'self-hosted-engine' on top of CentOS 
>> 7.4, the documentation doesn't make it clear what you should vs shouldn't 
>> setup on the host prior to deploying the hosted engine.
>> 
>> For example, some big questions pop up around networking, e.g.:
>> 
>> - Should I be setting those up during CentOS's install using the installer 
>> (which I believe configures them with Network Manager), or should I be 
>> setting up the ifcfg files manually by hand without touching Network Manager 
>> via the server's remote console after the install has finished?
> 
> Either is fine.
>  
>> 
>> - Is it OK for me to setup my first two NICs in a mode 1 (A/P) or 4 (XOR) 
>> bond (these are connected to a 'dumb' switch and provide internet access and 
>> later will be used for management activities such as vm migrations).
> 
> It is, though if not needed, I think it's easier to do it later via oVirt.
>  
>> 
>> - Is it OK for me to setup my second two NICs in a LACP bond (required as 
>> they connect to our core switches) and to add VLANs on top of that bond, 
>> include the storage VLAN required for iSCSI access which is later required 
>> to host the hosted-engine?
> 
> It is, though it might be easier to do it later via oVirt (unless you need it 
> to access the storage Hosted-Engine is using!)
>  
>> 
>> SRC: 
>> https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine/
>> 
>> ---
>> 
>> I think the hardest thing is that the documentation for oVirt seems very 
>> poorly maintained, or it's at least scattered around various links or 
>> different guides.
> 
> Our documentation, like the code, is open source. Patches are always welcome.
> 
>> 
>> Perhaps this isn't obvious to people that are already familiar with the 
>> components, terminology and setup practises of oVirt / RHEV, but for someone 
>> like me coming from XenServer - it's confusing as anything.
>> 
>> 
>> Example diagram of infrastructure: https://i.imgur.com/U4hCP3a.png
> 
> With iSCSI, I prefer multipathing, but I see why you'd want bond, if it's 
> used for other traffic as well.
> Y.
> 
> [1] ovirt-system-tests.readthedocs.io/en/latest/ 
>  
>> 
>> --
>> Sam McLeod (protoporpoise on IRC)
>> https://smcleod.net
>> https://twitter.com/s_mcleod
>> 
>> Words are my own opinions and do not necessarily represent those of my 
>> employer or partners.
>> 
>> 
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>> 
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] ovirt-live 4.2 - missing stable ISO? + Networking question - when to setup host & in NM or ifcfg?

[Sam McLeod]

I'm trying to find the stable / current oVirt-live ISO to download.

According to the official documentation, it looks like there is only the legacy 
4.1 ISO, or nightly / unstable builds of 4.2(.2?)?

SRC: https://www.ovirt.org/download/ovirt-live/ 
<https://www.ovirt.org/download/ovirt-live/>

---

Alternatively, if one is to deploy the 'self-hosted-engine' on top of CentOS 
7.4, the documentation doesn't make it clear what you should vs shouldn't setup 
on the host prior to deploying the hosted engine.

For example, some big questions pop up around networking, e.g.:

- Should I be setting those up during CentOS's install using the installer 
(which I believe configures them with Network Manager), or should I be setting 
up the ifcfg files manually by hand without touching Network Manager via the 
server's remote console after the install has finished?

- Is it OK for me to setup my first two NICs in a mode 1 (A/P) or 4 (XOR) bond 
(these are connected to a 'dumb' switch and provide internet access and later 
will be used for management activities such as vm migrations).

- Is it OK for me to setup my second two NICs in a LACP bond (required as they 
connect to our core switches) and to add VLANs on top of that bond, include the 
storage VLAN required for iSCSI access which is later required to host the 
hosted-engine?

SRC: 
https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine/
 
<https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine/>

---

I think the hardest thing is that the documentation for oVirt seems very poorly 
maintained, or it's at least scattered around various links or different guides.

Perhaps this isn't obvious to people that are already familiar with the 
components, terminology and setup practises of oVirt / RHEV, but for someone 
like me coming from XenServer - it's confusing as anything.


Example diagram of infrastructure: https://i.imgur.com/U4hCP3a.png 
<https://i.imgur.com/U4hCP3a.png>

--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod

Words are my own opinions and do not necessarily represent those of my employer 
or partners.

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

Re: [ovirt-users] Behaviour when attaching shared iSCSI storage with existing data

[Sam McLeod]

Hi Yaniv,

Thanks for your detailed reply, it's very much appreciated.

> On 5 Jan 2018, at 8:34 pm, Yaniv Kaul  wrote:
> 
> Indeed, greenfield deployment has its advantages.
> 
> The down side to that is juggling iSCSI LUNs, I'll have to migrate VMs on 
> XenServer off one LUN at a time, remove that LUN from XenServer and add it to 
> oVirt as new storage, and continue - but if it's what has to be done, we'll 
> do it.
> 
> The migration of VMs has three parts:
> - VM configuration data (from name to number of CPUs, memory, etc.)

That's not too much of an issue for us, we have a pretty standard set of 
configuration for performance / sizing.

> - Data - the disks themselves.

This is the big one, for most hosts at least the data is on a dedicated logical 
volume, for example if it's postgresql, it would be LUKS on top of a logical 
volume for /var/lib/pgsql etc

> - Adjusting VM internal data (paths, boot kernel, grub?, etc.)

Everything is currently PVHVM which uses standard grub2, you could literally dd 
any one of our VMs to a physical disk and boot it in any x86/64 machine.

> The first item could be automated. Unfortunately, it was a bit of a challenge 
> to find a common automation platform. For example, we have great Ansible 
> support, which I could not find for XenServer (but[1], which may be a bit 
> limited). Perhaps if there aren't too many VMs, this could be done manually. 
> If you use Foreman, btw, then it could probably be used for both to provision?
> The 2nd - data movement could be done in at least two-three ways:
> 1. Copy using 'dd' from LUN/LV/raw/? to a raw volume in oVirt.
> 2. (My preferred option), copy using 'dd' from LUN/LV/raw and upload using 
> the oVirt upload API (example in Python[2]). I think that's an easy to 
> implement option and provides the flexibility to copy from pretty much any 
> source to oVirt.

A key thing here would be how quickly the oVirt API can ingest the data, our 
storage LUNs are 100% SSD each LUN can easily provide at least 1000MB/s and 
around 2M 4k write IOP/s and 2-4M 4k read IOP/s so we always find hypervisors 
disk virtualisation mechanisms to be the bottleneck - but adding an API to the 
mix, especially one that is single threaded (if that does the data stream 
processing) could be a big performance problem.

> 3. There are ways to convert XVA to qcow2 - I saw some references on the 
> Internet, never tried any.

This is something I was thinking of potentially doing, I can actually export 
each VM as an OVF/OVA package - since that's very standard I'm assuming oVirt 
can likely import them and convert to qcow2 or raw/LVM?

> 
> As for the last item, I'm really not sure what changes are needed, if at all. 
> I don't know the disk convention, for example (/dev/sd* for SCSI disk -> 
> virtio-scsi, but are there are other device types?)

Xen's virtual disks are all /dev/xvd[a-z]
Thankfully, we partition everything as LVM and partitions (other than boot I 
think) are mounted as such.

> 
> I'd be happy to help with any adjustment needed for the Python script below.

Very much appreciated, when I get to the point where I'm happy with the basic 
architectural design and POC deployment of oVirt - that's when I'll be testing 
importing VMs / data in various ways and have made note of these scripts.

> 
> Y.
> 
> [1] http://docs.ansible.com/ansible/latest/xenserver_facts_module.html 
> 
> [2] 
> https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py
>  
> 
>  

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

Re: [ovirt-users] Deploying self-hosted engine - Waiting for VDSM host to become operation + received packet with own address as source

[Sam McLeod]

Hi Simone,

Thanks for your response.

> Could you please attach/share hosted-engine-setup, vdsm, supervdsm and 
> host-deploy (on the engine VM) logs?

I was on the IRC channel yesterday (username: protoporpoise) and user 'zipur' 
suggested that although the self-hosted engine documentation doesn't mention it 
- they thought that perhaps oVirt doesn't support having it's management 
network setup (bridged) to a bonded interface.

It does indeed seem like the documentation is a bit fragmented between the 
three major install options (self-hosted engine vs engine vs the appliance-like 
ISO (I think this was called oVirt live?)).

In addition, we usually remove NetworkManager as part of our normal / existing 
CentOS 7 SOE as we believe it's not ready for server deployments (yet, maybe 
it's OK in the latest Fedora), however it appears oVirt depends on it.

I noticed it generates a big mess of ifcfg files in sysconfig/network-scripts/ 
, and often changing configuration using nmtui / nmcli / editing files gives 
inconsistent results and nmtui actually adds a lot of options to bonded 
interfaces without notifying you or letting you set / change them (for example, 
with LACP, you can't set the lacp_rate to fast, and it sets it to slow for some 
reason), so this wasn't helping the confusion.

Today I'm going to try installing oVirt hosted-engine on CentOS 7.4 without the 
network interfaces being bonded.

> Yes, currently ovirt-hosted-engine-cleanup is not able to revert to initial 
> network configuration but hosted-engine-setup is supposed to be able to 
> consume an existing management bridge.

That's definitely what I experienced yesterday and found it easier (although 
very time consuming) to completely reinstall the entire OS each time to get to 
a 'clean' state to test the install on.
I also had to blkdiscard / zero out the iSCSI LUN, otherwise the installer 
would either crash out, or complain that it can't be used.

Wish me luck for trying the install without bonded interfaces today - I'll 
update this thread with my results and if I'm still having problems I'll 
compile the logs up and provide them (off-list), is there anyone else that I 
should send them to other than yourself?

If I find inconsistent documentation, I'll try to make notes as to where and 
then submit merge requests to the site when possible.

Thanks again, I'll be on the IRC channel all day.


> --
> Sam McLeod (protoporpoise on IRC)
> https://smcleod.net <https://smcleod.net/>
> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
> 
> Words are my own opinions and do not necessarily represent those of my 
> employer or partners.

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

[ovirt-users] Deploying self-hosted engine - Waiting for VDSM host to become operation + received packet with own address as source

[Sam McLeod]

Hello,

I'm trying to setup a host as a self-hosted engine as per 
https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine/
 
<https://www.ovirt.org/documentation/self-hosted/chap-Deploying_Self-Hosted_Engine/>.
The host is configured with two bonded network interfaces:

bond0 = management network for hypervisors, setup as active/passive.
bond1 = network that has VLANs for various network segments for virtual 
machines to use, setup as LACP bond to upstream switches.

On the host, both networks are operational and work as expected.

When setting up the self-hosted engine, bond0 is selected as network to bridge 
with, and a unique IP is given to the self-hosted engine VM.

During the final stages of the self-hosted engine setup, the installer gets 
stuck on ' Waiting for the VDSM host to become operational'.
While it is repeating this every minute or so the host repeats the message 
'bond0: received packet with own address as source address', which is odd to me 
as it's in active/passive bond and I'd only expect to see this kind of message 
on XOR / load balanced interfaces.

Host console screenshot: https://imgur.com/a/a2JLd <https://imgur.com/a/a2JLd>
Host OS: CentOS 7.4
oVirt version: 4.2.0

ip a on host while install is stuck waiting for VDSM:

# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp2s0f0:  mtu 9000 qdisc mq master 
bond1 portid 01373031384833 state UP qlen 1000
link/ether 78:e3:b5:10:74:88 brd ff:ff:ff:ff:ff:ff
3: enp2s0f1:  mtu 9000 qdisc mq master 
bond1 portid 02373031384833 state UP qlen 1000
link/ether 78:e3:b5:10:74:88 brd ff:ff:ff:ff:ff:ff
4: ens1f0:  mtu 1500 qdisc mq master 
bond0 portid 01474835323543 state UP qlen 1000
link/ether 00:9c:02:3c:49:90 brd ff:ff:ff:ff:ff:ff
5: ens1f1:  mtu 1500 qdisc mq master 
bond0 portid 02474835323543 state UP qlen 1000
link/ether 00:9c:02:3c:49:90 brd ff:ff:ff:ff:ff:ff
6: bond1:  mtu 9000 qdisc noqueue state 
UP qlen 1000
link/ether 78:e3:b5:10:74:88 brd ff:ff:ff:ff:ff:ff
inet6 fe80::7ae3:b5ff:fe10:7488/64 scope link
   valid_lft forever preferred_lft forever
7: storage@bond1:  mtu 9000 qdisc noqueue 
state UP qlen 1000
link/ether 78:e3:b5:10:74:88 brd ff:ff:ff:ff:ff:ff
inet 10.51.40.172/24 brd 10.51.40.255 scope global storage
   valid_lft forever preferred_lft forever
inet6 fe80::7ae3:b5ff:fe10:7488/64 scope link
   valid_lft forever preferred_lft forever
9: ovs-system:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether ae:c0:02:25:42:24 brd ff:ff:ff:ff:ff:ff
10: br-int:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether be:92:5d:c3:28:4d brd ff:ff:ff:ff:ff:ff
30: bond0:  mtu 1500 qdisc noqueue 
master ovirtmgmt state UP qlen 1000
link/ether 00:9c:02:3c:49:90 brd ff:ff:ff:ff:ff:ff
46: ovirtmgmt:  mtu 1500 qdisc noqueue state 
UP qlen 1000
link/ether 00:9c:02:3c:49:90 brd ff:ff:ff:ff:ff:ff
inet 10.51.14.112/24 brd 10.51.14.255 scope global ovirtmgmt
   valid_lft forever preferred_lft forever
47: ;vdsmdummy;:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 8e:c0:25:88:40:de brd ff:ff:ff:ff:ff:ff


Before the self-hosted engine install was run the following did not exist:

;vdsmdummy;
ovs-system
br-int
ovirtmgmt

and bond0 was not a slave of ovirtmgmt.

I'm now going to kick off a complete reinstall of CentOS 7 on the host as I've 
since tried cleaning up the host using the ovirt-hosted-engine-cleanup command 
and removing the packages which seem to leave the network configuration a mess 
an doesn't actually cleanup files on disk as expected.


--
Sam McLeod (protoporpoise on IRC)
https://smcleod.net
https://twitter.com/s_mcleod

Words are my own opinions and do not necessarily represent those of my employer 
or partners.

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

Re: [ovirt-users] bad bond name when setting up hosted engine

[Sam McLeod]

Thank you for the information Dan, Dominik and Didi,

To avoid logging yet another bug for this issue, I've updated bug 
https://bugzilla.redhat.com/show_bug.cgi?id=1459229 
<https://bugzilla.redhat.com/show_bug.cgi?id=1459229> as you've mentioned with 
the brief of our conversation here.

By the way, it is very useful to name a bonded interface things other than 
bondXYZ, for example, you might have 6 bonds, each of a different network or 
native VLAN.
It helps with debugging, troubleshooting and logging if the interface is named 
after the (native) network, e.g. your iSCSI storage network might have a bond 
called 'storage', while your management or hypervisor network might have a bond 
named 'mgmt' then perhaps you have 'data' bond that might have several vlans 
off it such as 'db' (database), 'dmz', 'staff' etc... depending on how and 
where you chop your network up.

--
Sam McLeod
https://smcleod.net
https://twitter.com/s_mcleod

> On 7 Jan 2018, at 6:08 pm, Yedidyah Bar David  wrote:
> 
> On Fri, Jan 5, 2018 at 7:44 AM, Dan Kenigsberg  <mailto:dan...@redhat.com>> wrote:
> On Thu, Jan 4, 2018 at 5:50 AM, Sam McLeod  <mailto:mailingli...@smcleod.net>> wrote:
> > I'm having a problem where when setting up hosted engine deployment it fails
> > stating that the selected bond name is bad.
> >
> > "code=25, message=bad bond name(s): mgmt)"
> >
> > - Is there a problem similar to
> > https://bugzilla.redhat.com/show_bug.cgi?id=1519807 
> > <https://bugzilla.redhat.com/show_bug.cgi?id=1519807> that's known?
> 
> Please note that this is just but one bug in a series/tree of
> related bugs, some of which are open. If you decide to follow
> Dan's suggestion, perhaps reuse one of the others, or perhaps
> even better - open a new one, and eventually one or more will
> be closed as duplicate of one or more of the others. Sadly,
> not all of them link properly to each other, and at least one
> which was fixed caused another bug, so the fix was reverted.
> See also e.g. all of the discussion in:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1459229 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1459229>
> 
>  
> > - If it seems to be this bug, is it preferred that I simply update the
> > existing, closed issue as I have done, or open a new bug?
> >
> > --
> > Sam McLeod
> > https://smcleod.net <https://smcleod.net/>
> > https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
> 
> I see that you are trying to use a bond interface named "mgmt".
> To avoid confusion while debugging a system, Vdsm has opted to allow
> only bond names starting with "bond" followed by one or more decimal
> digits. Anything else is considered "bad bond".
> 
> I prefer keeping the "bond" prefix compulsory, but I'd like to hear
> why using different names is useful.
> 
> You can reopen this bug, but please move it to vdsm and rename it: it
> should be something like "Allow any bondXYZ name for bonds" or "Allow
> any bond name" and explain there why it is a good idea.
> 
> Dominik, is there an Engine-side limitation on bond names?
> ___
> Users mailing list
> Users@ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users 
> <http://lists.ovirt.org/mailman/listinfo/users>
> 
> 
> 
> -- 
> Didi

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

Re: [ovirt-users] Behaviour when attaching shared iSCSI storage with existing data

[Sam McLeod]

Thanks for your response Yaniv,

> 
> Context: Investigating migration from XenServer to oVirt (4.2.0)
> 
> A very interesting subject - would love to see the outcome!

I'll certainly be writing one of not many blog posts on the process and outcome 
:)

We've been wanting to switch to something more 'modern' for a while, but 
XenServer has had a very low TCO for us, sure it doesn't perform as well as 
Xen/KVM setup on top of CentOS/RHEL with updated kernels, tuning etc... but it 
just kept working, meanwhile we lost some people in my team so it hasn't been 
the right time to look at moving... until now...

Citrix / XenServer recently screwed over the community (I don't use that term 
lightly) by kneecapping the free / unlicensed version of XenServer: 
https://xenserver.org/blog/entry/xenserver-7-3-changes-to-the-free-edition.html 
<https://xenserver.org/blog/entry/xenserver-7-3-changes-to-the-free-edition.html>

There's a large number of people very unhappy about this, as many of the people 
that contribute heavily to bug reporting, testing and rapid / modern deployment 
lifecycles were / are using the unlicensed version (like us over @infoxchange), 
so for us - this was the straw that broke the camel's back.

I've been looking into various options such as oVirt, Proxmox, OpenStack and a 
roll-your-own libvirt style platform based on our CentOS (7 at present) SOE, so 
far oVirt is looking promising.

>  
> 
> All our iSCSI storage is currently attached to XenServer hosts, XenServer 
> formats those raw LUNs with LVM and VMs are stored within them.
> 
> I suspect we need to copy the data. We might be able to do some tricks, but 
> at the end of the day I think copying the data, LV to LV, makes the most 
> sense.
> However, I wonder what else is needed - do we need a conversion of the 
> drivers, different kernel, etc.?

All our Xen VMs are PVHVM, so there's no reason we could't export them as 
files, then import them to oVirt of we do go down the oVirt path after the POC.
We run kernel-ml across our fleet (almost always running near-latest kernel 
release) and automate all configuration with Puppet.

The issue I have with this is that it will be slow - XenServer's storage 
performance is terrible and there'd be lots of manual work involved.

If this was to be the most simple option, I think we'd opt for rebuilding VMs 
from scratch, letting Puppet setup their config etc... then restoring data from 
backups / rsync etc... that way we'd still be performing the manual work - but 
we'd end up with nice clean VMs.

The down side to that is juggling iSCSI LUNs, I'll have to migrate VMs on 
XenServer off one LUN at a time, remove that LUN from XenServer and add it to 
oVirt as new storage, and continue - but if it's what has to be done, we'll do 
it.

> 
> What are the export options Xen provides? Perhaps OVF?
> Is there an API to stream the disks from Xen?
> Y.

Yes, Xen does have an API, but TBH - it's pretty awful to work with, think XML 
and lots of UUIDs...

>  
> 

--
Sam McLeod
https://smcleod.net
https://twitter.com/s_mcleod

> On 4 Jan 2018, at 7:58 pm, Yaniv Kaul  wrote:
> 
> 
> 
> On Thu, Jan 4, 2018 at 4:03 AM, Sam McLeod  <mailto:mailingli...@smcleod.net>> wrote:
> If one was to attach a shared iSCSI LUN as 'storage' to an oVirt data centre 
> that contains existing data - how does oVirt behave?
> 
> For example the LUN might be partitioned as LVM, then contain existing 
> filesystems etc...
>  
> - Would oVirt see that there is existing data on the LUN and simply attach it 
> as any other linux initiator (client) world, or would it try to wipe the LUN 
> clean and reinitialise it?
> 
> Neither - we will not be importing these as existing data domains, nor wipe 
> them, as they have contents.
>  
> 
> 
> Context: Investigating migration from XenServer to oVirt (4.2.0)
> 
> A very interesting subject - would love to see the outcome!
>  
> 
> All our iSCSI storage is currently attached to XenServer hosts, XenServer 
> formats those raw LUNs with LVM and VMs are stored within them.
> 
> I suspect we need to copy the data. We might be able to do some tricks, but 
> at the end of the day I think copying the data, LV to LV, makes the most 
> sense.
> However, I wonder what else is needed - do we need a conversion of the 
> drivers, different kernel, etc.?
> 
> What are the export options Xen provides? Perhaps OVF?
> Is there an API to stream the disks from Xen?
> Y.
>  
> 
> 
> 
> If the answer to this is already out there and I should have found it by 
> searching, I apologise, please point me to the link and I'll RTFM.
> 
> --
>

Re: [ovirt-users] bad bond name when setting up hosted engine

[Sam McLeod]

(Provided logs off-list)

--
Sam McLeod
https://smcleod.net
https://twitter.com/s_mcleod

> On 5 Jan 2018, at 1:20 am, Doron Fediuck  wrote:
> 
> Can you please provide the installation logs?
> 
> On 4 January 2018 at 05:50, Sam McLeod  <mailto:mailingli...@smcleod.net>> wrote:
> I'm having a problem where when setting up hosted engine deployment it fails 
> stating that the selected bond name is bad.
> 
> "code=25, message=bad bond name(s): mgmt)"
> 
> - Is there a problem similar to 
> https://bugzilla.redhat.com/show_bug.cgi?id=1519807 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1519807> that's known?
> - If it seems to be this bug, is it preferred that I simply update the 
> existing, closed issue as I have done, or open a new bug?
> 
> --
> Sam McLeod
> https://smcleod.net <https://smcleod.net/>
> https://twitter.com/s_mcleod <https://twitter.com/s_mcleod>
> 
> ___
> Users mailing list
> Users@ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users 
> <http://lists.ovirt.org/mailman/listinfo/users>
> 
> 

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

[ovirt-users] bad bond name when setting up hosted engine

[Sam McLeod]

I'm having a problem where when setting up hosted engine deployment it fails 
stating that the selected bond name is bad.

"code=25, message=bad bond name(s): mgmt)"

- Is there a problem similar to 
https://bugzilla.redhat.com/show_bug.cgi?id=1519807 
<https://bugzilla.redhat.com/show_bug.cgi?id=1519807> that's known?
- If it seems to be this bug, is it preferred that I simply update the 
existing, closed issue as I have done, or open a new bug?

--
Sam McLeod
https://smcleod.net
https://twitter.com/s_mcleod

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

[ovirt-users] Behaviour when attaching shared iSCSI storage with existing data

[Sam McLeod]

If one was to attach a shared iSCSI LUN as 'storage' to an oVirt data centre 
that contains existing data - how does oVirt behave?

For example the LUN might be partitioned as LVM, then contain existing 
filesystems etc...
 
- Would oVirt see that there is existing data on the LUN and simply attach it 
as any other linux initiator (client) world, or would it try to wipe the LUN 
clean and reinitialise it?


Context: Investigating migration from XenServer to oVirt (4.2.0)

All our iSCSI storage is currently attached to XenServer hosts, XenServer 
formats those raw LUNs with LVM and VMs are stored within them.



If the answer to this is already out there and I should have found it by 
searching, I apologise, please point me to the link and I'll RTFM.

--
Sam McLeod
https://smcleod.net
https://twitter.com/s_mcleod

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