[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Yedidyah Bar David]

On Sat, Oct 5, 2019 at 3:32 PM  wrote:
>
> I got a three-node and a single-node HCI that I upgraded from 4.3.5 on CentOS 
> 7.6 to 4.3.6 on CentOS 7.7.
>
> The three-node update worked like a charm, mostly just using the GUI: VMs got 
> properly migrated but the SPM wasn't, I'm afraid, causing a re-election and 
> some Gluster healing wobbles I had to iron out.
>
> The single node updates generally are much more painful than you describe. I 
> find that hosted-engine is complaining about the storage being inaccessible 
> and I need to restart the Gluster daemon to have gluster volume status all 
> show TCP ports. I then generally restart the ovirt-ha-broker and agent until 
> they stop complaining, I might do hosted-engine --connect-storage etc. until 
> eventually hosted-engine --vm-status is at least no longer complaining about 
> lack of storage.
>
> I can then start the management engine and leave maintenance mode.
>
> BTW: With the ovirt 4.3.6 update came a new hosted-engine template image so I 
> guessed running an update on the management engine VM would be in order: At 
> that point I noticed a rather useful message, that engine-setup should be 
> re-run as part of the upgrade, which then again tried to pull various updates 
> (that should have been already satisfied at that point).

engine-setup locks with yum/dnf versionlock plugin the RPMs of the
engine itself, so that it can both upgrade them and the database
schema (and sometimes other things) all at once.

IIRC some years ago there were discussions about allowing upgrade from
the UI. I think this didn't go anywhere, probably because it wasn't
easy, and didn't seem worth it.

The notice you saw to run engine-setup is actually a new 4.3 feature -
glad it helped you :-)

https://gerrit.ovirt.org/96446

>
> I guess the point I am trying to make is that while three-node host updates 
> are wonderfully served by the GUI, there is a stiff decline in UX ergonomics 
> when it comes to single node (which has limited usefulness, I understand) but 
> also the management engine: Updates of the latter may be less frequent, but 
> could either use some dedicated step-by-step documentation or UX support.
> ___
> 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/FU63CAAT5XNJJEXMQLRLHHDBQFTWCP5A/



-- 
Didi
___
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/WUGJCFFHQJDDUMH6XDNGLUDMWMQPGGK5/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[thomas]

I got a three-node and a single-node HCI that I upgraded from 4.3.5 on CentOS 
7.6 to 4.3.6 on CentOS 7.7.

The three-node update worked like a charm, mostly just using the GUI: VMs got 
properly migrated but the SPM wasn't, I'm afraid, causing a re-election and 
some Gluster healing wobbles I had to iron out.

The single node updates generally are much more painful than you describe. I 
find that hosted-engine is complaining about the storage being inaccessible and 
I need to restart the Gluster daemon to have gluster volume status all show TCP 
ports. I then generally restart the ovirt-ha-broker and agent until they stop 
complaining, I might do hosted-engine --connect-storage etc. until eventually 
hosted-engine --vm-status is at least no longer complaining about lack of 
storage.

I can then start the management engine and leave maintenance mode.

BTW: With the ovirt 4.3.6 update came a new hosted-engine template image so I 
guessed running an update on the management engine VM would be in order: At 
that point I noticed a rather useful message, that engine-setup should be 
re-run as part of the upgrade, which then again tried to pull various updates 
(that should have been already satisfied at that point).

I guess the point I am trying to make is that while three-node host updates are 
wonderfully served by the GUI, there is a stiff decline in UX ergonomics when 
it comes to single node (which has limited usefulness, I understand) but also 
the management engine: Updates of the latter may be less frequent, but could 
either use some dedicated step-by-step documentation or UX support.
___
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/FU63CAAT5XNJJEXMQLRLHHDBQFTWCP5A/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Guillaume Pavese]

Good idea Strahil.

I guess there could be benefits, as when I mailed vdo-devel in March asking
about emulate512 performance impact, the answer from RedHat's Michael
Sclafani was as follows :
Begin citation:

512 emulation was intended to support drivers that only do a fraction of
their I/O in blocks smaller 4KB. It is not optimized for performance in any
way. Under the covers, VDO is still operating on 4KB physical blocks, so
each 512-byte read is potentially amplified to a 4KB read, and each
512-byte write to a 4KB read followed by a 4KB write. A workload consisting
exclusively of 512-byte randomly-distributed writes could effectively be
amplified by a factor of 16.

We have a suite of automated tests we run in 512e mode on a nightly basis.
That suite is a subset of our regular tests, containing only ones we expect
would be likely to expose problems specific to the emulation.

There should be no penalty to having emulation enabled on a volume that no
longer uses it. If the I/O is 4KB-aligned and 4KB or larger, having it
enabled won't affect it.
It does not appear the setting can be modified by the VDO manager, but I
cannot remember at this moment why that should be so.


Best

Guillaume Pavese
Ingénieur Système et Réseau
Interactiv-Group


On Tue, Oct 1, 2019 at 6:07 PM Strahil  wrote:

> You can go with 512 emulation and later you can recreate the brick without
> that emulation (if there are benefits of doing so).
> After all, you gluster is either replica 2 arbiter 1 or a replica 3 volume.
>
> Best Regards,
> Strahil Nikolov
> On Oct 1, 2019 09:26, Satheesaran Sundaramoorthi 
> wrote:
>
> On Tue, Oct 1, 2019 at 11:27 AM Guillaume Pavese <
> guillaume.pav...@interactiv-group.com> wrote:
>
> Hi all,
>
> Sorry for asking again :/
>
> Is there any consensus on not using --emulate512 anymore while creating
> VDO volumes on Gluster?
> Since this parameter can not be changed once the volume is created and we
> are nearing production setup. I would really like to have an official
> advice on this.
>
> Best,
>
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
>
> Hello Guillaume Pavese,
> If you are not using --emulate512 for VDO volume, then VDO volume will be
> created
> as 4K Native volume (with 4K block size).
>
> There are couple of things that bothers here:
> 1. 4K Native device support requires fixes at QEMU that will be part of
> CentOS 7.7.2 ( not yet available )
> 2. 4K Native support with VDO volumes on Gluster is not yet validated
> thoroughly.
>
> Based on the above items, it would be better you have emulate512=on or
> delay
> your production setup ( if possible, till above both items are addressed )
> to make use of 4K VDO volume.
>
> @Sahina Bose  Do you have any other suggestions ?
>
> -- Satheesaran S (sas)
>
>
> On Fri, Sep 27, 2019 at 3:19 PM Sandro Bonazzola 
> wrote:
>
>
>
>

-- 


Ce message et toutes les pièces jointes (ci-après le “message”) sont 
établis à l’intention exclusive de ses destinataires et sont confidentiels. 
Si vous recevez ce message par erreur, merci de le détruire et d’en avertir 
immédiatement l’expéditeur. Toute utilisation de ce message non conforme a 
sa destination, toute diffusion ou toute publication, totale ou partielle, 
est interdite, sauf autorisation expresse. L’internet ne permettant pas 
d’assurer l’intégrité de ce message . Interactiv-group (et ses filiales) 
décline(nt) toute responsabilité au titre de ce message, dans l’hypothèse 
ou il aurait été modifié. IT, ES, UK.  

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

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Derek Atkins]

jvdw...@xs4all.nl writes:

>> Yes, it's still available. It will be dropped in 4.4.
>
> OK, good to know, time to polish up my ansible or start writing api scripts.
>
> Now that 4.4 popped up, how is that going?
> I looked a bit at the Gerrit yesterday and right now and see that el8
> builds are being done now, great work!

Yeah.  I've got a startup script that I use to start all my VMs (see
below).  I'll need to figure out how to migrate that script to SDK4.
It really sucks that there's no SDK4 version of ovirt-shell.  I suspect
my script will expand by an order of magnitude, and everyone who has
written a script around ovirt-shell will have to duplicate effort.

I know there is a feature for the engine to autostart VMs (which I
believe will be in 4.4), but AFAIK it doesn't do ordering.  I need at
least one specific VM to start up before everything else.

Thanks,

-derek

#!/bin/bash

[ -f /etc/sysconfig/vm_list ] || exit 0
. /etc/sysconfig/vm_list

echo -n "Starting at "
date

# Wait for the engine to respond
while [ `ovirt-shell -I -c -F -T 50 -E ping 2>/dev/null | grep -c success` != 1 
]
do
echo "Not ready... Sleeping..."
sleep 60
done

# Now wait for the storage domain to appear active
echo -n "Engine up.  Searching for disks at "
date
total_disks=`ovirt-shell -I -c -E summary | grep storage_domains-total | sed -e 
's/.*: //'`
# subtract one because we know we're not using the image-repository
total_disks=`expr $total_disks - 1`
active_disks=`ovirt-shell -I -c -E summary | grep storage_domains-active | sed 
-e 's/.*: //'`
while [ $active_disks -lt $total_disks ]
do
echo "Storage Domains not active yet.  Only found 
$active_disks/$total_disks.  Waiting..."
sleep 60
active_disks=`ovirt-shell -I -c -E summary | grep storage_domains-active | 
sed -e 's/.*: //'`
done

# Now start all of the VMs in the requested order.
echo -n "All storage mounted.  Starting VMs at "
date
for vm in "${vm_list[@]}"
do
  timeout=${vm_timeout[$vm]:-$default_timeout}
  ovirt-shell -I -c -E "action vm $vm start"
  sleep "$timeout"
done

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
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/NS4VMN66G6K3WH2ROGSEBTQDEAMZB5DQ/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Strahil]

You can go with 512 emulation and later you can recreate the brick without that 
emulation (if there are benefits of doing so).
After all, you gluster is either replica 2 arbiter 1 or a replica 3 volume.

Best Regards,
Strahil Nikolov
On Oct 1, 2019 09:26, Satheesaran Sundaramoorthi  wrote:
>
> On Tue, Oct 1, 2019 at 11:27 AM Guillaume Pavese 
>  wrote:
>>
>> Hi all,
>>
>> Sorry for asking again :/
>>
>> Is there any consensus on not using --emulate512 anymore while creating VDO 
>> volumes on Gluster?
>> Since this parameter can not be changed once the volume is created and we 
>> are nearing production setup. I would really like to have an official advice 
>> on this.
>>
>> Best,
>>
>> Guillaume Pavese
>> Ingénieur Système et Réseau
>> Interactiv-Group
>>
> Hello Guillaume Pavese,
> If you are not using --emulate512 for VDO volume, then VDO volume will be 
> created
> as 4K Native volume (with 4K block size). 
>
> There are couple of things that bothers here:
> 1. 4K Native device support requires fixes at QEMU that will be part of 
> CentOS 7.7.2 ( not yet available )
> 2. 4K Native support with VDO volumes on Gluster is not yet validated
> thoroughly.
>
> Based on the above items, it would be better you have emulate512=on or delay
> your production setup ( if possible, till above both items are addressed ) 
> to make use of 4K VDO volume.
>
> @Sahina Bose Do you have any other suggestions ?
>
> -- Satheesaran S (sas)
>>
>>
>> On Fri, Sep 27, 2019 at 3:19 PM Sandro Bonazzola  wrote:
>>>
>>>
>>>
___
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/WDETM3AKVJASI3MQKBB6EIZCK52C7IW2/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno mar 1 ott 2019 alle ore 09:48  ha scritto:

> September 30, 2019 2:23 PM, "Sandro Bonazzola" 
> wrote:
>
> > Il giorno ven 27 set 2019 alle ore 17:54 Derek Atkins 
> ha scritto:
> >
> >> On Fri, September 27, 2019 11:46 am, Sandro Bonazzola wrote:
> >> [nsip]
> >
> > I'm curious what the steps should be going from 4.1.9 / EL7.4 to 4.3.x /
> > EL7.7? I am pretty sure I need some steps along the way (I doubt I can
> > jump directly from 4.1.9 -> 4.3.x and 7.4 -> 7.7, right).
> >
> > So should I jump from 7.4/4.1.9 to 7.6/4.2.8 and then from there to
> > 7.7/4.3.6?
> >
> > 4.1 cluster level is still supported by 4.3 engine.
> > So you can upgrade the engine from 7.4/4.1.9 to 7.6/4.2.8 and then to
> > 7.7/4.3.6 while on the host side you can go straight to 4.3.6/7.7.
> > Once done, please update cluster level to 4.3.
> >> Excellent, I can do that. I just need to ensure that the cluster
> settings
> >> fully upgraded from 4.0 to 4.1.
> >>
> >> One final question: I know that ovirt-shell is deprecated, but is it
> >> still available in 4.3.x?
> >
> > Yes, it's still available. It will be dropped in 4.4.
>
> OK, good to know, time to polish up my ansible or start writing api
> scripts.
>
> Now that 4.4 popped up, how is that going?
> I looked a bit at the Gerrit yesterday and right now and see that el8
> builds are being done now, great work!
>

