Bernd Bausch's profile - activity

You are out of luck. It would be the PS driver, but:

The Dell PS Series volume driver is moving into maintanence mode in S release and will be removed in the T release.

You can use it until Stein.

Off-topic: The fact you have a single controller tells me that you don't care for down time that much. On the other hand you have ten compute nodes and 100 VMs, which doesn't look like a toy cloud. I think you should investigate high availability.

Depending on your situation, it might be an option to create an equivalent Ussuri or Victoria cloud, then copy all VMs to that cloud by snapshotting them. How easily you can copy Cinder volumes probably depends on the backend. How easily you can copy the virtual networks depends on their complexity.

Start here: https://docs.openstack.org/operations.... Then search for OpenStack summit presentations that share upgrade experiences.

Warning: Victoria is not released yet. Also, you can't go directly to Victoria or Ussuri. You need to go through all (?) intermediate releases.

There is obviously something wrong with the Cinder config, but I don't see what. What do you see in the Cinder API log?

I do note a typo in the cinder.conf on the controller: "memcahced_servers". If that typo is really in the file, I can imagine this leads to problems.

cinder-api and cinder-scheduler are normally on controllers.

You can have Cinder backends on compute nodes, it's just unusual. Since you have dedicated storage nodes, why put storage on compute nodes?

I don't know whether you should remove cinder-volume from the compute node. It depends on its backend(s). If you use LVM on the compute node as a backend, don't remove it. However you seem to be unclear about your Cinder configuration, which is a bit worrying.

collectd is not related to OpenStack. It collects performance metrics from the computer on which it runs.

Ceilometer is a framework for getting metrics from cloud resources like virtual machines, Neutron networks and Cinder volumes.

Perhaps collectd plugins could be written for this task, but obviously the developers of Ceilometer preferred creating their own solution.

If you ask what might replace Ceilometer, you should look into Prometheus.

I don't think that these parameters are related to migration. They just determine the kind of vCPU on a compute node. In other words, the parameters are as relevant for live migration as for cold migration.

It takes a while until cloud-init completes its work.

By the way, why do you need password authentication? In a cloud, you normally use SSH keys.

What didn't work?

If I understand https://cloudinit.readthedocs.io/en/l... right, your configuration sets the password of the default user. On a Ubuntu image, the default user is ubuntu. Did you try to log on as ubuntu?

Also, it's unclear why you need an RC file on the compute node. Do you log on to the compute node and run openstack commands there? The compute node is not meant to be used like this.

Can you run other commands, such as openstack project list or openstack server list? What about Cinder services - check them with openstack volume service list.

I'd check the Cinder API and Keystone logs for more information.

Your description is a bit confusing. You mention problems with the compute node without elaborating. You mention two storage nodes but cinder-vol seems to be installed on the compute node. And what's wrong with Devstack?

If the problem description is "unable to do it", the answer is "use someone who is able".

In other words, describe your problem. What do you do, what do you expect, what happens.

Banging your head against the wall because you don't have mysql is a strange reaction. It's not that hard to fix it. There will be many more occasions for headbanging down the road, I promise. Such as missing a comma in a config file, which provokes an error that points to everything but that config file.

Having said that, the Keystone Installation Guide says:

Ensure that you have completed the prerequisite installation steps in the Openstack Install Guide before proceeding.

The link unfortunately doesn't point to the first page of the environment description. In fact, in my opinion it should point to the beginning of the install guides. However, you are trying to do the equivalent of "Linux from Scratch", and it is your responsibility to do the research before starting the installation of a beast as complex as OpenStack. Remember, OpenStack is not meant to be a consumer product with a polished interface à la Windows.

Accurate information about MySQL: https://docs.openstack.org/install-gu.... After that, the following pages cover installation of message queue, memcached and etcd.

The Cinder log stops at 19:28:36, five seconds before the Nova error. This explains why it contains no trace of volume ec89c770-...

There must be SOMETHING about this volume in the Cinder api log, around the time of the failure.

You mean that b915cfd8-1b88-44de-a3c7-d1e32c7aac7e is a volume that you created from an image?

Nova seems to be unable to read or otherwise access the volume. As I said, check the Cinder API log around the timestamp of 16:38:18 (i.e. the timestamp of the error in the Nova API log).

