[virt-manager PATCH] Fix checking for graphics spice for Xen

Charles Arnold carnold at suse.com
Thu Feb 10 20:24:41 UTC 2022


On 2/10/22 8:26 AM, Cole Robinson wrote:
> On 2/9/22 4:53 PM, Charles Arnold wrote:
>> On 2/9/22 11:32 AM, Charles Arnold wrote:
>>> On 2/9/22 10:32 AM, Cole Robinson wrote:
>>>> On 2/9/22 9:50 AM, Charles Arnold wrote:
>>>>> Advertising graphics support doesn't necessarily mean spice support.
>>>>> self.devices.graphics.supported seems to not be spice specific
>>>>> but rather more generic in indicating whether graphics are supported.
>>>>> For Xen, spice is not supported so fallback to the old logic.
>>>>>
>>>>> Signed-off-by: Charles Arnold <carnold at suse.com>
>>>>>
>>>>> diff --git a/virtinst/domcapabilities.py b/virtinst/domcapabilities.py
>>>>> index 67bceaa3..ad6e3363 100644
>>>>> --- a/virtinst/domcapabilities.py
>>>>> +++ b/virtinst/domcapabilities.py
>>>>> @@ -382,7 +382,7 @@ class DomainCapabilities(XMLBuilder):
>>>>>            return len(models) > 0 and bool("emulator" in backends)
>>>>>
>>>>>        def supports_graphics_spice(self):
>>>>> -        if not self.devices.graphics.supported:
>>>>> +        if not self.devices.graphics.supported or self.conn.is_xen():
>>>>>                # domcaps is too old, or the driver doesn't advertise
>>>>> graphics
>>>>>                # support. Use our pre-existing logic
>>>>>                if not self.conn.is_qemu() and not self.conn.is_test():
>>>>>
>>>>>
>>>> Hmm but does that mean domcapabilities for xen is reporting that spice
>>>> is available? If that's the case, seems like a domcapabilities bug in
>>>> libvirt xen driver. Or am I missing something?
>>>>
>>>> Thanks,
>>>> Cole
>>>>
>>> Booted into Xen, virsh domcapabilities reports,
>>>
>>> <domainCapabilities>
>>>    <path>/usr/bin/qemu-system-x86_64</path>
>>>    <domain>xen</domain>
>>>    <machine>xenpv</machine>
>>>    <arch>x86_64</arch>
>>>    <vcpu max='512'/>
>>>    <iothreads supported='no'/>
>>>    <os supported='yes'>
>>>      <loader supported='no'/>
>>>    </os>
>>>    <cpu>
>>>      <mode name='host-passthrough' supported='no'/>
>>>      <mode name='maximum' supported='no'/>
>>>      <mode name='host-model' supported='no'/>
>>>      <mode name='custom' supported='no'/>
>>>    </cpu>
>>>    <devices>
>>>      <disk supported='yes'>
>>>        <enum name='diskDevice'>
>>>          <value>disk</value>
>>>          <value>cdrom</value>
>>>        </enum>
>>>        <enum name='bus'>
>>>          <value>ide</value>
>>>          <value>scsi</value>
>>>          <value>xen</value>
>>>        </enum>
>>>        <enum name='model'/>
>>>      </disk>
>>>      <graphics supported='yes'>
>>>        <enum name='type'>
>>>          <value>sdl</value>
>>>          <value>vnc</value>
>>>          <value>spice</value>
>>>        </enum>
>>>      </graphics>
>>>      <video supported='yes'>
>>>        <enum name='modelType'>
>>>          <value>vga</value>
>>>          <value>cirrus</value>
>>>          <value>xen</value>
>>>        </enum>
>>>      </video>
>>>      <hostdev supported='yes'>
>>>        <enum name='mode'>
>>>          <value>subsystem</value>
>>>        </enum>
>>>        <enum name='startupPolicy'>
>>>          <value>default</value>
>>>          <value>mandatory</value>
>>>          <value>requisite</value>
>>>          <value>optional</value>
>>>        </enum>
>>>        <enum name='subsysType'>
>>>          <value>usb</value>
>>>          <value>pci</value>
>>>        </enum>
>>>        <enum name='capsType'/>
>>>        <enum name='pciBackend'>
>>>          <value>xen</value>
>>>        </enum>
>>>      </hostdev>
>>>    </devices>
>>>    <features>
>>>      <gic supported='no'/>
>>>      <vmcoreinfo supported='no'/>
>>>      <genid supported='no'/>
>>>      <sev supported='no'/>
>>>    </features>
>>> </domainCapabilities>
>>>
> Thanks, this could be useful to add to the test suite. Is output the
> mostly the same for `virsh domcapabilities --machine xenfv` too?