Pushing builds to el8 and fc30. A few big show stoppers like the lack of
ansible in EPEL 8 (Bug 1744975
)
and CentOS Community Build System not yet enabled to build for CentOS 8,
but we are working on it.


>
> Greetings,
>
> 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/DAEUKE62ZOHVFRPCPSZ3UXMLDIXQGQED/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.*
___
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/UNBUUVH47BPIOE5JZSKJ4WADY26REKTR/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[jvdwege]

September 30, 2019 2:23 PM, "Sandro Bonazzola"  wrote:

> Il giorno ven 27 set 2019 alle ore 17:54 Derek Atkins  ha 
> scritto:
> 
>> On Fri, September 27, 2019 11:46 am, Sandro Bonazzola wrote:
>> [nsip]
> 
> I'm curious what the steps should be going from 4.1.9 / EL7.4 to 4.3.x /
> EL7.7? I am pretty sure I need some steps along the way (I doubt I can
> jump directly from 4.1.9 -> 4.3.x and 7.4 -> 7.7, right).
> 
> So should I jump from 7.4/4.1.9 to 7.6/4.2.8 and then from there to
> 7.7/4.3.6?
> 
> 4.1 cluster level is still supported by 4.3 engine.
> So you can upgrade the engine from 7.4/4.1.9 to 7.6/4.2.8 and then to
> 7.7/4.3.6 while on the host side you can go straight to 4.3.6/7.7.
> Once done, please update cluster level to 4.3.
>> Excellent, I can do that. I just need to ensure that the cluster settings
>> fully upgraded from 4.0 to 4.1.
>> 
>> One final question: I know that ovirt-shell is deprecated, but is it
>> still available in 4.3.x?
> 
> Yes, it's still available. It will be dropped in 4.4.

OK, good to know, time to polish up my ansible or start writing api scripts.

Now that 4.4 popped up, how is that going?
I looked a bit at the Gerrit yesterday and right now and see that el8 builds 
are being done now, great work!

Greetings,

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/DAEUKE62ZOHVFRPCPSZ3UXMLDIXQGQED/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Gobinda Das]

Hi Guillaume,
 As Satheesaran suggested the possible options which is completly valid
points. Thanks sas for that.
I would suggest to wait till 4Kn validation complet with Gluster + VDO (All
usecases), if you want 4K support. Other wise you can go ahead
with emulate512=on .

On Tue, Oct 1, 2019 at 11:56 AM Satheesaran Sundaramoorthi <
sasun...@redhat.com> wrote:

> On Tue, Oct 1, 2019 at 11:27 AM Guillaume Pavese <
> guillaume.pav...@interactiv-group.com> wrote:
>
>> Hi all,
>>
>> Sorry for asking again :/
>>
>> Is there any consensus on not using --emulate512 anymore while creating
>> VDO volumes on Gluster?
>> Since this parameter can not be changed once the volume is created and we
>> are nearing production setup. I would really like to have an official
>> advice on this.
>>
>> Best,
>>
>> Guillaume Pavese
>> Ingénieur Système et Réseau
>> Interactiv-Group
>>
>> Hello Guillaume Pavese,
> If you are not using --emulate512 for VDO volume, then VDO volume will be
> created
> as 4K Native volume (with 4K block size).
>
> There are couple of things that bothers here:
> 1. 4K Native device support requires fixes at QEMU that will be part of
> CentOS 7.7.2 ( not yet available )
> 2. 4K Native support with VDO volumes on Gluster is not yet validated
> thoroughly.
>
> Based on the above items, it would be better you have emulate512=on or
> delay
> your production setup ( if possible, till above both items are addressed )
> to make use of 4K VDO volume.
>
> @Sahina Bose  Do you have any other suggestions ?
>
> -- Satheesaran S (sas)
>
>>
>> On Fri, Sep 27, 2019 at 3:19 PM Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno ven 27 set 2019 alle ore 05:21 Guillaume Pavese <
>>> guillaume.pav...@interactiv-group.com> ha scritto:
>>>
 I see that oVirt 4.3.6 finally has 4k domain support.

 - Would that mean that VDO enabled Gluster domains will be created
 without the --emulate512 workaround?
 - If the wizard to create the Gluster volumes has not yet removed that
 parameter, is it safe to edit & remove it manually before creation?
 - Should we expect performance increase by using the native 4k block
 size of VDO?


>>>
>>> +Nir Soffer  +Sundaramoorthi, Satheesaran
>>>  +Gobinda Das  can you answer
>>> here?
>>>
>>>
>>>
 Thanks

 Guillaume Pavese
 Ingénieur Système et Réseau
 Interactiv-Group


 On Fri, Sep 27, 2019 at 12:00 AM Sandro Bonazzola 
 wrote:

> The oVirt Project is pleased to announce the general availability of
> oVirt 4.3.6 as of September 26th, 2019.
>
>
>
> This update is the sixth in a series of stabilization updates to the
> 4.3 series.
>
>
>
> This release is available now on x86_64 architecture for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
>
>
> This release supports Hypervisor Hosts on x86_64 and ppc64le
> architectures for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
> * oVirt Node 4.3 (available for x86_64 only)
>
>
>
> Due to Fedora 28 being now at end of life this release is missing
> experimental tech preview for x86_64 and s390x architectures for Fedora 
> 28.
>
> We are working on Fedora 29 and 30 support and we may re-introduce
> experimental support for Fedora in next release.
>
>
>
> See the release notes [1] for installation / upgrade instructions and
> a list of new features and bugs fixed.
>
>
>
> Notes:
>
> - oVirt Appliance is already available
>
> - oVirt Node is already available[2]
>
> oVirt Node and Appliance have been updated including:
>
> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>
> - Wildfly 17.0.1:
> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>
> - Latest CentOS 7.7 updates including:
>
>-
>
>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>
> 
>-
>
>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>
> 
>
>-
>
>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>
> 
>-
>
>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>
> 
>-
>
>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>
> 
>-
>
>CESA-2019:2258 Moderate CentOS 7 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Satheesaran Sundaramoorthi]

On Tue, Oct 1, 2019 at 11:27 AM Guillaume Pavese <
guillaume.pav...@interactiv-group.com> wrote:

> Hi all,
>
> Sorry for asking again :/
>
> Is there any consensus on not using --emulate512 anymore while creating
> VDO volumes on Gluster?
> Since this parameter can not be changed once the volume is created and we
> are nearing production setup. I would really like to have an official
> advice on this.
>
> Best,
>
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
>
> Hello Guillaume Pavese,
If you are not using --emulate512 for VDO volume, then VDO volume will be
created
as 4K Native volume (with 4K block size).

There are couple of things that bothers here:
1. 4K Native device support requires fixes at QEMU that will be part of
CentOS 7.7.2 ( not yet available )
2. 4K Native support with VDO volumes on Gluster is not yet validated
thoroughly.

Based on the above items, it would be better you have emulate512=on or delay
your production setup ( if possible, till above both items are addressed )
to make use of 4K VDO volume.

@Sahina Bose  Do you have any other suggestions ?

-- Satheesaran S (sas)

>
> On Fri, Sep 27, 2019 at 3:19 PM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno ven 27 set 2019 alle ore 05:21 Guillaume Pavese <
>> guillaume.pav...@interactiv-group.com> ha scritto:
>>
>>> I see that oVirt 4.3.6 finally has 4k domain support.
>>>
>>> - Would that mean that VDO enabled Gluster domains will be created
>>> without the --emulate512 workaround?
>>> - If the wizard to create the Gluster volumes has not yet removed that
>>> parameter, is it safe to edit & remove it manually before creation?
>>> - Should we expect performance increase by using the native 4k block
>>> size of VDO?
>>>
>>>
>>
>> +Nir Soffer  +Sundaramoorthi, Satheesaran
>>  +Gobinda Das  can you answer
>> here?
>>
>>
>>
>>> Thanks
>>>
>>> Guillaume Pavese
>>> Ingénieur Système et Réseau
>>> Interactiv-Group
>>>
>>>
>>> On Fri, Sep 27, 2019 at 12:00 AM Sandro Bonazzola 
>>> wrote:
>>>
 The oVirt Project is pleased to announce the general availability of
 oVirt 4.3.6 as of September 26th, 2019.



 This update is the sixth in a series of stabilization updates to the
 4.3 series.



 This release is available now on x86_64 architecture for:

 * Red Hat Enterprise Linux 7.7 or later (but < 8)

 * CentOS Linux (or similar) 7.7 or later (but < 8)



 This release supports Hypervisor Hosts on x86_64 and ppc64le
 architectures for:

 * Red Hat Enterprise Linux 7.7 or later (but < 8)

 * CentOS Linux (or similar) 7.7 or later (but < 8)

 * oVirt Node 4.3 (available for x86_64 only)



 Due to Fedora 28 being now at end of life this release is missing
 experimental tech preview for x86_64 and s390x architectures for Fedora 28.

 We are working on Fedora 29 and 30 support and we may re-introduce
 experimental support for Fedora in next release.



 See the release notes [1] for installation / upgrade instructions and a
 list of new features and bugs fixed.



 Notes:

 - oVirt Appliance is already available

 - oVirt Node is already available[2]

 oVirt Node and Appliance have been updated including:

 - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/

 - Wildfly 17.0.1:
 https://wildfly.org/news/2019/07/07/WildFly-1701-Released/

 - Latest CentOS 7.7 updates including:

-

Release for CentOS Linux 7 (1908) on the x86_64 Architecture

 
-

CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update

 

-

CEBA-2019:2023 CentOS 7 efivar BugFix Update

 
-

CEBA-2019:2614 CentOS 7 firewalld BugFix Update

 
-

CEBA-2019:2227 CentOS 7 grubby BugFix Update

 
-

CESA-2019:2258 Moderate CentOS 7 http-parser Security Update

 
-

CESA-2019:2600 Important CentOS 7 kernel Security Update

 
-

CEBA-2019:2599 CentOS 7 krb5 BugFix Update

 
-

CEBA-2019:2358 CentOS 7 libguestfs BugFix Update

 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Guillaume Pavese]

Hi all,

Sorry for asking again :/

Is there any consensus on not using --emulate512 anymore while creating VDO
volumes on Gluster?
Since this parameter can not be changed once the volume is created and we
are nearing production setup. I would really like to have an official
advice on this.

Best,

Guillaume Pavese
Ingénieur Système et Réseau
Interactiv-Group


On Fri, Sep 27, 2019 at 3:19 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno ven 27 set 2019 alle ore 05:21 Guillaume Pavese <
> guillaume.pav...@interactiv-group.com> ha scritto:
>
>> I see that oVirt 4.3.6 finally has 4k domain support.
>>
>> - Would that mean that VDO enabled Gluster domains will be created
>> without the --emulate512 workaround?
>> - If the wizard to create the Gluster volumes has not yet removed that
>> parameter, is it safe to edit & remove it manually before creation?
>> - Should we expect performance increase by using the native 4k block size
>> of VDO?
>>
>>
>
> +Nir Soffer  +Sundaramoorthi, Satheesaran
>  +Gobinda Das  can you answer here?
>
>
>
>> Thanks
>>
>> Guillaume Pavese
>> Ingénieur Système et Réseau
>> Interactiv-Group
>>
>>
>> On Fri, Sep 27, 2019 at 12:00 AM Sandro Bonazzola 
>> wrote:
>>
>>> The oVirt Project is pleased to announce the general availability of
>>> oVirt 4.3.6 as of September 26th, 2019.
>>>
>>>
>>>
>>> This update is the sixth in a series of stabilization updates to the 4.3
>>> series.
>>>
>>>
>>>
>>> This release is available now on x86_64 architecture for:
>>>
>>> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>>>
>>> * CentOS Linux (or similar) 7.7 or later (but < 8)
>>>
>>>
>>>
>>> This release supports Hypervisor Hosts on x86_64 and ppc64le
>>> architectures for:
>>>
>>> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>>>
>>> * CentOS Linux (or similar) 7.7 or later (but < 8)
>>>
>>> * oVirt Node 4.3 (available for x86_64 only)
>>>
>>>
>>>
>>> Due to Fedora 28 being now at end of life this release is missing
>>> experimental tech preview for x86_64 and s390x architectures for Fedora 28.
>>>
>>> We are working on Fedora 29 and 30 support and we may re-introduce
>>> experimental support for Fedora in next release.
>>>
>>>
>>>
>>> See the release notes [1] for installation / upgrade instructions and a
>>> list of new features and bugs fixed.
>>>
>>>
>>>
>>> Notes:
>>>
>>> - oVirt Appliance is already available
>>>
>>> - oVirt Node is already available[2]
>>>
>>> oVirt Node and Appliance have been updated including:
>>>
>>> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>>>
>>> - Wildfly 17.0.1:
>>> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>>>
>>> - Latest CentOS 7.7 updates including:
>>>
>>>-
>>>
>>>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>>>
>>> 
>>>
>>>-
>>>
>>>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>>>
>>> 
>>>-
>>>
>>>CESA-2019:2258 Moderate CentOS 7 http-parser Security Update
>>>
>>> 
>>>-
>>>
>>>CESA-2019:2600 Important CentOS 7 kernel Security Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2599 CentOS 7 krb5 BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2358 CentOS 7 libguestfs BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2679 CentOS 7 libvirt BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2501 CentOS 7 rsyslog BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update
>>>
>>> 
>>>-
>>>
>>>CEBA-2019:2602 CentOS 7 sos BugFix Update
>>>
>>> 
>>>
>>>-
>>>
>>>CEBA-2019:2564 CentOS 7 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 17:54 Derek Atkins  ha
scritto:

