On 9 Jul 2019, at 22:09, Vrgotic, Marko
Thank you for the update.
On 9 Jul 2019, at 19:07, Michal Skrivanek <michal.skrivanek(a)redhat.com
>> On 5 Jul 2019, at 16:09, Vrgotic, Marko <M.Vrgotic(a)activevideo.com
>> Dear oVIrt,
>> Happy to report I have deployed my first python vdsm_hook which removes A, AAAA,
TXT records of VM each time after_vm_destroy event is triggered, and it works fine.
>> This was required to be able to quickly redploy/rebuild VMs using same hostname.
>> Issue I am observing/just discovered now is:
>> Since live_migration of VM guest is considered a destruction from Host
perspective, DNS records get deleted and VM lands on new host without being resolvable 😊
>> I would like to introduce another python script for hook regarding migration
events to get these entries back into DNS but for that I need there IPs.
>> Where can I find/locate/read VMs IPs and Hostnames (is it dom_xml) to be able to
incorporate them for DNS Update script?
> IP is reported via guest agent.
> You can get that from engine’s API. But this being a hook you can probably poll
directly as part of the pre/post migration hook by directly interacting with vdsm, either
from a python hook or using vdsm-client, get VM's stats and parse it from there
This is definitely option I will look into. The downside of this is that I need to delete
the records, read the IPs and update the record into DNS. If software tests are running
and we have request relying on DNS after records deleted and before updated, they would
fail. But I assume that period is very short and it could be mitigated using cache.
is that a record for the guest IP? It won’t change during migration.
>> Or even better:
>> What would be even better, is there a way to not trigger the dns update if VM is
being Migrated? Can I use dom_xml or other location to check wheter VM is migrated or
not, which would allow me to control if dnsupdate should be triggered or not
> Not sure how exactly you mean that to work, in general you can use
before/after_vm_migrate_source and before/after_vm_migrate_destination hook points to
intervene wherever you prefer.
The reason why I mentioned this would be better, if it can be pulled off, is that I would
not need to trigger deletion of records if I could catch the migration action. In case it
would be shutdown/power off or delete, it would be triggered, but not in case of
there are hook points for all lifecycle actions, usually both before and after so you can
put it in the right place as you see fit.
>> If its relevant for the question: we are currently running oVIrt 4.3.3 version
>> Kindly awaiting your reply.
>> Marko Vrgotic
>> Users mailing list -- users(a)ovirt.org <mailto:email@example.com>
>> To unsubscribe send an email to users-leave(a)ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> List Archives: