Providing PM Ack to resolve this nominal change

I think this is a logical step I would support it but there is one missing piece and that is support for new wins in qxl. I mean the API for drivers has changed so it is probably a better question for spice-devels if they would have manpower for this enablement from spice point of view.

Spice QE should have capacity to test.

cc-ing David Blechter too.

-Tom

(In reply to Tomas Pelka from comment #2)
> I think this is a logical step I would support it but there is one missing
> piece and that is support for new wins in qxl. I mean the API for drivers
> has changed so it is probably a better question for spice-devels if they
> would have manpower for this enablement from spice point of view.
> 
> Spice QE should have capacity to test.
> 
> cc-ing David Blechter too.
> 
> -Tom

Sorry I've misread the bz, does this "without QXL"  support mean no advanced functions like multimonitor and high res would be expected?

-Tom

Yes, only basic unaccelerated framebuffer would be expected to work.

note we plan to use the QXL card without the driver, not cirrus.
It's the same as for the other Windows OSes, but we need to note in documentation that without drivers it provides less features/less performance

As I mentioned in the original e-mail we are not planing to include win 8 and win 2012 into our test matrix even with low prio. As the spice support is not planed in 3.6.

Having said that I also need to add that spice-qe cant commit to take over thist testing.

Sorry
-Tom

Testing scope (Michal Skrivanek):

It used to work like that in 3.4 so from spice perspective it doesn't need much Rhev qe should just test the effect of UI settings, that spice client can be opened and shows something on W2012/8

(In reply to Michal Skrivanek from comment #0)
> Many people report significant improvement in performance of SPICE console
> even without QXL drivers.
> Let's enable it!
> 
> (also see bug 957827)

And what about spice-vdagent?

(In reply to Ilanit Stein from comment #7)
> Testing scope (Michal Skrivanek):
> 
> It used to work like that in 3.4 so from spice perspective it doesn't need
> much Rhev qe should just test the effect of UI settings, that spice client
> can be opened and shows something on W2012/8

I've talked with Michal and we should be able to provide some initial and sanity testing of VGA mode. So should be fine from our POV.

-Tom

(In reply to David Blechter from comment #9)
> And what about spice-vdagent?

djasa confirmed it works ok, it's useful for copy&paste if nothing else.
we used to have the same configuration in 3.4 till we explicitly disabled SPICE in 3.4.z, there were no complaints about anything AFAIK

Lev, does the installer still install spice tools, even when we don't have qxl drivers?

(In reply to Michal Skrivanek from comment #11)
> (In reply to David Blechter from comment #9)
> > And what about spice-vdagent?
> 
> djasa confirmed it works ok, it's useful for copy&paste if nothing else.
> we used to have the same configuration in 3.4 till we explicitly disabled
> SPICE in 3.4.z, there were no complaints about anything AFAIK
> 
> Lev, does the installer still install spice tools, even when we don't have
> qxl drivers?

Hi Michal,

Yes, we currently install the Spice Agent (vdagent) for all Windows versions, including the ones that we currently don't have a Spice QXL driver for.

Hi Michal, I have a question about this from virt-v2v point of view:

In virt-v2v we can convert many different Windows versions, including
Win2003 which has no QXL drivers.

Virt-v2v always selects QXL for RHEV output, and that was considered
a bug (bug 1213701):
it would be possible for virt-v2v to detect if the guest can do QXL
or Cirrus and write either <rasd:Device>qxl</rasd:Device> or
<rasd:Device>cirrus</rasd:Device>, but it never did this for RHEV output.

The current bug enables framebuffer-only QXL for Windows >= 8, but
doesn't consider older Windows that don't have QXL support (Win2003).

Questions:

Should virt-v2v continue only using QXL for RHEV?

Or should RHEV enable QXL framebuffer-only everywhere?  (Is
there any point using Cirrus if we have QXL)

If we _don't_ do that (ie. if we really fix bug 1213701), then virt-v2v
would need to do something complex like:

if (linux)
  // who knows?
else
  if (windows has QXL drivers || windows > 7)
    use QXL
  else # eg windows 2003
    use Cirrus

That bug existed because of the original decision to block QXL in Windows 8/2012 guests in RHEV-M. 
Here in this bug we removed that restriction and now allow QXL without drivers to be used (it is deemed stable and actually still faster than cirrus even without proper qxl drivers)

I think we can just close that bug 1213701. One can always change it once it's imported...in v2v integration we only allow name, target SD and entwrok mapping to be defined up front, everything else needs to be changed within UI (or API) afterwards.
We didn't want to add too much UI complexity here as the "New VM" dialog is very complex and we want to support multiple VM import - so we want to keep the list of things you need to set before the conversion at minimum, and sort it out only after conversion finishes.
(OTOH it would greatly help to have a "mass edit" feature in UI, as now you have to do it one by one or use the API)

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, 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://rhn.redhat.com/errata/RHEA-2016-0376.html