Bug 2169232
| Summary: | RFE: reconnect option for stream socket back-end | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Stefano Brivio <sbrivio> | |
| Component: | qemu-kvm | Assignee: | Laurent Vivier <lvivier> | |
| qemu-kvm sub component: | Networking | QA Contact: | Lei Yang <leiyang> | |
| Status: | CLOSED ERRATA | Docs Contact: | ||
| Severity: | medium | |||
| Priority: | unspecified | CC: | chayang, jinzhao, jsuchane, juzhang, laine, leiyang, lvivier, virt-maint, yalzhang, zhguo | |
| Version: | 9.2 | Keywords: | FutureFeature, Triaged | |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
|
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | qemu-kvm-7.2.0-9.el9 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2172098 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-09 07:23:46 UTC | Type: | Feature Request | |
| 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: | 2172098 | |||
Hi Laurent Is there still a plan to support this backend in the current version? If so, could you please help provide the test steps? If not, please help to reset the ITR. Thanks Lei (In reply to Lei Yang from comment #2) > Hi Laurent > > Is there still a plan to support this backend in the current version? If so, Yes, but not sure it will be possible as we are already at milestone 24 > could you please help provide the test steps? If not, please help to reset > the ITR. Test is easy, you can use one QEMU and passt. * With QEMU and passt: 1- start passt: $ ./passt -f Outbound interface (IPv4): enp0s20f0u2u1u2 MAC: host: 04:7b:cb:5c:00:89 DHCP: assign: 192.168.100.30 mask: 255.255.255.0 router: 192.168.100.254 DNS: 192.168.100.254 DNS search list: redhat.com UNIX domain socket bound at /tmp/passt_1.socket You can now start qemu (>= 7.2, with commit 13c6be96618c): kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket or qrap, for earlier qemu versions: ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio 2- start QEMU: /usr/libexec/qemu-kvm -m 1G -enable-kvm -nodefaults -nographic -smp 2 -serial mon:stdio \ -blockdev node-name=disk1,file.driver=file,driver=qcow2,file.driver=file,file.filename=/var/lib/libvirt/images/vm1.qcow2 \ -device virtio-blk,drive=disk1 \ -netdev stream,id=netdev0,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket,reconnect=5 \ -device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 And check in passt terminal you can see something like: accepted connection from PID 1223660 DHCP: ack to request from 9a:2b:2c:2d:2e:2f check guest network is ok by pinging host. 3- kill passt 4- restart passt and check you have in less than 5 seconds: accepted connection from PID 1223660 5- check guest network is ok You can also use two QEMUs back-to-back: 1- start QEMU as a netdev server: /usr/libexec/qemu-kvm -m 1G -enable-kvm -nodefaults -nographic -smp 2 -serial mon:stdio \ -blockdev node-name=disk1,file.driver=file,driver=qcow2,file.driver=file,file.filename=/var/lib/libvirt/images/vm2.qcow2 \ -device virtio-blk,drive=disk1 \ -netdev stream,id=netdev0,server=on,addr.type=unix,addr.path=/tmp/qemu0 \ -device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 Set a static IP address: nmcli con modify 'Wired connection 1' ipv4.method manual ipv4.addresses 10.0.0.2/24 2- start QEMU as a netdev client: /usr/libexec/qemu-kvm -m 1G -enable-kvm -nodefaults -nographic -smp 2 -serial mon:stdio \ -blockdev node-name=disk1,file.driver=file,driver=qcow2,file.driver=file,file.filename=/var/lib/libvirt/images/vm1.qcow2 \ -device virtio-blk,drive=disk1 -netdev stream,id=netdev0,server=off,addr.type=unix,addr.path=/tmp/qemu0,reconnect=5 \ -device virtio-net,mac=9a:2b:2c:2d:2e:1f,netdev=netdev0 Set a static IP address: nmcli con modify 'Wired connection 1' ipv4.method manual ipv4.addresses 10.0.0.1/24 3- in QEMU monitor (Ctrl-a c): on netdev server: (qemu) info network virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=9a:2b:2c:2d:2e:2f \ netdev0: index=0,type=stream,unix:/tmp/qemu0 on netdev client: (qemu) info network virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=9a:2b:2c:2d:2e:1f \ netdev0: index=0,type=stream,unix:/tmp/qemu0 4- ping each other: ping 10.0.0.1 from netdev server, and ping 10.0.0.2 5- stop the netdev server # halt 6- check you cannot ping it from netdev client 7- check info network in netdev client: (qemu) info network virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=9a:2b:2c:2d:2e:1f \ netdev0: index=0,type=stream,connection error 8- restart netdev server (like step 1) 9- check info netdev in client: (qemu) info network virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=9a:2b:2c:2d:2e:1f \ netdev0: index=0,type=stream,unix:/tmp/qemu0 10- check you can ping each other (In reply to Laurent Vivier from comment #3) ... > Test is easy, you can use one QEMU and passt. > > * With QEMU and passt: > > 1- start passt: To build passt: $ git clone git://passt.top/passt $ cd passt $ make Then ./passt -f Lei, I set ITR to 25, if you disagree, please update it. (In reply to Laurent Vivier from comment #10) > Lei, I set ITR to 25, if you disagree, please update it. Thanks in first. It's ok for me,as long as MR can be merged in time. Best Regards Lei Jarda - Is the proper procedure to track libvirt support for a QEMU feature still to clone the BZ with package set to libvirt? If so, can you do that so it's there in the morning? (I would but want to avoid creating extra red tape that is incorrect) (In reply to Laine Stump from comment #15) > Jarda - Is the proper procedure to track libvirt support for a QEMU feature > still to clone the BZ with package set to libvirt? If so, can you do that so > it's there in the morning? (I would but want to avoid creating extra red > tape that is incorrect) Okay, I cloned it to libvirt as bug 2172098. Thanks. 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 (Moderate: qemu-kvm security, bug fix, and enhancement update), 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/RHSA-2023:2162 |
An option to automatically reconnect a qemu stream socket back-end is now available: http://patchwork.ozlabs.org/project/qemu-devel/patch/20230119101645.2001683-1-lvivier@redhat.com/ and backporting this for RHEL 9.2 would benefit the libvirt integration (#2108965) of passt: libvirt could instruct qemu, at least by default, to reconnect to its socket network back-end so that, should passt terminate for any reason, the guest will be able to have functioning networking again as soon as libvirt restarts the passt daemon.