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 likeopt/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
- Steffen implemented support for generic url schema to download files from qemu firmware.
- Duncan implemented automatic discovery and usage of AutoYaST profiles present in the firmware (in linuxrc).
This project is part of:
Hack Week 16
Activity
Comments
-
almost 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
andraw
) - 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, usemksusecd
Similar Projects
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
(with the help of
ftpboot
script, if you are at SUSE) - use
s3270
terminal emulation (used byopenQA
people?) - use
LXC
from IBM to start CP commands and analyze the results - use
zPXE
to do some PXE-alike booting (used by theorthos
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 theopenstack
terraform
provider (used byRancher
QA) - use
zvm_ansible
to controlSMAPI
- 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 withcurl
- use
zvmconnector
client python library from Feilong - use
zthin
part of Feilong to directly commandSMAPI
.
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.
Possible goals for Hackweek 25
Modernization, maturity, and maintenance.