Dear Michal,
Thank you for the update.
On 9 Jul 2019, at 19:07, Michal Skrivanek
<michal.skrivanek@redhat.com<mailto:michal.skrivanek@redhat.com>> wrote:
On 5 Jul 2019, at 16:09, Vrgotic, Marko
<M.Vrgotic@activevideo.com<mailto:M.Vrgotic@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-leave@ovirt.org<mailto:users-leave@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/TRQJAAGDZN6...