-
Notifications
You must be signed in to change notification settings - Fork 629
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
limactl: add --cpus
, --memory
, --mount-type
, --vm-type
, ...
#1468
Conversation
In the legacy systems, they used MiB instead (probably so you could do things like 0.5GiB, when using integers?)
For a modern system, it makes much more sense to use GiB. It also looks better, next to the vCPU count. (e.g. 4 / 4)
|
flags.Int("memory", 0, "memory in GiB") // colima-compatible | ||
_ = cmd.RegisterFlagCompletionFunc("memory", func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) { | ||
return []string{"1", "2", "4", "8", "16", "32"}, cobra.ShellCompDirectiveNoFileComp | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should also add "disk" here, ("disk in GiB")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some concern here, because disk size can only ever be increased. The only way to shrink disk size is by destroying and re-creating the instance, losing all your data.
So this is not something that you should casually do. Or it should require a confirmation prompt for the user to acknowledge (disabled by --tty=false
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For new instances it can be casually done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For new instances it can be casually done
Yes, my concern is purely about limectl edit default --disk 500GiB
, and then being unable to ever shrink it again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could disable (or prompt) the feature to edit the disk size, until grow and shrink has been implemented ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, --disk
should not be implemented until Lima can grow the disk automatically.
FWIW, I don't expect us to ever be able to shrink disks; is this even possible?
It should probably repeat the defaults ?
Or would that information be misleading, if it is different in the template or in the override ? |
I don't understand why "memory in GiB" should be an integer. Using rational numbers works just fine: $ l edit alpine --set '.memory = "4.5GiB"'
WARN[0000] `--set` is experimental
INFO[0000] Instance "alpine" configuration edited
[...]
$ ps -ef | grep qemu
501 26304 26294 0 12:30pm ttys000 0:09.16 /usr/local/bin/qemu-system-x86_64 -m 4608 ... |
I think this is fine; it shows the built-in defaults, not the current values. |
Just for the record, I did have some concerns about this being yet another redundant way to do something that is already possible (with the |
I’m trying to follow colima flags (when possible) |
That doesn't make much sense to me; by supporting fractional sizes in Lima we would be supporting a superset of what Why should the user not be allowed to write |
f015da5
to
b1e2616
Compare
Updated to allow this |
Thanks! Now we just have to make it accept j/k |
Translated these into yq: ".containerd.user = true" Editing the mounts requires some more knowledge.
|
Yes, complicated configs should be still provided via yq or YAML. |
Will rebase after merging: |
Rebased |
2d86dfa
to
60a8c95
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM; only cosmetics feedback. Making completion dynamic maybe not worth the effort.
Personally i wouldn't bother marking --network
, --set
, and --rosetta
as experimental, just to make a log.Warn
call when they are used. Do you expect to change them in a backward-incompatible way?
We can revisit this when we make vz driver and user-v2 network default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with merging this as is, and improving tab completion later.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
limactl create
,limactl start
,limactl edit
:--cpus=INT
(Similar tocolima start --cpu
, but the flag name is slightly different)--dns=IP
(Similar tocolima start --dns
)--memory=FLOAT
(Similar tocolima start --memory
)--mount=DIR[:w]
(Similar tocolima start --mount
)--mount-type=(reverse-sshfs|9p|virtiofs)
(Similar tocolima start --mount-type
)--mount-writable=BOOL
--network=(lima:shared|lima:bridged|lima:host|lima:user-v2|vzNAT)
--rosetta=BOOL
limactl create
andlimactl start
only:--arch=(x86_64|aarch64|riscv64)
(Similar tocolima start --arch
)--containerd=(user|system|user+system|none)
--disk=FLOAT
(Similar tocolima start --disk
)--vm-type=(qemu|vz)
(Similar tocolima start --vm-type
)