RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1790455 - Add guest-get-devices command to qemu-ga-win
Summary: Add guest-get-devices command to qemu-ga-win
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 8.0
Assignee: Basil Salman
QA Contact: xiagao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-13 11:40 UTC by Tomáš Golembiovský
Modified: 2021-09-03 15:24 UTC (History)
9 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:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-32126 0 None None None 2021-09-03 15:24:00 UTC
Red Hat Product Errata RHEA-2020:1757 0 None None None 2020-04-28 16:05:30 UTC

Description Tomáš Golembiovský 2020-01-13 11:40:09 UTC
In order for RHV to be able to deprecate it's own guest tools ISO and rely
purely on virtio-win we need to be able to get versions of the drivers
installed in the guest. A patch adding a new 'guest-get-drivers' command to
qemu-ga has been already posted to qemu-devel mailing list:

https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg01727.html

The patch needs to get it's way into qemu-ga-win.

Comment 2 Amnon Ilan 2020-02-09 11:29:26 UTC
Basil, Can you update on the status?

Comment 3 Basil Salman 2020-02-09 21:12:10 UTC
As the patches depend on qemu version greater than 3.1.0-rc0, i had to rebase 
rhpkg repository to use qemu 4.2.0-rc0 instead.

When i tried to build using brew, on el7 machine i was facing the following error:
+ ./build_configure.sh --cross-prefix=i686-w64-mingw32- --enable-guest-agent-msi --with-vss-sdk=/builddir/build/BUILD/qemu-4.2.0-rc0/VSSSDK72 --static
ERROR: glib-2.48 gthread-2.0 is required to compile QEMU
i tried to set the spec file to require this version manually but apparently there is no greater version than 2.46
in the default repositories.

i tried moving to el8 instead:
After solving dependencies issues, i am currently unable to compile this version with static linking
since mingw32-pixman/mingw64-pixman libraries are only availabe with dynamic versions for el8.
i am unable to build qemu-ga with static linking.

once one of these dependecy issues is solved adding the patches to downstream shouldn't be a problem.

Comment 4 xiagao 2020-02-11 03:29:27 UTC
Hi Basil Salman,

Confirm with you one thing.
Do you still want to fix this bug in rhel8.2.0? 
Now is testing phase, only exception+ or blocker+ bzs will be fix, and RFE bugs should be done before this period.

Comment 5 Tomáš Golembiovský 2020-02-11 13:33:48 UTC
Note that having it in RHEL 8.2 is important for RHV 4.4.

Comment 6 Basil Salman 2020-02-12 16:01:39 UTC
Hi,

I am doing my best to fix this as soon as possible so we can try and fix it in rhel8.2.0.
it would be recommended to do so. currently i have no clear ETA on how long will that take.
I will keep you updated.

Comment 7 Basil Salman 2020-02-14 00:16:47 UTC
I was able to fix all the dependency issues for el8.
i am compiling with qemu-4.2.0-rc0.
once i apply the patch it breaks the compilation.

attaching the compilation error:
  CC      qga/commands-win32.o
qga/commands-win32.c: In function 'qmp_guest_get_devices':
qga/commands-win32.c:2453:5: error: expected declaration or statement at end of input
     return head;
     ^~~~~~

Comment 8 Tomáš Golembiovský 2020-02-14 14:04:14 UTC
I have no problem applying the patch to qemu-4.2.0-rc0 and compiling with mingw. Apparently (based on the line number) there were other patches applied to the source. Could you share little bit more details what exactly is included in your build and how are you performing the build?

Comment 9 Basil Salman 2020-02-14 21:54:56 UTC
I had an issue with applying the patch on top of qemu with the patches from upstream.
apparently there is a merge issue between the patch and the last two commits.
anyhow apparently there is another issue with my build, that even if i compile qemu-4.2.0-rc0 flat
i am getting a bad msi installer, which throws an error during installation.

Comment 11 Tomáš Golembiovský 2020-02-25 11:09:04 UTC
May I ask what's the status on this?

Comment 19 Basil Salman 2020-03-04 12:55:36 UTC
The current status is that I am working on back-porting the patch to be able to compile with qemu-3.1.0-rc0 as base.

Comment 21 Basil Salman 2020-03-05 14:31:29 UTC
Hi,

Can you please test this build?
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1125096


Thanks.

Comment 22 Yvugenfi@redhat.com 2020-03-05 14:52:06 UTC
Changing description as the actual command now in upstream and downstream is "guest-get-devices"

