-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
qm sub-package Kernel-based Virtual Machine (KVM) #608
Conversation
The QM sub-package KVM includes drop-in configuration that enables the integration of Kernel-based Virtual Machine (KVM) management into the QM (Quality Management) container environment. This configuration allows users to easily configure and manage KVM virtual machines within the QM system, streamlining virtualization tasks in containerized setups. Use: make qm_dropin_mount_bind_kvm Signed-off-by: Douglas Schilling Landgraf <[email protected]>
|
||
Step 2: Preparing cloudinit files inside QM (/usr/lib/qm/rootfs/root) | ||
|
||
# Cloud-init files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you using cloud-init? i assume it is for the guest?
Is it only for the password?
I prefer to use this command after that one
virt-customize --uninstall cloud-init --root-password password:Aa1234 -a ./<fedora-image>.qcow2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds a good plan. If we merge can you test and improve it for us?
$host> chown qemu:qemu /usr/lib/qm/rootfs/var/lib/libvirt/* | ||
|
||
Step 3: Starting libvirtd and checking if it's active inside QM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you hit selinux issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, must be addressed in a next patch.
$host> make qm_dropin_mount_bind_kvm | ||
$host> sudo dnf install rpmbuild/RPMS/noarch/qm_mount_bind_kvm-0.6.7-1.fc40.noarch.rpm | ||
$host> sudo podman restart qm # if you have qm already running | ||
$host> sudo dnf --installroot /usr/lib/qm/rootfs/ install virt-install libvirt-daemon libvirt-daemon-qemu libvirt-daemon-kvm -y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prefer to use this one
sudo dnf install qemu
qemu-system-x86_64 --version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, qemu
should be containerized. This is nice for testing that the kvm device has been mounted correctly, but it is not the way to run a VM inside the QM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aesteve-rh ah, yes, the whole things should be containerized,
Step 1:
is running qemu in qm
Step 2:
qemu containerized in qm
Is it?
One more,
Do you think we should use virt-* packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Step 2 should be supported already, so we can aim for that directly.
Do you think we should use virt-* packages?
You mean for this documented example or in general? Probably, as a response to both, it should not be necessary to use them. I agree with you in that qemu would be preferred.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Yarboa yes, should work like that. @aesteve-rh can you share more about your vision so all of us are in the same page?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am only saying that workloads inside the qm are supposed to be containerized. Like, the image should be stored inside the qm and launched through a quadlet file. That allows to set rules to ensure FFI, control the system's surface that the process has access to, and also allows applying SELinux labels to allow only a correct subset of operations.
For developers, it may suffice to install all those packages directly on the qm container and test it there. But imo, this is not how virtualization should be documented for users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aesteve-rh completed agreed. It's just a documentation.
@Yarboa @aesteve-rh in general, it was just a test, the documentation process should be improved as much as possible. |
Yes. |
Ah @aesteve-rh you meant ContinerFile? Yes and shipped inside the RPM @Yarboa (in a next patch). Let's merge what we have and keep improving. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra work based on the comments here #609
The QM sub-package KVM includes drop-in configuration that enables the integration of Kernel-based Virtual Machine (KVM) management into the QM (Quality Management) container environment. This configuration allows users to easily configure and manage KVM virtual machines within the QM system, streamlining virtualization tasks in containerized setups.
Use: make qm_dropin_mount_bind_kvm