>
> On Fri, September 27, 2019 11:46 am, Sandro Bonazzola wrote:
> [nsip]
> >> I'm curious what the steps should be going from 4.1.9 / EL7.4 to 4.3.x /
> >> EL7.7?  I am pretty sure I need some steps along the way (I doubt I can
> >> jump directly from 4.1.9 -> 4.3.x and 7.4 -> 7.7, right).
> >>
> >> So should I jump from 7.4/4.1.9 to 7.6/4.2.8 and then from there to
> >> 7.7/4.3.6?
> >>
> >
> > 4.1 cluster level is still supported by 4.3 engine.
> > So you can upgrade the engine from 7.4/4.1.9 to 7.6/4.2.8 and then to
> > 7.7/4.3.6 while on the host side you can go straight to 4.3.6/7.7.
> > Once done, please update cluster level to 4.3.
>
> Excellent, I can do that.  I just need to ensure that the cluster settings
> fully upgraded from 4.0 to 4.1.
>
> One final question:  I know that ovirt-shell is deprecated, but is it
> still available in 4.3.x?
>

Yes, it's still available. It will be dropped in 4.4.


>
> Thanks for all your support!
>
> -derek
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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/ROZETTTDPTQDM6CBMQHSMKARBCMSQNRQ/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Vojtech Juranek]

Hi,

> > Engine reports the block size reported by vdsm. Once we get the system
> > up with your 4k storage domain,
> > we can check that engine reports the right value and update it if needed.
> > I think what you should do is:
> > 
> > 1. Backup storage domain metadata
> > /path/to/domain/domain-uuid/dom_md
> > 
> > 2. Deactivate the storage domain (from engine)
> > 
> > 3. Edit the metadata file:
> > - change BLOCK_SIZE to 4096
> > - delete the checksum line
> > (_SHA_CKSUM=9dde06bbc9f2316efc141565738ff32037b1ff66)
> > 
> > 4. Activate the domain
> > 
> > With vdsm < 4.3.6, the domain should be active, ignoring the block size.
> > 
> > 5. Upgrade back to 4.3.6
> > 
> > The system should detect the block size and work normally.
> > 
> > 6. File ovirt bug for this issue
> > 
> > We need at least to document the way to fix the storage domain manually.
> > 
> > We also should consider checking storage domain metadata during
> > upgrades. I think it will be
> > a better experience if upgrade will fail and you have a working system
> > with older version.
> 
> I've tried this procedure and it has worked! Thanks!
> 
> If you would like me to file a bug, which component should I log it against?

for vdms. Please include all the logs and db dump as Nir mentioned in previous 
email (see bellow).
Thanks

> >> 
> >> Please share more data so we can understand the failure:
> >> 
> >> - complete vdsm log showing the failure to activate the domain
> >>   - with 4.3.6
> >>   - with 4.3.5 (after you downgraded
> >> - contents of
> >> /rhev/data-center/mnt/_/domain-uuid/dom_md/metadata
> >>   (assuming your local domain mount is /domaindir)
> >> - engine db dump
> >> 


signature.asc
Description: This is a digitally signed message part.
___
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/EDTQ3WUXGWEOA7O2LTXQNJXYP6RYQKIB/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Rik Theys]

Hi,

On 9/29/19 12:54 AM, Nir Soffer wrote:
On Sat, Sep 28, 2019 at 11:04 PM Rik Theys > wrote:


Hi Nir,

Thank you for your time.

On 9/27/19 4:27 PM, Nir Soffer wrote:



On Fri, Sep 27, 2019, 12:37 Rik Theys mailto:rik.th...@esat.kuleuven.be>> wrote:

Hi,

After upgrading to 4.3.6, my storage domain can no longer be
activated, rendering my data center useless.

My storage domain is local storage on a filesystem backed by
VDO/LVM. It seems 4.3.6 has added support for 4k storage.
My VDO does not have the 'emulate512' flag set.


This configuration is not supported before 4.3.6. Various
operations may fail when
reading or writing to storage.

I was not aware of this when I set it up as I did not expect this
to influence a setup where oVirt uses local storage (a file system
location).


4.3.6 detects storageblock size, creates compatible storage
domain metadata, and
consider the block size when accessing storage.

I've tried downgrading all packages on the host to the
previous versions (with ioprocess 1.2), but this does not
seem to make any difference.


Downgrading should solve your issue, but without any logs we only
guess.


I was able to work around my issue by downgrading to ioprocess 1.1
(and vdsm-4.30.24). Downgrading to only 1.2 did not solve my
issue. With ioprocess downgraded to 1.1, I did not have to
downgrade the engine (still on 4.3.6).

ioprocess 1.1. is not recommended, you really want to use 1.3.0.

I think I now have a better understanding what happened that
triggered this.

During a nightly yum-cron, the ioprocess and vdsm packages on the
host were upgraded to 1.3 and vdsm 4.30.33. At this point, the
engine log started to log:

2019-09-27 03:40:27,472+02 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc]
Executing with domain map: {6bdf1a0d-274b-4195-8f
f5-a5c002ea1a77=active}
2019-09-27 03:40:27,646+02 WARN
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc]
Unexpected return value: Status [code=348, message=Block size does
not match storage block size: 'block_size=512,
storage_block_size=4096']

This means that when activating the storage domain, vdsm detected that 
the storage block size

is 4k, but the domain metadata reports block size of 512.

This combination may partly work for localfs domain since we don't use 
sanlock with local storage,
and vdsm does not use direct I/O when writing to storage, and always 
use 4k block size when

reading metadata from storage.

Note that with older ovirt-imageio < 1.5.2, image uploads and 
downloads may fail when using 4k storage.

in recent ovirt-imageio we detect and use the correct block size.

2019-09-27 03:40:27,646+02 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] FINISH,
ConnectStoragePoolVDSCommand, return: , log id: 483c7a17

I did not notice at first that this was a storage related issue
and assumed it may get resolved by also upgrading the engine. So
in the morning I upgraded the engine to 4.3.6 but this did not
resolve my issue.

I then found the above error in the engine log. In the release
notes of 4.3.6 I read about the 4k support.

I then downgraded ioprocess (and vdsm) to ioprocess 1.2 but that
did also not solve my issue. This is when I contacted the list
with my question.

Afterwards I found in the ioprocess rpm changelog that (partial?)
4k support was also in 1.2. I kept on downgrading until I got
ioprocess 1.1 (without 4k support) and at this point I could
re-attach my storage domain.

You mention above that 4.3.6 will detect the block size and
configure the metadata on the storage domain? I've checked the
dom_md/metadata file and it shows:

ALIGNMENT=1048576
*BLOCK_SIZE=512*
CLASS=Data
DESCRIPTION=studvirt1-Local
IOOPTIMEOUTSEC=10
LEASERETRIES=3
LEASETIMESEC=60
LOCKPOLICY=
LOCKRENEWALINTERVALSEC=5
MASTER_VERSION=1
POOL_DESCRIPTION=studvirt1-Local
POOL_DOMAINS=6bdf1a0d-274b-4195-8ff5-a5c002ea1a77:Active
POOL_SPM_ID=-1
POOL_SPM_LVER=-1
POOL_UUID=085f02e8-c3b4-4cef-a35c-e357a86eec0c
REMOTE_PATH=/data/images
ROLE=Master
SDUUID=6bdf1a0d-274b-4195-8ff5-a5c002ea1a77
TYPE=LOCALFS
VERSION=5
_SHA_CKSUM=9dde06bbc9f2316efc141565738ff32037b1ff66

So you have a v5 localfs storage domain - because we don't use leases, 
this domain should work

with 4.3.6 if you modify this line in the domain metadata.

BLOCK_SIZE=4096

To modify the line, you have to delete the checksum:

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Nir Soffer]

On Sat, Sep 28, 2019 at 11:04 PM Rik Theys 
wrote:

> Hi Nir,
>
> Thank you for your time.
> On 9/27/19 4:27 PM, Nir Soffer wrote:
>
>
>
> On Fri, Sep 27, 2019, 12:37 Rik Theys  wrote:
>
>> Hi,
>>
>> After upgrading to 4.3.6, my storage domain can no longer be activated,
>> rendering my data center useless.
>>
>> My storage domain is local storage on a filesystem backed by VDO/LVM. It
>> seems 4.3.6 has added support for 4k storage.
>> My VDO does not have the 'emulate512' flag set.
>>
>
> This configuration is not supported before 4.3.6. Various operations may
> fail when
> reading or writing to storage.
>
> I was not aware of this when I set it up as I did not expect this to
> influence a setup where oVirt uses local storage (a file system location).
>
>
> 4.3.6 detects storage block size, creates compatible storage domain
> metadata, and
> consider the block size when accessing storage.
>
>
>> I've tried downgrading all packages on the host to the previous versions
>> (with ioprocess 1.2), but this does not seem to make any difference.
>>
>
> Downgrading should solve your issue, but without any logs we only guess.
>
> I was able to work around my issue by downgrading to ioprocess 1.1 (and
> vdsm-4.30.24). Downgrading to only 1.2 did not solve my issue. With
> ioprocess downgraded to 1.1, I did not have to downgrade the engine (still
> on 4.3.6).
>
ioprocess 1.1. is not recommended, you really want to use 1.3.0.

> I think I now have a better understanding what happened that triggered
> this.
>
> During a nightly yum-cron, the ioprocess and vdsm packages on the host
> were upgraded to 1.3 and vdsm 4.30.33. At this point, the engine log
> started to log:
>
> 2019-09-27 03:40:27,472+02 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] Executing with
> domain map: {6bdf1a0d-274b-4195-8f
> f5-a5c002ea1a77=active}
> 2019-09-27 03:40:27,646+02 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] Unexpected return
> value: Status [code=348, message=Block size does not match storage block
> size: 'block_size=512, storage_block_size=4096']
>
This means that when activating the storage domain, vdsm detected that the
storage block size
is 4k, but the domain metadata reports block size of 512.

This combination may partly work for localfs domain since we don't use
sanlock with local storage,
and vdsm does not use direct I/O when writing to storage, and always use 4k
block size when
reading metadata from storage.

Note that with older ovirt-imageio < 1.5.2, image uploads and downloads may
fail when using 4k storage.
in recent ovirt-imageio we detect and use the correct block size.

> 2019-09-27 03:40:27,646+02 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] FINISH,
> ConnectStoragePoolVDSCommand, return: , log id: 483c7a17
>
> I did not notice at first that this was a storage related issue and
> assumed it may get resolved by also upgrading the engine. So in the morning
> I upgraded the engine to 4.3.6 but this did not resolve my issue.
>
> I then found the above error in the engine log. In the release notes of
> 4.3.6 I read about the 4k support.
>
> I then downgraded ioprocess (and vdsm) to ioprocess 1.2 but that did also
> not solve my issue. This is when I contacted the list with my question.
>
> Afterwards I found in the ioprocess rpm changelog that (partial?) 4k
> support was also in 1.2. I kept on downgrading until I got ioprocess 1.1
> (without 4k support) and at this point I could re-attach my storage domain.
>
> You mention above that 4.3.6 will detect the block size and configure the
> metadata on the storage domain? I've checked the dom_md/metadata file and
> it shows:
>
> ALIGNMENT=1048576
> *BLOCK_SIZE=512*
> CLASS=Data
> DESCRIPTION=studvirt1-Local
> IOOPTIMEOUTSEC=10
> LEASERETRIES=3
> LEASETIMESEC=60
> LOCKPOLICY=
> LOCKRENEWALINTERVALSEC=5
> MASTER_VERSION=1
> POOL_DESCRIPTION=studvirt1-Local
> POOL_DOMAINS=6bdf1a0d-274b-4195-8ff5-a5c002ea1a77:Active
> POOL_SPM_ID=-1
> POOL_SPM_LVER=-1
> POOL_UUID=085f02e8-c3b4-4cef-a35c-e357a86eec0c
> REMOTE_PATH=/data/images
> ROLE=Master
> SDUUID=6bdf1a0d-274b-4195-8ff5-a5c002ea1a77
> TYPE=LOCALFS
> VERSION=5
> _SHA_CKSUM=9dde06bbc9f2316efc141565738ff32037b1ff66
>
So you have a v5 localfs storage domain - because we don't use leases, this
domain should work
with 4.3.6 if you modify this line in the domain metadata.

