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

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.
 
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.
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
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
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.
Copy that.Thanks.I will file a bug report.
 
  • Like
Reactions: Johannes S