Error: Adding new Host to ovirt-engine
by Ahmad Khiet
Hi,
Can't add new host to ovirt engine, because the following error:
2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts :
Set facts] *************************************
2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => {
"ansible_facts": {
"ansible_python_interpreter": "/usr/bin/python2",
"host_deploy_vdsm_version": "4.40.0"
},
"changed": false
}
2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver
: Install ovs] *********************************
2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! =>
{}
MSG:
The conditional check 'cluster_switch == "ovs" or (ovn_central is defined
and ovn_central | ipaddr and ovn_engine_cluster_version is
version_compare('4.2', '>='))' failed. The error was: The ipaddr filter
requires python's netaddr be installed on the ansible controller
The error appears to be in
'/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml':
line 3, column 5, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- block:
- name: Install ovs
^ here
2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP
*********************************************************************
2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 :
ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0
ignored=0
whats missing!?
Thanks
--
Ahmad Khiet
Red Hat <https://www.redhat.com/>
akhiet(a)redhat.com
M: +972-54-6225629
<https://red.ht/sig>
1 year, 5 months
Merge rights changes in the oVirt Engine project
by Tal Nisan
Hi everyone,
As you probably know we are now in a mode in which we develop our next
zstream version on the master branch as opposed to how we worked before
where the master version was dedicated for the next major version. This
makes the rapid changes in master to be delivered to customers in a much
higher cadence thus affecting stability.
Due to that we think it's best that from now on merges in the master branch
will be done only by stable branch maintainers after inspecting those
closely.
What you need to do in order to get your patch merged:
- Have it pass Jenkins
- Have it get code review +2
- Have it mark verified +1
- It's always encourage to have it tested by OST, for bigger changes it's a
must
Once you have all those covered, please add me as a reviewer and I'll
examine it and merge if everything seems right, if I haven't done it in a
timely manner feel free to ping me.
3 years, 9 months
Error Java SDK Issue??
by Geschwentner, Patrick
Dear Ladies and Gentlemen!
I am currently working with the java-sdk and I encountered a problem.
If I would like to retrieve the disk details, I get the following error:
Disk currDisk = ovirtConnection.followLink(diskAttachment.disk());
The Error is occurring in this line:
[cid:image001.png@01D44537.AF127FD0]
The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok).
Error:
wrong number of arguments
The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/j... ).
Can you confirm the defect?
Best regards
Patrick
3 years, 9 months
CentOS Stream support
by Michal Skrivanek
Hi all,
we would like to ask about interest in community about oVirt moving to CentOS Stream.
There were some requests before but it’s hard to see how many people would really like to see that.
With CentOS releases lagging behind RHEL for months it’s interesting to consider moving to CentOS Stream as it is much more up to date and allows us to fix bugs faster, with less workarounds and overhead for maintaining old code. E.g. our current integration tests do not really pass on CentOS 8.1 and we can’t really do much about that other than wait for more up to date packages. It would also bring us closer to make oVirt run smoothly on RHEL as that is also much closer to Stream than it is to outdated CentOS.
So..would you like us to support CentOS Stream?
We don’t really have capacity to run 3 different platforms, would you still want oVirt to support CentOS Stream if it means “less support” for regular CentOS?
There are some concerns about Stream being a bit less stable, do you share those concerns?
Thank you for your comments,
michal
3 years, 11 months
Re: [ovirt-users] Re: [ANN] oVirt 4.4.4 is now generally available
by Benny Zlotnik
On Tue, Dec 22, 2020 at 6:33 PM Konstantin Shalygin <k0ste(a)k0ste.ru> wrote:
>
> Sandro, FYI we are not against cinderlib integration, more than we are upgrade 4.3 to 4.4 due movement to cinderlib.
>
> But (!) current Managed Storage Block realization support only krbd (kernel RBD) driver - it's also not a option, because kernel client is always lagging behind librbd, and every update\bugfix we should reboot whole host instead simple migration of all VMs and then migrate it back. Also with krbd host will be use kernel page cache, and will not be unmounted if VM will crash (qemu with librbd is one userland process).
>
There was rbd-nbd support at some point in cinderlib[1] which
addresses your concerns, but it was removed because of some issues
+Gorka, are there any plans to pick it up again?
[1] https://github.com/Akrog/cinderlib/commit/a09a7e12fe685d747ed390a59cd42d0...
> So for me current situation look like this:
>
> 1. We update deprecated OpenStack code? Why, Its for delete?.. Nevermind, just update this code...
>
> 2. Hmm... auth tests doesn't work, to pass test just disable any OpenStack project_id related things... and... Done...
>
> 3. I don't care how current cinder + qemu code works, just write new one for linux kernel, it's optimal to use userland apps, just add wrappers (no, it's not);
>
> 4. Current Cinder integration require zero configuration on oVirt hosts. It's lazy, why oVirt administrator do nothing? just write manual how-to install packages - oVirt administrators love anything except "reinstall" from engine (no, it's not);
>
> 5. We broke old code. New features is "Cinderlib is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production".
>
> 6. Oh, we broke old code. Let's deprecate them and close PRODUCTION issues (we didn't see anything).
>
>
> And again, we are not hate new cinderlib integration. We just want that new technology don't break all PRODUCTION clustes. Almost two years ago I write on this issue https://bugzilla.redhat.com/show_bug.cgi?id=1539837#c6 about "before deprecate, let's help to migrate". For now I see that oVirt totally will disable QEMU RBD support and want to use kernel RBD module + python os-brick + userland mappers + shell wrappers.
>
>
> Thanks, I hope I am writing this for a reason and it will help build bridges between the community and the developers. We have been with oVirt for almost 10 years and now it is a crossroads towards a different virtualization manager.
>
> k
>
>
> So I see only regressions for now, hope we'll found some code owner who can catch this oVirt 4.4 only bugs.
>
I looked at the bugs and I see you've already identified the problem
and have patches attached, if you can submit the patches and verify
them perhaps we can merge the fixes
3 years, 11 months
Issue: Device path changed after adding disks to guest VM
by Joy Li
Hi All,
I'm facing the problem that after adding disks to guest VM, the device
target path changed (My ovirt version is 4.3). For example:
Before adding a disk:
virsh # domblklist <vmname>
Target Source
---------------------------------------------------------
hdc -
vda /dev/mapper/3600a09803830386546244a546d494f53
vdb /dev/mapper/3600a09803830386546244a546d494f54
* vdc /dev/mapper/3600a09803830386546244a546d494f55*
vdd /dev/mapper/3600a09803830386546244a546d494f56
vde /dev/mapper/3600a09803830386546244a546d494f57
vdf /dev/mapper/3600a09803830386546244a546d494f58
After adding a disk, and then shutdown and start the VM:
virsh # domblklist <vmname>
Target Source
---------------------------------------------------------
hdc -
vda /dev/mapper/3600a09803830386546244a546d494f53
vdb /dev/mapper/3600a09803830386546244a546d494f54
*vdc /dev/mapper/3600a09803830386546244a546d494f6c*
* vdd /dev/mapper/3600a09803830386546244a546d494f55*
vde /dev/mapper/3600a09803830386546244a546d494f56
vdf /dev/mapper/3600a09803830386546244a546d494f57
vdg /dev/mapper/3600a09803830386546244a546d494f58
The devices' multipath doesn't map to the same target path as before, so in
my VM the /dev/vdc doesn't point to the old
/dev/mapper/3600a09803830386546244a546d494f55 anymore.
Anybody knows how can I make the device path mapping fixed without being
changed after adding or removing disks.
Many thanks in advance.
Joy
4 years
Vdsm: Small version numbering change?
by Milan Zamazal
Hi,
we have a nice coincidence now that Vdsm 4.40.40 corresponds to
ovirt-4.4.4 branch. Would we like to use this opportunity to make Vdsm
versions aligned with oVirt 4.4.* versions?
We can tag the next master build, which will be no longer part of
ovirt-4.4.4 branch, as v4.40.50. Or we could tag it as v4.40.500 to be
on the safe side, but both 4.4.3 and 4.4.4 had less than 10 tags on
master, so it's probably not needed and there is always v4.40.591-like
workaround available.
What do you think?
Regards,
Milan
4 years
