On Thu, Mar 09, 2023 at 05:03:02PM +0200, Andrey Drobyshev wrote:
On 3/9/23 16:50, Andrey Drobyshev wrote:
> On 3/8/23 22:46, Richard W.M. Jones wrote:
>>
>> The patch series looks generally fine, but it really needs a test ...
>>
>> We find that having tests prevents unnoticed regressions from
>> happening later.
>>
>> Rich.
>>
>
> Could you please elaborate on how do you imagine such a test case?
> Basically what I've been doing while making this series is installing a
> guest Win on the VM with an IDE controller only, then plugging
> virtio-scsi controller instead of IDE and running in-place conversion.
> VM should be able to boot as a result.
>
> I guess in the test we should play such a trick with both virtio-blk and
> virtio-scsi. But can we do that using phony windows.img from the
> test-data? And how do we actually check whether the guest is bootable
> after our manipulations?
A quick follow-up: I see that the test framework generally just checks
for the presence of various files and folders after the conversion. Do
you think that feeding v2v a VM config with either
virtio-blk/virito-scsi controllers and running is-file on viostor.sys or
vioscsi.sys accordingly would be enough?
Yeah I would just copy one of the existing Windows tests, eg:
tests/test-v2v-i-disk.sh and modify it to add the new --block-driver
parameter.
Depending on how far you want to go, you might poke inside the guest
image after the test to see if expected files exist using guestfish.
But often it's enough to simply test that the new option doesn't
break.
Don't forget to use a new uniquely named temporary directory
("d=..." variable).
Of course we cannot test real Windows in the test suite :-(
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org