Implement QEMU Firmware Config device support in Linuxrc/AutoYaST
a project by dmacvicar
Updated over 6 years ago. 3 hacker ♥️.

While normally data is passed to linuxrc (including an AutoYaST profile), modern auto-install tools like Ignition from CoreOS support a very interesting method: the QEMU Firmware Config device.

This allows to read from inside the VM a blob by reading /sys/firmware/qemu_fw_cfg/by_name/opt/keyname. The driver is included in recent Linux kernels.

In order to populate the key, one pass the data via the qemu command line: -fw_cfg name=opt/keyname,file=somedata.txt

This would allow to pass an AutoYaST profile directly if running qemu where the profile is located, and for libvirt or the terraform libvirt provider, the volume where the profile is uploaded before passed does not need to be attached to the machine.

The idea is to implement this in Linuxrc by:

  • url_read_file_anywhere()
  • Also check user-defined schemes, like /scripts/url/hmc
  • Choose a good URL scheme like the ones already available for AutoYaST](https://doc.opensuse.org/projects/autoyast/#Commandline.ay), eg: qemu://key
  • Allow to specify autoyast=qemu://key, or just look by default in a key like opt/suse/autoinst/raw
  • Take care of loading the module and including it in linuxrc.

This project is related to "Implement kernel cmdline and/or autoyast/kickstart support in terraform-provider-libvirt ".

Outcome

Join this project

Looking for hackers with the skills:

autoyast yast linuxrc terraform

This project is part of:

Hack Week 16

Activity

  • about 8 years ago: dmacvicar joined this project.
  • about 8 years ago: mbrugger liked this project.
  • about 8 years ago: michalnowak liked this project.
  • about 8 years ago: hsehic liked this project.
  • about 8 years ago: hsehic started this project.
  • about 8 years ago: dmacvicar added keyword "autoyast" to this project.
  • about 8 years ago: dmacvicar added keyword "yast" to this project.
  • about 8 years ago: dmacvicar added keyword "linuxrc" to this project.
  • about 8 years ago: dmacvicar added keyword "terraform" to this project.
  • about 8 years ago: dmacvicar originated this project.


    • Comments

    • snwint
      about 8 years ago by snwint | Reply

      The qemu driver is actually already in TW. Here's a proof-of-concept implementation:

      https://github.com/openSUSE/installation-images/pull/211

      Notes: - it's actually not trivial to make it nicer (without the by_name and raw) - it would require to go to a direct linuxrc implementation - those user defined url schemes already work in sle12(-sp3, at least) - to create a test iso, use mksusecd

    Similar Projects

    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as root FS.

    Why ZFS

    Ways in which ZFS is better than BTRFS

    Main goal

    Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install

    Goals

    • synergy of ZFS with dracut, so snapshots are correctly added to the grub
    • synergy of zedenv with zypper
      • before every update snapshot is created
      • when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
    • integrate Root on ZFS as install option to the YaST
    • configure Kiwi for the ZFS install images

    Completed goals

    • prepare ZFS pool compatible with openSUSE installation ✓
    • install openSUSE with root on ZFS ✓
    • boot to the prepared and installed system ✓

    Current progress

    Resources:

    terraform-provider-feilong by e_bischoff

    Project Description

    People need to test operating systems and applications on s390 platform.

    Installation from scratch solutions include:

    • just deploy and provision manually add-emoji (with the help of ftpboot script, if you are at SUSE)
    • use s3270 terminal emulation (used by openQA people?)
    • use LXC from IBM to start CP commands and analyze the results
    • use zPXE to do some PXE-alike booting (used by the orthos team?)
    • use tessia to install from scratch using autoyast
    • use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
    • directly install a Linux kernel on a LPAR and use kvm + libvirt from there

    Deployment from image solutions include:

    • use ICIC web interface (openstack in disguise, contributed by IBM)
    • use ICIC from the openstack terraform provider (used by Rancher QA)
    • use zvm_ansible to control SMAPI
    • connect directly to SMAPI low-level socket interface

    IBM Cloud Infrastructure Center (ICIC) harnesses the Feilong API, but you can use Feilong without installing ICIC, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.

    What about writing a terraform Feilong provider, just like we have the terraform libvirt provider? That would allow to transparently call Feilong from your main.tf files to deploy and destroy resources on your system/z.

    Other Feilong-based solutions include:

    • make libvirt Feilong-aware
    • simply call Feilong from shell scripts with curl
    • use zvmconnector client python library from Feilong
    • use zthin part of Feilong to directly command SMAPI.

    Goal for Hackweek 23

    My final goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.

    My technical preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean, and compatible with our existing development infrastructure.

    Goals for Hackweek 24

    Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!

    Let's add support for fiberchannel disks and multipath.

    Goals for Hackweek 25

    Modernization, maturity, and maintenance.

    Multimachine on-prem test with opentofu, ansible and Robot Framework by apappas

    Description

    A long time ago I explored using the Robot Framework for testing. A big deficiency over our openQA setup is that bringing up and configuring the connection to a test machine is out of scope.

    Nowadays we have a way¹ to deploy SUTs outside openqa, but we only use if for cloud tests in conjuction with openqa. Using knowledge gained from that project I am going to try to create a test scenario that replicates an openqa test but this time including the deployment and setup of the SUT.

    Goals

    Create a simple multimachine test scenario with the support server and SUT all created by the robot framework.

    Resources

    1. https://github.com/SUSE/qe-sap-deployment
    2. terraform-libvirt-provider

    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    Pending

    Debian 13

    The new version of the beloved Debian GNU/Linux OS

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [ ] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    • [ ] Package management (install, remove, update...)
    • [ ] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). Probably not for Debian as IIRC we don't support patches yet.
    • [ ] Applying any basic salt state (including a formula)
    • [ ] Salt remote commands
    • [ ] Bonus point: Java part for product identification, and monitoring enablement
    • [ ] Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    • [ ] Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)

    Rancher/k8s Trouble-Maker by tonyhansen

    Project Description

    When studying for my RHCSA, I found trouble-maker, which is a program that breaks a Linux OS and requires you to fix it. I want to create something similar for Rancher/k8s that can allow for troubleshooting an unknown environment.

    Goals for Hackweek 25

    • Update to modern Rancher and verify that existing tests still work
    • Change testing logic to populate secrets instead of requiring a secondary script
    • Add new tests

    Goals for Hackweek 24 (Complete)

    • Create a basic framework for creating Rancher/k8s cluster lab environments as needed for the Break/Fix
    • Create at least 5 modules that can be applied to the cluster and require troubleshooting

    Resources

    • https://github.com/celidon/rancher-troublemaker
    • https://github.com/rancher/terraform-provider-rancher2
    • https://github.com/rancher/tf-rancher-up
    • https://github.com/rancher/quickstart