[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

2020-09-01 Thread Michal Skrivanek 


> On 31 Aug 2020, at 21:20, Arik Hadas  wrote:
> 
> 
> 
> On Mon, Aug 31, 2020 at 8:41 PM  > wrote:
> Testing the 4.3 to 4.4 migration... what I describe here is facts is mostly 
> observations and conjecture, could be wrong, just makes writing easier...
> 
> While 4.3 seems to maintain a default emulated machine type 
> (pc-i440fx-rhel7.6.0 by default), it doesn't actually allow setting it in the 
> cluster settings: Could be built-in, could be inherited from the default 
> template... Most of my VMs were created with the default on 4.3.
> 
> oVirt 4.4 presets that to pc-q35-rhel8.1.0 and that has implications:
> 1. Any VM imported from an export on a 4.3 farm, will get upgraded to Q35, 
> which unfortunately breaks things, e.g. network adapters getting renamed as 
> the first issue I stumbled on some Debian machines 
> 2. If you try to compensate by lowering the cluster default from Q35 to 
> pc-i44fx the hosted-engine will fail, because it was either built or came as 
> Q35 and can no longer find critical devices: It evidently doesn't take/use 
> the VM configuration data it had at the last shutdown, but seems to 
> re-generate it according to some obscure logic, which fails here.

that is currently the case, yes. We have 
https://bugzilla.redhat.com/show_bug.cgi?id=1871694 - should be fixed by that, 
right?

> 
> I've tried creating a bit of backward compatibility by creating another 
> template based on pc-i440fx, but at the time of the import, I cannot switch 
> the template.
> If I try to downgrade the cluster, the hosted-engine will fail to start and I 
> can't change the template of the hosted-engine to something Q35.
> 
> Currently this leaves me in a position where I can't separate the move of VMs 
> from 4.3 to 4.4 and the upgrade of the virtual hardware, which is a different 
> mess for every OS in the mix of VMs.
> 
> Recommendations, tips anyone?
> 
> If you have to preserve the i440fx chipset, you can create another cluster 
> that is set with legacy bios and import the VMs to that cluster.
> The drawback in the alternative you tested (importing it to a q35 cluster and 
> override the chipset/emulated machine before launching the VM) is that on 
> import we 
> convert the VM to q35 (changing devices, clearing PCI addresses) and later 
> the VM is converted back to i440fx - so it's less recommended.

once the HE problem goes away it should be perfectly fine to just use that one 
cluster in i440fx mode if you prefer to. It’s q35 only because it’s a new one 
and we assume a new one is for new stuff. For upgraded setups the cluster is 
left as it was.

>  
> 
> P.S. A hypervisor reconstructing the virtual hardware from anywhere but 
> storage at every launch, is difficult to trust IMHO.
> ___
> 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/36WNCP6YMRM3MG44WIVHLVOUD2MACDQ5/
>  
> 
> ___
> 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/PAJJNL44JIIY3RAQTWB456EMQALV4SHM/

___
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/QDWSRU6XSBZ6BSPQNE3ZKJCDKKTHK6G7/

[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

2020-09-01 Thread Arik Hadas 
On Tue, Sep 1, 2020 at 1:22 AM  wrote:

> Thanks for the suggestion, I tried that, but I didn't get very far on a
> single node HCI cluster...
> And I'm afraid it won't be much better on HCI in general, which is really
> the use case I am most interested in.
>

Yes, that requires at least one more host for the second cluster


>
> Silently converting VMs is something rather unexpected from a hypervisor,
> doing it twice my result in the same machine here only by accident.
>
> That type of design decision needs highlighting in the documentation,
> because users just won't be expecting it.
> ___
> 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/MUGBA2TBEEIHIJJLBYVQTYQKUTOJ2MWK/
>
___
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/6GZIVEFL6MJLUSSHRHMUIYPXDZPOFKER/

[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

2020-08-31 Thread thomas 
Thanks for the suggestion, I tried that, but I didn't get very far on a single 
node HCI cluster...
And I'm afraid it won't be much better on HCI in general, which is really the 
use case I am most interested in.

Silently converting VMs is something rather unexpected from a hypervisor, doing 
it twice my result in the same machine here only by accident.

That type of design decision needs highlighting in the documentation, because 
users just won't be expecting it.
___
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/MUGBA2TBEEIHIJJLBYVQTYQKUTOJ2MWK/

[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

2020-08-31 Thread Arik Hadas 
On Mon, Aug 31, 2020 at 8:41 PM  wrote:

> Testing the 4.3 to 4.4 migration... what I describe here is facts is
> mostly observations and conjecture, could be wrong, just makes writing
> easier...
>
> While 4.3 seems to maintain a default emulated machine type
> (pc-i440fx-rhel7.6.0 by default), it doesn't actually allow setting it in
> the cluster settings: Could be built-in, could be inherited from the
> default template... Most of my VMs were created with the default on 4.3.
>
> oVirt 4.4 presets that to pc-q35-rhel8.1.0 and that has implications:
> 1. Any VM imported from an export on a 4.3 farm, will get upgraded to Q35,
> which unfortunately breaks things, e.g. network adapters getting renamed as
> the first issue I stumbled on some Debian machines
>
2. If you try to compensate by lowering the cluster default from Q35 to
> pc-i44fx the hosted-engine will fail, because it was either built or came
> as Q35 and can no longer find critical devices: It evidently doesn't
> take/use the VM configuration data it had at the last shutdown, but seems
> to re-generate it according to some obscure logic, which fails here.
>
> I've tried creating a bit of backward compatibility by creating another
> template based on pc-i440fx, but at the time of the import, I cannot switch
> the template.
> If I try to downgrade the cluster, the hosted-engine will fail to start
> and I can't change the template of the hosted-engine to something Q35.
>
> Currently this leaves me in a position where I can't separate the move of
> VMs from 4.3 to 4.4 and the upgrade of the virtual hardware, which is a
> different mess for every OS in the mix of VMs.
>
> Recommendations, tips anyone?
>

If you have to preserve the i440fx chipset, you can create another cluster
that is set with legacy bios and import the VMs to that cluster.
The drawback in the alternative you tested (importing it to a q35 cluster
and override the chipset/emulated machine before launching the VM) is that
on import we
convert the VM to q35 (changing devices, clearing PCI addresses) and later
the VM is converted back to i440fx - so it's less recommended.


>
> P.S. A hypervisor reconstructing the virtual hardware from anywhere but
> storage at every launch, is difficult to trust IMHO.
> ___
> 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/36WNCP6YMRM3MG44WIVHLVOUD2MACDQ5/
>
___
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/PAJJNL44JIIY3RAQTWB456EMQALV4SHM/

[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

2020-08-31 Thread thomas 
On a machine that survived the import, that worked as expected.

May want to add that to a check list, that the original machine type for legacy 
isn't carried over after an import but needs to be set explicitly.
___
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/AB55P6ATS2NLSOMAU2YCOTDL5TDOVHR4/

[ovirt-users] Re: How can you avoid breaking 4.3.11 legacy VMs imported in 4.4.1 during a migration?

2020-08-31 Thread thomas 
I might have found one: You can set the emulated machine to 'legacy' before the 
first launch.

No idea yet, if it will actually work, because the boot disk was copied empty...
___
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/RXIEQC5URNAZ3VIYOW27FOZCV3AFE23W/