Conversation
| for ifacename, ifaceconf := range sjson.State.Network { | ||
| if ifacename == "lo" { | ||
| // ignore loopback interface | ||
| continue | ||
| } | ||
| for _, addr := range ifaceconf.Addresses { | ||
| if addr.Family == "inet" && addr.Address != "" { | ||
| return addr.Address, nil | ||
| } | ||
| } |
There was a problem hiding this comment.
yup, I think I mentioned somewhere that I had exact same change :) I will rebase as needed
Add a new backend named lxd-vm, which is essentially VMs orchestrated through LXD. Signed-off-by: Maciej Borzecki <[email protected]>
LXD VMs, especially when running in GCP take quite long to have IP addresses assigned to them. Use a longer timeout in this case. Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
… and lxd-vm backends Signed-off-by: Maciej Borzecki <[email protected]>
bboozzoo
force-pushed
the
bbboozzoo/lxd-vm-backend
branch
from
11aef7b to
77fbb21
Compare
tests/lxd-vm/spread.yaml
Outdated
| backends: | ||
| lxd-vm: | ||
| systems: | ||
| - ubuntu-20.04 |
There was a problem hiding this comment.
This should probably also test 16.04, 18.04 and 22.04 as per #182 (assuming there are VM images for all old releases as well)
There was a problem hiding this comment.
16.04 and 18.04 don't work in a VM, lxd-agent does not come start, so I've limited this to 20.04 and 22.04 for now. Another issue I ran into, is that tests need to be run one by one, otherwise the host runs out of disk space.
There was a problem hiding this comment.
Eh, and 22.04 will only work when #184 or other similar fix lands.
Prepare the test to run on multiple systems and mention why Ubuntu 16.04, 18.04, and 22.04 are not currently working. Signed-off-by: Maciej Borzecki <[email protected]>
|
I'm seeing this message on execution using the lxd-vm backend, it can also be adjusted to mention virtual machine instead of container: |
Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
…bboozzoo/lxd-vm-backend
| } | ||
| } | ||
|
|
||
| func LXDVM(p *Project, b *Backend, o *Options) Provider { |
There was a problem hiding this comment.
In light of Spread already having support for declaring multiple named backends, choosing the provider with the type keyword, what benefit does adding a new provider type give?
| args = append(args, "-c", fmt.Sprintf("limits.memory=%dMiB", mem)) | ||
| } | ||
| if system.Storage != Size(0) { | ||
| args = append(args, "-d", fmt.Sprintf("root,size=%d", system.Storage)) |
There was a problem hiding this comment.
Containers could also benefit from support for the storage keyword.
| if p.vm { | ||
| // VM may take considerably longer to start | ||
| // TODO: should this be configurable? | ||
| maxTimeout = 180 * time.Second |
There was a problem hiding this comment.
I did not see this in my testing but it is probably true, are you using emulated VMs?
After the VM has an address, subsequent calls to lxc exec will fail until the lxd-agent inside the VM has started, ab8232d could be useful for this.
| } | ||
| if system.Storage != Size(0) { | ||
| args = append(args, "-d", fmt.Sprintf("root,size=%d", system.Storage)) | ||
| } |
There was a problem hiding this comment.
I see no way to specify the number of vCPUs for the VM. This is an important requirement as the default of 1 vCPU is most likely not sufficient.
In 804d1ee generic support for the LXD instance type concept is introduced driven by the already existing plan keyword.
LXD applies these constraints both to containers and VMs.
|
Hello! Out of curiosity, any updates on this/how we might progress on it? |
5 participants
Like LXD but with a twist, as instead of containers, it's using VMs. This is an improvement over the qemu backend, as LXD --vm generally runs with a virtio focused configuration ensuring that we're using hardware efficiently.
Another upside is that one does not need to build a special VM image anymore, LXD handles everything through cloud-init or the agent.