BLOCK_SIZE=4096

To modify the line, you have to delete the checksum:

_SHA_CKSUM=9dde06bbc9f2316efc141565738ff32037b1ff66

> I assume that at this point it works because ioprocess 1.1 does not report
> the block size to the engine (as it doesn't support this option?)?
>
I think it works because ioprocess 1.1 has a bug when it does not use
direct I/O when writing
files. This 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Rik Theys]

Hi Nir,

Thank you for your time.

On 9/27/19 4:27 PM, Nir Soffer wrote:



On Fri, Sep 27, 2019, 12:37 Rik Theys > wrote:


Hi,

After upgrading to 4.3.6, my storage domain can no longer be
activated, rendering my data center useless.

My storage domain is local storage on a filesystem backed by
VDO/LVM. It seems 4.3.6 has added support for 4k storage.
My VDO does not have the 'emulate512' flag set.


This configuration is not supported before 4.3.6. Various operations 
may fail when

reading or writing to storage.
I was not aware of this when I set it up as I did not expect this to 
influence a setup where oVirt uses local storage (a file system location).


4.3.6 detects storageblock size, creates compatible storage domain 
metadata, and

consider the block size when accessing storage.

I've tried downgrading all packages on the host to the previous
versions (with ioprocess 1.2), but this does not seem to make any
difference.


Downgrading should solve your issue, but without any logs we only guess.


I was able to work around my issue by downgrading to ioprocess 1.1 (and 
vdsm-4.30.24). Downgrading to only 1.2 did not solve my issue. With 
ioprocess downgraded to 1.1, I did not have to downgrade the engine 
(still on 4.3.6).


I think I now have a better understanding what happened that triggered this.

During a nightly yum-cron, the ioprocess and vdsm packages on the host 
were upgraded to 1.3 and vdsm 4.30.33. At this point, the engine log 
started to log:


2019-09-27 03:40:27,472+02 INFO 
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] Executing with 
domain map: {6bdf1a0d-274b-4195-8f

f5-a5c002ea1a77=active}
2019-09-27 03:40:27,646+02 WARN 
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] Unexpected 
return value: Status [code=348, message=Block size does not match 
storage block size: 'block_size=512, storage_block_size=4096']
2019-09-27 03:40:27,646+02 INFO 
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-384418) [695f38cc] FINISH, 
ConnectStoragePoolVDSCommand, return: , log id: 483c7a17


I did not notice at first that this was a storage related issue and 
assumed it may get resolved by also upgrading the engine. So in the 
morning I upgraded the engine to 4.3.6 but this did not resolve my issue.


I then found the above error in the engine log. In the release notes of 
4.3.6 I read about the 4k support.


I then downgraded ioprocess (and vdsm) to ioprocess 1.2 but that did 
also not solve my issue. This is when I contacted the list with my question.


Afterwards I found in the ioprocess rpm changelog that (partial?) 4k 
support was also in 1.2. I kept on downgrading until I got ioprocess 1.1 
(without 4k support) and at this point I could re-attach my storage domain.


You mention above that 4.3.6 will detect the block size and configure 
the metadata on the storage domain? I've checked the dom_md/metadata 
file and it shows:


ALIGNMENT=1048576
*BLOCK_SIZE=512*
CLASS=Data
DESCRIPTION=studvirt1-Local
IOOPTIMEOUTSEC=10
LEASERETRIES=3
LEASETIMESEC=60
LOCKPOLICY=
LOCKRENEWALINTERVALSEC=5
MASTER_VERSION=1
POOL_DESCRIPTION=studvirt1-Local
POOL_DOMAINS=6bdf1a0d-274b-4195-8ff5-a5c002ea1a77:Active
POOL_SPM_ID=-1
POOL_SPM_LVER=-1
POOL_UUID=085f02e8-c3b4-4cef-a35c-e357a86eec0c
REMOTE_PATH=/data/images
ROLE=Master
SDUUID=6bdf1a0d-274b-4195-8ff5-a5c002ea1a77
TYPE=LOCALFS
VERSION=5
_SHA_CKSUM=9dde06bbc9f2316efc141565738ff32037b1ff66

I assume that at this point it works because ioprocess 1.1 does not 
report the block size to the engine (as it doesn't support this option?)?


Can I update the storage domain metadata manually to report 4096 instead?

I also noticed that the storage_domain_static table has the block_size 
stored. Should I update this field at the same time as I update the 
metadata file?


If the engine log and database dump is still needed to better understand 
the issue, I will send it on Monday.


Regards,

Rik



Should I also downgrade the engine to 4.3.5 to get this to work
again. I expected the downgrade of the host to be sufficient.

As an alternative I guess I could enable the emulate512 flag on
VDO but I can not find how to do this on an existing VDO volume.
Is this possible?


Please share more data so we can understand the failure:

- complete vdsm log showing the failure to activate the domain
- with 4.3.6
- with 4.3.5 (after you downgraded
- contents of 
/rhev/data-center/mnt/_/domain-uuid/dom_md/metadata

(assuming your local domain mount is /domaindir)
- engine db dump

Nir


Regards,
Rik


On 9/26/19 4:58 PM, Sandro Bonazzola wrote:


The oVirt Project is pleased to announce the general availability
of oVirt 4.3.6 as of September 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Strahil]

I  have upgraded from engine and after reboot the engine knows that I have no 
more updates pending.
This is my flow:
0.Engine upgrade
1. Host is moved in maintenance (from UI) - no ticks for stopping gluster. 
Automatically evacuates  all VMs.
2. Use UI to check for updates
3. Update host (keep tick for autoreboot)
4. Wait for hostto come up and general system & gluster healthcheck


Best Regards,
Strahil Nikolov___
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/R4HF36BDIPFJ3IN2HCXTDWFAPUQ5AZPH/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Derek Atkins]

On Fri, September 27, 2019 11:46 am, Sandro Bonazzola wrote:
[nsip]
>> I'm curious what the steps should be going from 4.1.9 / EL7.4 to 4.3.x /
>> EL7.7?  I am pretty sure I need some steps along the way (I doubt I can
>> jump directly from 4.1.9 -> 4.3.x and 7.4 -> 7.7, right).
>>
>> So should I jump from 7.4/4.1.9 to 7.6/4.2.8 and then from there to
>> 7.7/4.3.6?
>>
>
> 4.1 cluster level is still supported by 4.3 engine.
> So you can upgrade the engine from 7.4/4.1.9 to 7.6/4.2.8 and then to
> 7.7/4.3.6 while on the host side you can go straight to 4.3.6/7.7.
> Once done, please update cluster level to 4.3.

Excellent, I can do that.  I just need to ensure that the cluster settings
fully upgraded from 4.0 to 4.1.

One final question:  I know that ovirt-shell is deprecated, but is it
still available in 4.3.x?

Thanks for all your support!

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
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/FDURRMTSB2IGUGIQPQHRXQCJT7PGDDEB/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 17:35 Derek Atkins  ha
scritto:

> HI,
>
> On Fri, September 27, 2019 7:23 am, Sandro Bonazzola wrote:
> > Il giorno ven 27 set 2019 alle ore 12:55 Derek Atkins 
> ha
> > scritto:
> >
> >> >
> >> > Please use the engine to upgrade hosts, there's a command in webadmin
> >> > interface for that.
> >>
> >> I didn't think you could do this in a single-host hosted-engine system?
> >> In such a deployment the engine has nowhere to migrate to, so it
> >> requires
> >> shutting down the whole "data center" in order to upgrade the host.  I
> >> didn't think that could be done via the engine?
> >>
> >> Personally, I still need to upgrade from 4.1.9 / CentOS 7.4!
> >>
> >
> > Single host self hosted engine will require more work.
> > You'll need to put the host in global maintenance, turn off the engine,
> > yum
> > upgrade the host and reboot.
> > Then get out of global maintenance and engine VM should get back up and
> > running in a few minutes.
>
> Yeah, this is how I've done it in the past.
>
> I'm curious what the steps should be going from 4.1.9 / EL7.4 to 4.3.x /
> EL7.7?  I am pretty sure I need some steps along the way (I doubt I can
> jump directly from 4.1.9 -> 4.3.x and 7.4 -> 7.7, right).
>
> So should I jump from 7.4/4.1.9 to 7.6/4.2.8 and then from there to
> 7.7/4.3.6?
>

4.1 cluster level is still supported by 4.3 engine.
So you can upgrade the engine from 7.4/4.1.9 to 7.6/4.2.8 and then to
7.7/4.3.6 while on the host side you can go straight to 4.3.6/7.7.
Once done, please update cluster level to 4.3.




>
> Thanks,
>
> -derek
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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/V23O776VOFLBVAOBKMZAQO4LMTWONBCU/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Gianluca Cecchi]

On Fri, Sep 27, 2019 at 5:25 PM Laura Wright  wrote:

> We've heard similar feedback around events before so it's definitely on
> our radar. I'm hoping we can address some of these issues when we start the
> PatternFly 4 design efforts around events.
>
>>
>> [snip]

> +Laura Wright  , +Martin Perina  can
>> you please look into this feedback?
>>
>>
>>
Just for reference, if I go with plain host update with manual steps,
instead than selecting "Upgrade" from the gui, the steps are smoother.
- I select host and put it into maintenance
Events:
Migration initiated by system (VM: enginecopy1, Source: ov301, Destination:
ov300, Reason: ). 9/27/19 5:15:09 PM
Host ov301 was switched to Maintenance mode by user1@my_domain@my_domain
(Reason: upgrade). 9/27/19 5:15:09 PM
Migration completed (VM: enginecopy1, Source: ov301, Destination: ov300,
Duration: 2 seconds, Total: 14 seconds, Actual downtime: 75ms) 9/27/19
5:15:24 PM


- on host:
yum update

Transaction Summary
==
Install1 Package  (+10 Dependent packages)
Upgrade  404 Packages
Remove 1 Package

Total download size: 393 M
Is this ok [y/d/N]:

...

  yum-utils.noarch 0:1.1.31-52.el7


Complete!
[g.cecchi@ov301 ~]$

In the mean time the icon of the host ov301 remained all time in
maintenance mode, without switching to any other state

- From web admin gui select host --> Management --> SSH Restart

In events:
Host ov301 was restarted using SSH by the engine. 9/27/19 5:26:45 PM

Icon of host become hourglass

- When host finishes rebooting, the icon becomes the one of the maintenance
again (the wrench, as expected). No events in the mean time

- select host --> Management --> Activate

In the events I see:

Activation of host ov301 initiated by user1@my_domain@my_domain. 9/27/19
5:34:18 PM
No faulty multipath paths on host ov301 9/27/19 5:36:44 PM
Executing power management status on Host ov301 using Proxy Host ov300 and
Fence Agent ipmilan:10.10.193.104 . 9/27/19 5:36:45 PM
Status of host ov301 was set to Up. 9/27/19 5:36:45 PM
Host ov301 power management was verified successfully. 9/27/19 5:36:45 PM

And the host icon becomes the "Up" one...

HIH making the upgrade from GUI a better experience form ovirt events point
of view.

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/B76KVJ42E6OCDRZNVOUCGV5PXAJKTMJB/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Derek Atkins]

HI,

On Fri, September 27, 2019 7:23 am, Sandro Bonazzola wrote:
> Il giorno ven 27 set 2019 alle ore 12:55 Derek Atkins  ha
> scritto:
>
>> >
>> > Please use the engine to upgrade hosts, there's a command in webadmin
>> > interface for that.
>>
>> I didn't think you could do this in a single-host hosted-engine system?
>> In such a deployment the engine has nowhere to migrate to, so it
>> requires
>> shutting down the whole "data center" in order to upgrade the host.  I
>> didn't think that could be done via the engine?
>>
>> Personally, I still need to upgrade from 4.1.9 / CentOS 7.4!
>>
>
> Single host self hosted engine will require more work.
> You'll need to put the host in global maintenance, turn off the engine,
> yum
> upgrade the host and reboot.
> Then get out of global maintenance and engine VM should get back up and
> running in a few minutes.

