[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2025

2024-10-28 Thread Piotr Kliczewski
We are excited to announce that the call for proposals is now open for the
Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM
2025, to be hosted on Sunday (Feb 2) 2025.

This devroom is a collaborative effort, and is organized by dedicated folks
from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and
Foreman. We invite everyone involved in these fields to submit your
proposals by December 8th, 2024.

About the Devroom

The Virtualization & IaaS devroom will feature session topics such as open
source hypervisors or virtual machine managers such as Xen Project, KVM,
bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such
as KubeVirt, Apache CloudStack, OpenStack, 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 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: 8th December 2024

Acceptance notifications: 10th December 2024

Final schedule announcement: 15th December 2024

Devroom: 2nd February 2025

Submit Your Proposal

All submissions must be made via the Pretalx event planning site[1]. It is
a new submission system so you will need to create an account. If you
submitted proposals for FOSDEM in previous years, you won’t be able to use
your existing account.

During submission please make sure to select Virtualization and Cloud
infrastructure from the Track list. Please 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 be recorded 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,

."

In the Submission notes field, please also confirm that if your talk is
accepted, you will be able to attend FOSDEM and deliver your presentation.
We will not consider proposals from prospective speakers who are unsure
whether they will be able to secure funds for travel and lodging to attend
FOSDEM. (Sadly, we are not able to offer travel funding for prospective
speakers.)

Code of Conduct

Following the release of the updated code of conduct for FOSDEM[3], 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.

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://pretalx.fosdem.org/fosdem-2025/cfp

[2] virtualization-devroom-manager at fosdem.org

[3] https://fosdem.org/2025/practical/conduct/


Re: reconfiguring a two vms bridge to two vms + the host with proper iface naming

2024-10-28 Thread Laine Stump

On 10/24/24 12:47 PM, daggs via Users wrote:




Sent: Thursday, October 24, 2024 at 7:43 PM
From: "Daniel P. Berrangé" 
To: "daggs" 
Cc: users@lists.libvirt.org
Subject: Re: reconfiguring a two vms bridge to  two vms + the host with proper 
iface naming

On Thu, Oct 24, 2024 at 06:18:26PM +0200, daggs via Users wrote:

Greetings,

I have two vms (vm1 and vm2) connected via a bridge named br1.
libvirt creates two taps, tap0 and tap1

I'm trying to rename them to some thing more meaningful for starts.
I assume that I cannot use vnet-vm1 or vnet-vm2 so I decided to configure it 
like this:
vm1:
   
 
 
   

vm2:
   
 
 
   

but when start the vms, the iface names are still tap1 and tap2. am I doing 
something wrong?


I didn't think libvirt created devices with 'tapXXX' naming,


The one place this isn't true is for guests started with unprivileged 
libvirt; it uses the qemu-bridge-helper to create the tap device and 
connect it to the bridge, and uses names of the form "tapX". So I'm 
fairly certain that daggs is running the guests as a normal user, not as 
root.



all our
generated names should be 'vnetXXX', and we reserve 'vnet' as a prefix
for our own use and will thus discard any such name if the user specifies
it in the XML.


Beyond that, when running guests in non-privileged mode, libvirt has no 
control over the tap device name under any vircumstances, and so the 
target dev name would be ignored no matter what it was. In the end this 
all means that you can't control what name the tap devices have (and it 
shouldn't matter other than cosmetic)



As for connecting the bridge device to the *host's* IP stack (which I 
*think* you alluded to in the subject line), that must be done outside 
of libvirt in the host's network config, essentially just move the IP 
configuration from the physical ethernet you want attached to the 
bridge, over to the bridge itself (removing it from the physical device).





With regards,
Daniel

this is my output:
utils-server:~# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
 link/ether 52:54:00:ab:30:dc brd ff:ff:ff:ff:ff:ff
8: br1:  mtu 1500 qdisc noqueue state UP group 
default qlen 1000
 link/ether 52:54:00:6b:1b:92 brd ff:ff:ff:ff:ff:ff
10: tap0:  mtu 1500 qdisc pfifo_fast master 
br1 state UNKNOWN group default qlen 1000
 link/ether fe:7f:ea:04:9d:97 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::fc7f:eaff:fe04:9d97/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
11: tap1:  mtu 1500 qdisc pfifo_fast master 
br1 state UNKNOWN group default qlen 1000
 link/ether fe:47:d8:75:ce:ee brd ff:ff:ff:ff:ff:ff
 inet6 fe80::fc47:d8ff:fe75:ceee/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever




--
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|