Hide Forgot
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.
Basil, Can you update on the status?
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.
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.
Note that having it in RHEL 8.2 is important for RHV 4.4.
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.
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; ^~~~~~
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?
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.
May I ask what's the status on this?
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.
Hi, Can you please test this build? https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1125096 Thanks.
Changing description as the actual command now in upstream and downstream is "guest-get-devices"
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 \
(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 \
(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.
Got it, thanks for your info, I will do some test to verify this bug.
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}}}]}
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