Yeah, this is how I've done it in the past.

I'm curious what the steps should be going from 4.1.9 / EL7.4 to 4.3.x /
EL7.7?  I am pretty sure I need some steps along the way (I doubt I can
jump directly from 4.1.9 -> 4.3.x and 7.4 -> 7.7, right).

So should I jump from 7.4/4.1.9 to 7.6/4.2.8 and then from there to
7.7/4.3.6?

Thanks,

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
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/RCQYRXCAH3BX5VIXFASDI432UNIXVEJ4/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Laura Wright]

We've heard similar feedback around events before so it's definitely on
our radar. I'm hoping we can address some of these issues when we start the
PatternFly 4 design efforts around events.

On Fri, Sep 27, 2019 at 11:07 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno ven 27 set 2019 alle ore 16:44 Gianluca Cecchi <
> gianluca.cec...@gmail.com> ha scritto:
>
>> On Fri, Sep 27, 2019 at 12:42 PM Sandro Bonazzola 
>> wrote:
>>
>> [snip
>>
>>
>>>
 engine
 1) yum update to update OS
 I think versionlock plugin of oVirt will prevent update of its core
 parts, correct?

>>>
>>> correct, version lock will prevent core oVirt packages to be updated.
>>>
>>>
>>>
>> [snip]
>>
>>>
 2) reboot

 3) update oVirt
 NOTE: probably non need d update setup packages, because put in in
 previous update phase, correct?

>>>
>>> correct, setup packages will be updated in previous loop, just run
>>> engine-setup here
>>>
>>>

 4) eventually yum update again to see if any packages due to new repo
 conf

>>>
>>> shouldn't be needed but no harm in doing it.
>>>
>> In fact I didn't get anything
>>
>>
>>>
>>>

 5) reboot of engine

>>>
>>> engine will be already restarted by engine-setup. If there are no new
>>> updates at kernel level no need to reboot again.
>>>
>> just to replicate a future scenario of rebooting and see that previous
>> time all went up ok
>>
>>
>>>
>>>

 hosts
 6) put into maintenance
 7) simply yum update that will update CentOS packages + oVirt ones
 (vdsm and such..)

>>>
>>> Please use the engine to upgrade hosts, there's a command in webadmin
>>> interface for that.
>>>
>>> It's *a bit* outdated, but still valid:
>>> https://ovirt.org/documentation/upgrade-guide/upgrade-guide.html
>>>
>>>
>>
>> I tried and went well (at least for the first host) as a final result,
>> but the events inside web admin gui don't seem to be well coordinated...
>>
>> See below the sequence of events I got after selecting
>> Installation --> Upgrade (and checking the box to migrate running VMs)
>>
>> one vm running on it was correctly migrated and then the host put into
>> maintenance, but then it seems to me that the following update of vdsmd or
>> other subsysystems tried to got it up again.
>> In fact I saw in the gui the host coming up, then down, then non
>> operational (the X in the red square)
>> Then the host rebooted and came in up state again and I was able to
>> manually migrate a VM into it.
>> One other thing to improve in my opinion is that the upgrade of the host
>> from engine should inject the job that normally once a day checks if a host
>> has available updates: it seems somehow quirky that you pilot host upgrade
>> form engine and engine itself doesn't know that the host has been upgraded
>> (till tomorrow of course...)
>>
>
> +Laura Wright  , +Martin Perina  can
> you please look into this feedback?
>
>
>
>
>>
>> Thanks,
>> Gianluca
>>
>>
>> Host ov200 upgrade was started (User: user1@my_domain@my_domain).
>> 9/27/19 3:55:10 PM
>> Migration initiated by system (VM: hostcopy1, Source: ov200, Destination:
>> ov301, Reason: ). 9/27/19 3:55:11 PM
>> Host ov200 was switched to Maintenance Mode. 9/27/19 3:55:11 PM
>> Migration completed (VM: hostcopy1, Source: ov200, Destination: ov301,
>> Duration: 13 seconds, Total: 20 seconds, Actual downtime: 88ms) 9/27/19
>> 3:55:31 PM
>> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
>> host 'ov200.my_domain', last response arrived 22501 ms ago. 9/27/19 3:57:03
>> PM
>> Host ov200 is not responding. It will stay in Connecting state for a
>> grace period of 60 seconds and after that an attempt to fence the host will
>> be issued. 9/27/19 3:57:03 PM
>> ..
>> Host ov200 is non responsive. 9/27/19 3:57:09 PM
>> Executing power management status on Host ov200 using Proxy Host ov301
>> and Fence Agent ipmilan:10.4.192.66. 9/27/19 3:57:09 PM
>> Soft fencing on host ov200 was successful. 9/27/19 3:57:19 PM
>> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
>> host 'ov200.my_domain', last response arrived 16876 ms ago. 9/27/19 3:59:03
>> PM
>> Host ov200 is non responsive. 9/27/19 3:59:03 PM
>> Executing power management status on Host ov200 using Proxy Host ov301
>> and Fence Agent ipmilan:10.4.192.66. 9/27/19 3:59:04 PM
>> No faulty multipath paths on host ov200 9/27/19 3:59:04 PM
>> Executing power management status on Host ov200 using Proxy Host ov301
>> and Fence Agent ipmilan:10.4.192.66. 9/27/19 3:59:04 PM
>> Status of host ov200 was set to NonResponsive. 9/27/19 3:59:17 PM
>> ..
>> Host ov200 is not responding. It will stay in Connecting state for a
>> grace period of 60 seconds and after that an attempt to fence the host will
>> be issued. 9/27/19 4:00:24 PM
>> Soft fencing on host ov200 was successful. 9/27/19 4:00:38 PM
>> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
>> host 'ov200.my_domain', last 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 16:44 Gianluca Cecchi <
gianluca.cec...@gmail.com> ha scritto:

> On Fri, Sep 27, 2019 at 12:42 PM Sandro Bonazzola 
> wrote:
>
> [snip
>
>
>>
>>> engine
>>> 1) yum update to update OS
>>> I think versionlock plugin of oVirt will prevent update of its core
>>> parts, correct?
>>>
>>
>> correct, version lock will prevent core oVirt packages to be updated.
>>
>>
>>
> [snip]
>
>>
>>> 2) reboot
>>>
>>> 3) update oVirt
>>> NOTE: probably non need d update setup packages, because put in in
>>> previous update phase, correct?
>>>
>>
>> correct, setup packages will be updated in previous loop, just run
>> engine-setup here
>>
>>
>>>
>>> 4) eventually yum update again to see if any packages due to new repo
>>> conf
>>>
>>
>> shouldn't be needed but no harm in doing it.
>>
> In fact I didn't get anything
>
>
>>
>>
>>>
>>> 5) reboot of engine
>>>
>>
>> engine will be already restarted by engine-setup. If there are no new
>> updates at kernel level no need to reboot again.
>>
> just to replicate a future scenario of rebooting and see that previous
> time all went up ok
>
>
>>
>>
>>>
>>> hosts
>>> 6) put into maintenance
>>> 7) simply yum update that will update CentOS packages + oVirt ones (vdsm
>>> and such..)
>>>
>>
>> Please use the engine to upgrade hosts, there's a command in webadmin
>> interface for that.
>>
>> It's *a bit* outdated, but still valid:
>> https://ovirt.org/documentation/upgrade-guide/upgrade-guide.html
>>
>>
>
> I tried and went well (at least for the first host) as a final result, but
> the events inside web admin gui don't seem to be well coordinated...
>
> See below the sequence of events I got after selecting
> Installation --> Upgrade (and checking the box to migrate running VMs)
>
> one vm running on it was correctly migrated and then the host put into
> maintenance, but then it seems to me that the following update of vdsmd or
> other subsysystems tried to got it up again.
> In fact I saw in the gui the host coming up, then down, then non
> operational (the X in the red square)
> Then the host rebooted and came in up state again and I was able to
> manually migrate a VM into it.
> One other thing to improve in my opinion is that the upgrade of the host
> from engine should inject the job that normally once a day checks if a host
> has available updates: it seems somehow quirky that you pilot host upgrade
> form engine and engine itself doesn't know that the host has been upgraded
> (till tomorrow of course...)
>

+Laura Wright  , +Martin Perina  can
you please look into this feedback?




>
> Thanks,
> Gianluca
>
>
> Host ov200 upgrade was started (User: user1@my_domain@my_domain). 9/27/19
> 3:55:10 PM
> Migration initiated by system (VM: hostcopy1, Source: ov200, Destination:
> ov301, Reason: ). 9/27/19 3:55:11 PM
> Host ov200 was switched to Maintenance Mode. 9/27/19 3:55:11 PM
> Migration completed (VM: hostcopy1, Source: ov200, Destination: ov301,
> Duration: 13 seconds, Total: 20 seconds, Actual downtime: 88ms) 9/27/19
> 3:55:31 PM
> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
> host 'ov200.my_domain', last response arrived 22501 ms ago. 9/27/19 3:57:03
> PM
> Host ov200 is not responding. It will stay in Connecting state for a grace
> period of 60 seconds and after that an attempt to fence the host will be
> issued. 9/27/19 3:57:03 PM
> ..
> Host ov200 is non responsive. 9/27/19 3:57:09 PM
> Executing power management status on Host ov200 using Proxy Host ov301 and
> Fence Agent ipmilan:10.4.192.66. 9/27/19 3:57:09 PM
> Soft fencing on host ov200 was successful. 9/27/19 3:57:19 PM
> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
> host 'ov200.my_domain', last response arrived 16876 ms ago. 9/27/19 3:59:03
> PM
> Host ov200 is non responsive. 9/27/19 3:59:03 PM
> Executing power management status on Host ov200 using Proxy Host ov301 and
> Fence Agent ipmilan:10.4.192.66. 9/27/19 3:59:04 PM
> No faulty multipath paths on host ov200 9/27/19 3:59:04 PM
> Executing power management status on Host ov200 using Proxy Host ov301 and
> Fence Agent ipmilan:10.4.192.66. 9/27/19 3:59:04 PM
> Status of host ov200 was set to NonResponsive. 9/27/19 3:59:17 PM
> ..
> Host ov200 is not responding. It will stay in Connecting state for a grace
> period of 60 seconds and after that an attempt to fence the host will be
> issued. 9/27/19 4:00:24 PM
> Soft fencing on host ov200 was successful. 9/27/19 4:00:38 PM
> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
> host 'ov200.my_domain', last response arrived 7121 ms ago. 9/27/19 4:00:56
> PM
> ..
> Host ov200 was restarted using SSH by the engine. 9/27/19 4:02:31 PM
> Upgrade was successful and host ov200 will be rebooted. 9/27/194:02:31 PM
> VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
> host 'ov200.my_domain', last response arrived 5341 ms ago. 9/27/19 4:02:46
> PM
> Host ov200 cannot access the Storage 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Gianluca Cecchi]

On Fri, Sep 27, 2019 at 12:42 PM Sandro Bonazzola 
wrote:

[snip


>
>> engine
>> 1) yum update to update OS
>> I think versionlock plugin of oVirt will prevent update of its core
>> parts, correct?
>>
>
> correct, version lock will prevent core oVirt packages to be updated.
>
>
>
[snip]

>
>> 2) reboot
>>
>> 3) update oVirt
>> NOTE: probably non need d update setup packages, because put in in
>> previous update phase, correct?
>>
>
> correct, setup packages will be updated in previous loop, just run
> engine-setup here
>
>
>>
>> 4) eventually yum update again to see if any packages due to new repo
>> conf
>>
>
> shouldn't be needed but no harm in doing it.
>
In fact I didn't get anything


>
>
>>
>> 5) reboot of engine
>>
>
> engine will be already restarted by engine-setup. If there are no new
> updates at kernel level no need to reboot again.
>
just to replicate a future scenario of rebooting and see that previous time
all went up ok


>
>
>>
>> hosts
>> 6) put into maintenance
>> 7) simply yum update that will update CentOS packages + oVirt ones (vdsm
>> and such..)
>>
>
> Please use the engine to upgrade hosts, there's a command in webadmin
> interface for that.
>
> It's *a bit* outdated, but still valid:
> https://ovirt.org/documentation/upgrade-guide/upgrade-guide.html
>
>

I tried and went well (at least for the first host) as a final result, but
the events inside web admin gui don't seem to be well coordinated...

See below the sequence of events I got after selecting
Installation --> Upgrade (and checking the box to migrate running VMs)

