| Summary: | virtio serial device fails to read on Windows 7 guest after libvirt update | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Wesley H <wesley> |
| Component: | virtio-win | Assignee: | Gal Hammer <ghammer> |
| Status: | CLOSED WORKSFORME | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | acathrow, bcao, bsarathy, nat, qzhang, rhod, virt-maint |
| Target Milestone: | rc | ||
| Target Release: | 7.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-01 22:57:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
You probably get the ERROR_NO_SYSTEM_RESOURCES error because no one is listening on the host side. Did you connect (using socat or nc) to the created /dev/pty/xxx? (In reply to Gal Hammer from comment #1) > You probably get the ERROR_NO_SYSTEM_RESOURCES error because no one is > listening on the host side. Did you connect (using socat or nc) to the > created /dev/pty/xxx? We're attempting to create a host -> guest communication channel in the scenario above, not vice versa. The error is raised when we're trying to read from the device on the guest side. The cause of ERROR_NO_SYSTEM_RESOURCES is: "This problem occurs because the cache manager cannot allocate any more memory for the file caching." We're only trying to read 4K on the guest side though, so this shouldn't be happening. Also, this worked with the previous version of the RPM. (In reply to Wesley H from comment #2) > (In reply to Gal Hammer from comment #1) > > You probably get the ERROR_NO_SYSTEM_RESOURCES error because no one is > > listening on the host side. Did you connect (using socat or nc) to the > > created /dev/pty/xxx? > > We're attempting to create a host -> guest communication channel in the > scenario above, not vice versa. The error is raised when we're trying to > read from the device on the guest side. You still need to be connected to the pty channel on the host side. Did you do it? > The cause of ERROR_NO_SYSTEM_RESOURCES is: > > "This problem occurs because the cache manager cannot allocate any more > memory for the file caching." > > We're only trying to read 4K on the guest side though, so this shouldn't be > happening. > > Also, this worked with the previous version of the RPM. Which version of the driver was it? (In reply to Gal Hammer from comment #3) > You still need to be connected to the pty channel on the host side. Did you > do it? To write to it, yes. > Which version of the driver was it? Version: 61.65.104.6500 (In reply to Wesley H from comment #4) > (In reply to Gal Hammer from comment #3) > > > You still need to be connected to the pty channel on the host side. Did you > > do it? > > To write to it, yes. There goes theory #1... :-( > > Which version of the driver was it? > > Version: 61.65.104.6500 Can you please try to reproduce with a newer driver? 61.65.104.7400 is the latest. Also please provide qemu's version and its command line. (In reply to Gal Hammer from comment #5) > (In reply to Wesley H from comment #4) > > (In reply to Gal Hammer from comment #3) > > > > > You still need to be connected to the pty channel on the host side. Did you > > > do it? > > > > To write to it, yes. > > There goes theory #1... :-( > > > > Which version of the driver was it? > > > > Version: 61.65.104.6500 > > Can you please try to reproduce with a newer driver? 61.65.104.7400 is the > latest. Also please provide qemu's version and its command line. How can I get a newer version of the driver? qemu rpm version: 0.12.1.2-2.415 What do you mean by its command line? (In reply to Wesley H from comment #6) > (In reply to Gal Hammer from comment #5) > > (In reply to Wesley H from comment #4) > > > (In reply to Gal Hammer from comment #3) > > > > > > > You still need to be connected to the pty channel on the host side. Did you > > > > do it? > > > > > > To write to it, yes. > > > > There goes theory #1... :-( > > > > > > Which version of the driver was it? > > > > > > Version: 61.65.104.6500 > > > > Can you please try to reproduce with a newer driver? 61.65.104.7400 is the > > latest. Also please provide qemu's version and its command line. > > How can I get a newer version of the driver? > > qemu rpm version: 0.12.1.2-2.415 > > What do you mean by its command line? The command line which is used to execute qemu. $ ps auxwww | grep qemu qemu cmd line: https://gist.github.com/anonymous/6fca6f35fabff1b9ad29 It's also worth noting that this all worked with the previous version of the libvirt rpms. Forgive my ignorance if this isn't right, but are the drivers packaged with those rpms? Then, when I configure a virtio serial device (through virsh or otherwise), it uses those drivers, right? Also, this is a guess/theory, but is it possible the driver is trying to allocate way more memory than needed when reading? Hence the "not enough resources" error. (In reply to Wesley H from comment #8) > qemu cmd line: https://gist.github.com/anonymous/6fca6f35fabff1b9ad29 > > It's also worth noting that this all worked with the previous version of the > libvirt rpms. Forgive my ignorance if this isn't right, but are the drivers Gal ,so is it a libvirt regression ? (In reply to Wesley H from comment #8) > qemu cmd line: https://gist.github.com/anonymous/6fca6f35fabff1b9ad29 Thanks. Nothing pops up, expect that I wonder how do you know which pty is assign to the "test_inbound" channel and which one to the "test_outbound" channel? > It's also worth noting that this all worked with the previous version of the > libvirt rpms. Forgive my ignorance if this isn't right, but are the drivers > packaged with those rpms? Then, when I configure a virtio serial device > (through virsh or otherwise), it uses those drivers, right? I'm not sure I understand your question. The libvirt rpm doesn't include the Windows drivers. > Also, this is a guess/theory, but is it possible the driver is trying to > allocate way more memory than needed when reading? Hence the "not enough > resources" error. Unless you found a new bug in the driver it is unlikely. (In reply to Mike Cao from comment #9) > (In reply to Wesley H from comment #8) > > qemu cmd line: https://gist.github.com/anonymous/6fca6f35fabff1b9ad29 > > > > It's also worth noting that this all worked with the previous version of the > > libvirt rpms. Forgive my ignorance if this isn't right, but are the drivers > > Gal ,so is it a libvirt regression ? I don't know yet. Still trying to figure it out or maybe reproduce. Dear Wesley, Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto |
Description of problem: When attempting to read from a virtio serial device in a Windows 7 x86_64 Guest, the following error is reported: 0x000005AA ERROR_NO_SYSTEM_RESOURCES Version-Release number of selected component (if applicable): libvirt-0.10.2-29 How reproducible: Always Steps to Reproduce: 1. Configure virtio serial device for guest a. Example xml: <channel type='pty'> <target type='virtio' name='test_outbound'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> 2. Compile the following: https://gist.github.com/wholevin/8060413 3. Run via command line with your virtio serial device name as an argument Actual results: Immediately returns with error code 1450 Expected results: Successful open, and will block until data is read from the host pty.