Update VM configuration results in error (invalid raw section: unsupported type)

[mb91]

Description
Updating the VM Configuration of an existing VM instance fails when using Raw data.
Error message:

[one.vm.updateconf] invalid raw section: unsupported type

To Reproduce

1. Create a VM template. At the adcanced options under "OS & CPU" enter some valid Raw data. Enable Validate of Raw data.

2. Instantiate a VM of the created VM template.

3. Call the new VM, navigate to the "Configuration" tab, and click "Update VM Configuration". The error message will appear once you click "Accept" (even if you don't make any changes).

Expected behavior
Updating VM configuration (like Context Variables or Keymap for the VNC session) without an error.

Details

• Affected Component: Sunstone
• Hypervisor: KVM
• Version: 7.0.1

Additional context
Creating Instance of VM Template creates the following POST request:

{"name":"testinstance","hold":false,"template":"<ROOT><CPU>0.02</CPU><HYPERVISOR>kvm</HYPERVISOR><LOGO>images/logos/windows8.png</LOGO><MEMORY>4096</MEMORY><OS_PROFILE>windows_optimized</OS_PROFILE><VCPU>2</VCPU><name>testinstance</name><CONTEXT><NETWORK>YES</NETWORK><SSH_PUBLIC_KEY>$USER[SSH_PUBLIC_KEY]</SSH_PUBLIC_KEY></CONTEXT><CPU_MODEL><MODEL>Broadwell-noTSX</MODEL></CPU_MODEL><DISK><DEV_PREFIX>vd</DEV_PREFIX><IMAGE>Empty Disk</IMAGE><IMAGE_ID>647</IMAGE_ID><IMAGE_UNAME>user.adm</IMAGE_UNAME><SIZE>20480</SIZE></DISK><FEATURES><ACPI>Yes</ACPI><APIC>Yes</APIC><GUEST_AGENT>Yes</GUEST_AGENT><HYPERV>Yes</HYPERV><LOCALTIME>no</LOCALTIME><PAE>Yes</PAE><VIRTIO_BLK_QUEUES>auto</VIRTIO_BLK_QUEUES><VIRTIO_SCSI_QUEUES>auto</VIRTIO_SCSI_QUEUES></FEATURES><GRAPHICS><KEYMAP>de</KEYMAP><LISTEN>0.0.0.0</LISTEN><TYPE>VNC</TYPE></GRAPHICS><NIC><NETWORK>VLAN878-KVM</NETWORK><NETWORK_ID>58</NETWORK_ID><NETWORK_UID>82</NETWORK_UID><NETWORK_UNAME>user.adm</NETWORK_UNAME></NIC><OS><ARCH>x86_64</ARCH><FIRMWARE>UEFI</FIRMWARE><FIRMWARE_SECURE>NO</FIRMWARE_SECURE><MACHINE>pc-q35-7.2</MACHINE><BOOT></BOOT></OS><RAW><DATA><sysinfo type='smbios'>\n  <oemStrings>\n    <entry>foo:bar</entry>\n    <entry>second: spaced</entry>\n    <entry>third:value</entry>\n  </oemStrings>\n</sysinfo></DATA><TYPE>kvm</TYPE><VALIDATE>YES</VALIDATE></RAW><SCHED_DS_REQUIREMENTS>ID="138"</SCHED_DS_REQUIREMENTS><SCHED_RANK>-RUNNING_VMS</SCHED_RANK><SCHED_REQUIREMENTS>HYPERVISOR=kvm & CLUSTER_ID = 111</SCHED_REQUIREMENTS><USER_INPUTS><MEMORY>M|range||4096..16384|4096</MEMORY></USER_INPUTS><VIDEO><RESOLUTION>1280x720</RESOLUTION><TYPE>vga</TYPE></VIDEO></ROOT>","persistent":false}

Creating the configuration of existing VM creates the following POST request:

{"template":"<ROOT><GRAPHICS><TYPE>VNC</TYPE><LISTEN>0.0.0.0</LISTEN><KEYMAP>de</KEYMAP></GRAPHICS><VIDEO><RESOLUTION>1280x720</RESOLUTION><TYPE>vga</TYPE></VIDEO><OS><ARCH>x86_64</ARCH><FIRMWARE>UEFI</FIRMWARE><FIRMWARE_SECURE>NO</FIRMWARE_SECURE><MACHINE>pc-q35-7.2</MACHINE><UUID>6faf5430-77ab-4ca3-871c-13dc56b1101a</UUID></OS><FEATURES><ACPI>Yes</ACPI><PAE>Yes</PAE><APIC>Yes</APIC><LOCALTIME>no</LOCALTIME><HYPERV>Yes</HYPERV><GUEST_AGENT>Yes</GUEST_AGENT></FEATURES><CONTEXT><SSH_PUBLIC_KEY></SSH_PUBLIC_KEY><START_SCRIPT></START_SCRIPT><NETWORK>YES</NETWORK><TOKEN>NO</TOKEN><REPORT_READY>NO</REPORT_READY><INIT_SCRIPTS></INIT_SCRIPTS><FILES_DS></FILES_DS><DISK_ID>1</DISK_ID><ETH0_DNS>10.0.0.1</ETH0_DNS><ETH0_EXTERNAL></ETH0_EXTERNAL><ETH0_GATEWAY>10.0.0.1</ETH0_GATEWAY><ETH0_IP>10.0.0.12</ETH0_IP><ETH0_IP6></ETH0_IP6><ETH0_IP6_GATEWAY></ETH0_IP6_GATEWAY><ETH0_IP6_METHOD>disable</ETH0_IP6_METHOD><ETH0_IP6_METRIC></ETH0_IP6_METRIC><ETH0_IP6_PREFIX_LENGTH></ETH0_IP6_PREFIX_LENGTH><ETH0_IP6_ULA></ETH0_IP6_ULA><ETH0_MAC>02:00:0a:00:00:12</ETH0_MAC><ETH0_MASK>255.255.252.0</ETH0_MASK><ETH0_METHOD></ETH0_METHOD><ETH0_METRIC></ETH0_METRIC><ETH0_MTU></ETH0_MTU><ETH0_NETWORK></ETH0_NETWORK><ETH0_SEARCH_DOMAIN>domain.tld</ETH0_SEARCH_DOMAIN><ETH0_VLAN_ID></ETH0_VLAN_ID><ETH0_VROUTER_IP></ETH0_VROUTER_IP><ETH0_VROUTER_IP6></ETH0_VROUTER_IP6><ETH0_VROUTER_MANAGEMENT></ETH0_VROUTER_MANAGEMENT><TARGET>hda</TARGET></CONTEXT><CPU_MODEL><MODEL>Broadwell-noTSX</MODEL></CPU_MODEL><RAW><DATA><sysinfo type='smbios'>\n  <oemStrings>\n    <entry>foo:bar</entry>\n    <entry>second: spaced</entry>\n    <entry>third:value</entry>\n  </oemStrings>\n</sysinfo></DATA><VALIDATE>YES</VALIDATE></RAW></ROOT>"}

When I update the VM configuration TYPE is missing in the RAW-section of the POST request, which is leading to an "unsupported type".

<RAW>...<TYPE>kvm</TYPE>...</RAW>

Progress Status

• Code committed
• Testing - QA
• Documentation (Release notes - resolved issues, compatibility, known issues)

[mb91]

I've find out that it is not just a display error in the WebUI or an API error.

I am able to set some cpu features in the RAW section via the CLI (onevm updateconf <vmid>).

Concrete:

<cpu mode='custom' match='exact' check='full'><feature policy='require' name='vmx'/></cpu>

The RAW Data are displayed in the web UI (including errors; see post above).

If I display the information via the hypervisor (virsh dumpxml one-<vmid>), I can see that the RAW data is not being passed to the VM.

<domain type='kvm' id='17'>
  [...]
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Broadwell-noTSX</model>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='rdrand'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='require' name='abm'/>
  </cpu>
  [...]
</domain>

[vichansson]

Hi @mb91,

Thanks for reporting this, confirmed the issue was a missing RAW.TYPE parameter from the WebUI's VM update configuration call, making the schema validation fail. This has been fixed now and will be included in the 7.4.1 release.

Cheers,
Victor