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@xxxxxxxx>
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
