On Fri, Aug 28, 2020 at 2:31 AM <tho...@hoberg.net> wrote: > > I am testing the migration from CentOS7/oVirt 4.3 to CentOS8/oVirt 4.4. > > Exporting all VMs to OVAs, and re-importing them on a new cluster built from > scratch seems the safest and best method, because in the step-by-step > migration, there is simply far too many things that can go wrong and no easy > way to fail-back after each step.
You should really try the attach/detach storage domain, this is the recommended way to move vms from one ovirt system to another. You could detach the entire domain with all vms from the old system, and connect it to the new system, without copying even one bit. I guess you cannot do this because you don't use shared storage? ... > So I have manually put the single-line fix in, which settles udev to ensure > that disks are not exported as zeros. That's the bug which renders the final > release oVirt 4.3 forever unfit, 4 years before the end of maintenance of > CentOS7, because it won't be fixed there. Using ovirt 4.3 when 4.4 was released is going to be painful, don't do this. ... > But just as I was exporting not one of the trivial machines, that I have been > using for testing, but one of the bigger ones, that actually contain a > significant amout of data, I find myself hitting this timeout bug. > > The disks for both the trival and less-trivial are defined at 500GB, thinly > allocated. The trivial is the naked OS at something like 7GB actually > allocated, the 'real' has 113GB allocated. In both cases the OVA export file > to a local SSD xfs partition is 500GB, with lots of zeros and sparse > allocation in the case of the first one. > > The second came to 72GB of 500GB actually allocated, which didn't seem like a > good sign already, but perhaps there was some compression involved? > > Still the export finished without error or incident and the import on the > other side went just as well. The machine even boots and runs, it was only > once I started using it, that I suddenly had all types of file system > errors... it turns out 113-73GB were actually really cut off and missing from > the OVA export, and there is nobody and nothing checking for that. You are hitting https://bugzilla.redhat.com/1854888 ... > I have the export domain backup running right now, but I'm not sure it's not > using the same mechanism under the cover with potentially similar results. No, export domain is using qemu-img, which is the best tool for copying images. This is how all disks are copied in oVirt in all flows. There are no issues like ignored errors or silent failures in storage code. ... > P.P.S. So just where (and on which machine) do I need to change the timeout? There are no timeouts in storage code, e.g. attach/detach domain, or export to export domain. Nir Nir _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z5BMSR6OGW7I4AU363QH562MY7HJ57NV/
