Re: [ovirt-users] Internet access for oVirt Nodes?

On Mon, May 15, 2017 at 5:00 AM, <users-request@ovirt.org> wrote:
hi,
do hypervisors, that are running oVirt Node (not standard CentOS/RHEL), need internet access for updates or can they be in a private, non routed network (and updates happen via engine)? it seems the latter is the case, but i want to be sure
thx matthias
Engine isn't very particular about updating in this case. As long as any repository is configured where 'yum check-update ovirt-node-ng-image-update' is true, upgrades from engine will work. In general, otopi's miniyum is a bit smarter than base yum, so 'check-update ...' is not always a reliable mechanism to verify this, but yes, a local repo in a non-routed network which presents the update will show an update from engine.

Am 2017-05-15 16:33, schrieb Ryan Barry:
On Mon, May 15, 2017 at 5:00 AM, <users-request@ovirt.org> wrote:
hi,
do hypervisors, that are running oVirt Node (not standard CentOS/RHEL), need internet access for updates or can they be in a private, non routed network (and updates happen via engine)? it seems the latter is the case, but i want to be sure
thx matthias
Engine isn't very particular about updating in this case. As long as any repository is configured where 'yum check-update ovirt-node-ng-image-update' is true, upgrades from engine will work.
In general, otopi's miniyum is a bit smarter than base yum, so 'check-update ...' is not always a reliable mechanism to verify this, but yes, a local repo in a non-routed network which presents the update will show an update from engine.
thanks, i guess configuring repositories in oVirt Node can only be achieved when using Foreman/Satellite integration, is that correct? i've just started to use oVirt Node and i'm beginning to realize that things are a _little_ bit different compared to a standard linux host. this brings me to another update related question: right now oVirt Nodes in my test environment can connect to the internet and there recently was an update available which i applied through the engine gui, which seemed to finish successfully. i remember wondering how i could check what actually changend, there was eg. no kernel change IIRC. today i discovered that on both updated hosts /tmp/imgbased.log exists and ends in an error: subprocess.CalledProcessError: Command '['lvcreate', '--thin', '--virtualsize', u'8506048512B', '--name', 'ovirt-node-ng-4.1.1.1-0.20170406.0', u'HostVG/pool00']' returned non-zero exit status 5 i have to mention i manually partitioned my oVirt Node host when i installed it from the installer ISO (because i want to use software raid). i used partitioning recommendations from https://bugzilla.redhat.com/show_bug.cgi?id=1369874 (doubling size recommendations). did my oVirt Node update complete successfully? how can i check this? why was there an lvcreate error? 'imgbase layout' says: ovirt-node-ng-4.1.1.1-0.20170406.0 +- ovirt-node-ng-4.1.1.1-0.20170406.0+1 kernel version is: 3.10.0-514.10.2.el7.x86_64 thanks a lot again matthias

