Allow to create instances stopped

[avoidik]

What are you trying to do?

I'm trying to change VM's settings using modifyvm, and to do that I have to stop it first.

What's your proposed solution?

Actually, I'd like to have an option to set host-only network, but it's also okay if I would be able to start VM in a stopped state, change VM settings using modifyvm, and start it using as usual using multipass launch command

Additional context

Workflow I'm following

cat > cloud-init.yaml <<'EOF'
write_files:
- path: /etc/netplan/60-host-only.yaml
  permissions: '0644'
  content: |
    network:
      ethernets:
        IFACE_NAME:
          optional: yes
          dhcp4: yes
          dhcp4-overrides:
            route-metric: 110
          set-name: IFACE_NAME
          dhcp6: no
      version: 2
runcmd:
- 'sed -i "s/IFACE_NAME/enp0s8/g" /etc/netplan/60-host-only.yaml'
- 'netplan generate'
- 'netplan apply'
EOF
multipass launch docker --cloud-init cloud-init.yaml
multipass stop docker
gsudo -s "%VBOX_MSI_INSTALL_PATH%\vboxmanage" modifyvm docker --nic2 hostonly --hostonlyadapter2 "VirtualBox Host-Only Ethernet Adapter"
multipass start docker

[Saviq]

Hi @avoidik, while conceptually it shouldn't be difficult, we'd need to consider the user experience here. Today the "contract" is that the instance is accessible after a multipass launch. We'd have no way to ensure that if we never boot the instance up. Between creation and first boot there could be a myriad of things that happened that could change what the instance experiences.

Your particular case would be better served, IMO, by supporting "host-only" networking as an option for --network when launching. Extending multipass networks with more features (primarily private networking between a group of instances) is something we have on our future roadmap.

[avoidik]

thank you for your prompt answer @Saviq, user experience will stay as is if the launch command would have something like optional --create-only flag, which under the cover creates VM without starting it

[Saviq]

Hey, by "user experience" I meant primarily what happens when something goes not as expected. On launch today the instance gets destroyed if something goes wrong. If we split that in two separate actions, it's easier to end up with broken instances and potentially leaking them.

We're likely to implement that in the long run, it's just that it's not as trivial as it may seem on the surface.