Comment 23 xiagao 2020-03-06 02:58:08 UTC
Test with (In reply to Basil Salman from comment #21)
> Hi,
> 
> Can you please test this build?
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1125096
> 
> 
> Thanks.

Test with this build.

{"execute":"guest-get-devices"}
{"return": [
{"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO SCSI pass-through controller", "driver-version": "100.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4168, "vendor-id": 6900}}}, 

{"driver-date": "2020-02-11", "driver-name": "VirtIO Serial Driver", "driver-version": "100.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4163, "vendor-id": 6900}}}, 

{"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO SCSI pass-through controller", "driver-version": "100.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4168, "vendor-id": 6900}}}, 

{"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO Ethernet Adapter #3", "driver-version": "100.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4161, "vendor-id": 6900}}}]}

I have several questions.
1) As I add two virtio-scsi-pci devices, from qga result the two devices info is totally the same, is it right?

2)Redhat's vendor-id is "Red Hat, Inc.",right?

3)And device-id, how do I verify it? Or the device id is certain for every virtio device?

I just get info form qga/qapi-schema.json.
> +# @vendor-id: vendor ID as hexadecimal string in uper case without 0x prefix
> +# @device-id: device ID as hexadecimal string in uper case without 0x prefix




qemu cmd line:
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \

-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=win2019.qcow2,node-name=system_file \
-blockdev driver=qcow2,node-name=drive_system_disk,file=system_file \
-device virtio-scsi-pci,id=scsi0,bus=pci.1 -device scsi-hd,drive=drive_system_disk,bus=scsi0.0,id=system_disk,bootindex=0 \

-netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0,vhost=on,queues=4 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:52:11:36:3f:0d,bus=pci.2,mq=on,vectors=10 \

-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/data-disk1.qcow2,node-name=data_file \
-blockdev driver=qcow2,node-name=drive_data_disk,file=data_file \
-device virtio-scsi-pci,id=scsi1,bus=pci.8 -device scsi-hd,drive=drive_data_disk,bus=scsi1.0,id=data_disk \

-device virtio-serial-pci,id=virtio-serial1,max_ports=31,bus=pci.6 \
-chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait  -device virtserialport,bus=virtio-serial1.0,chardev=channel2,name=org.qemu.guest_agent.0 \

Comment 24 xiagao 2020-03-06 02:59:41 UTC
(In reply to xiagao from comment #23)
> Test with (In reply to Basil Salman from comment #21)
> > Hi,
> > 
> > Can you please test this build?
> > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1125096
> > 
> > 
> > Thanks.
> 
> Test with this build.
> 
> {"execute":"guest-get-devices"}
> {"return": [
> {"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO SCSI
> pass-through controller", "driver-version": "100.82.104.17900", "address":
> {"type": "pci", "data": {"device-id": 4168, "vendor-id": 6900}}}, 
> 
> {"driver-date": "2020-02-11", "driver-name": "VirtIO Serial Driver",
> "driver-version": "100.82.104.17900", "address": {"type": "pci", "data":
> {"device-id": 4163, "vendor-id": 6900}}}, 
> 
> {"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO SCSI
> pass-through controller", "driver-version": "100.82.104.17900", "address":
> {"type": "pci", "data": {"device-id": 4168, "vendor-id": 6900}}}, 
> 
> {"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO Ethernet
> Adapter #3", "driver-version": "100.82.104.17900", "address": {"type":
> "pci", "data": {"device-id": 4161, "vendor-id": 6900}}}]}
> 
> I have several questions.
> 1) As I add two virtio-scsi-pci devices, from qga result the two devices
> info is totally the same, is it right?
> 
> 2)Redhat's vendor-id is "Red Hat, Inc.",right?
correct, Redhat's vendor-id is 6900, I think it's certain.

> 
> 3)And device-id, how do I verify it? Or the device id is certain for every
> virtio device?
> 
> I just get info form qga/qapi-schema.json.
> > +# @vendor-id: vendor ID as hexadecimal string in uper case without 0x prefix
> > +# @device-id: device ID as hexadecimal string in uper case without 0x prefix
> 
> 
> 
> 
> qemu cmd line:
> -device
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,
> addr=0x3 \
> -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
> -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
> -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
> -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
> 
> -blockdev
> driver=file,cache.direct=off,cache.no-flush=on,filename=win2019.qcow2,node-
> name=system_file \
> -blockdev driver=qcow2,node-name=drive_system_disk,file=system_file \
> -device virtio-scsi-pci,id=scsi0,bus=pci.1 -device
> scsi-hd,drive=drive_system_disk,bus=scsi0.0,id=system_disk,bootindex=0 \
> 
> -netdev
> tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0,vhost=on,queues=4 \
> -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:52:11:36:3f:0d,bus=pci.2,mq=on,
> vectors=10 \
> 
> -blockdev
> driver=file,cache.direct=off,cache.no-flush=on,filename=/home/data-disk1.
> qcow2,node-name=data_file \
> -blockdev driver=qcow2,node-name=drive_data_disk,file=data_file \
> -device virtio-scsi-pci,id=scsi1,bus=pci.8 -device
> scsi-hd,drive=drive_data_disk,bus=scsi1.0,id=data_disk \
> 
> -device virtio-serial-pci,id=virtio-serial1,max_ports=31,bus=pci.6 \
> -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait  -device
> virtserialport,bus=virtio-serial1.0,chardev=channel2,name=org.qemu.
> guest_agent.0 \

Comment 25 Tomáš Golembiovský 2020-03-06 09:44:04 UTC
(In reply to xiagao from comment #23)

> {"execute":"guest-get-devices"}
> {"return": [
> {"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO SCSI
> pass-through controller", "driver-version": "100.82.104.17900", "address":
> {"type": "pci", "data": {"device-id": 4168, "vendor-id": 6900}}}, 
> 
> {"driver-date": "2020-02-11", "driver-name": "VirtIO Serial Driver",
> "driver-version": "100.82.104.17900", "address": {"type": "pci", "data":
> {"device-id": 4163, "vendor-id": 6900}}}, 
> 
> {"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO SCSI
> pass-through controller", "driver-version": "100.82.104.17900", "address":
> {"type": "pci", "data": {"device-id": 4168, "vendor-id": 6900}}}, 
> 
> {"driver-date": "2020-02-11", "driver-name": "Red Hat VirtIO Ethernet
> Adapter #3", "driver-version": "100.82.104.17900", "address": {"type":
> "pci", "data": {"device-id": 4161, "vendor-id": 6900}}}]}
> 
> I have several questions.
> 1) As I add two virtio-scsi-pci devices, from qga result the two devices
> info is totally the same, is it right?

That's a good question. I would assume the device would be listed twice with exactly same info. But it is hard to tell without knowing the internal Windows device tree representation.

> 
> 2)Redhat's vendor-id is "Red Hat, Inc.",right?

