[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
4 years, 3 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
4 years, 3 months
oVirt 4.4: Self-hosted engine deployment fails with backup restore from 4.3 engine
by Oliver Leinfelder
Hi there,
I'm a bit puzzled about an possible upgrade paths from a 4.3 cluster to
version 4.4 in a self-hosted engine environment.
My idea was:
Set up a new host with a clean ovirt node 4.4 installation, then deploy the
hosted engine on this with a restored backup from the production cluster
and go from there.
This however fails with the following error:
2020-05-27 00:17:08,886+0200 DEBUG
otopi.ovirt_hosted_engine_setup.ansible_utils
ansible_utils._process_output:103 {'msg': 'non-zero return code', 'cmd':
['engine-setup', '--accept-defaults',
'--config-append=/root/ovirt-engine-answers'], 'stdout': "[ INFO ] Stage:
Initializing\n[ INFO ] Stage: Environment setup\n C
onfiguration files: /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf,
/etc/ovirt-engine-setup.conf.d/10-packaging.conf,
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf,
/root/ovirt-engine-answers\n Log file:
/var/log/ovirt-engine/setup/ovirt-engine-setup-20200527001657-fyeueu.log\n
Version: otop
i-1.9.1 (otopi-1.9.1-1.el8)\n[ INFO ] DNF Downloading 1 files, 0.00KB\n[
INFO ] DNF Downloaded CentOS-8 - AppStream\n[ INFO ] DNF Downloading 1
files, 0.00KB\n[ INFO ] DNF Downloaded CentOS-8 - Base\n[ INFO ] DNF
Downloading 1 files, 0.00KB\n
[...]
... anwsers from backup config follow ....
[...]
2020-05-27 00:17:12,396+0200 DEBUG otopi.context context._executeMethod:145
method exception
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
_executeMethod
method['method']()
File
"/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/misc.py",
line 403, in _closeup
r = ah.run()
File
"/usr/lib/python3.6/site-packages/ovirt_hosted_engine_setup/ansible_utils.py",
line 229, in run
raise RuntimeError(_('Failed executing ansible-playbook'))
Is this approach (restoring from 4.3) generally supposed to work? If not,
what is the appropriate upgrade path?
Thank you!
Regards
Oli
4 years, 3 months
Deploy hosted engine from backup fails
by JCampos
Command to execute backup:
#engine-backup --mode=backup --file=backup1 --log=backup1.log
Command to restore backup:
#hosted-engine --deploy --restore-from-file=backup1
Error:
2020-12-09 22:26:25,679+0000 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:107 fatal: [localhost]: FAILED! => {"changed": false, "msg": "Available memory ( {'failed': False, 'changed': False, 'ansible_facts': {u'max_mem': u'33211'}}MB ) is less then the minimal requirement (4096MB). Be aware that 512MB is reserved for the host and cannot be allocated to the engine VM."}
Ovirt version:
4.3.10.4-1.el7
# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
Memory available:
#free -m
total used free shared buff/cache available
Mem: 64132 30478 494 145 33158 32961
Swap: 16383 0 16383
Is there a way to ignore this check?
4 years, 3 months
Another illegal disk snapshot problem!
by Joseph Goldman
Hi List,
oVirt 4.3
I know there have been threads about this before - but I am unable to
find the exact scenario I am facing.
I have a VM with 3 snapshots - Active, and 2 dated ones (technically
created by vProtect)
After trying to do a fresh snapshot in the GUI it failed out and
marked one of the old snapshot disks as 'illegal' - then the other tried
to follow suit.
I tried 'unlocking' the entity using the unlock_entity.sh tool but any
action reverts them back to illegal.
Following previous advice - I can see the VDSM status is all showing
LEGAL:
image: 23710238-07c2-46f3-96c0-9061fe1c3e0d
- *c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1*
*status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type:
SPARSE, capacity: 107374182400, truesize: 18402942976**
*
- *a6d4533b-b0b0-475d-a436-26ce99a38d94**
** status: OK, voltype: INTERNAL, format: COW, legality:
LEGAL, type: SPARSE, capacity: 107374182400, truesize: 21521768448*
- 4b6f7ca1-b70d-4893-b473-d8d30138bb6b
status: OK, voltype: LEAF, format: COW, legality: LEGAL,
type: SPARSE, capacity: 107374182400, truesize: 12617457664
The 2 bold entries are the 'illegal' snapshots.
Looking in the DB see's:
select
image_guid,parentid
,imagestatus
,vm_snapshot_id
,volume_type
,volume_format
,active
from images
where image_group_id='23710238-07c2-46f3-96c0-9061fe1c3e0d';
image_guid | parentid |
imagestatus | vm_snapshot_id | volume_type | volume_format |
active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
4b6f7ca1-b70d-4893-b473-d8d30138bb6b |
a6d4533b-b0b0-475d-a436-26ce99a38d94 | 1 |
d5044ae5-dc48-4700-9e46-d61e676c73fc | 2 | 4 | t
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1 |
00000000-0000-0000-0000-000000000000 | 4 |
57337968-28da-4b03-ac40-134a347d8c11 | 2 | 5 | f
a6d4533b-b0b0-475d-a436-26ce99a38d94 |
c3dadf14-bb4e-45a7-8bee-b9a01fe29ae1 | 4 |
d2d82724-9fe7-452c-a114-f8d70b555520 | 2 | 4 | f
So from here previous advice has been to do things such as delete the
snapshot/disk etc but thats when they showed as illegal status. I also
notice the Active Image is not the same image that has a parentid of all
00000's so im not sure on the process of possibly deleting the other
snapshots and disks cleanly and/or safely.
Deleting or any tasks in the gui 100% fails and its at a point that if I
shut down the (critical) VM it will not come back on because of these
status'.
On top of this what is a good way to take a clean, manual backup of
current in use disk before I start playing with this in case worse comes
to worse I have to try build it as a new server (As at this point I
can't trust my vProtect backups)
Any help appreciated.
Thanks,
Joe
4 years, 3 months
ovirt 4.3 - locked image vm - unable to remove a failed deploy of a guest dom
by 3c.monitor@gruppofilippetti.it
Hi all.
I've deployed a VM from a corrupted template (it's disk is missing, but I've checked it later...).
My Software Version is:4.3
Now, I have an unmanaged VM in inventory and unable to remove it too.
It's reference is "locked image".
I've restarted ovirt-engine many times on self-hosted engine and hosts too, but no benefits.
So, what's now?
I've also consulted: https://access.redhat.com/solutions/396753
but still no results.
No tasks or items results to be "locked"...
Any other ideas?
Thanks a lot.
4 years, 3 months
Re: difference between CPU server and client family
by Vinícius Ferrão
AFAIK Client is for the i3/i5/i7/i9 families and the other one is for Xeon platforms.
But you have pretty unusually Xeon, so it may be missing some flags that will properly classify the CPU.
You can run this on the host to check what’s detected:
[root]# vdsm-client Host getCapabilities
Sent from my iPhone
On 8 Dec 2020, at 10:52, jb <jonbae77(a)gmail.com> wrote:
4 years, 3 months
Turkey Standart Time
by ozmen62@hotmail.com
Hi,
We've figured out there is no Turkish time zone on "Hardware Clock Time Offset" when we were trying sysprep
it causes some problems on GPO applyment, Outlook, Skype etc. connections in AD environment
Is there any cli options we can add this?
If you take this as an future request we'll appreciate
4 years, 3 months