Here is a diff between the two outputs (pv vs fv).

--- domcaps.out    2022-02-10 08:43:16.975623878 -0700
+++ domcaps-xenfv.out    2022-02-10 08:43:25.831836760 -0700
@@ -1,12 +1,22 @@
  <domainCapabilities>
    <path>/usr/bin/qemu-system-x86_64</path>
    <domain>xen</domain>
-  <machine>xenpv</machine>
+  <machine>xenfv</machine>
    <arch>x86_64</arch>
-  <vcpu max='512'/>
+  <vcpu max='128'/>
    <iothreads supported='no'/>
    <os supported='yes'>
-    <loader supported='no'/>
+    <loader supported='yes'>
+ <value>/usr/share/qemu/ovmf-x86_64-xen-4m.bin</value>
+      <value>/usr/lib/xen/boot/hvmloader</value>
+      <enum name='type'>
+        <value>rom</value>
+        <value>pflash</value>
+      </enum>
+      <enum name='readonly'>
+        <value>yes</value>
+      </enum>
+    </loader>
    </os>
    <cpu>
      <mode name='host-passthrough' supported='no'/>

>
>> The more precise error I'm trying to fix is while attempting to install
>> a Xen HVM guest it reports,
>>
>> details=Traceback (most recent call last):
>>    File "./virtManager/asyncjob.py", line 72, in cb_wrapper
>>      callback(asyncjob, *args, **kwargs)
>>    File "./virtManager/createvm.py", line 2008, in _do_async_install
>>      installer.start_install(guest, meter=meter)
>>    File "./virtinst/install/installer.py", line 704, in start_install
>>      doboot, transient)
>>    File "./virtinst/install/installer.py", line 649, in _create_guest
>>      domain = self.conn.createXML(install_xml or final_xml, 0)
>>    File "/usr/lib64/python3.6/site-packages/libvirt.py", line 4393, in
>> createXML
>>      raise libvirtError('virDomainCreateXML() failed')
>> libvirt.libvirtError: unsupported configuration: cannot add redirected
>> USB device: USB is disabled for this domain
>>
>> So in the latest code the VM is marked as supporting spice and later
>> wants to add a DeviceRedirdev. The 3.2.0 code always just failed for
>> spice if 'is_qemu()' was false.
> Okay, interesting. Can you provide the full --debug output? Probably our
> code that adds usb2/usb3 support by default is not triggering for xen.
> There might be something we need to tweak here. This could be a bug on
> its own since it probably means explicit `--graphics spice` on the cli
> doesn't work when it should.
>
> Can you also try adding `--redirdev none` on the cli and see if that
> fixes it, or hits another error?

With '--redirdev none':
ERROR    unsupported configuration: channel target type not supported

With '--channel none':
ERROR    internal error: libxenlight failed to create new domain <name>

This last error is because the default sound card is ich6. Adding 
'--soundhw ac97'
Success in starting the installation.

Final spice related changes for starting a Xen HVM installation,
--graphics spice --redirdev none --channel none --soundhw ac97

Also what works is just using '--graphics vnc' with none of the other 
options above.

The Xen driver in libvirt doesn't support spice usb redirection (Xen's 
libxl library does but
it isn't wired up in libvirt at this time). It does support the spice 
display type and port
and a handful of other spice related options. The display type can be 
changed to 'spice'
manually in virt-manager without adding the other spice devices if users 
want that.

>
> But my change wasn't intended to change the default for xen from vnc to
> spice. I didn't think xen supported spice so I didn't expect it to be
> advertised in domcaps. Rather than hack the domcaps check, I think we
> should make this explicit at the source: devices/graphics.py
> _default_type function. I've pushed this bit which I think will fix your
> case:
>
> diff --git a/virtinst/devices/graphics.py b/virtinst/devices/graphics.py
> index a91db289..0c3499ef 100644
> --- a/virtinst/devices/graphics.py
> +++ b/virtinst/devices/graphics.py
> @@ -155,10 +155,16 @@ class DeviceGraphics(Device):
>       def _default_type(self, guest):
>           gtype = guest.default_graphics_type
>           log.debug("Using default_graphics=%s", gtype)
> +
> +        if self.conn.is_xen():
> +            # Xen domcaps can advertise spice support, but we have
> historically
> +            # not defaulted to it for xen, so force vnc.
> +            log.debug("Not defaulting to spice for xen driver. Using vnc.")
> +            gtype = "vnc"
> +

Verified this works.

Thanks!

Charles





More information about the virt-tools-list mailing list