-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
How to access the virt-launchers libvirt socket for third party applications? #11806
Comments
@abbbi the answer is simple, it is because we discourage any direct access to libvirt and it doesn't follow the KubeVirt API, and it might leads to the an unexpected behavior. For your particular use-case, you should rely on the CSI snapshot, not on QEMU snapshot. This is fundamental design decision for KubeVirt. Your disk image should be expanded to fill the entire PVC, so you might not have enough space left on the PVC for the snapshot. |
If you still want to access it. Sidecars have the |
hi, thanks for the reply,
The new libvirt backup API does not use snapshots, but uses changed block tracking in the qemus block storage layer (dirty bitmaps). These bitmaps can then be exposed via NBD. If the volumes are QCOW based, this allows for incremental backups without having to scan the storage for changes. In case the volumes are RAW (which seems to be the case with kubevirt) it would at least be possible to create full backups. |
Even with CBT, the main idea doesn't change. We don't use block jobs from QEMU. There's been some ideas to use the qemu-storage-daemon to separate the qemu storage feature and CSI. However, this is hard to integrate and there's only been some experimentations, not a real plan. Otherwise, yes, KubeVirt uses raw images on PVC. |
What I want to make clear is that accessing the libvirt daemon might just be the tiny visible part of the iceberg. You need to consider how you are going to manage the storage in k8s. |
hi,
Im searching for a sane way[2] to access the virt-launchers libvirtd socket from a sidecar pod.
My use case here is to be able to use the libvirt/qemu incremental backup features[0]
As i understand there are sidecar hooks that allow for patching the created libvirt xml during launch, but i fail to
understand how i would be able to access the libvirt daemon via socket from a pod in the same deployment.
The scenario would be:
Im pretty new to kubevirt and k8 in general, any help how to archive this is highly appreciated!
[0] https://libvirt.org/kbase/live_full_disk_backup.html (https://libvirt.org/formatbackup.html)
[1] https://github.com/abbbi/virtnbdbackup
[2] abbbi/virtnbdbackup#178
The text was updated successfully, but these errors were encountered: