Bug 2032462

Summary: error when creating PXE VM without selecting "immediately start VM"
Product: Red Hat Enterprise Linux 9 Reporter: YunmingYang <yunyang>
Component: cockpit-machinesAssignee: Martin Pitt <mpitt>
Status: CLOSED ERRATA QA Contact: YunmingYang <yunyang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 9.0CC: hongzliu, jsuchane, juzhou, mpitt, skobyda, tyan, tzheng, virt-maint, wcheng, wshi, xchen, ymao
Target Milestone: rcKeywords: Triaged
Target Release: 9.0Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: cockpit-machines-261-1.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-17 12:44:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Deadline: 2022-02-22   

Description YunmingYang 2021-12-14 14:18:20 UTC
Description of problem:
Click 'Create VM" to create a PXE VM, fill the dialog, but no checking the checkbox of "immediately start VM", then click "Create", there will be an error tab shown without "show more" button, and in browser console, there is an error as follow:
Traceback (most recent call last):
  File "<stdin>", line 356, in <module>
  File "<stdin>", line 273, in create_vm
  File "<stdin>", line 310, in inject_metadata
  File "/usr/lib64/python3.9/xml/etree/ElementTree.py", line 1347, in XML
    parser.feed(text)
xml.etree.ElementTree.ParseError: junk after document element: line 61, column 0


Version-Release number of selected components (if applicable):
cockpit-258-1.el9.x86_64
cockpit-machines-256-1.el9.noarch
libvirt-dbus-1.4.1-5.el9.x86_64


How reproducible:
100%


Steps to Reproduce:
1 Log in cockpit, then switch to the machines page
2 Click "Create VM" button
3 Fill the dialog, select "Installation type" to "Network boot(PXE)", and no checking the checkbox of "immediately start VM", then click "Create"


Actual results:
1 After step 3, there will be an error tab shown on the page, but no "show more" button in it
2 After step 3, press F12 to check in browser console, there will be an error as follow
Traceback (most recent call last):
  File "<stdin>", line 356, in <module>
  File "<stdin>", line 273, in create_vm
  File "<stdin>", line 310, in inject_metadata
  File "/usr/lib64/python3.9/xml/etree/ElementTree.py", line 1347, in XML
    parser.feed(text)
xml.etree.ElementTree.ParseError: junk after document element: line 61, column 0


Expected results:
1 After step 3, the VM could be created successfully with shutoff state


Additional info:

Comment 1 Martin Pitt 2022-01-04 15:11:41 UTC
When cockpit creates a VM with "immediately start", it effectively calls this:

   virt-install --connect qemu:///system --quiet --name test1 --os-variant alpinelinux3.14 --memory 150 --check path_in_use=off --wait -1 --noautoconsole --disk none --graphics vnc,listen=127.0.0.1 --graphics spice,listen=127.0.0.1 --pxe --network network=default

