When used api to execute shell contains Chinese,caused :QEMU guest agent is not running

X

xiaodong.zou

New Member
Jul 25, 2025
4
1
3
Hi all,

I used the 8.4.0 api(POST /api2/json/nodes/{node}/qemu/{vmid}/agent/exec) to execute a shell script in the VM.

When the command contains Chinese characters,the execution result would be:

JSON: 
{
    "error": "",
    "methodType": "CREATE",
    "reasonPhrase": "VM 108 qmp command 'guest-exec' failed - got timeout",
    "requestParameters": {
        "command": [
            "/bin/bash",
            "-c",
            "cd /home && wget -q --no-check-certificate \"http://172.18.7.21:19001/zkxy-eda-edu-fileupload/ip/8cb27b96-3a90-44b7-9453-9de3f2073e57.pdf\" -O \"学生一-202506170081-实验报告 (1).pdf\" && chmod +777 \"学生一-202506170081-实验报告 (1).pdf\""
        ]
    },
    "requestResource": "/nodes/pve1/qemu/108/agent/exec",
    "response": {},
    "responseType": "JSON",
    "statusCode": 500,
    "successStatusCode": false
}
reasonPhrase is "VM 108 qmp command 'guest-exec' failed - got timeout".

When re-executing the same command via the API,the result becomes:
JSON: 
{
    "error": "",
    "methodType": "CREATE",
    "reasonPhrase": "QEMU guest agent is not running",
    "requestParameters": {
        "command": [
            "/bin/bash",
            "-c",
            "cd /home && wget -q --no-check-certificate \"http://172.18.7.21:19001/zkxy-eda-edu-fileupload/ip/8cb27b96-3a90-44b7-9453-9de3f2073e57.pdf\" -O \"学生一-202506170081-实验报告 (1).pdf\" && chmod +777 \"学生一-202506170081-实验报告 (1).pdf\""
        ]
    },
    "requestResource": "/nodes/pve1/qemu/108/agent/exec",
    "response": {},
    "responseType": "JSON",
    "statusCode": 500,
    "successStatusCode": false
}
reasonPhrase is "QEMU guest agent is not running".

However,checking the agent status in the VM with "systemctl status qemu-guest-agent",show it as "active(running)":

Bash: 
[root@zouxd /]# systemctl status qemu-guest-agent
● qemu-guest-agent.service - QEMU Guest Agent
   Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2025-07-28 10:51:59 CST; 1min 26s ago
 Main PID: 24587 (qemu-ga)
   CGroup: /system.slice/qemu-guest-agent.service
           └─24587 /usr/bin/qemu-ga --method=virtio-serial --path=/dev/virtio-ports/org.qemu.guest_agent.0 --blacklist= -F/etc/qemu-ga/fsfreeze-hook

Jul 28 10:51:59 zouxd systemd[1]: Stopped QEMU Guest Agent.
Jul 28 10:51:59 zouxd systemd[1]: Started QEMU Guest Agent.
Jul 28 10:52:07 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:52:08 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:52:19 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:52:30 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:52:40 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:52:50 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:53:01 zouxd qemu-ga[24587]: info: guest-ping called
Jul 28 10:53:11 zouxd qemu-ga[24587]: info: guest-ping called
[root@zouxd /]#

After executing "systemctl restart qemu-guest-agent" to restart the agent, its status is fully restored.
 
Seems like a bug. If you call qemu guest directly (not through API) do you get the same results?

If you do not, then there is a problem with the API.
If you do, it is a problem in QEMU.
 
guruevi said:
Seems like a bug. If you call qemu guest directly (not through API) do you get the same results?

If you do not, then there is a problem with the API.
If you do, it is a problem in QEMU.
Click to expand...
Thank you for your response. When executing the script directly within the QEMU guest, the issue does not occur – all scripts execute normally, and the QEMU guest agent status remains active and healthy.
 
I meant if you call from the hypervisor through:

QM: https://pve.proxmox.com/pve-docs/qm.1.html
- that removes the HTTP layer to some extent

Direct: socat /var/run/qemu-server/<VMID>.qga -
Send it '{"execute": "guest-exec", "arguments": {"path": "/bin/bash", "arg": ["-c", "cd", "/home"], "capture-output": true}}'
- that removes Proxmox entirely
 
guruevi said:
I meant if you call from the hypervisor through:

QM: https://pve.proxmox.com/pve-docs/qm.1.html
- that removes the HTTP layer to some extent

Direct: socat /var/run/qemu-server/<VMID>.qga -
Send it '{"execute": "guest-exec", "arguments": {"path": "/bin/bash", "arg": ["-c", "cd", "/home"], "capture-output": true}}'
- that removes Proxmox entirely
Click to expand...
Sorry about that.When I execute the qm command on the host machine, if the command contains Chinese characters, the issue still occurs. For example:
Bash: 
root@pve1:~# qm guest exec 108 "cd /home && wget -q --no-check-certificate \"http://172.18.7.21:19001/zkxy-eda-edu-files/10120_20250801095903_20250801.pdf\" -O \"报告.pdf\""
VM 108 qmp command 'guest-exec' failed - got timeout
root@pve1:~#
root@pve1:~# qm guest exec 108 "cd /home && wget -q --no-check-certificate \"http://172.18.7.21:19001/zkxy-eda-edu-files/10120_20250801095903_20250801.pdf\" -O \"报告.pdf\""
QEMU guest agent is not running
root@pve1:~#

