search

beringresearch / macpine

Lightweight Linux VMs on MacOS
https://beringresearch.github.io/macpine/
Apache License 2.0
910 stars 22 forks source link

Why attaching to the instance shell via ssh is so slow? #173

Closed timfayz closed 7 months ago

timfayz commented 7 months ago

First, thank you for this wonderful project! I wanted the simplest way to run linux on my mac and googled all the options: docker (huge), podmad (less so but feels the same), raw QEMU + Alpine (too much configuration), and here we are – macpine! The simplicity it needs to be! So, I installed it and everything goes fine for now. What is bothering me though is the time it takes to start the interactive shell with the instance:

~ $ alpine start osd
2024/03/25 17:22:57 booting osd
2024/03/25 17:22:57 awaiting ssh server...
2024/03/25 17:23:18 mounted /Users/timfayz/Desktop/osd on /mnt/osd
2024/03/25 17:23:18 osd started (90653)
# or
~ $ alpine restart osd
2024/03/25 17:19:02 restarting osd...
2024/03/25 17:19:02 osd stopped
2024/03/25 17:19:03 booting osd
2024/03/25 17:19:03 awaiting ssh server...
2024/03/25 17:19:24 mounted /Users/timfayz/Desktop/osd on /mnt/osd
2024/03/25 17:19:24 osd started (90607)

I get such a slow start because of the awaiting ssh server... step. You can see that it takes no less than 20 sec each time. Is it normal or am I missing something here?

I'm on M1 Air 2020, MacOS 12.0.1

idroz commented 7 months ago

Thanks very much for the kind words - glad you're enjoying the project :)

At startup, macpine syncs system clock with vm clock, which cases delays - it seems to take a while to execute that command over ssh at startup. However, most of the time, it's not necessary.

I've created a new brach (https://github.com/beringresearch/macpine/tree/ssh-wait) where it's possible to add --express=true flag to alpine launch, e.g. alpine launch test --ssh 2224 --express=true. After this, whenever you start the VM through alpien start, the VM will be immediately available over ssh, as no automated checking is performed. The default behavious is --express=false.

Copying in @maxzinkus for some additional thoughts. Maybe I have overlooked something :)

timfayz commented 7 months ago

Got it. Cool! Will be waiting in the upstream then. Thank you! Should I close the issue? Also, having no desire to spawn issues, running alpine list gives:

2024/03/25 20:09:56 open /Users/timfayz/.macpine/.DS_Store/config.yaml: not a directory

What's that?

idroz commented 7 months ago

No worries - keep it opened for now.

Do - rm /Users/timfayz/.macpine/.DS_Store and it will fix that.

Looks like a .DS_Store file was created in .macpine directory - probably because the directory was opened in e.g. VScode or another text edirot. I'll add a fix to this in code as well.

timfayz commented 7 months ago

Thanks! It worked!

I have another question though :). Can I use another (newer) version of the alpine image? It seems the current one is 3.16 which is about two years old.. [Update: Not necessary. I wanted to update only to get newer packages. It turns out that I can just uncomment the edge mirror for the apk at /etc/apk/repositories, do apk update and have everything up to date! And yet, in case I need some other version of alpine, what should I do?]

idroz commented 7 months ago

I'm putting a script together that will automatically build a macpine-compliant vm using an arbitrary alpine iso.

maxzinkus commented 7 months ago

Hey! Thanks for the @, I was looking at this issue as well but have been busy with dissertation things :)

Gosh, is the sync really the thing that blocks for 20s+? I’ll repro this and reply back. Thanks all!

idroz commented 7 months ago

Addressed in the latest set of pull requests, but it does place the responsibilty of syncing system and guest clock on the user. Will keep tinkering to see if there's an better option directly through qemu.