Unable to detect disks suitable for backup when backing up VM with network based disks

[steeldomejeff]

Version used
virtnbdbackup 2.38
ceph 19.2.3

Describe the bug
Unable to detect disks suitable for backup when backing up VM with RBD (ceph) based disks

Expected behavior
Backup should proceed

Hypervisor and/or virtual machine information:

• OS: Rocky 9.6
• HV type Libvirt 10.10/KVM
• virsh dumpxml for VM:

Logfiles:
virtnbdbackup --start-domain -U 'qemu+ssh://root@testsystem1-1/system' --nbd-ip 'testsystem1-1' --nbd-port '29714' --ssh-user 'root' --checkpointdir '/virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/_checkpoints' -d 'baseos-mtwcgtvs' -l 'auto' -o '/virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/2025-10/11a5894d-5d4f-4aa8-9f74-81573882c0ea' -e --raw

[2025-10-21 19:19:07] INFO lib common - printVersion [main]: Version: 2.38 Arguments: /usr/bin/virtnbdbackup --start-domain -U qemu+ssh://root@testsystem1-1/system --nbd-ip testsystem1-1 --nbd-port 29714 --ssh-user root --checkpointdir /virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/_checkpoints -d baseos-mtwcgtvs -l auto -o /virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/2025-10/11a5894d-5d4f-4aa8-9f74-81573882c0ea -e --raw
[2025-10-21 19:19:07] INFO root virtnbdbackup - main [main]: Backup level: [auto]
[2025-10-21 19:19:07] INFO root virtnbdbackup - main [main]: Store checkpoints in: [/virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/_checkpoints]
[2025-10-21 19:19:07] INFO virt client - _connect [main]: Connected to remote host: [testsystem1-1]
[2025-10-21 19:19:07] INFO root virtnbdbackup - main [main]: Libvirt library version: [10010000]
[2025-10-21 19:19:07] INFO root virtnbdbackup - main [main]: NBD library version: [1.20.3]
[2025-10-21 19:19:07] INFO root check - targetDir [main]: Backup mode auto, target folder is empty: executing full backup.
[2025-10-21 19:19:07] ERROR virt client - getDomainDisks [main]: Unable to detect disk volume type for disk [vda] [2025-10-21 19:19:07] WARNING root virtnbdbackup - main [main]: Emulated TPM device attached: User action required. [2025-10-21 19:19:07] WARNING root virtnbdbackup - main [main]: Please manually backup contents of: [/var/lib/libvirt/swtpm/11a5894d-5d4f-4aa8-9f74-81573882c0ea/]
[2025-10-21 19:19:07] INFO root virtnbdbackup - main [main]: Only raw disks attached, switching to backup mode copy.
[2025-10-21 19:19:07] ERROR root virtnbdbackup - main [main]: Unable to detect disks suitable for backup.
[2025-10-21 19:19:07] INFO root metadata - backupConfig [main]: Saving VM config to: [/virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/2025-10/11a5894d-5d4f-4aa8-9f74-81573882c0ea/vmconfig.copy.xml]
[2025-10-21 19:19:07] INFO root metadata - backupBootConfig [main]: Save additional boot config [loader] to: [/virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/2025-10/11a5894d-5d4f-4aa8-9f74-81573882c0ea/OVMF_CODE.secboot.fd]
[2025-10-21 19:19:07] INFO root metadata - backupBootConfig [main]: Save additional boot config [nvram] to: [/virtnbdbackup/machines/backups/6b9f10d7-09a7-4275-8766-f69605bb08ce/2025-10/11a5894d-5d4f-4aa8-9f74-81573882c0ea/baseos-mtwcgtvs_VARS.fd]

Workaround:
None found.

[abbbi]

w/o vm configuration file im not able to tell what the issue here
personally i dont use ceph/rbd direct attached devices for my virtual machines.

tool is unable to parse the disks from the xml config, so this vm seems to have a disk configuration type ive never experienced before:

getDomainDisks [main]: Unable to detect disk volume type for disk [vda]

[steeldomejeff]

