[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 http-parser

[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 subscript

[ovirt-users] Re: Ovirt 4.2.7 won't start and drops to emergency console

[Strahil]

You can view all LVs via 'lvs -a' and create a new metadata LV of bigger size.
Of course ,  lvdisplay -m /dev/gluster_vg1-lvthinpool-tpool_tmeta  shoould also 
 work.

Best Regards,
Strahil NikolovOn Oct 1, 2019 03:11, jeremy_tourvi...@hotmail.com wrote:
>
> vgs displays everything EXCEPT gluster_vg1 
> "dmsetup ls" does not list the VG in question.  That is why I couldn't run 
> the lvchange command.  They were not active or even detected by the system. 
>
> OK, I found my problem, and a solution: 
> https://access.redhat.com/solutions/3251681 
> # cd /var/log 
> # grep -ri gluster_vg1-lvthinpool-tpool 
> My metadata is 100% full !!! 
>
> Now, how do I find out how big my original metadata size was so I can make 
> the new one the correct size?
> ___
> 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/6PI2N24GVWL64UHVZ3BWF3KTJBRL2ALU/
___
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/U5EQGBF6ZH6V6WXNZQSOJ326ZSGDNFF4/

[ovirt-users] Re: Ovirt 4.2.7 won't start and drops to emergency console

[jeremy_tourville]

vgs displays everything EXCEPT gluster_vg1
"dmsetup ls" does not list the VG in question.  That is why I couldn't run the 
lvchange command.  They were not active or even detected by the system.

OK, I found my problem, and a solution: 
https://access.redhat.com/solutions/3251681
# cd /var/log
# grep -ri gluster_vg1-lvthinpool-tpool
My metadata is 100% full !!! 

Now, how do I find out how big my original metadata size was so I can make the 
new one the correct size?
___
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/6PI2N24GVWL64UHVZ3BWF3KTJBRL2ALU/

[ovirt-users] Re: change connection string in db

[Strahil]

I think that there is a special file on the shared storage (something  like 
OVA) that stores the necessary data.

Have you tried with:
hosted-engine --set-shared-config storage :/engine

hosted-engine --set-shared-config mnt_options
backup-volfile-servers=:

Best Regards,
Strahil NikolovOn Sep 30, 2019 19:14, olaf.buitel...@gmail.com wrote: > > Dear 
oVirt users, > > one thing i still cannot find out, is where the engine gathers 
the storage= value from in the /etc/ovirt-hosted-engine/hosted-engine.conf > I 
suppose it's somewhere in a answers file, but i cannot find it. > Any points 
are appreciated. hopfully this is the last place where the old connection 
string lives. > > Thanks Olaf > ___ 
> 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/GPPKRN5YLUMEJR5JV2IXFFXN73VZFGO3/___
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/AYLBM2AS2KI3PMV3M3RV323WAIK6M5XK/

[ovirt-users] Re: How should ovirt-engine be repaired if it is hung up

[Strahil]

1. Open VNC console and check the situation. Just like any other  VM.
2.  You can get the config  via checking the vdsm log on the host where the 
system has started properly last time  (as  current situation is bad, check 
previous  power up event).
You can save the xml and use that to define the VM in virsh, but you also need 
to define ovirtmgmt network -> check in the web , as I don't have access  to my 
systems right now.
If virsh complaints about the disks -  check that the storage domains'  link  
is properly set to your storage.

Best Regards,
Strahil NikolovOn Sep 30, 2019 05:49, wangyu13476969...@126.com wrote:
>
> 1. How should ovirt-engine be repaired if it is hung up? 
> 2. How do I export the ovirt-engine configuration file?
> ___
> 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/XNY4GUISXGCDY3WK7YXRGC2YDUHLUCXO/
___
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/BDGOB33S2Z4S5HQWHPWLKWB5X7FFCF4W/

[ovirt-users] Re: Ovirt 4.2.7 won't start and drops to emergency console

[Strahil]

What happens when it complain that there  is no VGs ?
When you run 'vgs' what is the output?

Also, take a  look into  
https://www.redhat.com/archives/linux-lvm/2016-February/msg00012.html

I have the feeling that you need to disable all lvs - not only the thin pool, 
but also the thin LVs (first).

Best Regards,
Strahil NikolovOn Sep 29, 2019 23:00, jeremy_tourvi...@hotmail.com wrote:
>
> Yes, I can take the downtime.  Actually, I don't have any choice at the 
> moment because it is a single node setup. :)  I think this is a distributed 
> volume from the research I have performed.  I posted the lvchange command in 
> my last post, this was the result-  I ran the command lvchange -an 
> /dev/gluster_vg1/lv_datadisks When I do this I get the message "Volume group 
> "gluster_vg1" not found. Cannot process volume group gluster_vg1".  I also 
> tried the command the way you specified with just the LV and get the same 
> results. 
>
> I had placed the system in Global maintenance mode prior to the reboot.  Upon 
> reboot I got the messages about the various gluster volumes not being able to 
> be mounted because of timeout issues.  That is what started my OP.  I think 
> we are both thinking along the same lines regarding the issue.  I think the 
> question is how do you  fix a volume that the system won't mount?  It does 
> seem likely that the thinpool needs to be repaired but what do you do if you 
> can't even perform the first step in the procedure?  
>
> ___
> 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/2X73CAASB4UCOK6Y25EBMGQBZBKKG7JV/
___
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/4C7BUN2XVBAL6CRTBYIZCXDBO2LVULYZ/

[ovirt-users] Re: change connection string in db

[olaf . buitelaar]

Dear oVirt users,

one thing i still cannot find out, is where the engine gathers the storage= 
value from in the /etc/ovirt-hosted-engine/hosted-engine.conf
I suppose it's somewhere in a answers file, but i cannot find it.
Any points are appreciated. hopfully this is the last place where the old 
connection string lives.

Thanks Olaf
___
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/GPPKRN5YLUMEJR5JV2IXFFXN73VZFGO3/

[ovirt-users] oVirt Software after upgrade

[Rick A]

I'm wondering why after upgrading our hosts, when viewing the host details, 
it's still showing the OS Description as 4.3.3.1. We are using the oVirt Node. 
Shouldn't the OS Description show the version we just upgraded to? I do the 
upgrade using the web UI.

Thanks


OS Version: RHEL - 7 - 6.1810.2.el7.centos
OS Description: oVirt Node 4.3.3.1   
<--
Kernel Version: 3.10.0 - 957.10.1.el7.x86_64
KVM Version: 2.12.0 - 18.el7_6.3.1
LIBVIRT Version: libvirt-4.5.0-10.el7_6.6
VDSM Version: vdsm-4.30.13-1.el7
SPICE Version: 0.14.0 - 6.el7_6.1
GlusterFS Version: glusterfs-5.5-1.el7
CEPH Version: librbd1-10.2.5-4.el7
Open vSwitch Version: openvswitch-2.10.1-3.el7
Kernel Features: PTI: 1, IBRS: 1, RETP: 0, SSBD: 3
VNC Encryption: Disabled
___
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/KFXXQE7M67FWFVG7C2KWF6WU4FRVTM6X/

[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&D 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:

_SHA_CKSUM=9d

[ovirt-users] Re: How should ovirt-engine be repaired if it is hung up

[wangyu13476969128]

Thanks very much ! 
___
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/GLNHVJRSXU7H2K52BAKS3PLVIU4JVBMJ/