There are a number of language bindings. Start at https://developer.openstack.org/. Or to submit APIs directly, use the API guide. For Python, there is the OpenStack SDK.

According to the above documentation, "unused" base images are deleted. The term "unused" is not defined; a superficial look at the source indicates that "used" means "there is an instance", no matter in what state. But I might be wrong.

In any case, I fear your instance can't be restarted.

Cinder API log, about 16:38:18.

Can you also share the commands you use to "create instance with volume" and "launch instance from volume"? And the precise error messages? And which user/project does that?

Why are you trying to launch an Amphora instance?

See also https://docs.openstack.org/nova/train....

The error message seems to indicate that Nova notices the absence of the file under _base and tries to recreated it from a Glance image. Since that Glance image is gone as well, it gives up.

The _base directory contains backing files for qcow files used by instances. I fear that without this _base file, you won't be able to resurrect your instance. How did it disappear? I can't say, but in any case, OpenStack can't prevent you from simply removing files from the filesystem.

You should be able to delete an image from Glance's image store without affecting the instances that were created from it. However, in your case what's missing is the copy of the image on the compute node where your instance is located. Someone/something deleted this copy under /var/lib/nova.

In principle yes, if the instances don't rely on specific CPU features. Check config parameters cpu_mode and cpu_models.

I am sorry, I don't know if this is significant and what it may signify. I would not go that deep into packet analysis right away; rather, I would use tcpdump to find out which is the first interface in the chain that doesn't see DHCP requests or replies.

I would have commented on your question how to install OpenStack on Xen if I had any experience with Xen. However, OpenStack makes no statement about the platform that is suitable for an installation, be it physical or virtual, and in the latter case, which virtualization technology.

Devstack is definitely meant to run on a VM. It is used in OpenStack's Continuous Integration environment, where it runs on VMs in an OpenStack cloud. See the documentation:

Warning

DevStack will make substantial changes to your system during installation. Only run DevStack on servers or virtual machines that are dedicated to this purpose.

You reference https://docs.openstack.org/nova/lates.... This is not a guide for installing OpenStack on Xen. This is a guide for using a XenAPI hypervisor to run instances in an OpenStack cloud. XenAPI is deprecated because the hypervisor driver has not been maintained recently (by the way, the libvirt interface to Xen is still supported).

So yes, you take a VM, or several VMs, or physical machine(s), install one of the supported Linux distros including Python 3 on them, then install OpenStack using one of the many methods - manual, Devstack, Packstack, Kolla, Tripleo, Charms, and probably a few others. By the way, Oracle supports Solaris as a platform.

Some methods such as manual installation, Devstack and Packstack are better suited to small machines. Others like OpenStack-Ansible or Kolla require comparatively large servers (16GB memory perhaps), and others even larger (Charms, Tripleo I would guess).

The first document uses eth0 as a sample NIC name, the second uses p1p1 and p1p2. Of course, you need to replace them with the names in your environment. Use ip a to list your interfaces.

it would help me help you if you told me which web page or other source refers to p1p1.

Yes you can list your server's (not the switch's) ports with ifconfig, although this tool is often not installed. Better use ip a.

I strongly recommend learning Linux networking before installing OpenStack.

Which documentation did you read? Please be aware that the instructions on docs.openstack.org don't know your particular interface names. You have to replace the examples in the documentation with the names on your servers.

There is an OpenStack HA guide that has not been updated in years. You can use it for inspiration: https://docs.openstack.org/ha-guide/i....

Very little: https://docs.openstack.org/arch-desig....

You need two, better three controllers. You need an HA database like Percona. RabbitMQ has HA built-in. Almost all services can run active-active behind HAproxy+keepalived; except cinder-vol.

It's etcd that insists on an IP address. I don't know why, but see https://github.com/etcd-io/etcd/blob/....

Since Devstack uses SERVICE_HOST as a parameter to etcd, I am afraid you have to change the code to achieve this.

In addition to availability, a production system needs support, thorough testing and security features, which Packstack lacks. There may be other factors.

Nothing prevents you from installing additional services on an existing cloud, so the answer to the second question is yes.

Packstack is not for production either, but production means at least three-way redundant controllers, which is not what you'd normally have at home.