It looks like it dropped the XML data I included in the ticket... Here is the <disk> section of the xml dump: <disk type='file' device='disk'> <driver name='qemu' type='qcow2' discard='unmap'/> <source file='/var/lib/libvirt/images/baseos-mtwcgtvs.meta.qcow2'> <dataStore type='network' protocol='rbd' name='auxiliaryvolumes.data/baseos-mtwcgtvs-os'> <host name='192.168.59.102' port='3300'/> <host name='192.168.59.101' port='3300'/> <host name='192.168.59.103' port='3300'/> <auth username='admin'> <secret type='ceph' uuid='ae9a5d54-4c6f-4b4d-a50a-3a1be1a7a1f3'/> </auth> </dataStore> </source> <target dev='vda' bus='virtio'/> </disk>

…

On Wed, Oct 22, 2025 at 4:49 PM Michael Ablassmeier < ***@***.***> wrote: *abbbi* left a comment (abbbi/virtnbdbackup#286) <#286 (comment)> w/o vm configuration file im not able to tell what the issue here personally i dont use ceph/rbd direct attached devices for my virtual machines. — Reply to this email directly, view it on GitHub <#286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV6ODXZ6CZ2HVGAK6S4XOTT3Y7UUZAVCNFSM6AAAAACJ57G23GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZUGE2TQNRTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[abbbi]

i see the disk type is set to "file", yet i dont see the big picture. Seems to be a qcow overlay for a ceph network device. I dont have such a setup , so its hard for me to reproduce..

The disk type is detected within this function which seems to fail to detect this specific configuration:

https://github.com/abbbi/virtnbdbackup/blob/master/libvirtnbdbackup/virt/client.py#L337

but after that, not sure which other enhancements have to be done to support this type of VM disk conifguration.
running with debug uption might help.

[steeldomejeff]

I have this setup in the lab... I'll investigate the client.py segment you sent me and report back with what I find. Standby. Thank you Michael.

…

On Wed, Oct 22, 2025 at 5:01 PM Michael Ablassmeier < ***@***.***> wrote: *abbbi* left a comment (abbbi/virtnbdbackup#286) <#286 (comment)> i see the disk type is set to "file", yet i dont see the big picture. Seems to be a qcow overlay for a ceph network device. I dont have such a setup , so its hard for me to reproduce.. The disk type is detected within this function which seems to fail to detect this specific configuration: https://github.com/abbbi/virtnbdbackup/blob/master/libvirtnbdbackup/virt/client.py#L337 but after that, not sure which other enhancements have to be done to support this type of VM disk conifguration. — Reply to this email directly, view it on GitHub <#286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV6ODX456LHMJZY5BCKNAN33Y7WC3AVCNFSM6AAAAACJ57G23GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZUGE4DSMZSGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[abbbi]

what is see is:

<disk type='file' device='disk'>

and the code does:

diskType = disk.get("type")
[..]
 elif diskType == "file":

which should match this case, but it doesnt for some reason ...
Having the complete config would help,..

[abbbi]

i tried to craft an vm with this type of disk config but fail to define:

sudo virsh define vm7.xml
error: Failed to define domain from vm7.xml
error: XML error: missing data file store format

running on debian trixie ..

maybe, if you want incremental backups for ceph/rbd backed devices, you need to specify like described
here:

https://github.com/abbbi/virtnbdbackup?tab=readme-ov-file#libvirt-versions--v10100-1

[steeldomejeff]

Send XML via email as the webui isn't rendering this correctly for some reason: virsh dumpxml baseos-kfdvsfxo <domain type='kvm'> <name>baseos-kfdvsfxo</name> <uuid>8534fe43-2346-443d-9f55-e88e045c40d2</uuid> <metadata xmlns:cockpit_machines=" https://github.com/cockpit-project/cockpit-machines"> <libosinfo:libosinfo xmlns:libosinfo=" http://libosinfo.org/xmlns/libvirt/domain/1.0"> <libosinfo:os id="http://rockylinux.org/rocky/9"/> </libosinfo:libosinfo> <cockpit_machines:data> <cockpit_machines:os_variant>rocky9</cockpit_machines:os_variant> </cockpit_machines:data> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-rhel9.6.0'>hvm</type> <firmware> <feature enabled='yes' name='enrolled-keys'/> <feature enabled='yes' name='secure-boot'/> </firmware> <loader readonly='yes' secure='yes' type='pflash' format='raw'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader> <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/baseos-kfdvsfxo_VARS.fd</nvram> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <smm state='on'/> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' clusters='1' cores='1' threads='1'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <pm> <suspend-to-mem enabled='no'/> <suspend-to-disk enabled='no'/> </pm> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none'/> <auth username='admin'> <secret type='ceph' uuid='ae9a5d54-4c6f-4b4d-a50a-3a1be1a7a1f3'/> </auth> <source protocol='rbd' name='auxiliaryvolumes.data/baseos-kfdvsfxo-os'> <host name='192.168.59.102' port='3300'/> <host name='192.168.59.101' port='3300'/> <host name='192.168.59.103' port='3300'/> </source> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </disk> <controller type='usb' index='0' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x15'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0x16'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> </controller> <controller type='pci' index='8' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='8' port='0x17'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/> </controller> <controller type='pci' index='9' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='9' port='0x18'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='10' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='10' port='0x19'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> </controller> <controller type='pci' index='11' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='11' port='0x1a'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/> </controller> <controller type='pci' index='12' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='12' port='0x1b'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/> </controller> <controller type='pci' index='13' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='13' port='0x1c'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/> </controller> <controller type='pci' index='14' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='14' port='0x1d'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:65:fd:be'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <tpm model='tpm-crb'> <backend type='emulator' version='2.0'/> </tpm> <graphics type='vnc' port='-1' autoport='yes'> <listen type='address'/> </graphics> <audio id='1' type='none'/> <video> <model type='virtio' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <watchdog model='itco' action='reset'/> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </rng> </devices> </domain>

…

On Wed, Oct 22, 2025 at 5:12 PM Michael Ablassmeier < ***@***.***> wrote: *abbbi* left a comment (abbbi/virtnbdbackup#286) <#286 (comment)> i tried to craft an vm with this type of disk config but fail to define: error: XML error: missing data file store format running on debian trixie .. — Reply to this email directly, view it on GitHub <#286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV6ODX225ZXT7IND24RMF533Y7XLZAVCNFSM6AAAAACJ57G23GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZUGIYTQNRZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[steeldomejeff]

I have this setup and fully functional in my lab. Let me know if there is anything you need me to try/test to validate the process.

[abbbi]

ok, now i see the full picture, the disk is configured differently as in your first posts here:

#286 (comment)

The disk is configured as type "network" disk:

<disk type='network' device='disk'>

there is currently no support for this in virtnbdbackup, and i dont have such a setup at hand (at least not with an ceph backend). Adding support for the ceph backend without having the setup or the need for it is something that is out of scope for me currently (w/o getting paid). That said, its not only the backup part that needs to be implemented but also the restore part, in this particular case.

While i could add support for this using the "--raw" option, the restore is not handled correctly. The backup is then
handled like a raw file and restore will not map and write to the network devices /ceph endpoints directly.

You should better try to configure the disk with an qcow overlay image using the new data-file features, it would make more sense because it allows for complete feature set:

https://github.com/abbbi/virtnbdbackup?tab=readme-ov-file#libvirt-versions--v10100-1

and this setup should be working, because it basically doesn't matter what backend the real data is using.

You have to check the libvirt documentation how and if it is possble to configure a metadata image for ceph backed devices. Otherwise the vm disk data-file setting must point to an mapped RBD device locally (as in, /dev/rbdX, that is mapped on the host system).

According to the examples in the libvirt test repository, it works for NBD, so i think it might work for CEPH in a
similar way:

https://github.com/libvirt/libvirt/blob/master/tests/qemuxmlconfdata/disk-qcow2-datafile-store.x86_64-latest.xml#L44

I think thats an better way to sorting out backup for this type of machines, instead of attempting to treat the disks as raw devices which will not be handled correctly during restore, and, overall, do not provide the featureset this utility was created for in the first place.

As with the latest commit, it at least handles these kind of situations gracefully and prints a proper error message.