which works fine. Whereas without "immediately start", it calls the command with --print-xml (and without --noautoconsole, but that's noise -- the bug still happens with that option)

   virt-install --connect qemu:///system --quiet --name test1 --os-variant alpinelinux3.14 --memory 150 --check path_in_use=off --wait -1 --disk none --graphics vnc,listen=127.0.0.1 --graphics spice,listen=127.0.0.1 --print-xml --pxe --network network=default

and that duplicates the top-level document:

<domain type="kvm">
  <name>test1</name>
  <uuid>2a45ae1d-2526-4dab-914b-c5948b8cf087</uuid>
  <metadata>
[...]
</domain>
<domain type="kvm">
  <name>test1</name>
  <uuid>2a45ae1d-2526-4dab-914b-c5948b8cf087</uuid>
  <metadata>
[...]
</domain>

The second "<domain" tag is on line 65, exactly where the XML parser (rightfully) complains about "junk after document tag".

This still happens with a simplified command:

    virt-install --name test1 --os-variant alpinelinux3.14  --disk none --print-xml --pxe

the argument order also doesn't matter, moving the --print-xml to the end doesn't change the bug. But dropping "--pxe" results in a single <domain> document, so it's --pxe option which triggers this.

I tested this with virt-install-3.2.0-4.fc35.noarch, but it also happens with virt-install-3.2.0-11.el9.noarch in RHEL 9.

Comment 2 Martin Pitt 2022-01-04 15:14:37 UTC
Sorry, I accidentally submitted my previous comment/investigation as "minor change", thereby skipping the email notification. I reassigned this to virt-install, details are in the previous comment.

Comment 3 Jonathon Jongsma 2022-02-01 17:57:22 UTC
Whenever there is an install phase (e.g. booting install media from a cdrom or network and using that to install an OS into the guest), virt-install will actually generate two slightly different guest definitions: one for the very first boot (where the OS is installed to the guest) and one for subsequent boots (after the OS is installed on the guest). By default, --print-xml will print both the install phase xml and the final xml, which is why you see two domain elements. But this is not unique to --pxe. If you had specified e.g. a --cdrom install media instead of --pxe, you would have noticed that virt-install would have also produced two <domain> elements.  

I'm not sure what cockpit intends to do with the output of the --print-xml command, but if you want only the install phase xml or the final xml, you can add the optional STEP argument to the --print-xml option as mentioned in the man page:

   --print-xml
       Syntax: --print-xml [STEP]

       Print  the  generated XML of the guest, instead of defining it. By default this WILL do storage creation (can be disabled with --dry-run). This op‐
       tion implies --quiet.

       If the VM install has multiple phases, by default this will print all generated XML. If you want to print a particular step, use --print-xml 2 (for
       the second phase XML).


Does that help?

Comment 4 Martin Pitt 2022-02-03 10:07:03 UTC
Thanks Jonathon! This helps. Printing all XML is a little weird honestly, because that's exactly the use case of feeding this into virt-install. But `--print-xml=1` works for this case. I hope it will work in every case then. I'll file a PR and add tests. Cheers!

Comment 5 Jan Ščotka 2022-02-03 11:15:55 UTC
Hi,
re-acking the bug, as it was lost, when reassigning components
    Regards
    Honza

Comment 6 zixchen 2022-02-09 01:27:11 UTC
*** Bug 2035842 has been marked as a duplicate of this bug. ***

Comment 7 Martin Pitt 2022-02-14 07:59:20 UTC
Being fixed in https://github.com/cockpit-project/cockpit-machines/pull/568

Comment 8 Martin Pitt 2022-02-15 10:04:15 UTC
Fix landed upstream, will be released in 261 tomorrow.

Comment 9 Martin Pitt 2022-02-17 15:41:29 UTC
The fix has an accompanying gating test.

Comment 10 Martin Pitt 2022-02-21 08:44:56 UTC
For some reason, ET missed to update this bz with the link. This got added to https://errata.devel.redhat.com/advisory/82811

Comment 13 YunmingYang 2022-02-25 11:47:05 UTC
Test Versions:
cockpit-261-1.el9.x86_64
cockpit-machines-262-1.el9.noarch
libvirt-dbus-1.4.1-5.el9.x86_64


Test Steps:
1 Log in cockpit, then switch to the machines page
2 Click "Create VM" button
3 Fill the dialog, select "Installation type" to "Network boot(PXE)" or "Download an OS", and without checking "immediately start VM", then click "Create"

Test Results:
1 The VM create successfully with "Shut off" state and "Install" button
2 No error like below shown in browser console
Traceback (most recent call last):
  File "<stdin>", line 356, in <module>
  File "<stdin>", line 273, in create_vm
  File "<stdin>", line 310, in inject_metadata
  File "/usr/lib64/python3.9/xml/etree/ElementTree.py", line 1347, in XML
    parser.feed(text)
xml.etree.ElementTree.ParseError: junk after document element: line 61, column 0

According to the results, move status to VERIFIED.

Comment 15 errata-xmlrpc 2022-05-17 12:44:42 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: cockpit-machines), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2388