I just did a test with yestearday's Nova Git (output of `git describe`:
"13.0.0-500-g654181b" when I tested), seems like during instance
evacuate (`nova evacuate vm1 target-host`), QEMU guest agent metadata
for the evauated instance _does_ seem to persist the destination
Compute node.
Test procedure
--------------
(1) Ensure `qemu-guest-agent` is running on both, source _and_ target
Compute nodes:
$ systemctl status qemu-guest-agent
* qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; static; vendor preset: enabled)
Active: active (running) since Wed 2016-04-20 05:16:59 EDT; 2h 10min ago
[...]
(2) Update Glance image metadata property to have
'hw_qemu_guest_agent=yes':
(6) 'nova-compute' binary is marked down on devstack1 (where the first
Compute node is running):
$ nova service-list
+----+----------------+-----------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+----+----------------+-----------+----------+---------+-------+----------------------------+-----------------+
| 3 | nova-conductor | devstack1 | internal | enabled | up | 2016-04-20T11:14:10.000000 | - |
| 4 | nova-cert | devstack1 | internal | enabled | up | 2016-04-20T11:14:07.000000 | - |
| 5 | nova-scheduler | devstack1 | internal | enabled | up | 2016-04-20T11:14:08.000000 | - |
| 6 | nova-compute | devstack1 | nova | enabled | down | 2016-04-20T11:14:04.000000 | - |
| 7 | nova-compute | devstack2 | nova | enabled | up | 2016-04-20T11:14:05.000000 | - |
+----+----------------+-----------+----------+---------+-------+----------------------------+-----------------+
(7) Perform the evacuation of the Nova instance ('cirrvm1') to the
destination Compute node (called 'devstack2' in this case):
$ nova evacuate cirrvm1 devstack2
(8) SSH into the destination Compute node, and check (a) if 'cirrvm1' is
running there, and (b) if the QEMU guest agent XML metadata snippet
is present:
I just did a test with yestearday's Nova Git (output of `git describe`: 500-g654181b" when I tested), seems like during instance
"13.0.0-
evacuate (`nova evacuate vm1 target-host`), QEMU guest agent metadata
for the evauated instance _does_ seem to persist the destination
Compute node.
Test procedure
--------------
(1) Ensure `qemu-guest-agent` is running on both, source _and_ target
Compute nodes:
$ systemctl status qemu-guest-agent agent.service - QEMU Guest Agent systemd/ system/ qemu-guest- agent.service; static; vendor preset: enabled)
* qemu-guest-
Loaded: loaded (/usr/lib/
Active: active (running) since Wed 2016-04-20 05:16:59 EDT; 2h 10min ago
[...]
(2) Update Glance image metadata property to have qemu_guest_ agent=yes' :
'hw_
$ glance image-update 9c915a2c- 5c74-4274- aca4-112d322618 dd \ guest_agent= yes
--property hw_qemu_
(3) Boot an instance (and ensure the instance is active):
$ nova boot --flavor 1 --key_name oskey1 --image \
9c915a2c- 5c74-4274- aca4-112d322618 dd cirrvm1
(4) Check for the QEMU guest agent libvirt XML snippet for the instance:
$ sudo virsh dumpxml 06e11b94- d178-4a3a- 99cc-ce76b37385 79 | grep agent -A3 -B1 var/lib/ libvirt/ qemu/org. qemu.guest_ agent.0. instance- 00000003. sock'/> qemu.guest_ agent.0' state=' disconnected' /> serial' controller='0' bus='0' port='1'/>
<channel type='unix'>
<source mode='bind' path='/
<target type='virtio' name='org.
<alias name='channel0'/>
<address type='virtio-
</channel>
(5) Force-down the 'nova-compute' binary on the host where source
Compute node is running:
$ nova service-force-down devstack1 nova-compute ------- --+---- ------- ---+--- ------- ---+ ------- --+---- ------- ---+--- ------- ---+ ------- --+---- ------- ---+--- ------- ---+
+--
| Host | Binary | Forced down |
+--
| devstack1 | nova-compute | True |
+--
(6) 'nova-compute' binary is marked down on devstack1 (where the first
Compute node is running):
$ nova service-list --+---- ------- -----+- ------- ---+--- ------- +------ ---+--- ----+-- ------- ------- ------- -----+- ------- ------- --+ --+---- ------- -----+- ------- ---+--- ------- +------ ---+--- ----+-- ------- ------- ------- -----+- ------- ------- --+ 20T11:14: 10.000000 | - | 20T11:14: 07.000000 | - | 20T11:14: 08.000000 | - | 20T11:14: 04.000000 | - | 20T11:14: 05.000000 | - | --+---- ------- -----+- ------- ---+--- ------- +------ ---+--- ----+-- ------- ------- ------- -----+- ------- ------- --+
+--
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+--
| 3 | nova-conductor | devstack1 | internal | enabled | up | 2016-04-
| 4 | nova-cert | devstack1 | internal | enabled | up | 2016-04-
| 5 | nova-scheduler | devstack1 | internal | enabled | up | 2016-04-
| 6 | nova-compute | devstack1 | nova | enabled | down | 2016-04-
| 7 | nova-compute | devstack2 | nova | enabled | up | 2016-04-
+--
(7) Perform the evacuation of the Nova instance ('cirrvm1') to the
destination Compute node (called 'devstack2' in this case):
$ nova evacuate cirrvm1 devstack2
(8) SSH into the destination Compute node, and check (a) if 'cirrvm1' is
running there, and (b) if the QEMU guest agent XML metadata snippet
is present:
$ sudo virsh dumpxml 06e11b94- d178-4a3a- 99cc-ce76b37385 79 | grep agent -B1 -A3 var/lib/ libvirt/ qemu/org. qemu.guest_ agent.0. instance- 00000003. sock'/> qemu.guest_ agent.0' state=' disconnected' /> serial' controller='0' bus='0' port='1'/>
<channel type='unix'>
<source mode='bind' path='/
<target type='virtio' name='org.
<alias name='channel0'/>
<address type='virtio-
</channel>
As it can be seen in step-(8), post instance evacuation, the guest agent
metadata persists on the target Compute node.