Hi there,
@Landry Thanks for the great article, it was just what I was looking
for!
Since I wanted to be able to retrieve the network interfaces from the
VM, I have applied the FreeBSD patches on qemu-5.1.0 (and slightly
modified them to work with OpenBSD 6.8) which enables the additional
commands:
"guest-get-fsinfo"
"guest-get-vcpus"
"guest-network-get-interfaces"
Which allows, in my case, proxmox to show the network interfaces and
addresses of an OpenBSD VM:
proxmox# qm agent 100 network-get-interfaces
[
{
"ip-addresses" : [
{
"ip-address" : "::1",
"ip-address-type" : "ipv6",
"prefix" : 128
},
{
"ip-address" : "fe80:3::1",
"ip-address-type" : "ipv6",
"prefix" : 64
},
{
"ip-address" : "127.0.0.1",
"ip-address-type" : "ipv4",
"prefix" : 8
}
],
"name" : "lo0"
},
{
"hardware-address" : "12:34:56:78:9a:bc",
"ip-addresses" : [
{
"ip-address" : "fe80:1::7075:8aff:def0:1234",
"ip-address-type" : "ipv6",
"prefix" : 64
},
{
"ip-address" : "10.0.0.2",
"ip-address-type" : "ipv4",
"prefix" : 24
}
],
"name" : "vio0"
},
{
"name" : "enc0"
},
{
"hardware-address" : "00:00:00:00:00:00",
"name" : "pflog0"
}
]
If anybody is interested, I can share these patches, which might need
some polishing. Also, I'm ready to do what's necessary to get these
into stable as for my purposes I need this functionality.
Regards,
Jeroen Derks
On 13/05/2020 11:57, Landry Breuil wrote:
> Hi,
>
> experimenting with proxmox VE since some years (but that also applies to
> plain kvm/qemu OpenBSD vms), today i had a look at the qemu guest agent
> feature:
> https://pve.proxmox.com/wiki/Qemu-guest-agent
> https://wiki.qemu.org/Features/GuestAgent
>
> in the host config/webui, enabling the guest agent adds a virtio-serial
> device to the kvm cmdline:
> -chardev socket,path=/var/run/qemu-server/100.qga,server,nowait,id=qga0
> -device virtio-serial,id=qga0,bus=pci.0,addr=0x8
> -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0
>
> in the guest, this is detected as a new virtio device for which we have
> no dedicated driver, so it stays unconfigured:
>
> virtio1 at pci0 dev 8 function 0 "Qumranet Virtio Console" rev 0x00
> virtio1: no matching child driver; not configured
>
> but looking at the qemu-guest-agent & proxmox qm docs:
> https://www.qemu.org/docs/master/interop/qemu-ga.html
> https://pve.proxmox.com/wiki/Manual:_qm.conf
>
> there's a way to tell proxmox to use the 'isa-serial' device type:
> proxmox# grep agent /etc/pve/qemu-server/100.conf
> agent: 1,type=isa
>
> which adds another device type to the kvm cmdline:
> -chardev socket,path=/var/run/qemu-server/100.qga,server,nowait,id=qga0
> -device isa-serial,chardev=qga0
>
> and in the guest.. there's a new serial device (com0 is used by the qemu
> console):
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
>
> from that point, one can run qemu-ga, pointing at this serial port (-f
> and -t are used because otherwise qemu-ga hardcodes
> /usr/local/$something):
> guest$ doas qemu-ga -m isa-serial -p /dev/cua01 -f /tmp/xx.pid -t /tmp/ -v
> 1589361079.833754: debug: disabling command: guest-suspend-disk
> 1589361079.833788: debug: disabling command: guest-suspend-ram
> 1589361079.833799: debug: disabling command: guest-suspend-hybrid
> 1589361079.833809: debug: disabling command: guest-network-get-interfaces
> 1589361079.833818: debug: disabling command: guest-get-vcpus
> 1589361079.833827: debug: disabling command: guest-set-vcpus
> 1589361079.833836: debug: disabling command: guest-get-memory-blocks
> 1589361079.833852: debug: disabling command: guest-set-memory-blocks
> 1589361079.833862: debug: disabling command: guest-get-memory-block-size
> 1589361079.833872: debug: disabling command: guest-get-memory-block-info
> 1589361079.833881: debug: disabling command: guest-get-fsinfo
> 1589361079.833890: debug: disabling command: guest-fsfreeze-status
> 1589361079.833898: debug: disabling command: guest-fsfreeze-freeze
> 1589361079.833907: debug: disabling command: guest-fsfreeze-freeze-list
> 1589361079.833916: debug: disabling command: guest-fsfreeze-thaw
> 1589361079.833924: debug: disabling command: guest-get-fsinfo
> 1589361079.833933: debug: disabling command: guest-fstrim
>
> (yeah, some commands are disabled, something to probably fix w/
> upstream, freebsd has some work done in
> https://github.com/aborche/qemu-guest-agent)
>
> from that point one can send commands via the host:
>
> proxmox# qm agent 100 get-host-name
> {
> "host-name" : "c64.proxmox2"
> }
>
> proxmox# qm agent 100 get-time
> 1589361360033920000
> proxmox# qm agent 100 get-osinfo
> {
> "kernel-release" : "6.7",
> "kernel-version" : "GENERIC.MP#182",
> "machine" : "amd64"
> }
>
> sadly, sending 'shutdown' doesnt work, but that should be possible to
> fix.
>
> according to the 'info' command, those qemu commands should work:
> proxmox# qm guest cmd 100 info | jq '.supported_commands | .[] | select(.enabled == true) | select (."success-response" == true) | .name'
> "guest-get-osinfo"
> "guest-get-timezone"
> "guest-get-users"
> "guest-get-host-name"
> "guest-exec"
> "guest-exec-status"
> "guest-set-user-password"
> "guest-file-flush"
> "guest-file-seek"
> "guest-file-write"
> "guest-file-read"
> "guest-file-close"
> "guest-file-open"
> "guest-info"
> "guest-set-time"
> "guest-get-time"
> "guest-ping"
> "guest-sync"
> "guest-sync-delimited"
>
> testing shows some are broken at runtime, but that allows the host to
> list files within the guest:
>
> proxmox# qm guest exec 100 ls /tmp
> {
> "exitcode" : 0,
> "exited" : 1,
> "out-data" : ".ICE-unix\n.X11-unix\nqga.state\nsndio\ntmux-1000\nvi.recover\n"
> }
>
> and finally, this allows a graceful shutdown of the guest from the host:
>
> proxmox# qm guest exec 100 halt
> QEMU guest agent is not running
>
> (and the vm is properly stopped)
>
> Hoping that can be useful for people who use OpenBSD in qemu/kvm VMs,
> havent found any kind of doc on that specific to OpenBSD so far.
>
> bits to consider portswise: i think it would make sense to subpackage
> qemu-ga binary, having to install the complete qemu package with all its
> dependencies in a VM if a bit much imo. Will see if that's feasible..
> fixing hardcoded paths and some commands would be nice too :)
>
> Landry
>
No comments:
Post a Comment