I been tasked with job of add a dedicated fleet of nodes with Nova LXD on a already running Openstack KVM Cluster.
That scenario is nothing new and I already have Nova LXC up and running, but sadly the integration between libvirtd and LXC offer limited functionallity.
Now I’m trying Nova LXD but I’m having some issues (probably related to my limited experiencie with LXD).
The most rare, is that when I launch a instance nova-compute consume a lot of CPU, takes a lot of time and fails.
Strace shows me that nova-compute is processing an anormal amount of data (probably the image). What is the correct format in this scenario? rootfs.tar.gz? or a typical cloud image in RAW format?
Checking this site I found people with Clouds implemented using Openstack and Nova LXD. Can you share tips and configurations?
Thanks in advance.
Edit:
In the end I successfully extended my Openstack cluster to support LXD along side KVM on production. Some problems where related to my poor knowledge of LXD and other where bugs still presents in the the old version of the software (in my case, the control plane was Ocata) that needed fixes and special configurations on nova-compute and pylxd.
There are some caveats and pitfalls. In this type of deployment (nested containers) you have to use btrfs as storage backend. You will have to enable bluestore with ceph-osd as well. Storage pool on the Nova Compute node would not be initialised properly and you will have to manually create btrfs storage pool on the Nova Compute node.
Have in mind that you cannotrun both KVM and Nova LXD on the same Nova Compute node.
I’m Running Ubuntu 16.04 with Ocata from Cloud Archive. For this node I’m using a manual installation of the components. The rest of the cluster has Kolla-Ansible.
Do I need a special configuration on LXD? In the previous iterations I encounter some issues like HostNotFound: Unable to connect to LXD daemon on nova compute.
So the error HostNotFound: Unable to connect to LXD daemon essentially means that the nova-lxd <-> pylxd <-> lxd daemon is not being found, and I suspect, it’s pylxd not finding the socket for the local (to the host) LXD daemon.
Please could you provide the version for
LXD
OpenStack versions (e.g. for Ocata it will be something like 15.0.x.x for nova and nova-lxd)
pylxd on the host (either use pip freeze or the apt python package is python-pylxd)
If you log into the host and run lxc version it’ll tell you the version of LXD installed on that host.
Also, if you could describe how LXD is configured on the host, that would be very useful.
I found a problem with the LXD socket and its permissions (root:root). After a quick fix Nova (pylxd) is capable of connecting to socket and is sending the glance Image correctly to the LXD deamon (lxc image list show the correct UUID).
Now I’m facing a problem where neutron-linuxbridge-agent is not creating the tap interface (the bridge is been created just fine). With LXC+Libvirt NeutronLinuxBrigeAgent is working fine so I’m doing more troubleshooting on this environment.
About the versions:
NovaLXD: 15.0.2
NovaCompute: 15.1.5
pylxd: 2.2.4
LXD: 2.0.11 (default installation. profile: nictype: bridged, parent: lxdbro, type: nic)
Now it’s look like the creation of the neutron port is my main problem.
With NovaLXD, neutron agent is still responsible of creating the port and attaching it to the bridge?
But can you run KVM and Nova LXD in two separate compute nodes on the same host? Using the openstack-on-lxd yaml files, you can create as separate compute nodes with each have a different virt-type
You could have two compute nodes deployed in LXD containers on the same host. However, you will have no control over selecting a node to which an application will be deployed.
A better way to deploy two or more compute nodes would be to create additional cells. I used Juju charms to deploy additional cells.
Do you have an example I can review? As far I as knew, host aggregates was the only way to go for segregating virt-types. Using metadata tags and host aggregates is suppose to prompt the scheduler to spin up the instance where the correct virt-type is deployed.