Bug 619349

Summary: [RFE] Please expand virtio-drivers.vfd in virtio-win package
Product: Red Hat Enterprise Linux 6 Reporter: Matthew Booth <mbooth>
Component: virtio-winAssignee: Jay Greguske <jgreguske>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: acathrow, hbrock, llim, mikeb, qzhang, rjones, syeghiay, tburke, ykaul
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: virtio-win-1.0.0-8.3.41879.el6 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 636516 (view as bug list) Environment:
Last Closed: 2010-11-11 15:01:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 617635, 636516    

Description Matthew Booth 2010-07-29 10:51:28 UTC
Description of problem:
virt-v2v needs to install the viostor drivers into an offline image. We need viostor.sys relevant to the target image to do this. We currently include the relevant files taken from virtio-drivers in the virt-v2v package itself, but we'd like to stop doing this.

Could the virtio-win package please install, in addition to virtio-win.iso and virtio-drivers.vfd, the complete expanded contents of virtio-drivers.vfd.

Version-Release number of selected component (if applicable):
virtio-win-1.0.0-8.2.41879.el6.noarch

Comment 1 Yaniv Kaul 2010-07-29 10:59:29 UTC
I've suggested in the past that the contents of the VFD would be expanded in the ISO's root directory, to ease installation of the drivers from the ISO (and not only from the VFD - which RHEVM cannot attach to the VM while it's up). 
This will probably satisfy your requirement as well, no?

Comment 2 Matthew Booth 2010-07-29 11:05:27 UTC
Unfortunately no, because we'd still have to extract them from the iso at runtime. It would be as awkward as trying to pull them from the vfd, for example. I was proposing that they be expanded on the host filesystem.

However, I was surprised when I discovered the vfd contents weren't on the iso. I believe this would be separately worthwhile.

Comment 3 Dor Laor 2010-08-03 09:19:23 UTC
Why not take all of them from the iso? It is easy to mount and all the drivers exist there

Comment 4 Richard W.M. Jones 2010-08-03 09:58:05 UTC
It's indirect.  Why not construct the ISO on the fly?

What we really need is to have the drivers available in known locations
that won't change.

Comment 5 Dor Laor 2010-08-03 10:50:15 UTC
We need the iso to serve as simple install/upgrade tool for users.
All of the internal directories are known and guaranteed to stick

Comment 6 Matthew Booth 2010-08-03 11:10:10 UTC
So we can pull files out of the vfd (note: the ISO doesn't contain the files we're interested in) on the fly. However, this requires that the tool has to mount and unmount the vfd on the fly every time it runs, which is untidy, error-prone, and requires that the tool runs as root.

We're asking for the package to contain:

* The vfd
* The expanded contents of the vfd
* The ISO image

This would only add ~128k to the uncompressed size of the package.

Thanks,

Matt

Comment 7 Richard W.M. Jones 2010-08-03 11:19:23 UTC
We could do it with guestfish or virt-tar.  However I still think that
expanding the drivers we need is the best course of action here.

Comment 8 Mike Bonnet 2010-08-09 20:58:09 UTC
I can't think of any reason not to do this.  Where do we want to put the expanded drivers?  Under /usr/share/virtio-win?  Should it follow the same structure as the .vfd?  Something like:

/usr/share/virtio-win/drivers/i386/Win2003/viostor.sys
/usr/share/virtio-win/drivers/amd64/Win2008/netkvm.cat

etc?

Alternatively we could just create a .zip file with the same structure as the .vfd and drop it into the current directory next to the vfd.  Preferences?

Comment 18 releng-rhel@redhat.com 2010-11-11 15:01:52 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.