Bug 1782636 - virtio-win iso's volume label is virtio-win-1.9.1 which is not correct
Summary: virtio-win iso's volume label is virtio-win-1.9.1 which is not correct
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Vadim Rozenfeld
QA Contact: xiagao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-12 01:40 UTC by xiagao
Modified: 2020-04-28 16:06 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:05:15 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
virtio-win cdrom info on guest. (151.36 KB, image/png)
2019-12-12 01:40 UTC, xiagao
no flags Details
disk management (116.27 KB, image/png)
2019-12-13 02:01 UTC, xiagao
no flags Details
iso name in guest of draft iso (87.41 KB, image/png)
2020-02-17 03:16 UTC, xiagao
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:1757 None None None 2020-04-28 16:06:07 UTC

Description xiagao 2019-12-12 01:40:01 UTC
Created attachment 1644254 [details]
virtio-win cdrom info on guest.

Description of problem:
as $summary

Version-Release number of selected component (if applicable):
virtio-win-1.9.10-0.el8.noarch

How reproducible:
100%

Steps to Reproduce:
1.install latest virtio-win-1.9.10-0.el8.noarch in rhel8 host
2.check iso file
# rpm -ql virtio-win-1.9.10-0.el8.noarch
/usr/share/virtio-win/virtio-win-1.9.10.iso
/usr/share/virtio-win/virtio-win.iso
......
3.boot win2019 guest with virtio-win-1.9.10.iso

4.check virtio-win volume


Actual results:
virtio-win volume label is: virtio-win-1.9.1

Expected results:
virtio-win-1.9.10

Additional info:

Comment 1 Danilo Cesar Lemes de Paula 2019-12-12 11:36:57 UTC
For the record: I've read somewhere that the labels in some filesystems are limited to 11 chars.
This is not the case here (as it's showing around 15 chars).

I checked the data in Linux and it shows 'virtio-win-1.9.10' as volume label.
In a linux guest it also shows 'virtio-win-1.9.10' as CDROM, so the problem isn't the package or the iso.

I believe this can be one of those two:
 1 - This is an emulation problem (eg: a bug in qemu).
 2 - This is a test problem (eg: the label is correct, but the window is small and got cut off)

Xiagao: Can you try to check the label in the filesystem manager? Going into properties or something like that. In my old days of windows I remember using a tool like a file disk manager. We can check if the information is wrong there.
I know the screenshot also shows the information in a terminal, but I'm not sure how much can we trust it. I just want to be sure that this is an actual bug before moving this to a developer.

Comment 3 xiagao 2019-12-13 02:01:41 UTC
Created attachment 1644611 [details]
disk management

Comment 4 xiagao 2019-12-13 02:11:30 UTC
(In reply to Danilo Cesar de Paula from comment #1)
> For the record: I've read somewhere that the labels in some filesystems are
> limited to 11 chars.
> This is not the case here (as it's showing around 15 chars).
> 
> I checked the data in Linux and it shows 'virtio-win-1.9.10' as volume label.
> In a linux guest it also shows 'virtio-win-1.9.10' as CDROM, so the problem
> isn't the package or the iso.
> 
> I believe this can be one of those two:
>  1 - This is an emulation problem (eg: a bug in qemu).
>  2 - This is a test problem (eg: the label is correct, but the window is
> small and got cut off)
I don't think it's the window's problem, if changing the view by list, it's still 1.9.1

> 
> Xiagao: Can you try to check the label in the filesystem manager? Going into
> properties or something like that. In my old days of windows I remember
> using a tool like a file disk manager. We can check if the information is
> wrong there.
Do you mean in the disk management, I created a screenshot in attachment. 
It's still 1.9.1 and no content got cut off.

> I know the screenshot also shows the information in a terminal, but I'm not
> sure how much can we trust it. I just want to be sure that this is an actual
> bug before moving this to a developer.

Comment 5 Danilo Cesar Lemes de Paula 2019-12-13 10:11:17 UTC
Since this is not a distribution problem, I will reassign to Amnon so he can evaluate an developer to investigate this further.

Comment 10 Vadim Rozenfeld 2020-01-08 02:57:44 UTC
Disabling Joliet (removing "-J" flag from 
/usr/bin/mkisofs \
    -m 'virtio-win*.vfd' \
    -m vfddrivers \
    -m %{qemu_ga_win_build} \
    -o %{name}-%{version}.iso \
    -r -J \
    -input-charset iso8859-1 \
    -V "%{name}-%{version}" .
in virtio-win.spec file ) seems to be fixing this problem.

Danilo, can you give it a try and see how it works?

Best,
Vadim.

Comment 11 Vadim Rozenfeld 2020-01-08 07:57:21 UTC
Just for the record.
Looks as Microsoft doesn't use Joliet either.

[vrozenfe@huan tmp]$ isoinfo -d -i /images/isos/18362.448.191016-1855.19H1_RELEASE_SVC_PROD3_CLIENTMULTICOMBINED_UUP_A64FRE_EN-US.ISO 
CD-ROM is in ISO 9660 format
System id: 
Volume id: CCSA_A64FRE_EN-US_DV5
Volume set id: CCSA_A64FRE_EN-US_DV5
Publisher id: MICROSOFT CORPORATION
Data preparer id: MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080
Application id: OSCDIMG 2.56 (01/01/2005 TM)
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 2631710
El Torito VD version 1 found, boot catalog is in sector 22
NO Joliet present   <------------------------------------------- NO JOLIET !!!!
NO Rock Ridge present

Comment 12 Danilo Cesar Lemes de Paula 2020-01-10 14:56:51 UTC
Two thoughts:

Disabling joliet seems to be a workaround for a bug we don't know where it is.
 
The main feature of using joliet is to allow bigger filenames (afaik, I'm no windows expert).
But we don't depend on it.

It seems fine from my point of view, but I would like to see someone else input.
@Cole, can you see any problem in doing this?

Comment 13 Cole Robinson 2020-01-13 17:02:42 UTC
I don't know enough to say whether it's okay to drop -J or not. My initial thought it is we couldn't do it without some testing: there's lots of projects that are consuming the file layout of the iso programmatically, and I don't know how -J may affect their usage or now.

Comment 14 Vadim Rozenfeld 2020-01-13 21:12:42 UTC
Can we make a new iso, without Joliet turned on, and let QE to do some preliminary testing? 
From my side, I'm going to try building an iso with oscdimg.exe and check if enabling Joliet 
has the same effect when using MS tools.

Comment 20 Richard W.M. Jones 2020-02-11 12:39:16 UTC
Will the filenames be different for a Linux consumer?  I see we've
still got the -r ("rational Rock Ridge") flag, so I suppose not.

Is there a new ISO image which I can ask Tingting to test?

Comment 24 xiagao 2020-02-17 03:16:42 UTC
Created attachment 1663427 [details]
iso name in guest of draft iso

It works with iso in comment 23.

Comment 25 Vadim Rozenfeld 2020-02-17 04:54:04 UTC
(In reply to xiagao from comment #24)
> Created attachment 1663427 [details]
> iso name in guest of draft iso
> 
> It works with iso in comment 23.

Do we have any formal iso evaluation procedure?
Because not only Joliet was dropped in this case.
I also changed iso level to 4 to keep the same
letter cases as in the original iso.

Best,
Vadim.

Comment 26 xiagao 2020-02-17 09:12:59 UTC
(In reply to Vadim Rozenfeld from comment #25)
> (In reply to xiagao from comment #24)
> > Created attachment 1663427 [details]
> > iso name in guest of draft iso
> > 
> > It works with iso in comment 23.
> 
> Do we have any formal iso evaluation procedure?
> Because not only Joliet was dropped in this case.
> I also changed iso level to 4 to keep the same
> letter cases as in the original iso.
> 
> Best,
> Vadim.

@lijin  I don't know if we have such a procedure, could you help to check?

Comment 27 lijin 2020-02-17 10:21:22 UTC
(In reply to Vadim Rozenfeld from comment #25)
> (In reply to xiagao from comment #24)
> > Created attachment 1663427 [details]
> > iso name in guest of draft iso
> > 
> > It works with iso in comment 23.
> 
> Do we have any formal iso evaluation procedure?
> Because not only Joliet was dropped in this case.
> I also changed iso level to 4 to keep the same
> letter cases as in the original iso.



As far as I know, KVM QE does not have a formal procedure for that.

I check two commands that we used in our automation scripts: 
1. mkisofs -o %s -max-iso9660-filenames -relaxed-filenames -D --input-charset iso8859-1 %s    % (self.path, self.mount)
2. mkisofs -o $ISO_CREATE_ROOT_PATH/$VIRTIO_WIN_ISO_NAME -input-charset iso8859-1 -J -R -V "Virtio-Win" $VIR_WIN_TGT_ISO_PATH

Comment 28 Richard W.M. Jones 2020-02-18 12:32:25 UTC
(In reply to Vadim Rozenfeld from comment #25)
> (In reply to xiagao from comment #24)
> > Created attachment 1663427 [details]
> > iso name in guest of draft iso
> > 
> > It works with iso in comment 23.
> 
> Do we have any formal iso evaluation procedure?

Yes, the QE team test virt-v2v with the virtio-win ISO (from brew normally).

I downloaded the ISO you provided, and did a couple of quick tests.  Firstly
I compared the filenames in virtio-win-1.9.10-3.el8.noarch with the filenames
in your ISO (using virt-ls).  The filenames are identical but there are some
odd differences in apparent file sizes, eg:

-- 0555       2728 /Balloon/2k16/amd64/balloon.inf
-- 0555     962560 /Balloon/2k16/amd64/balloon.pdb
-- 0555      50376 /Balloon/2k16/amd64/balloon.sys
-- 0555     168648 /Balloon/2k16/amd64/blnsvr.exe
-- 0555    6352896 /Balloon/2k16/amd64/blnsvr.pdb
+- 0555          0 /Balloon/2k16/amd64/balloon.inf
+- 0555          0 /Balloon/2k16/amd64/balloon.pdb
+- 0555          0 /Balloon/2k16/amd64/balloon.sys
+- 0555          0 /Balloon/2k16/amd64/blnsvr.exe
+- 0555          0 /Balloon/2k16/amd64/blnsvr.pdb

These seem to be real problems.  Could there be a problem with the way
that you created the ISO?

For my second test I did a v2v conversion of a Windows guest using
virt-v2v 1.40.2rhel=8,release=20.module+el8.2.0+5433+9e1420c8,libvirt
and your ISO.  The conversion actually worked, which is sort of
expected (virt-v2v doesn't really care about what's in the files or
if they are empty, since it only copies them into the guest image
and modifies the Registry to pick them up at first boot).  I suspect
if I had a Windows guest that I could boot then it would have failed
at that point, assuming those files really are empty.

Comment 29 Vadim Rozenfeld 2020-02-18 13:02:14 UTC
(In reply to Richard W.M. Jones from comment #28)
> (In reply to Vadim Rozenfeld from comment #25)
> > (In reply to xiagao from comment #24)
> > > Created attachment 1663427 [details]
> > > iso name in guest of draft iso
> > > 
> > > It works with iso in comment 23.
> > 
> > Do we have any formal iso evaluation procedure?
> 
> Yes, the QE team test virt-v2v with the virtio-win ISO (from brew normally).
> 
> I downloaded the ISO you provided, and did a couple of quick tests.  Firstly
> I compared the filenames in virtio-win-1.9.10-3.el8.noarch with the filenames
> in your ISO (using virt-ls).  The filenames are identical but there are some
> odd differences in apparent file sizes, eg:
> 
> -- 0555       2728 /Balloon/2k16/amd64/balloon.inf
> -- 0555     962560 /Balloon/2k16/amd64/balloon.pdb
> -- 0555      50376 /Balloon/2k16/amd64/balloon.sys
> -- 0555     168648 /Balloon/2k16/amd64/blnsvr.exe
> -- 0555    6352896 /Balloon/2k16/amd64/blnsvr.pdb
> +- 0555          0 /Balloon/2k16/amd64/balloon.inf
> +- 0555          0 /Balloon/2k16/amd64/balloon.pdb
> +- 0555          0 /Balloon/2k16/amd64/balloon.sys
> +- 0555          0 /Balloon/2k16/amd64/blnsvr.exe
> +- 0555          0 /Balloon/2k16/amd64/blnsvr.pdb
> 
> These seem to be real problems.  Could there be a problem with the way
> that you created the ISO?


I think I know where the problem comes from.
Will try to prepare a new iso image shortly.


> 
> For my second test I did a v2v conversion of a Windows guest using
> virt-v2v 1.40.2rhel=8,release=20.module+el8.2.0+5433+9e1420c8,libvirt
> and your ISO.  The conversion actually worked, which is sort of
> expected (virt-v2v doesn't really care about what's in the files or
> if they are empty, since it only copies them into the guest image
> and modifies the Registry to pick them up at first boot).  I suspect
> if I had a Windows guest that I could boot then it would have failed
> at that point, assuming those files really are empty.

Comment 30 Vadim Rozenfeld 2020-02-19 08:27:15 UTC
This one should be better
http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip

I tried to check the original and this new isos with 
diff -qr /mnt/iso/ /mnt/iso1/ where
/home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
/home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)

They seem to be equal, but I can be missing something.

Comment 31 tingting zheng 2020-02-19 08:50:20 UTC
(In reply to Vadim Rozenfeld from comment #30)
> This one should be better
> http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip
> 
> I tried to check the original and this new isos with 
> diff -qr /mnt/iso/ /mnt/iso1/ where
> /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on
> /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type
> iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> 
> They seem to be equal, but I can be missing something.

Is this iso suitable for testing from virt-v2v's side,if so QE will test it using virt-v2v.

Comment 32 Vadim Rozenfeld 2020-02-19 08:59:59 UTC
(In reply to tingting zheng from comment #31)
> (In reply to Vadim Rozenfeld from comment #30)
> > This one should be better
> > http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip
> > 
> > I tried to check the original and this new isos with 
> > diff -qr /mnt/iso/ /mnt/iso1/ where
> > /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on
> > /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> > /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type
> > iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> > 
> > They seem to be equal, but I can be missing something.
> 
> Is this iso suitable for testing from virt-v2v's side,if so QE will test it
> using virt-v2v.

It should be on a par with the original iso from virtio-win-1.9.10-3.el8 package.
So, in my understanding, it should be fine to try it for v2v.

Comment 33 xiagao 2020-02-19 09:16:34 UTC
(In reply to Vadim Rozenfeld from comment #30)
> This one should be better
> http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip
> 
> I tried to check the original and this new isos with 
> diff -qr /mnt/iso/ /mnt/iso1/ where
> /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on
> /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type
> iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> 
> They seem to be equal, but I can be missing something.

I test win2012 guest, it works and name shows virtio-win-1.9.10 .

Comment 34 tingting zheng 2020-02-19 12:54:34 UTC
(In reply to Vadim Rozenfeld from comment #32)
> (In reply to tingting zheng from comment #31)
> > (In reply to Vadim Rozenfeld from comment #30)
> > > This one should be better
> > > http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip
> > > 
> > > I tried to check the original and this new isos with 
> > > diff -qr /mnt/iso/ /mnt/iso1/ where
> > > /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso on
> > > /mnt/iso type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> > > /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso on /mnt/iso1 type
> > > iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)
> > > 
> > > They seem to be equal, but I can be missing something.
> > 
> > Is this iso suitable for testing from virt-v2v's side,if so QE will test it
> > using virt-v2v.
> 
> It should be on a par with the original iso from virtio-win-1.9.10-3.el8
> package.
> So, in my understanding, it should be fine to try it for v2v.

Got it,QE will test it and add test result later.

Comment 35 mxie@redhat.com 2020-02-20 07:33:26 UTC
I can reproduce bug with virtio-win-1.9.10-3.el8.noarch in win2019, win2016, win10 and win2012r2 guest, also can reproduce the bug in win2012 guest although xiagao said virtio-win version shows correct in win2012 guest in comment33, the reproduced steps are same with comment0. As rjones said in comment28, this bug won't affect v2v installs drivers from virtio-win for windows guest, so can't help to debug the bug from v2v side.

Comment 37 Vadim Rozenfeld 2020-02-24 01:32:20 UTC
(In reply to mxie@redhat.com from comment #35)
> I can reproduce bug with virtio-win-1.9.10-3.el8.noarch in win2019, win2016,
> win10 and win2012r2 guest, also can reproduce the bug in win2012 guest
> although xiagao said virtio-win version shows correct in win2012 guest in
> comment33, the reproduced steps are same with comment0. As rjones said in
> comment28, this bug won't affect v2v installs drivers from virtio-win for
> windows guest, so can't help to debug the bug from v2v side.

Do you still have the same problem as Richard mentioned in 
https://bugzilla.redhat.com/show_bug.cgi?id=1782636#c28
even with the latest iso 
http://people.redhat.com/vrozenfe/virtio-win-1.9.10.zip
I checked them, the original iso and the new one
with "tree -du -h" and the both look absolutely the same in terms of layout 
and size while the latest on has no Joliet, which means that Windows
can read long volume names

[vrozenfe@panda iso1]$ isoinfo -d -i /home/share/bugs/1782636/usr/share/virtio-win/virtio-win-1.9.10.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: virtio-win-1.9.10
Volume set id: 
Publisher id: 
Data preparer id: 
Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 131255
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
[vrozenfe@panda iso1]$ isoinfo -d -i /home/share/bugs/1782636/usr/share/virtio-win-1.9.10.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: virtio-win-1.9.10
Volume set id: 
Publisher id: 
Data preparer id: 
Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 280207
CD-ROM uses ISO 9660:1999 relaxed format
NO Joliet present
Rock Ridge signatures version 1 found

Comment 38 mxie@redhat.com 2020-02-24 05:46:49 UTC
(In reply to Vadim Rozenfeld from comment #37)
> (In reply to mxie@redhat.com from comment #35)
> > I can reproduce bug with virtio-win-1.9.10-3.el8.noarch in win2019, win2016,
> > win10 and win2012r2 guest, also can reproduce the bug in win2012 guest
> > although xiagao said virtio-win version shows correct in win2012 guest in
> > comment33, the reproduced steps are same with comment0. As rjones said in
> > comment28, this bug won't affect v2v installs drivers from virtio-win for
> > windows guest, so can't help to debug the bug from v2v side.
> 
> Do you still have the same problem as Richard mentioned in 
> https://bugzilla.redhat.com/show_bug.cgi?id=1782636#c28

Hi Vadim
   
   I got same result with Richard if use virt-ls to compare the files between the virtio-win iso file you built in commnet23 and virtio-win iso file which is installed from brewweb, below is the steps to reproduce and detailed difference pls refer to http://pastebin.test.redhat.com/838671

# virt-ls -lR -d rhel8.2-baremetal /home/virtio-win > virtio-win-vadim-new.log
# virt-ls -lR -d rhel8.2-baremetal /home/virtio-win > virtio-win-brew-new.log
# diff virtio-win-brew-new.log virtio-win-vadim-new.log
1c1
< d 0755       4096 /home/virtio-win
---
> d 0755         94 /home/virtio-win
5,11c5,11
< - 0555    1795952 /home/virtio-win/Balloon/2k12/amd64/WdfCoInstaller01011.dll
< - 0444       9433 /home/virtio-win/Balloon/2k12/amd64/balloon.cat
< - 0555       2894 /home/virtio-win/Balloon/2k12/amd64/balloon.inf
< - 0555    1167360 /home/virtio-win/Balloon/2k12/amd64/balloon.pdb
< - 0555      49864 /home/virtio-win/Balloon/2k12/amd64/balloon.sys
< - 0555     168136 /home/virtio-win/Balloon/2k12/amd64/blnsvr.exe
< - 0555    6320128 /home/virtio-win/Balloon/2k12/amd64/blnsvr.pdb
---
> - 0555          0 /home/virtio-win/Balloon/2k12/amd64/WdfCoInstaller01011.dll
> - 0444          0 /home/virtio-win/Balloon/2k12/amd64/balloon.cat
> - 0555          0 /home/virtio-win/Balloon/2k12/amd64/balloon.inf
> - 0555          0 /home/virtio-win/Balloon/2k12/amd64/balloon.pdb
> - 0555          0 /home/virtio-win/Balloon/2k12/amd64/balloon.sys
> - 0555          0 /home/virtio-win/Balloon/2k12/amd64/blnsvr.exe
> - 0555          0 /home/virtio-win/Balloon/2k12/amd64/blnsvr.pdb
14,20c14,20
.....

  
    But I slightly doubt above result because I didn't see any difference when use command 'ls -l' to compare their files, for example, compare the files in Balloon/2k12/amd64

# ls -l virtio-win-vadim/Balloon/2k12/amd64
total 9304
-r--r--r--. 1 root root    9433 Feb 23 23:49 balloon.cat
-r-xr-xr-x. 1 root root    2894 Feb 23 23:49 balloon.inf
-r-xr-xr-x. 1 root root 1167360 Feb 23 23:49 balloon.pdb
-r-xr-xr-x. 1 root root   49864 Feb 23 23:49 balloon.sys
-r-xr-xr-x. 1 root root  168136 Feb 23 23:49 blnsvr.exe
-r-xr-xr-x. 1 root root 6320128 Feb 23 23:49 blnsvr.pdb
-r-xr-xr-x. 1 root root 1795952 Feb 23 23:49 WdfCoInstaller01011.dll

[root@bootp-73-225-155 home]# ls -l virtio-win-brew/Balloon/2k12/amd64
total 9304
-r--r--r--. 1 root root    9433 Feb 23 23:55 balloon.cat
-r-xr-xr-x. 1 root root    2894 Feb 23 23:55 balloon.inf
-r-xr-xr-x. 1 root root 1167360 Feb 23 23:55 balloon.pdb
-r-xr-xr-x. 1 root root   49864 Feb 23 23:55 balloon.sys
-r-xr-xr-x. 1 root root  168136 Feb 23 23:55 blnsvr.exe
-r-xr-xr-x. 1 root root 6320128 Feb 23 23:55 blnsvr.pdb
-r-xr-xr-x. 1 root root 1795952 Feb 23 23:55 WdfCoInstaller01011.dll


   Besides, I use the virtio-win iso which is built in commnet23 as windows guest driver source during v2v conversion, v2v can installs drivers from the iso you built successfully.
# export VIRTIO_WIN=/home/virtio-win-1.9.10.iso 
# virt-v2v -ic vpx://root@10.73.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA   esx6.7-win2019-x86_64 -on esx6.7-win2019-x86_64-vadim --password-file /home/passwd


  Overall, the volume label of virtio-win iso file you built in comment23 shows correct in windows guest and v2v can install drivers from this iso successfully.

Comment 39 Richard W.M. Jones 2020-02-24 09:41:56 UTC
New ISO seems to work fine for me:

$ virt-ls -a virtio-win-1.9.10.iso -m /dev/sda -lR /Balloon/2k16/amd64/
d 0555       2048 /Balloon/2k16/amd64
- 0444      10411 /Balloon/2k16/amd64/balloon.cat
- 0555       2728 /Balloon/2k16/amd64/balloon.inf
- 0555     962560 /Balloon/2k16/amd64/balloon.pdb
- 0555      50376 /Balloon/2k16/amd64/balloon.sys
- 0555     168648 /Balloon/2k16/amd64/blnsvr.exe
- 0555    6352896 /Balloon/2k16/amd64/blnsvr.pdb

Comment 45 Danilo Cesar Lemes de Paula 2020-03-05 16:30:11 UTC
We can include this change in the regular virtio-win package that is going to be built next week (I assume).
Most of the drivers are signed and ready. I believe we're only missing netkvm now.

Meanwhile, is there a patch posted somewhere Vadim?

Comment 46 Vadim Rozenfeld 2020-03-05 23:06:48 UTC
(In reply to Danilo Cesar de Paula from comment #45)
> We can include this change in the regular virtio-win package that is going
> to be built next week (I assume).
> Most of the drivers are signed and ready. I believe we're only missing
> netkvm now.
> 
> Meanwhile, is there a patch posted somewhere Vadim?

Unfortunatly, I was not using the standard iso building  procedure,
but re-created the iso with the following command instead:

genisoimage -V virtio-win-1.9.10 -r -input-charset iso8859-1 -iso-level 4 -o ../virtio-win-1.9.10.iso ./virtio-win

as you can see, comparing with the scrip, which has the following part

/usr/bin/mkisofs \
    -m 'virtio-win*.vfd' \
    -m vfddrivers \
    -m %{qemu_ga_win_build} \
    -o %{name}-%{version}.iso \
    -r -J \
    -input-charset iso8859-1 \
    -V "%{name}-%{version}" .

I just dropped off Joliet (-J) and added "-iso-level 4" parameter.
IIUC the above changes should work with mkisofs as well.

Vadim.

Comment 51 xiagao 2020-03-19 10:14:49 UTC
Verify this bug with virtio-win-1.9.11-1.el8.
virtio-win volume label is: virtio-win-1.9.11

@tingting
Could you verify from v2v side?

Thanks,
Xiaoling

Comment 52 tingting zheng 2020-03-20 01:52:57 UTC
(In reply to xiagao from comment #51)
> Verify this bug with virtio-win-1.9.11-1.el8.
> virtio-win volume label is: virtio-win-1.9.11
> 
> @tingting
> Could you verify from v2v side?

Sure, test result will be added later.

> 
> Thanks,
> Xiaoling

Comment 53 mxie@redhat.com 2020-03-20 03:07:32 UTC
The result is passed when test virtio-win-1.9.11-1.el8.noarch from v2v side, pls refer to below auto testing, all windows cases are passed.

https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/v2v/view/RHEL-8.2/job/v2v-RHEL-8.2-runtest-x86_64-acceptance-ovirt/31/testReport/rhel/convert_vm_to_ovirt/

Comment 54 lijin 2020-03-21 00:47:44 UTC
Change status to verified according to comment#51 and #53

Comment 57 errata-xmlrpc 2020-04-28 16:05:15 UTC
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://access.redhat.com/errata/RHEA-2020:1757


Note You need to log in before you can comment on or make changes to this bug.