one vm running on it was correctly migrated and then the host put into
maintenance, but then it seems to me that the following update of vdsmd or
other subsysystems tried to got it up again.
In fact I saw in the gui the host coming up, then down, then non
operational (the X in the red square)
Then the host rebooted and came in up state again and I was able to
manually migrate a VM into it.
One other thing to improve in my opinion is that the upgrade of the host
from engine should inject the job that normally once a day checks if a host
has available updates: it seems somehow quirky that you pilot host upgrade
form engine and engine itself doesn't know that the host has been upgraded
(till tomorrow of course...)

Thanks,
Gianluca


Host ov200 upgrade was started (User: user1@my_domain@my_domain). 9/27/19
3:55:10 PM
Migration initiated by system (VM: hostcopy1, Source: ov200, Destination:
ov301, Reason: ). 9/27/19 3:55:11 PM
Host ov200 was switched to Maintenance Mode. 9/27/19 3:55:11 PM
Migration completed (VM: hostcopy1, Source: ov200, Destination: ov301,
Duration: 13 seconds, Total: 20 seconds, Actual downtime: 88ms) 9/27/19
3:55:31 PM
VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
host 'ov200.my_domain', last response arrived 22501 ms ago. 9/27/19 3:57:03
PM
Host ov200 is not responding. It will stay in Connecting state for a grace
period of 60 seconds and after that an attempt to fence the host will be
issued. 9/27/19 3:57:03 PM
..
Host ov200 is non responsive. 9/27/19 3:57:09 PM
Executing power management status on Host ov200 using Proxy Host ov301 and
Fence Agent ipmilan:10.4.192.66. 9/27/19 3:57:09 PM
Soft fencing on host ov200 was successful. 9/27/19 3:57:19 PM
VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
host 'ov200.my_domain', last response arrived 16876 ms ago. 9/27/19 3:59:03
PM
Host ov200 is non responsive. 9/27/19 3:59:03 PM
Executing power management status on Host ov200 using Proxy Host ov301 and
Fence Agent ipmilan:10.4.192.66. 9/27/19 3:59:04 PM
No faulty multipath paths on host ov200 9/27/19 3:59:04 PM
Executing power management status on Host ov200 using Proxy Host ov301 and
Fence Agent ipmilan:10.4.192.66. 9/27/19 3:59:04 PM
Status of host ov200 was set to NonResponsive. 9/27/19 3:59:17 PM
..
Host ov200 is not responding. It will stay in Connecting state for a grace
period of 60 seconds and after that an attempt to fence the host will be
issued. 9/27/19 4:00:24 PM
Soft fencing on host ov200 was successful. 9/27/19 4:00:38 PM
VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
host 'ov200.my_domain', last response arrived 7121 ms ago. 9/27/19 4:00:56
PM
..
Host ov200 was restarted using SSH by the engine. 9/27/19 4:02:31 PM
Upgrade was successful and host ov200 will be rebooted. 9/27/194:02:31 PM
VDSM ov200 command ConnectStorageServerVDS failed: Connection timeout for
host 'ov200.my_domain', last response arrived 5341 ms ago. 9/27/19 4:02:46
PM
Host ov200 cannot access the Storage Domain(s)  attached to the
Data Center MYDC. Setting Host state to Non-Operational. 9/27/19 4:02:46 PM
Failed to connect Host ov200 to Storage Pool MYDC 9/27/19 4:02:46 PM
...
Executing power management status on Host ov200 using Proxy Host ov301 and
Fence Agent ipmilan:10.4.192.66. 9/27/19 4:12:27 PM
Status of host ov200 was set to Up. 9/27/19 4:12:27 PM
Host ov200 power management was 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Nir Soffer]

On Fri, Sep 27, 2019, 12:37 Rik Theys  wrote:

> Hi,
>
> After upgrading to 4.3.6, my storage domain can no longer be activated,
> rendering my data center useless.
>
> My storage domain is local storage on a filesystem backed by VDO/LVM. It
> seems 4.3.6 has added support for 4k storage.
> My VDO does not have the 'emulate512' flag set.
>

This configuration is not supported before 4.3.6. Various operations may
fail when
reading or writing to storage.

4.3.6 detects storage block size, creates compatible storage domain
metadata, and
consider the block size when accessing storage.


> I've tried downgrading all packages on the host to the previous versions
> (with ioprocess 1.2), but this does not seem to make any difference.
>

Downgrading should solve your issue, but without any logs we only guess.


> Should I also downgrade the engine to 4.3.5 to get this to work again. I
> expected the downgrade of the host to be sufficient.
>
> As an alternative I guess I could enable the emulate512 flag on VDO but I
> can not find how to do this on an existing VDO volume. Is this possible?
>

Please share more data so we can understand the failure:

- complete vdsm log showing the failure to activate the domain
  - with 4.3.6
  - with 4.3.5 (after you downgraded
- contents of /rhev/data-center/mnt/_/domain-uuid/dom_md/metadata
  (assuming your local domain mount is /domaindir)
- engine db dump

Nir


>
> Regards,
> Rik
>
>
> On 9/26/19 4:58 PM, Sandro Bonazzola wrote:
>
> The oVirt Project is pleased to announce the general availability of oVirt
> 4.3.6 as of September 26th, 2019.
>
>
>
> This update is the sixth in a series of stabilization updates to the 4.3
> series.
>
>
>
> This release is available now on x86_64 architecture for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
>
>
> This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
> for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
> * oVirt Node 4.3 (available for x86_64 only)
>
>
>
> Due to Fedora 28 being now at end of life this release is missing
> experimental tech preview for x86_64 and s390x architectures for Fedora 28.
>
> We are working on Fedora 29 and 30 support and we may re-introduce
> experimental support for Fedora in next release.
>
>
>
> See the release notes [1] for installation / upgrade instructions and a
> list of new features and bugs fixed.
>
>
>
> Notes:
>
> - oVirt Appliance is already available
>
> - oVirt Node is already available[2]
>
> oVirt Node and Appliance have been updated including:
>
> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>
> - Wildfly 17.0.1:
> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>
> - Latest CentOS 7.7 updates including:
>
>-
>
>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>
> 
>-
>
>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>
> 
>
>-
>
>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>
> 
>-
>
>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>
> 
>-
>
>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>
> 
>-
>
>CESA-2019:2258 Moderate CentOS 7 http-parser Security Update
>
> 
>-
>
>CESA-2019:2600 Important CentOS 7 kernel Security Update
>
> 
>-
>
>CEBA-2019:2599 CentOS 7 krb5 BugFix Update
>
> 
>-
>
>CEBA-2019:2358 CentOS 7 libguestfs BugFix Update
>
> 
>-
>
>CEBA-2019:2679 CentOS 7 libvirt BugFix Update
>
> 
>-
>
>CEBA-2019:2501 CentOS 7 rsyslog BugFix Update
>
> 
>-
>
>CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update
>
> 
>-
>
>CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update
>
> 
>-
>
>CEBA-2019:2602 CentOS 7 sos BugFix Update
>
> 
>
>-
>
>

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Satheesaran Sundaramoorthi]

On Fri, Sep 27, 2019 at 4:13 PM Sandro Bonazzola 
wrote:

> Il giorno ven 27 set 2019 alle ore 11:31 Rik Theys <
> rik.th...@esat.kuleuven.be> ha scritto:
>
>> Hi,
>>
>> After upgrading to 4.3.6, my storage domain can no longer be activated,
>> rendering my data center useless.
>>
> Hello Rik,

Did you get the exact engine log, why the storage domain can't be
activated. ?
Could you send the engine.log ?

>
>> My storage domain is local storage on a filesystem backed by VDO/LVM. It
>> seems 4.3.6 has added support for 4k storage.
>>
> Do you have gluster in this combination of VDO/LVM ?
There are some QEMU fixes that is required for 4K storage to work with
oVirt.
These fixes will be part of CentOS 7.7 batch update 2


> My VDO does not have the 'emulate512' flag set.
>>
> This means your VDO volume would have been configured as a 4K' native device
by default.
Was it this way, before updating to oVirt 4.3.6 ?
I believe so, because you can't change the block size of VDO on the fly.
So my guess is that you are running fortunate with 4K VDO volume

>
>> I've tried downgrading all packages on the host to the previous versions
>> (with ioprocess 1.2), but this does not seem to make any difference. Should
>> I also downgrade the engine to 4.3.5 to get this to work again. I expected
>> the downgrade of the host to be sufficient.
>>
>> As an alternative I guess I could enable the emulate512 flag on VDO but I
>> can not find how to do this on an existing VDO volume. Is this possible?
>>
> As state above, this is not possible.
Once VDO volume is created, its block size can't be changed dynamically.

-- Satheesaran S ( sas )
___
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/BGMYU5BOTZWGLJRZMZHQX3PN72VF6O74/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Gobinda Das]

Hi,

On Fri, Sep 27, 2019 at 3:07 PM Rik Theys 
wrote:

> Hi,
>
> After upgrading to 4.3.6, my storage domain can no longer be activated,
> rendering my data center useless.
>
> My storage domain is local storage on a filesystem backed by VDO/LVM. It
> seems 4.3.6 has added support for 4k storage.
> My VDO does not have the 'emulate512' flag set.
>
> I've tried downgrading all packages on the host to the previous versions
> (with ioprocess 1.2), but this does not seem to make any difference. Should
> I also downgrade the engine to 4.3.5 to get this to work again. I expected
> the downgrade of the host to be sufficient.
>
What does engine log saying? Does it sending block_size =0 or 512?
If engine is sending 0 after you downgrade the hosts, then you need to
downgrade engine too.

>
> As an alternative I guess I could enable the emulate512 flag on VDO but I
> can not find how to do this on an existing VDO volume. Is this possible?
>
I don't think you can change  emulate512 value once you create VDO volume.

>
> Regards,
> Rik
>
>
> On 9/26/19 4:58 PM, Sandro Bonazzola wrote:
>
> The oVirt Project is pleased to announce the general availability of oVirt
> 4.3.6 as of September 26th, 2019.
>
>
>
> This update is the sixth in a series of stabilization updates to the 4.3
> series.
>
>
>
> This release is available now on x86_64 architecture for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
>
>
> This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
> for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
> * oVirt Node 4.3 (available for x86_64 only)
>
>
>
> Due to Fedora 28 being now at end of life this release is missing
> experimental tech preview for x86_64 and s390x architectures for Fedora 28.
>
> We are working on Fedora 29 and 30 support and we may re-introduce
> experimental support for Fedora in next release.
>
>
>
> See the release notes [1] for installation / upgrade instructions and a
> list of new features and bugs fixed.
>
>
>
> Notes:
>
> - oVirt Appliance is already available
>
> - oVirt Node is already available[2]
>
> oVirt Node and Appliance have been updated including:
>
> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>
> - Wildfly 17.0.1:
> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>
> - Latest CentOS 7.7 updates including:
>
>-
>
>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>
> 
>-
>
>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>
> 
>
>-
>
>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>
> 
>-
>
>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>
> 
>-
>
>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>
> 
>-
>
>CESA-2019:2258 Moderate CentOS 7 http-parser Security Update
>
> 
>-
>
>CESA-2019:2600 Important CentOS 7 kernel Security Update
>
> 
>-
>
>CEBA-2019:2599 CentOS 7 krb5 BugFix Update
>
> 
>-
>
>CEBA-2019:2358 CentOS 7 libguestfs BugFix Update
>
> 
>-
>
>CEBA-2019:2679 CentOS 7 libvirt BugFix Update
>
> 
>-
>
>CEBA-2019:2501 CentOS 7 rsyslog BugFix Update
>
> 
>-
>
>CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update
>
> 
>-
>
>CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update
>
> 
>-
>
>CEBA-2019:2602 CentOS 7 sos BugFix Update
>
> 
>
>-
>
>CEBA-2019:2564 CentOS 7 subscription-manager BugFix Update
>
> 
>-
>
>CEBA-2019:2356 CentOS 7 systemd BugFix Update
>
> 
>-
>
>CEBA-2019:2605 CentOS 7 tuned BugFix Update
>
> 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 12:55 Derek Atkins  ha
scritto:

>
> On Fri, September 27, 2019 6:41 am, Sandro Bonazzola wrote:
> [snip]
> >> hosts
> >> 6) put into maintenance
> >> 7) simply yum update that will update CentOS packages + oVirt ones (vdsm
> >> and such..)
> >>
> >
> > Please use the engine to upgrade hosts, there's a command in webadmin
> > interface for that.
>
> I didn't think you could do this in a single-host hosted-engine system?
> In such a deployment the engine has nowhere to migrate to, so it requires
> shutting down the whole "data center" in order to upgrade the host.  I
> didn't think that could be done via the engine?
>
> Personally, I still need to upgrade from 4.1.9 / CentOS 7.4!
>

