[ovirt-devel] Re: chanking mkIsoFs path
On 2 Sep 2019, at 13:47, Milan Zamazal <mzamazal(a)redhat.com>
wrote:
Dan Kenigsberg <danken(a)redhat.com> writes:
> I bumped by accident on https://gerrit.ovirt.org/#/c/102698/
> py3: mkimage: Remove md5 part in getFileName
>
> and I don't think it is right: if a VM is created in a 4.3 cluster and then
> migrated to a 4.4 cluster, qemu would not find the ISO image where it
> expects it, and it would break.
You're right, thank you for noticing this and pointing it out.
> I don't recall WHY we had md5 included into the path. It may well has been
> a mistake. I just do not see a (easy) backward-compatible way to drop it
> now.
Bleh, my bad. Indeed it will be a problem. Thinking about it, I think it could be solvable
for
4.3->4.4 - just honor the existing path. We get the source xml in migrationCreate so we
can understand if the metadata’s payload already have a disk drive defined.
4.4->4.3 is more tricky. we can fix 4.3 code too..though i’d really like to keep
compatiblity with 4.3 too. Then I *think* we can call the migrationCreate - it will create
the payload in vmid-md5 location on destination. Then we can call the dumpXML (before
starting the migration), get the actual destination path, communicate it down to a libvirt
hook on source, and change the xml on the fly. We did that in the past…so may be doable.
Ugly…
Hopefully it can be done with some rewriting on incoming and outgoing
migrations, we'll see. I'm working on a fix now.
_______________________________________________
Devel mailing list -- devel(a)ovirt.org
To unsubscribe send an email to devel-leave(a)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/devel@ovirt.org/message/5QIEUOPTQMQ...