pgrade 4.3 to 4.4 with migration CentOS7 to CentOS8.3
by Ilya Fedotov
Good day,
Encountered such a problem when migrating to ovirt 4.4
At
hosted-engine --deploy --restore-from-file=backup.bck
Getting, error below
Upgrading engine extension configuration:
/etc/ovirt-engine/extensions.d/xx-xxxx.properties", "[ INFO ] Upgrading
CA", "[ INFO ]
Creating CA: /etc/pki/ovirt-engine/qemu-ca.pem", "[ ERROR ] Failed to
execute stage 'Misc configuration': [Errno 17]
File exists: '/etc/pki/ovirt-engine/ca.pem' ->
'/etc/pki/ovirt-engine/apache-ca.pem'", "[ INFO ]
DNF Performing DNF transaction rollback", "[ INFO ] Stage: Clean up",
At setting of initial parameters I select "No" parameter in para
'Renew engine CA on restore if needed? Please notice ' 'that if you choose
Yes, all hosts will have to be ' 'later manually reinstalled from the
engine. ' '(@VALUES@)[@DEFAULT@]
Dosnt need to renew the .ca certificate, thats upgrade and dosnt need to
re-make connections with nodes!
Even with this item, he still tries to create a new certificate.
I found a similar question here:
https://www.mail-archive.com/users@ovirt.org/msg61114.html
Package Data:
ovirt-hosted-engine-setup-2.4.8-1.el8.noarch
ovirt-hosted-engine-ha-2.4.5-1.el8.noarch
ovirt-engine-appliance-4.4-20201110154142.1.el8.x86_64
CentOS Linux release 8.3.2011
4.18.0-240.1.1.el8_3.x86_64
Pls, help programmers.....
with br, Ilya Fedotov
3 years, 11 months
hosted engine wrong bios
by Michael Rohweder
Hi,
i run with ovirt node 4.4.2 in some old mistake.
I changed cluster default to uefi weeks ago.
now today node must be restarted, and now i cannot work.
manager VM try to boot on uefi. and all other vm are down, because i cannot
start anny with cli.
how can i change (some config, file or something els) that setting in this
vm to normal bios?
Greetings
Michael
3 years, 11 months
Hosted engine deployment w/ two networks (one migration, one management).
by Gilboa Davara
Hello all,
I'm slowly building a new ovirt over glusterfs cluster with 3 fairly beefy
servers.
Each of the nodes has the following network configuration:
3x1GbE: ILO, ovirtmgmt and SSH.
4x10GbE: Private and external VM network(s).
2x40GBE: GlusterFS and VM migration.
Now, for some odd reasons, I rather keep the two 40GbE networks
disconnected from my normal management network.
My question is simple: I remember that I can somehow configure ovirt to use
two different networks for for management / migration, but as far as I can
see, I cannot configure the cluster to use a different network for
migration purposes.
1. Am I missing something?
2. Can I somehow configure the hosted engine to have an IP in more than
network (management and migration)?
3. More of a gluster question: As the 40GbE NICs and 1GbE NIC sitting on
different switches, can I somehow configure gluster to fallback to the 1GbE
NIC if the main 40GbE link fails? AFAIR bond doesn't support asymmetrical
network device configuration. (And rightly so, in this case).
Thanks,
Gilboa
3 years, 11 months
VMs shut down after backup: "moved from 'Up' --> 'Down'" on RHEL host
by Łukasz Kołaciński
Hello,
Thank you for helping with previous issue. Unfortunately we got another. We have RHV manager with several different hosts. After the backup, vm placed on RHEL shuts down. In engine.log I found moment when this happen: "VM '35183baa-1c70-4016-b7cd-528889876f19'(stor2rrd) moved from 'Up' --> 'Down'". I attached whole logs to email. It doesn't matter if it's a full or incremental, results are always the same. RHVH hosts works properly.
Log fragment:
2020-12-08 10:18:33,845+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-76) [60da31e3-92f6-4555-8c43-2f8afee272e0] Updating image transfer 87bdb42e-e64c-460d-97ac-218e923336a1 (image e57e4af0-5d0b-4f60-9e6c-e217c666e5e6) phase to Finalizing Success
2020-12-08 10:18:33,940+01 INFO [org.ovirt.engine.core.bll.StopVmBackupCommand] (default task-76) [89ec1a77-4b46-42b0-9d0f-15e53d5f952a] Running command: StopVmBackupCommand internal: false. Entities affected : ID: 35183baa-1c70-4016-b7cd-528889876f19 Type: VMAction group BACKUP_DISK with role type ADMIN, ID: e57e4af0-5d0b-4f60-9e6c-e217c666e5e6 Type: DiskAction group BACKUP_DISK with role type ADMIN
2020-12-08 10:18:33,940+01 INFO [org.ovirt.engine.core.bll.StopVmBackupCommand] (default task-76) [89ec1a77-4b46-42b0-9d0f-15e53d5f952a] Stopping VmBackup 'aae03819-cea6-45a1-9ee5-0f831af8464d'
2020-12-08 10:18:33,952+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.StopVmBackupVDSCommand] (default task-76) [89ec1a77-4b46-42b0-9d0f-15e53d5f952a] START, StopVmBackupVDSCommand(HostName = rhv-2, VmBackupVDSParameters:{hostId='afad6b8b-78a6-4e9a-a9bd-783ad42a2d47', backupId='aae03819-cea6-45a1-9ee5-0f831af8464d'}), log id: 78b2c27a
2020-12-08 10:18:33,958+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.StopVmBackupVDSCommand] (default task-76) [89ec1a77-4b46-42b0-9d0f-15e53d5f952a] FINISH, StopVmBackupVDSCommand, return: , log id: 78b2c27a
2020-12-08 10:18:33,975+01 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-76) [89ec1a77-4b46-42b0-9d0f-15e53d5f952a] EVENT_ID: VM_BACKUP_FINALIZED(10,794), Backup <UNKNOWN> for VM stor2rrd finalized (User: admin@internal-authz).
2020-12-08 10:18:35,221+01 INFO [org.ovirt.engine.core.sso.servlets.OAuthRevokeServlet] (default task-73) [] User admin@internal successfully logged out
2020-12-08 10:18:35,236+01 INFO [org.ovirt.engine.core.bll.aaa.TerminateSessionsForTokenCommand] (default task-81) [1b35276c] Running command: TerminateSessionsForTokenCommand internal: true.
2020-12-08 10:18:35,236+01 INFO [org.ovirt.engine.core.bll.aaa.SessionDataContainer] (default task-81) [1b35276c] Not removing session '90TxdK0PBueLijy+sCrFoHC/KNUGNzNpZuYMK/yKDAkbAefFr+8wOJsATsDKv18LxpyxCl+eX7hTHNxN23anAw==', session has running commands for user 'admin@internal-authz'.
2020-12-08 10:18:35,447+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-31) [] VM '35183baa-1c70-4016-b7cd-528889876f19' was reported as Down on VDS 'afad6b8b-78a6-4e9a-a9bd-783ad42a2d47'(rhv-2)
2020-12-08 10:18:35,448+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-31) [] START, DestroyVDSCommand(HostName = rhv-2, DestroyVmVDSCommandParameters:{hostId='afad6b8b-78a6-4e9a-a9bd-783ad42a2d47', vmId='35183baa-1c70-4016-b7cd-528889876f19', secondsToWait='0', gracefully='false', reason='', ignoreNoVm='true'}), log id: 4f473135
2020-12-08 10:18:35,451+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-31) [] FINISH, DestroyVDSCommand, return: , log id: 4f473135
2020-12-08 10:18:35,451+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-31) [] VM '35183baa-1c70-4016-b7cd-528889876f19'(stor2rrd) moved from 'Up' --> 'Down'
2020-12-08 10:18:35,466+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-31) [] EVENT_ID: VM_DOWN_ERROR(119), VM stor2rrd is down with error. Exit message: Lost connection with qemu process.
2020-12-08 10:18:35,484+01 INFO [org.ovirt.engine.core.bll.ProcessDownVmCommand] (EE-ManagedThreadFactory-engine-Thread-34085) [3da40159] Running command: ProcessDownVmCommand internal: true.
The environment of faulty host is:
OS Version: RHEL - 8.3 - 1.0.el8
OS Description: Red Hat Enterprise Linux 8.3 (Ootpa)
Kernel Version: 4.18.0 - 240.1.1.el8_3.x86_64
KVM Version: 5.1.0 - 14.module+el8.3.0+8438+644aff69
LIBVIRT Version: libvirt-6.6.0-7.module+el8.3.0+8424+5ea525c5
VDSM Version: vdsm-4.40.26.3-1.el8ev
SPICE Version: 0.14.3 - 3.el8
GlusterFS Version: [N/A]
CEPH Version: librbd1-12.2.7-9.el8
Open vSwitch Version: openvswitch-2.11-7.el8ev
Nmstate Version: nmstate-0.3.4-13.el8_3
Regards
Łukasz Kołaciński
Junior Java Developer
e-mail: l.kolacinski(a)storware.eu<mailto:l.kolacinski@storware.eu>
<mailto:m.helbert@storware.eu>
[STORWARE]<http://www.storware.eu/>
ul. Leszno 8/44
01-192 Warszawa
www.storware.eu <https://www.storware.eu/>
[facebook]<https://www.facebook.com/storware>
[twitter]<https://twitter.com/storware>
[linkedin]<https://www.linkedin.com/company/storware>
[Storware_Stopka_09]<https://www.youtube.com/channel/UCKvLitYPyAplBctXibFWrkw>
Storware Spółka z o.o. nr wpisu do ewidencji KRS dla M.St. Warszawa 000510131 , NIP 5213672602. Wiadomość ta jest przeznaczona jedynie dla osoby lub podmiotu, który jest jej adresatem i może zawierać poufne i/lub uprzywilejowane informacje. Zakazane jest jakiekolwiek przeglądanie, przesyłanie, rozpowszechnianie lub inne wykorzystanie tych informacji lub podjęcie jakichkolwiek działań odnośnie tych informacji przez osoby lub podmioty inne niż zamierzony adresat. Jeżeli Państwo otrzymali przez pomyłkę tę informację prosimy o poinformowanie o tym nadawcy i usunięcie tej wiadomości z wszelkich komputerów. This message is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you have received this message in error, please contact the sender and remove the material from all of your computer systems.
3 years, 11 months
oVirt and RHEV
by tommy
1、 If oVirt can be used to manage RHEV ?
2、 What relation between oVirt and RHEV?
Thanks!
3 years, 11 months
OPNsense / FreeBSD 12.1
by Jorge Visentini
Hi all.
I tried to install OPNsense 20.7.6 (FreeBSD 12.1) and it was not possible
to detect the NICs.
I tried both the virtio driver and the e1000. Virtio does not detect and
e1000 crashes at startup.
In pure KVM, it works, so I believe there is some incompatibility with
oVirt 4.4.4.
Any tips?
--
Att,
Jorge Visentini
+55 55 98432-9868
3 years, 11 months
Recent news & oVirt future
by Charles Kozler
I guess this is probably a question for all current open source projects
that red hat runs but -
Does this mean oVirt will effectively become a rolling release type
situation as well?
How exactly is oVirt going to stay open source and stay in cadence with all
the other updates happening around it on packages/etc that it depends on if
the streams are rolling release? Do they now need to fork every piece of
dependency?
What exactly does this mean for oVirt going forward and its overall
stability?
--
*Notice to Recipient*: https://www.fixflyer.com/disclaimer
<https://www.fixflyer.com/disclaimer>
3 years, 11 months
[CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski
We are excited to announce that the call for proposals is now open for the
Virtualization & IaaS devroom at the upcoming FOSDEM 2021, to be hosted
virtually on February 6th 2021.
This year will mark FOSDEM’s 21th anniversary as one of the longest-running
free and open source software developer events, attracting thousands of
developers and users from all over the world. Due to Covid-19, FOSDEM will
be held virtually this year on February 6th & 7th, 2021.
About the Devroom
The Virtualization & IaaS devroom will feature session topics such as open
source hypervisors and virtual machine managers such as Xen Project, KVM,
bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as
KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula.
This devroom will host presentations that focus on topics of shared
interest, such as KVM; libvirt; shared storage; virtualized networking;
cloud security; clustering and high availability; interfacing with multiple
hypervisors; hyperconverged deployments; and scaling across hundreds or
thousands of servers.
Presentations in this devroom will be aimed at users or developers working
on these platforms who are looking to collaborate and improve shared
infrastructure or solve common problems. We seek topics that encourage
dialog between projects and continued work post-FOSDEM.
Important Dates
Submission deadline: 20th of December
Acceptance notifications: 25th of December
Final schedule announcement: 31st of December
Recorded presentations upload deadline: 15th of January
Devroom: 6th February 2021
Submit Your Proposal
All submissions must be made via the Pentabarf event planning site[1]. If
you have not used Pentabarf before, you will need to create an account. If
you submitted proposals for FOSDEM in previous years, you can use your
existing account.
After creating the account, select Create Event to start the submission
process. Make sure to select Virtualization and IaaS devroom from the Track
list. Please fill out all the required fields, and provide a meaningful
abstract and description of your proposed session.
Submission Guidelines
We expect more proposals than we can possibly accept, so it is vitally
important that you submit your proposal on or before the deadline. Late
submissions are unlikely to be considered.
All presentation slots are 30 minutes, with 20 minutes planned for
presentations, and 10 minutes for Q&A.
All presentations will need to be pre-recorded and put into our system at
least a couple of weeks before the event.
The presentations should be uploaded by 15th of January and made available
under Creative
Commons licenses. In the Submission notes field, please indicate that you
agree that your presentation will be licensed under the CC-By-SA-4.0 or
CC-By-4.0 license and that you agree to have your presentation recorded.
For example:
"If my presentation is accepted for FOSDEM, I hereby agree to license all
recordings, slides, and other associated materials under the Creative
Commons Attribution Share-Alike 4.0 International License. Sincerely,
<NAME>."
In the Submission notes field, please also confirm that if your talk is
accepted, you will be able to attend the virtual FOSDEM event for the Q&A.
We will not consider proposals from prospective speakers who are unsure
whether they will be able to attend the FOSDEM virtual event.
If you are experiencing problems with Pentabarf, the proposal submission
interface, or have other questions, you can email our devroom mailing
list[2] and we will try to help you.
Code of Conduct
Following the release of the updated code of conduct for FOSDEM, we'd like
to remind all speakers and attendees that all of the presentations and
discussions in our devroom are held under the guidelines set in the CoC and
we expect attendees, speakers, and volunteers to follow the CoC at all
times.
If you submit a proposal and it is accepted, you will be required to
confirm that you accept the FOSDEM CoC. If you have any questions about the
CoC or wish to have one of the devroom organizers review your presentation
slides or any other content for CoC compliance, please email us and we will
do our best to assist you.
Call for Volunteers
We are also looking for volunteers to help run the devroom. We need
assistance with helping speakers to record the presentation as well as
helping with streaming and chat moderation for the devroom. Please contact
devroom mailing list [2] for more information.
Questions?
If you have any questions about this devroom, please send your questions to
our devroom mailing list. You can also subscribe to the list to receive
updates about important dates, session announcements, and to connect with
other attendees.
See you all at FOSDEM!
[1] <https://penta.fosdem.org/submission/FOSDEM17>https://penta.fosdem
.org/submission/FOSDEM21
[2] iaas-virt-devroom at lists.fosdem.org
3 years, 11 months
Nodes in CentOS 8.3 and oVirt 4.4.3.12-1.el8 but not able to update cluster version
by Gianluca Cecchi
Hello,
my engine is 4.4.3.12-1.el8 and my 3 oVirt nodes (based on plain CentOS due
to megaraid_sas kernel module needed) have been updated, bringing them to
CentOS 8.3.
But if I try to put cluster into 4.5 I get the error:
"
Error while executing action: Cannot change Cluster Compatibility Version
to higher version when there are active Hosts with lower version.
-Please move Host ov300, ov301, ov200 with lower version to maintenance
first.
"
Do I have to wait until final 4.4.4 or what is the problem?
Does 4.5 gives anything more apart the second number... (joking..)?
On nodes:
Software
OS Version: RHEL - 8.3 - 1.2011.el8
OS Description: CentOS Linux 8
Kernel Version: 4.18.0 - 240.1.1.el8_3.x86_64
KVM Version: 4.2.0 - 34.module_el8.3.0+555+a55c8938
LIBVIRT Version: libvirt-6.0.0-28.module_el8.3.0+555+a55c8938
VDSM Version: vdsm-4.40.35.1-1.el8
SPICE Version: 0.14.3 - 3.el8
GlusterFS Version: [N/A]
CEPH Version: librbd1-12.2.7-9.el8
Open vSwitch Version: [N/A]
Nmstate Version: nmstate-0.3.6-2.el8
Kernel Features: MDS: (Vulnerable: Clear CPU buffers attempted, no
microcode; SMT vulnerable), L1TF: (Mitigation: PTE Inversion; VMX:
conditional cache flushes, SMT vulnerable), SRBDS: (Not affected),
MELTDOWN: (Mitigation: PTI), SPECTRE_V1: (Mitigation: usercopy/swapgs
barriers and __user pointer sanitization), SPECTRE_V2: (Mitigation: Full
generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB
filling), ITLB_MULTIHIT: (KVM: Mitigation: Split huge pages),
TSX_ASYNC_ABORT: (Not affected), SPEC_STORE_BYPASS: (Mitigation:
Speculative Store Bypass disabled via prctl and seccomp)
VNC Encryption: Disabled
FIPS mode enabled: Disabled
Gianluca
3 years, 11 months