Single host self hosted engine will require more work.
You'll need to put the host in global maintenance, turn off the engine, yum
upgrade the host and reboot.
Then get out of global maintenance and engine VM should get back up and
running in a few minutes.



>
> > It's *a bit* outdated, but still valid:
> > https://ovirt.org/documentation/upgrade-guide/upgrade-guide.html
>
> -derek
>
> --
>Derek Atkins 617-623-3745
>de...@ihtfp.com www.ihtfp.com
>Computer and Internet Security Consultant
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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/QVJBGSIK4IE5HEM6ROEVA27EAQEZQCXP/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Derek Atkins]

On Fri, September 27, 2019 6:41 am, Sandro Bonazzola wrote:
[snip]
>> hosts
>> 6) put into maintenance
>> 7) simply yum update that will update CentOS packages + oVirt ones (vdsm
>> and such..)
>>
>
> Please use the engine to upgrade hosts, there's a command in webadmin
> interface for that.

I didn't think you could do this in a single-host hosted-engine system?
In such a deployment the engine has nowhere to migrate to, so it requires
shutting down the whole "data center" in order to upgrade the host.  I
didn't think that could be done via the engine?

Personally, I still need to upgrade from 4.1.9 / CentOS 7.4!

> It's *a bit* outdated, but still valid:
> https://ovirt.org/documentation/upgrade-guide/upgrade-guide.html

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
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/A6MYNHANZ3IN5WDACOTFMK7ZHNCW7D6R/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 11:31 Rik Theys <
rik.th...@esat.kuleuven.be> ha scritto:

> Hi,
>
> After upgrading to 4.3.6, my storage domain can no longer be activated,
> rendering my data center useless.
>
> My storage domain is local storage on a filesystem backed by VDO/LVM. It
> seems 4.3.6 has added support for 4k storage.
> My VDO does not have the 'emulate512' flag set.
>
> I've tried downgrading all packages on the host to the previous versions
> (with ioprocess 1.2), but this does not seem to make any difference. Should
> I also downgrade the engine to 4.3.5 to get this to work again. I expected
> the downgrade of the host to be sufficient.
>
> As an alternative I guess I could enable the emulate512 flag on VDO but I
> can not find how to do this on an existing VDO volume. Is this possible?
>

+Sahina Bose  +Gobinda Das 
+Sundaramoorthi,
Satheesaran  please follow up here.



>
> Regards,
> Rik
>
>
> On 9/26/19 4:58 PM, Sandro Bonazzola wrote:
>
> The oVirt Project is pleased to announce the general availability of oVirt
> 4.3.6 as of September 26th, 2019.
>
>
>
> This update is the sixth in a series of stabilization updates to the 4.3
> series.
>
>
>
> This release is available now on x86_64 architecture for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
>
>
> This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
> for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
> * oVirt Node 4.3 (available for x86_64 only)
>
>
>
> Due to Fedora 28 being now at end of life this release is missing
> experimental tech preview for x86_64 and s390x architectures for Fedora 28.
>
> We are working on Fedora 29 and 30 support and we may re-introduce
> experimental support for Fedora in next release.
>
>
>
> See the release notes [1] for installation / upgrade instructions and a
> list of new features and bugs fixed.
>
>
>
> Notes:
>
> - oVirt Appliance is already available
>
> - oVirt Node is already available[2]
>
> oVirt Node and Appliance have been updated including:
>
> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>
> - Wildfly 17.0.1:
> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>
> - Latest CentOS 7.7 updates including:
>
>-
>
>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>
> 
>-
>
>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>
> 
>
>-
>
>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>
> 
>-
>
>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>
> 
>-
>
>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>
> 
>-
>
>CESA-2019:2258 Moderate CentOS 7 http-parser Security Update
>
> 
>-
>
>CESA-2019:2600 Important CentOS 7 kernel Security Update
>
> 
>-
>
>CEBA-2019:2599 CentOS 7 krb5 BugFix Update
>
> 
>-
>
>CEBA-2019:2358 CentOS 7 libguestfs BugFix Update
>
> 
>-
>
>CEBA-2019:2679 CentOS 7 libvirt BugFix Update
>
> 
>-
>
>CEBA-2019:2501 CentOS 7 rsyslog BugFix Update
>
> 
>-
>
>CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update
>
> 
>-
>
>CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update
>
> 
>-
>
>CEBA-2019:2602 CentOS 7 sos BugFix Update
>
> 
>
>-
>
>CEBA-2019:2564 CentOS 7 subscription-manager BugFix Update
>
> 
>-
>
>CEBA-2019:2356 CentOS 7 systemd BugFix Update
>
> 
>-
>
>CEBA-2019:2605 CentOS 7 tuned BugFix Update
>
> 
>-
>
>CEBA-2019:2871 CentOS 7 tzdata BugFix Update
>
> 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 12:15 Gianluca Cecchi <
gianluca.cec...@gmail.com> ha scritto:

> On Thu, Sep 26, 2019 at 5:23 PM Sandro Bonazzola 
> wrote:
>
>>
>>> Does this mean that CentOS 7.6 is not supported any more starting from
>>> 4.3.6?
>>> Due to the fact that eg 4.3.5 was only supported on CentOS < 7.7 how
>>> should it be the correct flow of updating OS and oVirt versions in this
>>> case? Both for plain CentOS hosts and engine...
>>>
>>
>> 4.3.5 will work with CentOS 7.7 too.
>>
>> https://lists.ovirt.org/archives/list/annou...@ovirt.org/thread/DJF37K7TQFTR346JPJ54YNLY5X6NY2EF/
>> says 7.6 or later but < 8
>>
>>
> Sure, but at date of announce of oVirt 4.3.5 (30/07), CentOS 7.7 was not
> available yet (17/09)... so that phrase was a bit speculation... ;-)
>
> In my case I currently have both my separate server engine and 3 plain
> hosts in CentOS 7.6 + 4.3.5
> What would it be the workflow?
> Did you test this scenario, that I think will be very common with users
> that upgrades often (eg in their test env)?
>
> engine
> 1) yum update to update OS
> I think versionlock plugin of oVirt will prevent update of its core parts,
> correct?
>

correct, version lock will prevent core oVirt packages to be updated.



> I see many ovirt related packages put in. See here:
>
> https://drive.google.com/file/d/1IvvwfJGgzdn6qkrI7d-WBAShRxUTdC1g/view?usp=sharing
>
> versionlock prevented:
>
> [g.cecchi@ovmgr1 ~]$ sudo yum versionlock status
> Loaded plugins: fastestmirror, langpacks, versionlock
> Repository centos-sclo-rh-release is listed more than once in the
> configuration
> Loading mirror speeds from cached hostfile
>  * base: centos.mirror.garr.it
>  * epel-util: epel.besthosting.ua
>  * extras: centos.mirror.garr.it
>  * ovirt-4.3: ftp.nluug.nl
>  * ovirt-4.3-epel: epel.besthosting.ua
>  * updates: centos.mirror.garr.it
> 0:ovirt-engine-webadmin-portal-4.3.6.6-1.el7.*
> 0:ovirt-engine-ui-extensions-1.0.10-1.el7.*
> 0:ovirt-engine-dwh-4.3.6-1.el7.*
> 0:ovirt-engine-tools-backup-4.3.6.6-1.el7.*
> 0:ovirt-engine-restapi-4.3.6.6-1.el7.*
> 0:ovirt-engine-dbscripts-4.3.6.6-1.el7.*
> 0:ovirt-engine-4.3.6.6-1.el7.*
> 0:ovirt-engine-backend-4.3.6.6-1.el7.*
> 0:ovirt-engine-wildfly-17.0.1-1.el7.*
> 0:ovirt-engine-wildfly-overlay-17.0.1-1.el7.*
> 0:ovirt-engine-tools-4.3.6.6-1.el7.*
> versionlock status done
> [g.cecchi@ovmgr1 ~]$
>
> 2) reboot
>
> 3) update oVirt
> NOTE: probably non need d update setup packages, because put in in
> previous update phase, correct?
>

correct, setup packages will be updated in previous loop, just run
engine-setup here


>
> 4) eventually yum update again to see if any packages due to new repo conf
>

shouldn't be needed but no harm in doing it.


>
> 5) reboot of engine
>

engine will be already restarted by engine-setup. If there are no new
updates at kernel level no need to reboot again.


>
> hosts
> 6) put into maintenance
> 7) simply yum update that will update CentOS packages + oVirt ones (vdsm
> and such..)
>

Please use the engine to upgrade hosts, there's a command in webadmin
interface for that.

It's *a bit* outdated, but still valid:
https://ovirt.org/documentation/upgrade-guide/upgrade-guide.html


>
> Do you agree or have alternative path?
> Thanks,
> Gianluca
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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/NAIH7VNWNL4BW4MQMZLKD4NMWMB2H2AM/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Gianluca Cecchi]

On Thu, Sep 26, 2019 at 5:23 PM Sandro Bonazzola 
wrote:

>
>> Does this mean that CentOS 7.6 is not supported any more starting from
>> 4.3.6?
>> Due to the fact that eg 4.3.5 was only supported on CentOS < 7.7 how
>> should it be the correct flow of updating OS and oVirt versions in this
>> case? Both for plain CentOS hosts and engine...
>>
>
> 4.3.5 will work with CentOS 7.7 too.
>
> https://lists.ovirt.org/archives/list/annou...@ovirt.org/thread/DJF37K7TQFTR346JPJ54YNLY5X6NY2EF/
> says 7.6 or later but < 8
>
>
Sure, but at date of announce of oVirt 4.3.5 (30/07), CentOS 7.7 was not
available yet (17/09)... so that phrase was a bit speculation... ;-)

In my case I currently have both my separate server engine and 3 plain
hosts in CentOS 7.6 + 4.3.5
What would it be the workflow?
Did you test this scenario, that I think will be very common with users
that upgrades often (eg in their test env)?

engine
1) yum update to update OS
I think versionlock plugin of oVirt will prevent update of its core parts,
correct?
I see many ovirt related packages put in. See here:
https://drive.google.com/file/d/1IvvwfJGgzdn6qkrI7d-WBAShRxUTdC1g/view?usp=sharing

versionlock prevented:

[g.cecchi@ovmgr1 ~]$ sudo yum versionlock status
Loaded plugins: fastestmirror, langpacks, versionlock
Repository centos-sclo-rh-release is listed more than once in the
configuration
Loading mirror speeds from cached hostfile
 * base: centos.mirror.garr.it
 * epel-util: epel.besthosting.ua
 * extras: centos.mirror.garr.it
 * ovirt-4.3: ftp.nluug.nl
 * ovirt-4.3-epel: epel.besthosting.ua
 * updates: centos.mirror.garr.it
0:ovirt-engine-webadmin-portal-4.3.6.6-1.el7.*
0:ovirt-engine-ui-extensions-1.0.10-1.el7.*
0:ovirt-engine-dwh-4.3.6-1.el7.*
0:ovirt-engine-tools-backup-4.3.6.6-1.el7.*
0:ovirt-engine-restapi-4.3.6.6-1.el7.*
0:ovirt-engine-dbscripts-4.3.6.6-1.el7.*
0:ovirt-engine-4.3.6.6-1.el7.*
0:ovirt-engine-backend-4.3.6.6-1.el7.*
0:ovirt-engine-wildfly-17.0.1-1.el7.*
0:ovirt-engine-wildfly-overlay-17.0.1-1.el7.*
0:ovirt-engine-tools-4.3.6.6-1.el7.*
versionlock status done
[g.cecchi@ovmgr1 ~]$

2) reboot

3) update oVirt
NOTE: probably non need d update setup packages, because put in in previous
update phase, correct?

4) eventually yum update again to see if any packages due to new repo conf

5) reboot of engine

hosts
6) put into maintenance
7) simply yum update that will update CentOS packages + oVirt ones (vdsm
and such..)

Do you agree or have alternative path?
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/IHQRZTZUKIVXSBO4VYPTXSYNA4EZJGGK/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Rik Theys]

Hi,

After upgrading to 4.3.6, my storage domain can no longer be activated, 
rendering my data center useless.


My storage domain is local storage on a filesystem backed by VDO/LVM. It 
seems 4.3.6 has added support for 4k storage.

My VDO does not have the 'emulate512' flag set.

I've tried downgrading all packages on the host to the previous versions 
(with ioprocess 1.2), but this does not seem to make any difference. 
Should I also downgrade the engine to 4.3.5 to get this to work again. I 
expected the downgrade of the host to be sufficient.


As an alternative I guess I could enable the emulate512 flag on VDO but 
I can not find how to do this on an existing VDO volume. Is this possible?


Regards,
Rik


On 9/26/19 4:58 PM, Sandro Bonazzola wrote:


