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':

    $ glance image-update 9c915a2c-5c74-4274-aca4-112d322618dd \
        --property hw_qemu_guest_agent=yes

(3) Boot an instance (and ensure the instance is active):

    $ nova boot --flavor 1 --key_name oskey1 --image \
        9c915a2c-5c74-4274-aca4-112d322618dd cirrvm1

(4) Check for the QEMU guest agent libvirt XML snippet for the instance:

    $ sudo virsh dumpxml 06e11b94-d178-4a3a-99cc-ce76b3738579 | grep agent -A3 -B1
        <channel type='unix'>
          <source mode='bind' path='/var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-00000003.sock'/>
          <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
          <alias name='channel0'/>
          <address type='virtio-serial' controller='0' bus='0' port='1'/>
        </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
    +----+----------------+-----------+----------+---------+-------+----------------------------+-----------------+
    | 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:

    $ sudo virsh dumpxml 06e11b94-d178-4a3a-99cc-ce76b3738579 | grep agent -B1 -A3
        <channel type='unix'>
          <source mode='bind' path='/var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-00000003.sock'/>
          <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
          <alias name='channel0'/>
          <address type='virtio-serial' controller='0' bus='0' port='1'/>
        </channel>


As it can be seen in step-(8), post instance evacuation, the guest agent
metadata persists on the target Compute node.