You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After extensive research, this turns out to be the responsibility of the guest OS, not the connecting terminal [emulator] or virtual serial devices. The TERM value is set by the init system, be it systemd or otherwise. A guest disk image would need to be modified to set the TERM to something appropriate for a terminal emulator (such as xterm256-color).
After a few experimental implementations, including calling libguestfs directly using the cgo FFI, and invoking guestfish as a series of child processes, I have concluded that it should not be the responsibility of vm to modify the guest filesystem to suite its expectations. This obviously applies to modifying the TERM value of serial TTYs, but I also feel it extends to supporting something like cloud-init. While cloud-init is prominently used in the "cloud image" space, it can easily be supported by applying an appropriately constructed read-only disk image using the --disk option of the create subcommand.
Put another way, vm enables the easy creation of domains backed by existing qcow2 disk images. It will also fetch images from provided URLs and convert them to qcow2 if necessary, but it will not modify said image in any way. There are mature tools (guestfish, virt-builder) to aid in the modification and creation of qcow2 images already.
Is it possible to set the
TERM
toxterm-256color
, or inherit theTERM
value from the calling environment?The text was updated successfully, but these errors were encountered: