How-to launch a VM with additional disks


What I’m after is something like this:

incus init --vm --empty test
incus config device add test drive2 disk pool=lvmpool name=xyz

or even better:
incus init --vm --empty test -D drive2,pool=lvmpool,name=xyz

I’m aware I can do this:

incus storage volume create lvmpool xyz size=1TiB --type=block
incus config device add test xyz disk pool=lvmpool source=xyz

but I’d like to launch the vm with it all in on line and ideally with a random naming all if not specified, the simpler the better :smiley:

I’ve seen other people attempting to do similar things in one line. Last time I recommended to use profiles. It’s possible to add all your configuration and devices to profiles and then launch an image with a set of profiles just by adding -p <profile name> to add your specific configuration.

Much easier to reproduce and much cleaner as well.

Usually, setting no profile is equivalent to doing -p default, in which case the default profile is used. You can add a drive2 profile, add your device and other configuration there and then launch your image with -p default -p drive2. The default would still be needed in this case to include networking and the root file system. If you want, you can also add that to the drive2 profile, but the organization part is your choice.

Thanks @victoitor, but I’m already quite familiar with using profiles and unfortunately even that wouldn’t quite work since you can’t have a block device in the profile that doesn’t already exist and it wouldn’t make sense to have profiles for every little thing specially since I use incus for lot of quick and dirty testing that’s why I’m particularly a fan of one liners because it allows me to spin something up in one swift step and be done with it shortly after and nothing to clean-up on afterwards with profiles and custom storages it means I’d have to create them, keep track of them and delete them individually increasing the number of steps by quiet a bit, so I suppose this more of a feature request really :slight_smile: pretty please @stgraber.

I’m not sure that we want to add that to incus launch/incus create as those commands are already a bit cluttered as they are.

But I’ve been wanting to add the ability to define additional disks to be attached to instances through profiles/config.

Basically having something like:

    pool: xyz
    path: /foo

This would then create a custom volume named <instance name>-<device name> so for instance foo and device docker, you’d get foo-docker as a custom volume.

There are some complications though:

  • Need to handle the case where it already exists (fail)
  • Need to make it clear what will happen on instance delete (nothing, volume sticks around)
  • Need to make it clear that instance snapshots don’t apply to attached volumes
  • Need to handle renaming the device (should rename the volume)

But in general, I think that’d be useful to have and would be somewhat similar to what’s done for the main instance storage volume.

If that sounds like it’d work for you, feel free to file something at Issues · lxc/incus · GitHub

1 Like

Thanks @stgraber

I think it would be unintuitive to have the volumes stick around after deletion of the very reason they exists in the first place. perhaps an additional key can be set to say protect this volume in which case it will throw a warning and refuse to delete the volume?

Since all volumes would belong to the same instance (unless shared) shouldn’t snapshots apply to all of them as opposed to just root? again perhaps a key can be set to say take snapshots of this volume too just so that we don’t have to hop around the command line going from incus config set ... to incus storage volume set ... to incus config device set ... it will feels a bit convoluted really

As mentioned before the whole reason I was really after this one liner doodah was so that I won’t have to keep track of things and manually go back in to delete them or whatever, I was hoping to have a way to associating everything to one source of truce and if that is gone then everything associated with it would be gone too (unless specified otherwise) that feels more natural no?