[ovirt-devel] [vdsm] s390 draft patches submitted for review

Michal Skrivanek michal.skrivanek at redhat.com
Wed Sep 20 20:04:25 UTC 2017


> On 20 Sep 2017, at 16:12, Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> wrote:
> 
> On 20.09.2017 15:40, Michal Skrivanek wrote:
>> 
>>> On 19 Sep 2017, at 14:08, Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> wrote:
>>> 
>>> On 18.09.2017 17:52, Juan Hernández wrote:
>>>> On 09/18/2017 05:31 PM, Viktor Mihajlovski wrote:
>>>>> Hi,
>>>>> 
>>>>> I have submitted a topic branch containing the changes necessary to
>>>>> enable support for the s390 arch in VDSM and would appreciate your
>>>>> feedback, not only for the code, but also on the procedure:
>>>>> 
>>>>> 1. I've submitted the patches as draft, following the suggestions on the
>>>>> homepage. Not sure whether this is really required.
>>>>> 
>>>>> 2. The individual commits are actually tiny, let me know whether this is
>>>>> OK, or you prefer a single commit.
>>>>> 
>>>>> 3. Topic branch here: https://gerrit.ovirt.org/#/q/topic:s390-base
>>>>> 
>>>> 
>>>> Note that draft changes are generally OK, but they have the inconvenient
>>>> that they are invisible for people that isn't explicitly added as
>>>> reviewers. So you will need to either promote them to regular patches,
>>>> maybe adding a [WIP] prefix to the subject, or else explicitly add
>>>> reviewers, otherwise nobody will see them.
>>>> 
>>> Thanks for the clarification, I have done as you suggested. Looking
>>> forward for comments.
>> 
>> Hi Viktor,
>> thank you for the contribution! It looks good so far, some of the patches are already in a good shape, feel free to remove the WIP prefix.
>> Size of the patches is also quite matching the typical scope of each patch, at least for vdsm.
>> 
>> Do you intend to work on ovirt-engine component as well? If yes then it would be great if you share the areas which you expect will need to change, or perhaps some other higher level overview of what kind of changes in general are required in oVirt to have a complete s390 support
> Hi Michal,
> 
> thanks for the feedback. I'll have to clean up the vdsm/libvirt stuff
> first. There's still an issue with NUMA on s390 I have to solve…

sure, it’s the one to start with. Are other system dependencies (qemu, libvirt, other)?
> 
> Once I'm done with vdsm, I'll provide patches for ovirt-engine. As a

that’s great!

> prerequisite for that I need to update ovirt-engine-api-model (new
> architecture and a new watchdog device type).

regarding watchdog…we have an overdue plan/intent to use pvpanic instead of watchdog devices. They are not widely used anyway. So I wonder if there are plans to support pvpanic on s390 at the qemu/libvirt level and (separately) whether a watchdog is an important item for s390 users

> Most of the changes have to do with the s390 cpu type handling, nothing
> really fancy.
> 
> Maybe a side discussion: I use ovirt-host-deploy to turn a Fedora
> installation into a hypervisor. This worked (with minor changes) well
> for Fedora 25, but fails for Fedora 26. This is because F26 uses DNF
> version 3 whereas the otopi/python dnf plugin refuses to work with DNF
> != 1. Has anyone been hit by that before, and if so, any plans to fix that?

yeah, unfortunately we are a bit behind on moving to new dnf and due to qemu and libvirt features we are forced to move out of F25 to F26….which is not ideal - F25 is no longer enough to run, but you can’t really deploy ovirt on F26. A fix is not expected to happen for some time and I’m afraid for the timebeing you’d need to work around that manually, perhaps deploying on F25 and then upgrading to F26 would work. 
We’re mostly focusing on EL platform, it may also make sense to work on top of EL 7.4 with custom QEMU/libvirt (I’m assuming you do need some bleeding edge changes there)

Thanks,
michal

> [...]
> -- 
> 
> Mit freundlichen Grüßen/Kind Regards
>   Viktor Mihajlovski

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170920/9f2d0830/attachment-0001.html>


More information about the Devel mailing list