[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host
Yes, I think it's the same issue. So, are you planning to integrate the following patch into the source code? https://bugs.launchpad.net/qemu/+bug/1914117/comments/10 Or is there a better solution you are working on? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: New Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host
I am not sure if a separate slirp installation via macports is necessary. When you install qemu via homebrew, it's supposed to install any slirp related libarries as part of qemu installation. Having said that, I haven't noticed a slirp package installed on my mac when I did a `brew list`. So, I don't know how exactly is qemu packing slirp libraries within itself while installing on a mac. I think there's some kinda git option during installation. Perhaps brew uses that. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: New Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host
** Description changed: Steps to reproduce: - 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) + 1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: New Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I tried on Catalina and Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host
** Description changed: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) - 2. Spin up a guest VM (say) Cent OS8 using user mode networking. + 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 ** Tags added: libslirp -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: New Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1916344] Re: User mode networking not working properly on QEMU on Mac OS X host
** Description changed: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) 2. Spin up a guest VM (say) Cent OS8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB - unexpected EOF + unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work - together on fixing this. + together on fixing this. Here's the link to the libslirp issue: + + https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: New Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) 2. Spin up a guest VM (say) Cent OS 8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1916344] [NEW] User mode networking not working properly on QEMU on Mac OS X host
Public bug reported: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) 2. Spin up a guest VM (say) Cent OS8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 ** Affects: qemu Importance: Undecided Status: New ** Tags: mac networking osx podman qemu slirp user-mode ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1916344 Title: User mode networking not working properly on QEMU on Mac OS X host Status in QEMU: New Bug description: Steps to reproduce: 1. Install QEMU using homebrew on Mac OS X (I used Big Sur) 2. Spin up a guest VM (say) Cent OS8 using user mode networking. 3. Install podman inside the guest 4. Run podman pull alpine The result is: [root@localhost ~]# podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/alpine:latest... Getting image source signatures Copying blob ba3557a56b15 [==] 2.7MiB / 2.7MiB unexpected EOF Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. Here's the link to the libslirp issue: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916344/+subscriptions
[Bug 1912857] Re: virtio-serial blocks hostfwd ssh on windows 10 host
** Description changed: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> THIS WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev socket,id=cid0,host=localhost,port=55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. The following doesn't work either: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev file,id=cid0,path=mypath No matter which character device I use for my virtserialport communication (socket or udp or file or pipe), the hostfwd doesn't work. Also, if I enable the display, I am unable to type anything in the emulator window when I use virtserialport. Host: Windows 10 Guest: archlinux QEMU version 5.2 + + The same thing works just fine on a Mac OS X host (tested on Big Sur) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1912857 Title: virtio-serial blocks hostfwd ssh on windows 10 host Status in QEMU: New Bug description: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> THIS WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev socket,id=cid0,host=localhost,port=55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. The following doesn't work either: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev file,id=cid0,path=mypath No matter which character device I use for my virtserialport communication (socket or udp or file or pipe), the hostfwd doesn't work. Also, if I enable the display, I am unable to type anything in the emulator window when I use virtserialport. Host: Windows 10 Guest: archlinux QEMU version 5.2 The same thing works just fine on a Mac OS X host (tested on Big Sur) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1912857/+subscriptions
[Bug 1912857] Re: virtio-serial blocks hostfwd ssh on windows 10 host
** Description changed: - qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev - user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> - WORKS - meaning I can ssh into the vm via port + qemu-system-x86_64 + -display none + -hda archlinux.qcow2 + -m 4G + -netdev user,id=n1,hostfwd=tcp::-:22 + -device virtio-net-pci,netdev=n1 - qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev - user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 - -device virtio-serial -device virtserialport,chardev=cid0 -chardev - socket,id=cid0,host:localhost,port:55298,server,nowait --> DOES NOT WORK - - meaning I cannot ssh into the vm + --> THIS WORKS - meaning I can ssh into the vm via port + + qemu-system-x86_64 + -display none + -hda archlinux.qcow2 + -m 4G + -netdev user,id=n1,hostfwd=tcp::-:22 + -device virtio-net-pci,netdev=n1 + -device virtio-serial + -device virtserialport,chardev=cid0 + -chardev socket,id=cid0,host:localhost,port:55298,server,nowait + + --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. The following doesn't work either: - qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev - user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 - -device virtio-serial -device virtserialport,chardev=cid0 -chardev - file,id=cid0,path=temp,server,nowait + qemu-system-x86_64 + -display none + -hda archlinux.qcow2 + -m 4G + -netdev user,id=n1,hostfwd=tcp::-:22 + -device virtio-net-pci,netdev=n1 + -device virtio-serial -device virtserialport,chardev=cid0 + -chardev file,id=cid0,path=temp,server,nowait No matter which character device I use for my virtserialport communication (socket or udp or file or pipe), the hostfwd doesn't work. Host: Windows 10 Guest: archlinux QEMU version 5.2 ** Description changed: - qemu-system-x86_64 - -display none - -hda archlinux.qcow2 - -m 4G - -netdev user,id=n1,hostfwd=tcp::-:22 - -device virtio-net-pci,netdev=n1 + qemu-system-x86_64 + -display none + -hda archlinux.qcow2 + -m 4G + -netdev user,id=n1,hostfwd=tcp::-:22 + -device virtio-net-pci,netdev=n1 --> THIS WORKS - meaning I can ssh into the vm via port - qemu-system-x86_64 - -display none - -hda archlinux.qcow2 - -m 4G - -netdev user,id=n1,hostfwd=tcp::-:22 - -device virtio-net-pci,netdev=n1 - -device virtio-serial - -device virtserialport,chardev=cid0 - -chardev socket,id=cid0,host:localhost,port:55298,server,nowait + qemu-system-x86_64 + -display none + -hda archlinux.qcow2 + -m 4G + -netdev user,id=n1,hostfwd=tcp::-:22 + -device virtio-net-pci,netdev=n1 + -device virtio-serial + -device virtserialport,chardev=cid0 + -chardev socket,id=cid0,host=localhost,port=55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. The following doesn't work either: - qemu-system-x86_64 - -display none - -hda archlinux.qcow2 - -m 4G - -netdev user,id=n1,hostfwd=tcp::-:22 - -device virtio-net-pci,netdev=n1 - -device virtio-serial -device virtserialport,chardev=cid0 - -chardev file,id=cid0,path=temp,server,nowait + qemu-system-x86_64 + -display none + -hda archlinux.qcow2 + -m 4G + -netdev user,id=n1,hostfwd=tcp::-:22 + -device virtio-net-pci,netdev=n1 + -device virtio-serial -device virtserialport,chardev=cid0 + -chardev file,id=cid0,path=temp,server,nowait No matter which character device I use for my virtserialport communication (socket or udp or file or pipe), the hostfwd doesn't work. Host: Windows 10 Guest: archlinux QEMU version 5.2 ** Description changed: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> THIS WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -device virtserialport,chardev=cid0 -chardev socket,id=cid0,host=localhost,port=55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. The following doesn't work either: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 - -device virtio-serial -device virtserialport,chardev=cid0 + -device virtio-serial + -device
[Bug 1912857] Re: virtio-serial blocks hostfwd ssh on windows 10 host
** Description changed:
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -->
WORKS - meaning I can ssh into the vm via port
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1
-device virtio-serial -device virtserialport,chardev=cid0 -chardev
- socket,id=cid0,{socket_addr_serial},server,nowait --> DOES NOT WORK -
- meaning I cannot ssh into the vm
+ socket,id=cid0,host:localhost,port:55298,server,nowait --> DOES NOT WORK
+ - meaning I cannot ssh into the vm
Not only does the port not work, but I am not able to perform any
serial transfer on port 55298 as well.
+ The following doesn't work either:
+
+ qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
+ user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1
+ -device virtio-serial -device virtserialport,chardev=cid0 -chardev
+ file,id=cid0,path=temp,server,nowait
+
+ No matter which character device I use for my virtio-serial-port
+ communication (socket or udp or file or pipe), the hostfwd doesn't work.
+
Host: Windows 10
Guest: archlinux
QEMU version 5.2
** Description changed:
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -->
WORKS - meaning I can ssh into the vm via port
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1
-device virtio-serial -device virtserialport,chardev=cid0 -chardev
socket,id=cid0,host:localhost,port:55298,server,nowait --> DOES NOT WORK
- meaning I cannot ssh into the vm
Not only does the port not work, but I am not able to perform any
serial transfer on port 55298 as well.
The following doesn't work either:
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1
-device virtio-serial -device virtserialport,chardev=cid0 -chardev
file,id=cid0,path=temp,server,nowait
- No matter which character device I use for my virtio-serial-port
+ No matter which character device I use for my virtserialport
communication (socket or udp or file or pipe), the hostfwd doesn't work.
Host: Windows 10
Guest: archlinux
QEMU version 5.2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1912857
Title:
virtio-serial blocks hostfwd ssh on windows 10 host
Status in QEMU:
New
Bug description:
qemu-system-x86_64
-display none
-hda archlinux.qcow2
-m 4G
-netdev user,id=n1,hostfwd=tcp::-:22
-device virtio-net-pci,netdev=n1
--> THIS WORKS - meaning I can ssh into the vm via port
qemu-system-x86_64
-display none
-hda archlinux.qcow2
-m 4G
-netdev user,id=n1,hostfwd=tcp::-:22
-device virtio-net-pci,netdev=n1
-device virtio-serial
-device virtserialport,chardev=cid0
-chardev socket,id=cid0,host=localhost,port=55298,server,nowait
--> DOES NOT WORK - meaning I cannot ssh into the vm
Not only does the port not work, but I am not able to perform any
serial transfer on port 55298 as well.
The following doesn't work either:
qemu-system-x86_64
-display none
-hda archlinux.qcow2
-m 4G
-netdev user,id=n1,hostfwd=tcp::-:22
-device virtio-net-pci,netdev=n1
-device virtio-serial
-device virtserialport,chardev=cid0
-chardev file,id=cid0,path=temp,server,nowait
No matter which character device I use for my virtserialport
communication (socket or udp or file or pipe), the hostfwd doesn't
work.
Host: Windows 10
Guest: archlinux
QEMU version 5.2
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1912857/+subscriptions
[Bug 1912857] Re: virtio-serial blocks hostfwd ssh on windows 10 host
** Description changed:
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -->
WORKS - meaning I can ssh into the vm via port
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1
- -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES
- NOT WORK - meaning I cannot ssh into the vm
+ -device virtio-serial -device virtserialport,chardev=cid0 -chardev
+ socket,id=cid0,{socket_addr_serial},server,nowait --> DOES NOT WORK -
+ meaning I cannot ssh into the vm
Not only does the port not work, but I am not able to perform any
serial transfer on port 55298 as well.
Host: Windows 10
Guest: archlinux
QEMU version 5.2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1912857
Title:
virtio-serial blocks hostfwd ssh on windows 10 host
Status in QEMU:
New
Bug description:
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -->
WORKS - meaning I can ssh into the vm via port
qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev
user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1
-device virtio-serial -device virtserialport,chardev=cid0 -chardev
socket,id=cid0,{socket_addr_serial},server,nowait --> DOES NOT WORK -
meaning I cannot ssh into the vm
Not only does the port not work, but I am not able to perform any
serial transfer on port 55298 as well.
Host: Windows 10
Guest: archlinux
QEMU version 5.2
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1912857/+subscriptions
[Bug 1912857] [NEW] virtio-serial blocks hostfwd ssh on windows 10 host
Public bug reported: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. Host: Windows 10 Guest: archlinux QEMU version 5.2 ** Affects: qemu Importance: Undecided Status: New ** Description changed: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm - Not only does the port work, but I am not able to perform any + Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. Host: Windows 10 Guest: archlinux QEMU version 5.2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1912857 Title: virtio-serial blocks hostfwd ssh on windows 10 host Status in QEMU: New Bug description: qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 --> WORKS - meaning I can ssh into the vm via port qemu-system-x86_64 -display none -hda archlinux.qcow2 -m 4G -netdev user,id=n1,hostfwd=tcp::-:22 -device virtio-net-pci,netdev=n1 -device virtio-serial -serial tcp:localhost:55298,server,nowait --> DOES NOT WORK - meaning I cannot ssh into the vm Not only does the port not work, but I am not able to perform any serial transfer on port 55298 as well. Host: Windows 10 Guest: archlinux QEMU version 5.2 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1912857/+subscriptions
[Bug 1911797] Re: hmp command `hostfwd_remove` does not work on running vm
(qemu) hostfwd_add tcp::43210-:43210 (qemu) hostfwd_remove tcp::43210-:43210 invalid format -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911797 Title: hmp command `hostfwd_remove` does not work on running vm Status in QEMU: New Bug description: On a running VM, I ran the following two hmp commands: "hostfwd_add tcp::43210-:43210" --> WORKS 'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' QEMU version 5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911797/+subscriptions
[Bug 1911797] Re: hmp command `hostfwd_remove` does not work on running vm
Not sure I understand. The intended behavior is to remove the ports. It doesn't do that. And it returns 'invalid format'. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911797 Title: hmp command `hostfwd_remove` does not work on running vm Status in QEMU: New Bug description: On a running VM, I ran the following two hmp commands: "hostfwd_add tcp::43210-:43210" --> WORKS 'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' QEMU version 5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911797/+subscriptions
[Bug 1911797] Re: hmp command `hostfwd_remove` does not work on running vm
My bad. The correct command is this: (qemu) hostfwd_remove tcp::43210 This bug can be closed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911797 Title: hmp command `hostfwd_remove` does not work on running vm Status in QEMU: New Bug description: On a running VM, I ran the following two hmp commands: "hostfwd_add tcp::43210-:43210" --> WORKS 'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' QEMU version 5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911797/+subscriptions
[Bug 1911797] [NEW] hmp command `hostfwd_remove` does not work on running vm
Public bug reported: On a running VM, I ran the following two hmp commands: "hostfwd_add tcp::43210-:43210" --> WORKS 'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' QEMU version 5.1 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1911797 Title: hmp command `hostfwd_remove` does not work on running vm Status in QEMU: New Bug description: On a running VM, I ran the following two hmp commands: "hostfwd_add tcp::43210-:43210" --> WORKS 'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' QEMU version 5.1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911797/+subscriptions