There are two IDs: 0x1af4 (6900) and 0x1b36 (6966). Both belong to Red Hat, Inc.

> 
> 3)And device-id, how do I verify it? Or the device id is certain for every
> virtio device?

You can either check the INF files for the drivers or compare the IDs with what is in here:

https://github.com/qemu/qemu/blob/master/docs/specs/pci-ids.txt

> 
> I just get info form qga/qapi-schema.json.
> > +# @vendor-id: vendor ID as hexadecimal string in uper case without 0x prefix
> > +# @device-id: device ID as hexadecimal string in uper case without 0x prefix

You're looking at some older version of the patch. The IDs are no longer a hex string but a decimal numbers.

Comment 26 xiagao 2020-03-06 10:26:30 UTC
Got it, thanks for your info, I will do some test to verify this bug.

Comment 27 xiagao 2020-03-09 03:34:59 UTC
Verify this bug.

1. boot up guest with many devices and install drivers.
-device virtio-serial-pci,id=virtio-serial-ga -chardev socket,id=channel-ga,path=/tmp/qga.sock,server,nowait  -device virtserialport,bus=virtio-serial-ga.0,chardev=channel-ga,name=org.qemu.guest_agent.0 \
-device virtio-serial-pci,id=virtio-serial0 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait  -device virtserialport,bus=virtio-serial0.0,chardev=channel1,name=com.redhat.rhevm.vdsm1 \
-device virtio-serial-pci,id=virtio-serial1,disable-legacy=on,disable-modern=false -chardev socket,id=channel2,host=127.0.0.1,port=2222,server,nowait  -device virtserialport,bus=virtio-serial1.0,chardev=channel2,name=com.redhat.rhevm.vdsm2 \

-netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0,vhost=on,queues=4 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:52:3b:35:86:08,mq=on,vectors=10 \
-netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet1,vhost=on,queues=4 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:52:3b:35:86:09,mq=on,vectors=10 \

