The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/468c6f13981de5309adc0f01272523265f74967a

commit 468c6f13981de5309adc0f01272523265f74967a
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Fri Apr 27 21:36:58 2018

vm_tools: make the lxd ready and client start timeouts longer

On Kevin the very first invocation of lxd seems to take a long time --
sometimes more than 40 seconds, so we need to make the wait ready
timout and the client vm start timeouts longer. Longer term we'd like
to figure out what it's doing and optimize the first invocation of
lxd.

BUG= chromium:837445 
TEST=manual test on kevin

Change-Id: Id3ff9201ab1664f10f22a49bf3e0cfee60afe689
Reviewed-on: https://chromium-review.googlesource.com/1031738
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>

[modify] https://crrev.com/468c6f13981de5309adc0f01272523265f74967a/vm_tools/concierge/service.cc
[modify] https://crrev.com/468c6f13981de5309adc0f01272523265f74967a/vm_tools/concierge/client.cc

I should look closer at this for M-70

I think I found the culprit: 4096-bit RSA key generation, which happens on LXD's first startup. The math for this is pretty slow, especially on 32-bit ARM.

We could:
1) Generate ECDSA certs which are much, much smaller.
and/or
2) Add a config to LXD to disable TLS (and serving the REST API over TCP), since we only use the unix domain socket.

Sounds like a good upstreaming candidate :)

Deleted: lxd.svg 324 KB

lxd.svg 324 KB Download

Oh nice -- I guess option 1 wouldn't require any changes to lxd but option 2 would?

Both would require LXD changes. The cert generation code right now only does 4096-bit RSA: https://github.com/lxc/lxd/blob/2c80ee64df0f84201d2c06860a07258c7f761966/shared/cert.go#L250

> Sounds like a good upstreaming candidate :)

It does indeed. :)

I'm not currently working on this, but someone knowledgeable in go should take it

Which of the two approaches are you working on?

Seems to me like having the server certificate generated on-demand on the server side would be pretty easy to do and certainly something we'd be quite willing to merge upstream.

Let me know if you're running into problems and please send us a PR when you have something we can look at.

I think we'd have the cert generated on-demand.

Upstream has switched to generating EC384 so I'll pick that patch instead.

https://github.com/lxc/lxd/pull/5206

https://github.com/lxc/lxd/issues/5064

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e2d64fea75409b1dae263969c483b320051c6373

commit e2d64fea75409b1dae263969c483b320051c6373
Author: Stephen Barber <smbarber@chromium.org>
Date: Fri Nov 02 07:26:26 2018

app-emulation/lxd: add patch for EC384 certs

BUG= chromium:837445 
TEST=vm.CrostiniStartEverything

Change-Id: I1b8f9b2a60e99886cb1a72c304b4a40675989df8
Reviewed-on: https://chromium-review.googlesource.com/1313770
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>

[add] https://crrev.com/e2d64fea75409b1dae263969c483b320051c6373/app-emulation/lxd/files/lxd-3.0.2-cert-ec384.patch
[modify] https://crrev.com/e2d64fea75409b1dae263969c483b320051c6373/app-emulation/lxd/lxd-3.0.2.ebuild
[rename] https://crrev.com/e2d64fea75409b1dae263969c483b320051c6373/app-emulation/lxd/lxd-3.0.2-r2.ebuild

Verified with component 11220.0.0.