[Libguestfs] [virt-v2v RFC wave 2 03/10] convert/windows_virtio: restrict the warning with virtio-win.iso absent

[Richard W.M. Jones]

On Tue, Nov 09, 2021 at 11:55:32AM +0100, Laszlo Ersek wrote:
> On 11/06/21 18:40, Richard W.M. Jones wrote:
> > On Sat, Nov 06, 2021 at 04:45:33PM +0100, Laszlo Ersek wrote:
> >> On 11/02/21 09:52, Richard W.M. Jones wrote:
> >>> I hesitate to submit patches for parts of the code where someone else
> >>> is working since it creates a mess of conflicts, but would you like me
> >>> to have a go at a patch for removing rcaps?
> >>
> >> Yes, absolutely; please go ahead and do it. I'm happy to rebuild my
> >> patches on top of that -- I won't really approach the new situation as a
> >> rebase, with conflicts to resolve, but as a series of potential
> >> individual cherry picks, and reimplementations from zero.
> > 
> > I'll have a go at this, probably not going to be til Monday though.
> 
> I'm done with the raw rebase (without handling the OVF, JSON and
> OpenStack outputs).
> 
> I've noticed that the cirrus device model has become effectively dead
> too, meaning both the Cirrus constructor of type "guestcaps_video_type",
> and the Source_Cirrus constructor of type "source_video".
> 
> If I remove those constructors, then each type will be left with a
> single constructor -- "guestcaps_video_type" will only have Standard_VGA
> (not parametric), and "source_video" will have only "Source_other_video
> of string" (basically: a string).
> 
> This suggests that "guestcaps_video_type" should be eliminated
> altogether (its occurrences could be replaced by constants),

This bit certainly seems to make sense - if there's "only VGA" then
there's nothing that needs to be expressed by guestcaps_video_type.

Guestcaps is used to communicate from the conversion stage to the
output stage what the guest supports.  Previous to your patch we had
to tell the output stage if the guest supported QXL or had to use
Cirrus.  Presumably that's no longer needed.

> and that
> "source_video" should be replaced by plain "string".
>
> (I'll go further: "source_video" looks unused beyond "--print-source",
> so it could be removed fully as well!)

Yes, --print-source is for debugging and troubleshooting virt-v2v.  If
the information is not strictly required for v2v (and especially as it
is present elsewhere, eg in the source VMX or source libvirt XML) then
there's no need to print it.

> Should I attempt doing this at the end of the series?

Seems entirely reasonable.

> I'm asking now because these simplifications look technically possible
> even before I start investigating the "OVF video device" topic. I expect
> the latter to turn into an infinite mess, so if I can (or should) tack
> the cirrus cleanup patches to the end of my series, I figure I'd like to
> do that first.

OVF is always "fun".  Just remember it's not a standard, it's a
collection of formats, each targeted at a specific hypervisor,
sometimes several different formats for one hypervisor, that happen to
share some common XML elements some of the time.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW