Dear Michal, Thank you for the update.
On 9 Jul 2019, at 19:07, Michal Skrivanek <michal.skriva...@redhat.com<mailto:michal.skriva...@redhat.com>> wrote: On 5 Jul 2019, at 16:09, Vrgotic, Marko <m.vrgo...@activevideo.com<mailto:m.vrgo...@activevideo.com>> wrote: 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. Question: * 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. * 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 migration. * If its relevant for the question: we are currently running oVIrt 4.3.3 version Kindly awaiting your reply. Marko Vrgotic ActiveVideo _______________________________________________ Users mailing list -- users@ovirt.org<mailto:users@ovirt.org> To unsubscribe send an email to users-le...@ovirt.org<mailto:users-le...@ovirt.org> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TRQJAAGDZN67BLLWRLLRAGYUSB2EDAWA/
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UYM6K5IM55KWOHZ4EQNOLJ7XTX4RYN4P/