On Mon, May 15, 2017 at 1:09 PM, Matthias Leopold < matthias.leopold@meduniwien.ac.at> wrote:
thanks, i guess configuring repositories in oVirt Node can only be achieved when using Foreman/Satellite integration, is that correct? i've just started to use oVirt Node and i'm beginning to realize that things are a _little_ bit different compared to a standard linux host.
Well, yes/no. We whitelist which packages are able to be updated from the oVirt repositories and disable the base centos repositories, but you can easily change "enabled=0" to "enabled=1" in any of them, or add your own repos just like you would with CentOS. In general, I'd recommend not including updates for any packages which are part of Node itself, but that decision is yours to make.
this brings me to another update related question: right now oVirt Nodes in my test environment can connect to the internet and there recently was an update available which i applied through the engine gui, which seemed to finish successfully. i remember wondering how i could check what actually changend, there was eg. no kernel change IIRC. today i discovered that on both updated hosts /tmp/imgbased.log exists and ends in an error:
Node is still an A/B image, so you'd need to reboot in order to see a new kernel, if it's part of a new image.
subprocess.CalledProcessError: Command '['lvcreate', '--thin', '--virtualsize', u'8506048512B', '--name', 'ovirt-node-ng-4.1.1.1-0.20170406.0', u'HostVG/pool00']' returned non-zero exit status 5
i have to mention i manually partitioned my oVirt Node host when i installed it from the installer ISO (because i want to use software raid). i used partitioning recommendations from https://bugzilla.redhat.com/sh ow_bug.cgi?id=1369874 (doubling size recommendations).
As long as you're thinly provisioned, this should update normally,, though I have to say that I haven't tried software RAID.
did my oVirt Node update complete successfully? how can i check this? why was there an lvcreate error?
I'll try to reproduce this, but attempting the lvcreate by hand may give some usable debugging information.
'imgbase layout' says: ovirt-node-ng-4.1.1.1-0.20170406.0 +- ovirt-node-ng-4.1.1.1-0.20170406.0+1
If 'imgabase layout' only shows these, then it's likely that it didn't update. Node uses LVM directly, so "lvm lvs" may show a new device, but from the command above, I'm guessing it wasn't able to create it. I'd suspect that it wasn't able to create it because it's the same version, and LVM sees a duplicate LV. Can you attach your engine log (or the yum log from the host) so we can see what it pulled?
kernel version is: 3.10.0-514.10.2.el7.x86_64
thanks a lot again
-- RYAN BARRY SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHEV HYPERVISOR Red Hat NA <https://www.redhat.com/> rbarry@redhat.com M: +1-651-815-9306 IM: rbarry <https://red.ht/sig>

Am 2017-05-16 um 22:01 schrieb Ryan Barry:
On Mon, May 15, 2017 at 1:09 PM, Matthias Leopold <matthias.leopold@meduniwien.ac.at <mailto:matthias.leopold@meduniwien.ac.at>> wrote:
thanks, i guess configuring repositories in oVirt Node can only be achieved when using Foreman/Satellite integration, is that correct? i've just started to use oVirt Node and i'm beginning to realize that things are a _little_ bit different compared to a standard linux host.
Well, yes/no. We whitelist which packages are able to be updated from the oVirt repositories and disable the base centos repositories, but you can easily change "enabled=0" to "enabled=1" in any of them, or add your own repos just like you would with CentOS.
In general, I'd recommend not including updates for any packages which are part of Node itself, but that decision is yours to make.
this brings me to another update related question: right now oVirt Nodes in my test environment can connect to the internet and there recently was an update available which i applied through the engine gui, which seemed to finish successfully. i remember wondering how i could check what actually changend, there was eg. no kernel change IIRC. today i discovered that on both updated hosts /tmp/imgbased.log exists and ends in an error:
Node is still an A/B image, so you'd need to reboot in order to see a new kernel, if it's part of a new image.
subprocess.CalledProcessError: Command '['lvcreate', '--thin', '--virtualsize', u'8506048512B', '--name', 'ovirt-node-ng-4.1.1.1-0.20170406.0', u'HostVG/pool00']' returned non-zero exit status 5
i have to mention i manually partitioned my oVirt Node host when i installed it from the installer ISO (because i want to use software raid). i used partitioning recommendations from https://bugzilla.redhat.com/show_bug.cgi?id=1369874 <https://bugzilla.redhat.com/show_bug.cgi?id=1369874> (doubling size recommendations).
As long as you're thinly provisioned, this should update normally,, though I have to say that I haven't tried software RAID.
did my oVirt Node update complete successfully? how can i check this? why was there an lvcreate error?
I'll try to reproduce this, but attempting the lvcreate by hand may give some usable debugging information.
'imgbase layout' says: ovirt-node-ng-4.1.1.1-0.20170406.0 +- ovirt-node-ng-4.1.1.1-0.20170406.0+1
If 'imgabase layout' only shows these, then it's likely that it didn't update. Node uses LVM directly, so "lvm lvs" may show a new device, but from the command above, I'm guessing it wasn't able to create it. I'd suspect that it wasn't able to create it because it's the same version, and LVM sees a duplicate LV. Can you attach your engine log (or the yum log from the host) so we can see what it pulled?
i'll try the update with another oVirt Node where i'll stay with standard partitioning and see what happens. i have to understand the update process more thoroughly anyway thx matthias

