Created attachment 1913817 [details]
Guest starting correcly

Hi, thanks for raising this issue. Few questions on the steps:
1. The bug does not exist on RHEL right? I saw you mentioned Ubuntu/Debian/SUSE host.
2. You mean you create a vm on the host, then edit the xml to add a disk without full disk path, and them vm failed to boot, am I right?
Thank you.

Hi, my notes below:

1. RedHat or other selinux-based distro does not suffer from this issue because no virt-aa-helper wrapper must be called (the security label is attached to the file itself);

2. No, I mean using cockpit to create a VM on the host *without* disks and then edit the very same guest to add a new disk via cockpit.

You can find some more info on upstream bug opened here:
https://github.com/cockpit-project/cockpit-machines/issues/815#issuecomment-1315122114

Thank you for your quick response.
Got it for question 1.

For questions 2, sorry I'm not quite sure about "create a VM on the host *without* disks",could you give detailed step or command on this? Thank you.

And I saw the discussion on the ticket, thank you, chaning it with RFE since I think the point is to provide "creating and attaching a disk with full path" , right?
So I guess the host does not matter on verifying , once on RHEL we have this feature, the issue on non-RHEL host would be fixed too.
Correct me if I understand wrongly , thank you.

Creating a VM with no disks simply means to select "No storage" in the "Create VM" wizard (see screenshot).

Please note that when creating a VM with a new disk selected, virt-install automatically modifies the virtual disk definition specifying the full path rather than the pool/file combo. However, this automatically create a qcow2 disks, which is not always the right format. Moreover, one should be able to add additional disks to an already-defined virtual machine.

Created attachment 1924954 [details]
New VM without virtual disks

Thanks for all the explaination, reproduce as following:

Version:
cockpit-machines-276-1.el9.noarch
Steps:
1. Create VM:
Installation type: Download an OS
Operation system: Fedora35
Storage: No storage
Memory: 2G

2. Enter the VM details page, click "Add disk"
Pool: images
Name: fedora-test
Size: 10G
Format: qcow2
Click "Add"

3. Check the xml:
# virsh dumpxml fedora35-2022-11-18
    <disk type='volume' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source pool='images' volume='fedora-test' index='1'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </disk>

It's pool/file combo, better to be full path like following to avoid boot issue on apparmor-enabled host (ie: Ubuntu, Debian, SUSE):
source file='/var/lib/libvirt/images/fedora-test.qcow'

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.