On Wed, May 18, 2016 at 02:00:56PM +0200, Cédric Bosdonnat wrote:
Setting spice display if we know the libvirt guest doesn't have
QXL
capabilities will only make the guest slower for the user. Fallback
to VNC in such a case.
A typical use case is when v2v-ing a windows guest without having the
windows QXL driver at hand.
---
v2v/output_libvirt.ml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/v2v/output_libvirt.ml b/v2v/output_libvirt.ml
index bedd6b4..1999600 100644
--- a/v2v/output_libvirt.ml
+++ b/v2v/output_libvirt.ml
@@ -239,7 +239,9 @@ let create_libvirt_xml ?pool source target_buses guestcaps
| Some { s_display_type = VNC } ->
e "graphics" [ "type", "vnc" ] []
| Some { s_display_type = Spice } ->
- e "graphics" [ "type", "spice" ] [] in
+ match guestcaps.gcaps_video with
+ | QXL -> e "graphics" [ "type", "spice" ] []
+ | Cirrus -> e "graphics" [ "type", "vnc" ] []
in
(match source.s_display with
| Some { s_keymap = Some km } -> append_attr ("keymap", km) graphics
I didn't have a comment on this patch before, but it doesn't
look correct to me now.
What it says is if we have a guest which originally was using SPICE
[quite unusual -- does Xen support SPICE? if not, what kind of source
hypervisor supports SPICE?], but during conversion we didn't manage to
install a QXL driver, then we should switch the guest to use VNC.
But that's a problem for two reasons:
(a) You can use SPICE without any special drivers. It falls back to
emulating a high resolution SVGA device.
(b) We're changing the access method from SPICE to VNC, unnecessarily.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html