Am 2017-05-16 22:01, schrieb Ryan Barry:
On Mon, May 15, 2017 at 1:09 PM, Matthias Leopold <matthias.leopold@meduniwien.ac.at> wrote:
thanks, i guess configuring repositories in oVirt Node can only be achieved when using Foreman/Satellite integration, is that correct? i've just started to use oVirt Node and i'm beginning to realize that things are a _little_ bit different compared to a standard linux host.
Well, yes/no. We whitelist which packages are able to be updated from the oVirt repositories and disable the base centos repositories, but you can easily change "enabled=0" to "enabled=1" in any of them, or add your own repos just like you would with CentOS.
In general, I'd recommend not including updates for any packages which are part of Node itself, but that decision is yours to make.
this brings me to another update related question: right now oVirt Nodes in my test environment can connect to the internet and there recently was an update available which i applied through the engine gui, which seemed to finish successfully. i remember wondering how i could check what actually changend, there was eg. no kernel change IIRC. today i discovered that on both updated hosts /tmp/imgbased.log exists and ends in an error:
Node is still an A/B image, so you'd need to reboot in order to see a new kernel, if it's part of a new image.
subprocess.CalledProcessError: Command '['lvcreate', '--thin', '--virtualsize', u'8506048512B', '--name', 'ovirt-node-ng-4.1.1.1-0.20170406.0', u'HostVG/pool00']' returned non-zero exit status 5
i have to mention i manually partitioned my oVirt Node host when i installed it from the installer ISO (because i want to use software raid). i used partitioning recommendations from https://bugzilla.redhat.com/show_bug.cgi?id=1369874 [1] (doubling size recommendations).
As long as you're thinly provisioned, this should update normally,, though I have to say that I haven't tried software RAID.
did my oVirt Node update complete successfully? how can i check this? why was there an lvcreate error?
I'll try to reproduce this, but attempting the lvcreate by hand may give some usable debugging information.
'imgbase layout' says: ovirt-node-ng-4.1.1.1-0.20170406.0 +- ovirt-node-ng-4.1.1.1-0.20170406.0+1
If 'imgabase layout' only shows these, then it's likely that it didn't update. Node uses LVM directly, so "lvm lvs" may show a new device, but from the command above, I'm guessing it wasn't able to create it. I'd suspect that it wasn't able to create it because it's the same version, and LVM sees a duplicate LV. Can you attach your engine log (or the yum log from the host) so we can see what it pulled?
ok, after _hours_ of debugging and reinstalling i came to the following conclusion (which may point to a bug): when i install oVirt Node from the ovirt-node-ng-installer-ovirt-4.1-2017040614.iso, register the Node in my engine and check for updates the engine tells me about an available update. when i apply this update everything seems to be ok (and in fact everything _is_ ok). what happens as an "update" is that the packages ovirt-node-ng-image-4.1.1.1-1.el7.centos.noarch and ovirt-node-ng-image-update-4.1.1.1-1.el7.centos.noarch are installed and the postinstall script for ovirt-node-ng-image-update is executed which calls "imgbase update". this fails with the above mentioned lvcreate error because it's the same version and the volume is already there (like you suspected). why this useless "update" happens is beyond me, but because i never before saw a "real" update and i'm using this non-standard setup with software raid and manual partitioning i was so anxious that something might be wrong in my setup that i desperately looked for an explanation to this "error". what helped to understand was a "real" update from version 4.1.1 to 4.1.1.1. i hope all of this might be of use to somebody, i spent a lot of time, but now i'm ok... thx matthias
participants (2)
-
Matthias Leopold
-
Ryan Barry