The oVirt Project is pleased to announce the general availability of 
oVirt 4.3.6 as of September 26th, 2019.


This update is the sixth in a series of stabilization updates to the 
4.3 series.


This release is available now on x86_64 architecture for:

* Red Hat Enterprise Linux 7.7 or later (but < 8)

* CentOS Linux (or similar) 7.7 or later (but < 8)

This release supports Hypervisor Hosts on x86_64 and ppc64le 
architectures for:


* Red Hat Enterprise Linux 7.7 or later (but < 8)

* CentOS Linux (or similar) 7.7 or later (but < 8)

* oVirt Node 4.3 (available for x86_64 only)

Due to Fedora 28 being now at end of life this release is missing 
experimental tech preview for x86_64 and s390x architectures for 
Fedora 28.


We are working on Fedora 29 and 30 support and we may re-introduce 
experimental support for Fedora in next release.


See the release notes [1] for installation / upgrade instructions and 
a list of new features and bugs fixed.


Notes:

- oVirt Appliance is already available

- oVirt Node is already available[2]


oVirt Node and Appliance have been updated including:

- oVirt4.3.6: http://www.ovirt.org/release/4.3.6/

- Wildfly17.0.1: 
https://wildfly.org/news/2019/07/07/WildFly-1701-Released/


- Latest CentOS 7.7updates including:

 *

Release for CentOS Linux 7 (1908) on the x86_64 Architecture



 *

CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update



 *

CEBA-2019:2023 CentOS 7 efivar BugFix Update



 *

CEBA-2019:2614 CentOS 7 firewalld BugFix Update



 *

CEBA-2019:2227 CentOS 7 grubby BugFix Update



 *

CESA-2019:2258 Moderate CentOS 7 http-parser Security Update



 *

CESA-2019:2600 Important CentOS 7 kernel Security Update



 *

CEBA-2019:2599 CentOS 7 krb5 BugFix Update



 *

CEBA-2019:2358 CentOS 7 libguestfs BugFix Update



 *

CEBA-2019:2679 CentOS 7 libvirt BugFix Update



 *

CEBA-2019:2501 CentOS 7 rsyslog BugFix Update



 *

CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update



 *

CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update



 *

CEBA-2019:2602 CentOS 7 sos BugFix Update



 *

CEBA-2019:2564 CentOS 7 subscription-manager BugFix Update



 *

CEBA-2019:2356 CentOS 7 systemd BugFix Update



 *

CEBA-2019:2605 CentOS 7 tuned BugFix Update



 *

CEBA-2019:2871 CentOS 7 tzdata BugFix Update



- latest CentOS Virt and Storage SIG updates:

 *

Ansible2.8.5:

https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.8.rst#v2-8-5

 *

Glusterfs6.5: https://docs.gluster.org/en/latest/release-notes/6.5/

 *

QEMU KVM EV2.12.0-33.1 :
https://cbs.centos.org/koji/buildinfo?buildID=26484


Given the amount of security fixes 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno ven 27 set 2019 alle ore 05:21 Guillaume Pavese <
guillaume.pav...@interactiv-group.com> ha scritto:

> I see that oVirt 4.3.6 finally has 4k domain support.
>
> - Would that mean that VDO enabled Gluster domains will be created without
> the --emulate512 workaround?
> - If the wizard to create the Gluster volumes has not yet removed that
> parameter, is it safe to edit & remove it manually before creation?
> - Should we expect performance increase by using the native 4k block size
> of VDO?
>
>

+Nir Soffer  +Sundaramoorthi, Satheesaran
 +Gobinda Das  can you answer here?



> Thanks
>
> Guillaume Pavese
> Ingénieur Système et Réseau
> Interactiv-Group
>
>
> On Fri, Sep 27, 2019 at 12:00 AM Sandro Bonazzola 
> wrote:
>
>> The oVirt Project is pleased to announce the general availability of
>> oVirt 4.3.6 as of September 26th, 2019.
>>
>>
>>
>> This update is the sixth in a series of stabilization updates to the 4.3
>> series.
>>
>>
>>
>> This release is available now on x86_64 architecture for:
>>
>> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>>
>> * CentOS Linux (or similar) 7.7 or later (but < 8)
>>
>>
>>
>> This release supports Hypervisor Hosts on x86_64 and ppc64le
>> architectures for:
>>
>> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>>
>> * CentOS Linux (or similar) 7.7 or later (but < 8)
>>
>> * oVirt Node 4.3 (available for x86_64 only)
>>
>>
>>
>> Due to Fedora 28 being now at end of life this release is missing
>> experimental tech preview for x86_64 and s390x architectures for Fedora 28.
>>
>> We are working on Fedora 29 and 30 support and we may re-introduce
>> experimental support for Fedora in next release.
>>
>>
>>
>> See the release notes [1] for installation / upgrade instructions and a
>> list of new features and bugs fixed.
>>
>>
>>
>> Notes:
>>
>> - oVirt Appliance is already available
>>
>> - oVirt Node is already available[2]
>>
>> oVirt Node and Appliance have been updated including:
>>
>> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>>
>> - Wildfly 17.0.1:
>> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>>
>> - Latest CentOS 7.7 updates including:
>>
>>-
>>
>>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>>
>> 
>>-
>>
>>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>>
>> 
>>
>>-
>>
>>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>>
>> 
>>-
>>
>>CESA-2019:2258 Moderate CentOS 7 http-parser Security Update
>>
>> 
>>-
>>
>>CESA-2019:2600 Important CentOS 7 kernel Security Update
>>
>> 
>>-
>>
>>CEBA-2019:2599 CentOS 7 krb5 BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2358 CentOS 7 libguestfs BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2679 CentOS 7 libvirt BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2501 CentOS 7 rsyslog BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2602 CentOS 7 sos BugFix Update
>>
>> 
>>
>>-
>>
>>CEBA-2019:2564 CentOS 7 subscription-manager BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2356 CentOS 7 systemd BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2605 CentOS 7 tuned BugFix Update
>>
>> 
>>-
>>
>>CEBA-2019:2871 CentOS 7 tzdata BugFix Update
>>
>> 
>>
>> - latest 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Guillaume Pavese]

I see that oVirt 4.3.6 finally has 4k domain support.

- Would that mean that VDO enabled Gluster domains will be created without
the --emulate512 workaround?
- If the wizard to create the Gluster volumes has not yet removed that
parameter, is it safe to edit & remove it manually before creation?
- Should we expect performance increase by using the native 4k block size
of VDO?

Thanks

Guillaume Pavese
Ingénieur Système et Réseau
Interactiv-Group


On Fri, Sep 27, 2019 at 12:00 AM Sandro Bonazzola 
wrote:

> The oVirt Project is pleased to announce the general availability of oVirt
> 4.3.6 as of September 26th, 2019.
>
>
>
> This update is the sixth in a series of stabilization updates to the 4.3
> series.
>
>
>
> This release is available now on x86_64 architecture for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
>
>
> This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
> for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
> * oVirt Node 4.3 (available for x86_64 only)
>
>
>
> Due to Fedora 28 being now at end of life this release is missing
> experimental tech preview for x86_64 and s390x architectures for Fedora 28.
>
> We are working on Fedora 29 and 30 support and we may re-introduce
> experimental support for Fedora in next release.
>
>
>
> See the release notes [1] for installation / upgrade instructions and a
> list of new features and bugs fixed.
>
>
>
> Notes:
>
> - oVirt Appliance is already available
>
> - oVirt Node is already available[2]
>
> oVirt Node and Appliance have been updated including:
>
> - oVirt 4.3.6: http://www.ovirt.org/release/4.3.6/
>
> - Wildfly 17.0.1:
> https://wildfly.org/news/2019/07/07/WildFly-1701-Released/
>
> - Latest CentOS 7.7 updates including:
>
>-
>
>Release for CentOS Linux 7 (1908) on the x86_64 Architecture
>
> 
>-
>
>CEBA-2019:2601 CentOS 7 NetworkManager BugFix Update
>
> 
>
>-
>
>CEBA-2019:2023 CentOS 7 efivar BugFix Update
>
> 
>-
>
>CEBA-2019:2614 CentOS 7 firewalld BugFix Update
>
> 
>-
>
>CEBA-2019:2227 CentOS 7 grubby BugFix Update
>
> 
>-
>
>CESA-2019:2258 Moderate CentOS 7 http-parser Security Update
>
> 
>-
>
>CESA-2019:2600 Important CentOS 7 kernel Security Update
>
> 
>-
>
>CEBA-2019:2599 CentOS 7 krb5 BugFix Update
>
> 
>-
>
>CEBA-2019:2358 CentOS 7 libguestfs BugFix Update
>
> 
>-
>
>CEBA-2019:2679 CentOS 7 libvirt BugFix Update
>
> 
>-
>
>CEBA-2019:2501 CentOS 7 rsyslog BugFix Update
>
> 
>-
>
>CEBA-2019:2355 CentOS 7 selinux-policy BugFix Update
>
> 
>-
>
>CEBA-2019:2612 CentOS 7 sg3_utils BugFix Update
>
> 
>-
>
>CEBA-2019:2602 CentOS 7 sos BugFix Update
>
> 
>
>-
>
>CEBA-2019:2564 CentOS 7 subscription-manager BugFix Update
>
> 
>-
>
>CEBA-2019:2356 CentOS 7 systemd BugFix Update
>
> 
>-
>
>CEBA-2019:2605 CentOS 7 tuned BugFix Update
>
> 
>-
>
>CEBA-2019:2871 CentOS 7 tzdata BugFix Update
>
> 
>
> - latest CentOS Virt and Storage SIG updates:
>
>-
>
>Ansible 2.8.5:
>
> https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.8.rst#v2-8-5
>-
>
>Glusterfs 6.5: https://docs.gluster.org/en/latest/release-notes/6.5/
>-
>
>QEMU KVM EV 2.12.0-33.1 :
>https://cbs.centos.org/koji/buildinfo?buildID=26484
>
>
>
>
> Given the amount of security 

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Sandro Bonazzola]

Il giorno gio 26 set 2019 alle ore 17:11 Gianluca Cecchi <
gianluca.cec...@gmail.com> ha scritto:

> On Thu, Sep 26, 2019 at 5:02 PM Sandro Bonazzola 
> wrote:
>
>> The oVirt Project is pleased to announce the general availability of
>> oVirt 4.3.6 as of September 26th, 2019.
>>
>>
>>
>> This update is the sixth in a series of stabilization updates to the 4.3
>> series.
>>
>>
>>
>> This release is available now on x86_64 architecture for:
>>
>> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>>
>> * CentOS Linux (or similar) 7.7 or later (but < 8)
>>
>>
>>
>> This release supports Hypervisor Hosts on x86_64 and ppc64le
>> architectures for:
>>
>> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>>
>> * CentOS Linux (or similar) 7.7 or later (but < 8)
>>
>> * oVirt Node 4.3 (available for x86_64 only)
>>
>>
>>
>
> Does this mean that CentOS 7.6 is not supported any more starting from
> 4.3.6?
> Due to the fact that eg 4.3.5 was only supported on CentOS < 7.7 how
> should it be the correct flow of updating OS and oVirt versions in this
> case? Both for plain CentOS hosts and engine...
>

4.3.5 will work with CentOS 7.7 too.
https://lists.ovirt.org/archives/list/annou...@ovirt.org/thread/DJF37K7TQFTR346JPJ54YNLY5X6NY2EF/
says 7.6 or later but < 8



>
> Thanks,
>
> Gianluca
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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/GA3PGCYZ4DRXTLADML2Z6GLEFBFZ5RRI/

[ovirt-users] Re: [ANN] oVirt 4.3.6 is now generally available

[Gianluca Cecchi]

On Thu, Sep 26, 2019 at 5:02 PM Sandro Bonazzola 
wrote:

> The oVirt Project is pleased to announce the general availability of oVirt
> 4.3.6 as of September 26th, 2019.
>
>
>
> This update is the sixth in a series of stabilization updates to the 4.3
> series.
>
>
>
> This release is available now on x86_64 architecture for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
>
>
> This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
> for:
>
> * Red Hat Enterprise Linux 7.7 or later (but < 8)
>
> * CentOS Linux (or similar) 7.7 or later (but < 8)
>
> * oVirt Node 4.3 (available for x86_64 only)
>
>
>

Does this mean that CentOS 7.6 is not supported any more starting from
4.3.6?
Due to the fact that eg 4.3.5 was only supported on CentOS < 7.7 how should
it be the correct flow of updating OS and oVirt versions in this case? Both
for plain CentOS hosts and engine...

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/JD27PV2XI5T624RMJOXHSKR6ZWWFFAFR/