-device virtio-scsi-pci,id=scsi0,num_queues=4 -drive file=disk1.raw,if=none,id=drive-scsi-disk0,format=raw,cache=none -device scsi-hd,bus=scsi0.0,drive=drive-scsi-disk0,id=scsi-disk0 \
-device virtio-scsi-pci,id=scsi1,num_queues=4 -drive file=disk2.raw,if=none,id=drive-scsi-disk1,format=raw,cache=none -device scsi-hd,bus=scsi1.0,drive=drive-scsi-disk1,id=scsi-disk1 \
-object iothread,id=thread0 \
-drive file=disk5.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,iothread=thread0,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,disable-legacy=on,disable-modern=false \
-drive file=disk6.raw,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,iothread=thread0,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1 \

-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 \
-device virtio-balloon-pci,id=balloon0,disable-legacy=on,disable-modern=false \
-device pvpanic,id=pvpanic0,ioport=0x0505 \
-device virtio-keyboard-pci,id=kbd0,serial=virtio-keyboard -device virtio-mouse-pci,id=mouse0,serial=virtio-mouse -device virtio-tablet-pci,id=tablet0,serial=virtio-tablet \


2. issue {"execute":"guest-get-devices"} from host
{"return": [
{"driver-date": "2020-01-21", "driver-name": "Red Hat VirtIO Ethernet Adapter", "driver-version": "62.82.104.17800", "address": {"type": "pci", "data": {"device-id": 4096, "vendor-id": 6900}}}, 

{"driver-date": "2020-01-21", "driver-name": "Red Hat VirtIO Ethernet Adapter #2", "driver-version": "62.82.104.17800", "address": {"type": "pci", "data": {"device-id": 4096, "vendor-id": 6900}}}, 

{"driver-date": "2019-12-19", "driver-name": "VirtIO Input Driver", "driver-version": "62.81.104.17500", "address": {"type": "pci", "data": {"device-id": 4178, "vendor-id": 6900}}}, 

{"driver-date": "2019-12-19", "driver-name": "VirtIO Input Driver", "driver-version": "62.81.104.17500", "address": {"type": "pci", "data": {"device-id": 4178, "vendor-id": 6900}}}, 

{"driver-date": "2019-12-19", "driver-name": "VirtIO Input Driver", "driver-version": "62.81.104.17500", "address": {"type": "pci", "data": {"device-id": 4178, "vendor-id": 6900}}}, 

{"driver-date": "2020-02-11", "driver-name": "VirtIO Serial Driver", "driver-version": "62.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4163, "vendor-id": 6900}}}, 

{"driver-date": "2020-01-08", "driver-name": "Red Hat VirtIO SCSI controller", "driver-version": "62.81.104.17600", "address": {"type": "pci", "data": {"device-id": 4097, "vendor-id": 6900}}}, 

{"driver-date": "2020-02-11", "driver-name": "VirtIO Serial Driver", "driver-version": "62.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4099, "vendor-id": 6900}}},
 
{"driver-date": "2020-02-11", "driver-name": "VirtIO Serial Driver", "driver-version": "62.82.104.17900", "address": {"type": "pci", "data": {"device-id": 4099, "vendor-id": 6900}}}, 

{"driver-date": "2020-02-19", "driver-name": "Red Hat VirtIO SCSI pass-through controller", "driver-version": "62.82.104.18000", "address": {"type": "pci", "data": {"device-id": 4100, "vendor-id": 6900}}},

{"driver-date": "2020-02-19", "driver-name": "Red Hat VirtIO SCSI pass-through controller", "driver-version": "62.82.104.18000", "address": {"type": "pci", "data": {"device-id": 4100, "vendor-id": 6900}}},
 
{"driver-date": "2020-01-10", "driver-name": "VirtIO Balloon Driver", "driver-version": "62.82.104.17700", "address": {"type": "pci", "data": {"device-id": 4165, "vendor-id": 6900}}}, 

{"driver-date": "2020-01-08", "driver-name": "Red Hat VirtIO SCSI controller", "driver-version": "62.81.104.17600", "address": {"type": "pci", "data": {"device-id": 4162, "vendor-id": 6900}}},
 
{"driver-date": "2019-12-19", "driver-name": "VirtIO RNG Device", "driver-version": "62.81.104.17500", "address": {"type": "pci", "data": {"device-id": 4101, "vendor-id": 6900}}}]}

Comment 32 errata-xmlrpc 2020-04-28 16:05:16 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.