Gianluca Cecchi <gianluca.cecchi(a)gmail.com> writes:
On Thu, Dec 17, 2020 at 5:30 PM Milan Zamazal
<mzamazal(a)redhat.com> wrote:
> Gianluca Cecchi <gianluca.cecchi(a)gmail.com> writes:
>
> > On Wed, Dec 16, 2020 at 8:59 PM Milan Zamazal <mzamazal(a)redhat.com>
> wrote:
> >
> >>
> >> If the checkbox is unchecked, the migration shouldn't be prevented.
> >> I think the TSC frequency shouldn't be written to the VM domain XML in
> >> such a case and then there should be no restrictions (and no guarantees)
> >> on the frequency.
> >>
> >> Do you mean you can't migrate even with the checkbox unchecked? If so,
> >> what error message do you get in such a case?
> >>
> >
> > Yes, exactly.
> > I powered off the VM and then disabled the check and then powered on the
> VM
> > again, that is running on host ov301. ANd I have other two hosts: ov300
> and
> > ov200.
> > From web admin gui if I select the VM and "migrate" button I cannot
> select
> > the destination host and inside the bix there is the words "No available
> > host to migrate VMs to" and going to engine.log, as soon as I click the
> > "migrate" button I see these new lines:
>
> I see, I can reproduce it. It looks like a bug in Engine. While the VM
> is correctly started without TSC frequency set, the migration filter in
> Engine apparently still applies.
>
> I'll add a note about it to the TSC migration bug.
>
> Regards,
> Milan
>
>
Ok, thanks.
In the meantime do I have any sort of workaround to be able to migrate the
VM? Eg I could set the VM as non High Performance, or any better other
option?
Non high performance VMs should migrate fine, but changing the VM kind
requires restart. Once a high performance VM is running, I don't know
about any good way to avoid the TSC constraint.
Regards,
Milan