containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.81k stars 2.42k forks source link

Provide ability to access console / tty of podman machine via socket #20466

Open mairin opened 1 year ago

mairin commented 1 year ago

Feature request description

Sometimes if you update your podman machine or otherwise break it, you might render it in a state where it doesn't boot such that you can access a shell. You might not understand why it's broken or if it's recoverable. You could create a new podman machine but you might lose what you had set up in the old one.

Suggest potential solution

For these situations, it would be helpful to be able to access the TTYs for the VM to try to get some output and see what is going on. This would be regardless is the VM backend is qemu, hyper-v, etc.

We would like to provide this via Podman Desktop but need access to the TTYs via socket.

Have you considered any alternatives?

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Correponding RFE for Podman Desktop is here: https://github.com/containers/podman-desktop/issues/4493

rhatdan commented 1 year ago

@baude @ashley-cui @gbraad @n1hility PTAL

ashley-cui commented 1 year ago

Something like showing the tty output for podman machine start in the terminal that we're currently running it from? I remember qemu has a flag for this, but we'd have to find the equiv on the other providers.

mairin commented 1 year ago

@ashley-cui if that's preboot output then yeh!

rhatdan commented 1 year ago

Yes add a podman machine start --ttyflag and then setup the terminal for the virtualization tool to show the terminal output, if possible.

n1hility commented 1 year ago

Just a note that today on the qemu based runtimes right now if you start with --log-level debug it does open a emu graphical window into the console. However unless you set a password (or boot it into single user) you won't be able to login.

baude commented 1 year ago

i think with log-level=debug you get a ton of information. that said, i am sitting on a PR that @cevich is testing where i have added some logic to ensure gvproxy is running before proceeding. The same logic could added to vfkit (i believe qemu already does it). this would separate machine issues from booting issues.

while boot issues are rare, they are usually visible in the debug console.

cevich commented 1 year ago

IIRC, you said the 'debug console" is a GUI only thing, eh?

github-actions[bot] commented 11 months ago

A friendly reminder that this issue had no activity for 30 days.

rhatdan commented 11 months ago

@baude @cevich Any update?