> On 3 Oct 2019, at 12:50, Vrgotic, Marko <m.vrgo...@activevideo.com> wrote:
>
> Hi Michal,
>
> Thank you. Would you be so kind to provide me with additional clarification?
>
>> you can’t just add a random tag into libvirt xml in a random place, it will
>> be dropped by libvirt.
> I understand, thank you. About persistence of added tag, it was not
> used/written during 1xMigration, but it was present in domxml in 2xMigration.
>
>> you can add it to metadata though. we use that for ovirt-specific information
> Can you please provide some more HowTo/HowNotTo information?
> Can we manipulate the tag in metadata section in each iteration?
> I assume VM metadata shared/communicated between Hosts or read and provided
> to Hosts by oVirt-Engine?
> In short we are trying to achive:
> - start migration
> - ex: 10_create_tag inserts <is_migration/> tag into XML
> metadata section <= maybe we can use before_vm_migration_source hook
> - migration is finished and after_vm_destroy hooks comes to turn:
> - ex: 20_nsupdate reads the metadata and:
> - if tag <is_migrated/> exists, do not run dns
> update, but remove the tag
> - if tag <is_migrated/> does not exists, run dns
> update and remove the tag
so..hmm..if IIUC you basically just need not to execute dns update(remove the
entry for vm) when VM migrates away. and do execute it when it shuts down.
maybe i can suggest two other approaches which could work? these would be
preferable because manipulating with libvirt’s xml at the time of lifecycle
changes are better to be avoided. libvirt is touching the xml at the same tie
and it may run into ugly locking problems.
how about
- use after_vm_migrate_source and make a note of that vmid (touch a file in
/tmp/<vmdid> or whatever), and then check that in after_vm_destroy
or
- use before_vm_destroy and use vdsm-client VM getStats vmid=‘xyz’ to get the
curent VM’s status from vdsm (before it goes away) and you should see if it’s
“Migration Source” vs anything else(Powering Down for ordinary shutdowns or Up
for crashes, I guess)
Thanks,
michal
>
> Kindly awaiting your reply.
>
> Marko Vrgotic
>
> On 03/10/2019, 12:27, "Michal Skrivanek" <michal.skriva...@redhat.com> wrote:
>
>
>
>> On 2 Oct 2019, at 13:29, Vrgotic, Marko <m.vrgo...@activevideo.com> wrote:
>>
>> Any ideas
>>
>> From: "Vrgotic, Marko" <m.vrgo...@activevideo.com>
>> Date: Friday, 27 September 2019 at 17:26
>> To: "users@ovirt.org" <users@ovirt.org>
>> Subject: How to pass parameters between VDSM Hooks domxml in single run
>>
>> Dear oVIrt,
>>
>> A while ago we discussed on ways to change/update content of parameters of
>> domxml in certain action.
>>
>> As I mentioned before, we have added the VDSMHook 60_nsupdate which removes
>> the DNS record entries when a VM is destroyed:
>>
>> …
>> domxml = hooking.read_domxml()
>> name = domxml.getElementsByTagName('name')[0]
>> name = " ".join(name.nodeValue for name in name.childNodes if
>> name.nodeType == name.TEXT_NODE)
>> nsupdate_commands = """server {server_ip}
>> update delete {vm_name}.example.com a
>> update delete {vm_name}. example.com aaaa
>> update delete {vm_name}. example.com txt
>> send
>> """.format(server_ip="172.16.1.10", vm_name=name)
>> …
>>
>> The goal:
>> However, we did not want to execute remove dns records when VM is only
>> migrated. Since its considered a “destroy” action we took following approach.
>> • In state “before_vm_migrate_source add hook which will write flag
>> “is_migration” to domxml
>> • Once VM is scheduled for migration, this hook should add the flag
>> “is_migration” to domxml
>> • Once 60_nsupdate is triggered, it will check for the flag and if
>> there, skip executing dns record action, but only remove the flag
>> “is_migration” from domxml of the VM
>>
>> …
>> domxml = hooking.read_domxml()
>> migration = domxml.createElement("is_migration")
>> domxml.getElementsByTagName("domain")[0].appendChild(migration)
>> logging.info("domxml_updated {}".format(domxml.toprettyxml()))
>> hooking.write_domxml(domxml)
>> …
>>
>> When executing first time, we observed that flag “
>>
>> <name>hookiesvm</name>
>> <uuid>fcfa66cb-b251-43a3-8e2b-f33b3024a749</uuid>
>> <metadata xmlns:ns0="http://ovirt.org/vm/tune/1.0";
>> xmlns:ns1="http://ovirt.org/vm/1.0";>
>> <ns0:qos/>
>> <ovirt-vm:vm xmlns:ovirt-vm="http://ovirt.org/vm/1.0";>
>> <ovirt-vm:clusterVersion>4.3</ovirt-vm:clusterVersion>
>> <ovirt-vm:destroy_on_reboot
>> type="bool">False</ovirt-vm:destroy_on_reboot>
>> <ovirt-vm:launchPaused>false</ovirt-vm:launchPaused>
>> <ovirt-vm:memGuaranteedSize
>> type="int">1024</ovirt-vm:memGuaranteedSize>
>> <ovirt-vm:minGuaranteedMemoryMb
>> type="int">1024</ovirt-vm:minGuaranteedMemoryMb>
>> ...skipping...
>> <address bus="0x00" domain="0x0000" function="0x0"
>> slot="0x09" type="pci"/>
>> </rng>
>> </devices>
>> <seclabel model="selinux" relabel="yes" type="dynamic">
>> <label>system_u:system_r:svirt_t:s0:c169,c575</label>
>>
>> <imagelabel>system_u:object_r:svirt_image_t:s0:c169,c575</imagelabel>
>> </seclabel>
>> <seclabel model="dac" relabel="yes" type="dynamic">
>> <label>+107:+107</label>
>> <imagelabel>+107:+107</imagelabel>
>> </seclabel>
>> <is_migration/>
>
> you can’t just add a random tag into libvirt xml in a random place, it
> will be dropped by libvirt.
> you can add it to metadata though. we use that for ovirt-specific
> information
>
>> </domain>
>> is added to domxml, but was present once 60_nsupdate hook was executed.
>>
>> The question: How do we make sure that, when domxml is updated, that the
>> update is visible/usable by following hook, in single run? How to pass these
>> changes between hooks?
>>
>> Kindly awaiting your reply.
>>
>>
>> — — —
>> Met vriendelijke groet / Kind regards,
>>
>> Marko Vrgotic
>>
>>
>> _______________________________________________
>> 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/IC4J6CAJUQOSLU3ZJPX3ZHTUM4HUCMGU/
>
>
>
_______________________________________________
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/CBKPZVR4G47LCRL4OFQIPZXCBYP5VXII/
