trung-t-trinh's profile - activity

2016-10-24 21:54:52 -0600 received badge  Necromancer (source)
2016-02-17 16:49:00 -0600 received badge  Famous Question (source)
2015-04-15 06:29:04 -0600 received badge  Famous Question (source)
2015-01-05 00:51:11 -0600 answered a question Nova: Server's metadata

Metadata attribute is optional and defaults to an empty dictionary. It's free to define the key/value pairs for this metadata dictionary. The purpose is to input additional parameters to the process of launching VM instance. However, we have to modify legacy Nova source code upon adding new key/value pairs accordingly. Otherwise, it won't make any sense.

The only way to understand this metadata is to look into Nova source code.

2015-01-05 00:39:40 -0600 answered a question How manage licenses for software running in OpenStack clouds?

It would be better to combine both VM instance UUID and the MAC of the computing node on which the VM instance is launched.

2015-01-05 00:24:55 -0600 answered a question instance hostname vs display_name

In Nova source code, "hostname" or "host" is the name of the computing node on which the VM instance is launched. It's stored in this one: instance['host']

2014-12-10 00:47:32 -0600 received badge  Enthusiast
2014-12-09 02:04:15 -0600 asked a question From Cinder, how to check VM instance status?

From Cinder source code, based on the instance_uuid (extracted from the volume object), how to check if the VM instance is deleted or not? Any API or method for this is available?


2014-12-04 20:37:52 -0600 received badge  Popular Question (source)
2014-12-04 20:37:52 -0600 received badge  Notable Question (source)
2014-12-03 01:19:55 -0600 asked a question Convert flat state-machine of VM states to HSM

From this link: , it can be seen that the state machine of VM states is flat-styled and highly-complex.

Is it better to convert this flat state machine to the HSM (Hierarchical State Machine)?

Pros: utilize HSM benefits such as grouping related states to a parent state for some common handling, having ENTRY and EXIT handling for each state and etc

Cons: can introduce potential errors due to the re-work.

2014-11-11 08:55:16 -0600 received badge  Famous Question (source)
2014-11-06 00:30:45 -0600 answered a question Keystone did not start

I myself used to encounter this problem! The root cause is because the specified HOST_IP in the file "local.conf" is neither valid nor reachable! Consequently, no service endpoints (such as keystone, nova and etc) that are bound to the HOST_IP can be invoked.

Make sure the specified HOST_IP is valid and reachable. Alternatively, do not specify it and let DevStack pick up some IP for it.

2014-11-04 21:08:34 -0600 received badge  Notable Question (source)
2014-11-04 09:54:33 -0600 received badge  Popular Question (source)
2014-11-04 04:10:48 -0600 asked a question Boot a new VM from volume in a different availability zone

On single-node deployment of OpenStack (i.e. all components/services are running on the same host), it is quite possible to boot a new VM from volume in a different availability zone. This means that the volume used for booting is in an availability zone different from the one of the created VM.

My question is if this also works on multi-node deployment (i.e. components/services are running on multiple hosts)?

It seems to be that on single-node deployment, it is possible to have only one active availability zone. This is because when trying to create a new availability zone (via creating host-aggregate), this newly-created availability zone hide away the default availability zone.

2014-10-30 13:31:19 -0600 received badge  Teacher (source)
2014-10-29 03:05:45 -0600 answered a question extending Nova

Your scenario is involved with "Scaling". You want to have some kind of redundancy for Cloud. All your questions/confusions can be answered/made clear at the following links:


At first, you should read the general architecture of OpenStack ( ). After that, you can concentrate on Nova as your interest (google with "openstack nova doc"). These docs will guide you how to setup a development environment of Nova. Finally, you can view Nova source code, make some modification and run its Unit-Test.

Last but not least, it's the good way to use DevStack ( ) to install/deploy OpenStack that can be run in a virtual machine on your own laptop.

Nova/virt/libvirt is one of the hot components because it's responsible to create the VMs.

2014-09-25 16:08:59 -0600 received badge  Notable Question (source)
2014-09-25 07:04:08 -0600 received badge  Popular Question (source)
2014-09-25 02:36:28 -0600 asked a question Horizon: display status of the VM

Hi all,

I'd like to ask one question as follow.

If the VM instance is launched but actually the VM can not be booted up completed or the VM is stuck at the booting phase, then Horizon still displays the status of "Running" on dashboard. So, is this kind of behavior right?

For me, this kind of behavior should be wrong. This is because the actual status of the VM is "being-hung" or "stuck". Is it possible for OpenStack Horizon to check the real status of the launched VM via Nova Compute or LibVirt?

Thanks and regards Trung

2014-09-25 01:37:38 -0600 received badge  Notable Question (source)
2014-09-22 00:03:42 -0600 received badge  Popular Question (source)
2014-09-21 21:58:23 -0600 received badge  Editor (source)
2014-09-18 05:19:55 -0600 received badge  Student (source)
2014-09-18 05:02:16 -0600 asked a question Switch firewall_driver control from Neutron to Nova

Hello everyone,

Introduction: We are a group of members working on realization of the PXE net-boot feature that allows user to launch VM from network.

Question: Will OpenStack Nova and Neutron allow to switch firewall_driver control from Neutron to Nova? If no, please explain the disadvantage? If yes, please state some potential drawback?

Scenario: When installing OpenStack (IceHouse release) by using DevStack, by default, firewall_driver control is done completely by Neutron's plugin OVSHybridIptablesFirewallDriver. As the OVSHybridIptablesFirewallDriver generates iptables firewall rules that unfortunately drop our PXE net-boot requests (including DHCP and TFTP requests). Could someone help answer why Neutron firewall rules drop this kind of traffic? Consequently, we ought to change Nova config file and Neutron config file so that Neutron firewall_driver is disabled and Nova firewall_driver is used. In fact, if only Nova IpTablesFirewallDriver is used, then the PXE net-boot requests are passed through. Our change is as follows:

  1. Change Neutron configuration to disable the generation of firewall rules: in file /etc/neutron/plugins/ml2/ml2_conf.ini, comment out or remove the line : firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

  2. Change Nova configuration to enable the generation of firewall rules: in file /etc/nova/nova.conf, change the line: "firewall_driver = nova.virt.firewall.NoopFirewallDriver" to "firewall_driver = nova.virt.firewall.IptablesFirewallDriver"