Created attachment 1913816 [details]
Guest unable to start

Description of problem:
cockpit-machines, in all version up to the one included in the latest RHEL 9.0, default to creating/attaching a new disk via the pool + file definition.

For example, adding a disk called "disk2.qcow2" results in the following xml:
<disk type='volume' device='disk'>
<driver name='qemu' type='qcow2'/>
<source pool='default' volume='disk2.qcow'/>
<target dev='vdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
</disk>

Doing the same via virt-manager (any version) produce a different outcome, because virt-manager resolves (and defines) the full file path/name. Example below:
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/disk2.qcow' index='2'/>
<backingStore/>
<target dev='vdb' bus='virtio'/>
<alias name='virtio-disk1'/>
<address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
</disk>

This is not a cosmetic issue only, as any apparmor-enabled hosts is effectively unable to run a guest with such pool + file disk definition (see here[1] and here[2]). The underlying issue is that virt-aa-helper is unable to parse such disk definition. As changing the iteration between libvirt, virt-aa-helper and apparmor proved problematic, the most obvious solution is to let cockpit-machines specify the full disk path/name when adding or attaching disks.

I attach two screenshots showing how:

• attaching a new disk results in a pool + file definition, with the guest unable to start;
• re-attaching the same disk with a full disk path/name results in the guest running correctly.

[1] https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398
[2] https://gitlab.com/libvirt/libvirt/-/issues/135

Version-Release number of selected component (if applicable):
cockpit-machines 265-1

How reproducible:
Always

Steps to Reproduce:
1. create and add a new disk on a apparmor-enabled host (ie: Ubuntu, Debian, SUSE)
2. try to start the guest
3. observe how the guest does not start showing an error instead.

Actual results:
Guest unable to start

Expected results:
Guest should start and work correcly

Additional info:
See screenshots