However, when I execute the same command via socat —even with Chinese characters—it executes and exits normally, and returns an exit code of 0:
Bash: 
root@pve1:~# socat - /var/run/qemu-server/108.qga
{
  "execute": "guest-exec",
  "arguments": {
    "path": "/bin/bash",
    "arg": ["-c", "cd /home && wget -q --no-check-certificate \"http://172.18.7.21:19001/zkxy-eda-edu-files/10120_20250801095903_20250801.pdf\" -O \"报告.pdf\""],
    "capture-output": true
  }
}
{"return": {"pid": 3257}}

{"execute": "guest-exec-status", "arguments": {"pid": 3257}}

{"return": {"exitcode": 0, "exited": true}}
 
Great, now with this information, I think you have enough information to file a bug report here:
https://bugzilla.proxmox.com/

Somewhere in the Proxmox API it's not handling UTF-8 (I'm presuming those characters are) well. Do you know the Unicode code points of those characters? It may be helpful for the dev team to know what those characters are. I can see the ones you posted in my browser are CJK, not sure if they're coming through correctly.
 
  • Like
Reactions: Johannes S
guruevi said:
Great, now with this information, I think you have enough information to file a bug report here:
https://bugzilla.proxmox.com/

Somewhere in the Proxmox API it's not handling UTF-8 (I'm presuming those characters are) well. Do you know the Unicode code points of those characters? It may be helpful for the dev team to know what those characters are. I can see the ones you posted in my browser are CJK, not sure if they're coming through correctly.
Click to expand...
Copy that.Thanks.I will file a bug report.
 
  • Like
Reactions: Johannes S
Suspected related observation: Unicode guest-exec timeout with agent still active

Hello,

I would like to add a potentially related field observation to this thread and bug6609. This is a timing/symptom match, not a verified minimal reproduction or proof that the same underlying defect is responsible.

Observed versions

- Proxmox qemu-server: 9.2.11
- pve-qemu-kvm: 11.0.3-4
- libpve-common-perl: 9.2.3
- Guest: Ubuntu26.04.1 LTS, kernel7.0.0-38-generic
- Guest agent: QEMU Guest Agent10.2.1
- Ubuntu package: 1:10.2.1+ds-1ubuntu3.2

Observed failure

On October24,2026, a deployment helper invoked qm guest exec with python3 -c and a Python command containing a literal ↗ character (U+2197). The command was intended to update an HTML navigation link. It was submitted over SSH to the hypervisor by an AI-assisted deployment tool, rather than entered directly inside the guest.

The command timed out. Subsequent guest-ping requests also timed out and Proxmox reported that the QEMU guest agent was not running. Inside the VM, however, systemd still reported the original guest-agent process active/running, with no process restart. Ordinary guest SSH and application HTTP access remained available.

The preceding routine collector guest-exec/status request had completed successfully. At17:04:37UTC, the old agent logged a ping immediately before the attempted deployment. At17:04:42UTC, the hypervisor logged the guest-exec timeout. Subsequent collector pings failed until the service was restarted at approximately17:10UTC.

The queried kernel journal contained no OOM kill, agent segfault or hung-task evidence for this interval. The VM did not reboot.

Recovery and workaround observed

Restarting only qemu-guest-agent inside the guest restored communication. After restart, an ASCII-safe deployment that transferred UTF-8 content as encoded data succeeded, and routine guest-exec/status calls resumed. This is an observed operational workaround, not an isolated A/B experiment: both the restart and command transport changed.

The lab collector depended on guest-exec to write a host snapshot into the guest. When that channel stopped responding, the snapshot became stale and dependent dashboards correctly marked those sources unavailable. This impact did not indicate an outage of the monitored applications themselves.

Limits of this evidence

- I have not rerun the suspected trigger on the live VM.
- I do not have a verified minimal reproducer; a simple print of U+2197 has NOT been tested.
- I have not compared the same payload through direct QGA socket access or isolated ASCII/Unicode variants in a disposable VM.
- The installed QMPClient.pm uses to_json in its QGA send path, but that observation alone does not establish a serialization bug.
- I could not verify the current status or fixed versions of bug6609 because the tracker presented an automated-access challenge.
- The agent had elevated memory usage before restart, but there is no evidence establishing memory exhaustion or a memory leak as the cause.

Would the maintainers consider this consistent with bug6609, and which specific diagnostics or test version would be most useful next? I can prepare a bounded test in a disposable guest if needed. I have deliberately omitted private command payloads, internal addresses, credentials and unrelated raw logs.

Kingsley Izex / IZEX Solutions

Reference thread: https://forum.proxmox.com/threads/w...aused-qemu-guest-agent-is-not-running.168946/
Related issue referenced by Proxmox staff: https://bugzilla.proxmox.com/show_bug.cgi?id=6609
 
You must log in or register to reply here.
Top Bottom
Back