[ovirt-users] Re: Windows VMs randomly wont boot after compatibility change

2022-04-22 Thread Erez Zarum
Hey,
This is noted in the documents:
https://www.ovirt.org/documentation/upgrade_guide/index.html#Changing_the_Cluster_Compatibility_Version_minor_updates
I recommend if you can't cope with it (i.e: logging to console and
reconfiguring the NICs/Disks) it to change the VM custom emulated machine
to "pc-q35-rhel8.1.0", this is the default emulated machine when cluster
compatibility level is set to 4.4.
Also note, if you heavily rely on VNC, there's a bug introduced in libvirt
8 that won't allow to set password length longer than 8 chars, oVirt by
default tries to set a password length of 12 chars but up until now libvirt
simply ignored that and set the password based on the first 8 chars, i
don't know from which version that happened but in 4.4.10 you won't be able
to use VNC so i recommend to use SPICE (which is actually much better).



On Fri, Apr 22, 2022 at 2:57 PM David Sekne  wrote:

> Hello,
>
> I have noticed that some of our Windows VM's (2012 - 2022) randomly won't
> boot when reboot is initiated from guest OS. As far as I can tell this
> started happening after we raised the cluster compatibility from 4.4 to 4.5
> (it's 4.6 now). To fix it a VM needs to be stopped and started.
>
> We are running oVirt 4.4.10.
>
> I cannot really see much from the logs if grepping for a specific VM that
> had these issues.
>
> Example VM ID is: daf33e97-a76f-4b82-b4f2-20fa4891c88b
>
> Im attaching logs:
>
> - Initial hypervisor where VM was running on (reboot is initiated at
> 4:06:38 AM): vdsm-1.log
> - Second hypervisor where VM was started after it was stopped and started
> back (this was done 7:45:43 AM): vdsm-2.log
> - Engine log: engine.log
>
> Has someone noticed any similar issues and can provide some feedback /
> help?
>
> Regards,
> David
> ___
> 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/GGAVCU7PPGITPAPZVABJEROFSF3CKXUD/
>
___
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/LIUJVBCGKWNWP46AYR46AUL7A6ZJH7CX/


[ovirt-users] Re: Windows VMs randomly wont boot after compatibility change

2022-04-22 Thread David Sekne
Hello,

I followed the documentation on updating the compatibility version. We had
no issues with NIC's, all VMs just needed a reboot. No other issues were
displayed for VM's after the reboot (we have around 400 VMs) so not sure
which changes we would need to do on VM's themselves?

I will try to change the emulated machine for Windows VMs to see if it
helps (other OS's have no issues).

Thank you for the help.

Regards,
David

On Fri, Apr 22, 2022 at 3:02 PM Erez Zarum  wrote:

> Hey,
> This is noted in the documents:
> https://www.ovirt.org/documentation/upgrade_guide/index.html#Changing_the_Cluster_Compatibility_Version_minor_updates
> I recommend if you can't cope with it (i.e: logging to console and
> reconfiguring the NICs/Disks) it to change the VM custom emulated machine
> to "pc-q35-rhel8.1.0", this is the default emulated machine when cluster
> compatibility level is set to 4.4.
> Also note, if you heavily rely on VNC, there's a bug introduced in libvirt
> 8 that won't allow to set password length longer than 8 chars, oVirt by
> default tries to set a password length of 12 chars but up until now libvirt
> simply ignored that and set the password based on the first 8 chars, i
> don't know from which version that happened but in 4.4.10 you won't be able
> to use VNC so i recommend to use SPICE (which is actually much better).
>
>
>
> On Fri, Apr 22, 2022 at 2:57 PM David Sekne  wrote:
>
>> Hello,
>>
>> I have noticed that some of our Windows VM's (2012 - 2022) randomly won't
>> boot when reboot is initiated from guest OS. As far as I can tell this
>> started happening after we raised the cluster compatibility from 4.4 to 4.5
>> (it's 4.6 now). To fix it a VM needs to be stopped and started.
>>
>> We are running oVirt 4.4.10.
>>
>> I cannot really see much from the logs if grepping for a specific VM that
>> had these issues.
>>
>> Example VM ID is: daf33e97-a76f-4b82-b4f2-20fa4891c88b
>>
>> Im attaching logs:
>>
>> - Initial hypervisor where VM was running on (reboot is initiated at
>> 4:06:38 AM): vdsm-1.log
>> - Second hypervisor where VM was started after it was stopped and started
>> back (this was done 7:45:43 AM): vdsm-2.log
>> - Engine log: engine.log
>>
>> Has someone noticed any similar issues and can provide some feedback /
>> help?
>>
>> Regards,
>> David
>> ___
>> 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/GGAVCU7PPGITPAPZVABJEROFSF3CKXUD/
>>
>
___
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/RROFT5HTYUCTLDJC6Z7S3PWLUO7OEBGD/


[ovirt-users] Re: Windows VMs randomly wont boot after compatibility change

2022-04-22 Thread Erez Zarum
Hey,
This only happens to Windows VMs mostly, when you update the cluster
compatibility level it should alert you on VMs that might have this issues
and let you know before you resume the upgrade.


On Fri, Apr 22, 2022 at 8:04 PM David Sekne  wrote:

> Hello,
>
> I followed the documentation on updating the compatibility version. We had
> no issues with NIC's, all VMs just needed a reboot. No other issues were
> displayed for VM's after the reboot (we have around 400 VMs) so not sure
> which changes we would need to do on VM's themselves?
>
> I will try to change the emulated machine for Windows VMs to see if it
> helps (other OS's have no issues).
>
> Thank you for the help.
>
> Regards,
> David
>
> On Fri, Apr 22, 2022 at 3:02 PM Erez Zarum  wrote:
>
>> Hey,
>> This is noted in the documents:
>> https://www.ovirt.org/documentation/upgrade_guide/index.html#Changing_the_Cluster_Compatibility_Version_minor_updates
>> I recommend if you can't cope with it (i.e: logging to console and
>> reconfiguring the NICs/Disks) it to change the VM custom emulated machine
>> to "pc-q35-rhel8.1.0", this is the default emulated machine when cluster
>> compatibility level is set to 4.4.
>> Also note, if you heavily rely on VNC, there's a bug introduced in
>> libvirt 8 that won't allow to set password length longer than 8 chars,
>> oVirt by default tries to set a password length of 12 chars but up until
>> now libvirt simply ignored that and set the password based on the first 8
>> chars, i don't know from which version that happened but in 4.4.10 you
>> won't be able to use VNC so i recommend to use SPICE (which is actually
>> much better).
>>
>>
>>
>> On Fri, Apr 22, 2022 at 2:57 PM David Sekne 
>> wrote:
>>
>>> Hello,
>>>
>>> I have noticed that some of our Windows VM's (2012 - 2022)
>>> randomly won't boot when reboot is initiated from guest OS. As far as I can
>>> tell this started happening after we raised the cluster compatibility from
>>> 4.4 to 4.5 (it's 4.6 now). To fix it a VM needs to be stopped and started.
>>>
>>> We are running oVirt 4.4.10.
>>>
>>> I cannot really see much from the logs if grepping for a specific VM
>>> that had these issues.
>>>
>>> Example VM ID is: daf33e97-a76f-4b82-b4f2-20fa4891c88b
>>>
>>> Im attaching logs:
>>>
>>> - Initial hypervisor where VM was running on (reboot is initiated at
>>> 4:06:38 AM): vdsm-1.log
>>> - Second hypervisor where VM was started after it was stopped and
>>> started back (this was done 7:45:43 AM): vdsm-2.log
>>> - Engine log: engine.log
>>>
>>> Has someone noticed any similar issues and can provide some feedback /
>>> help?
>>>
>>> Regards,
>>> David
>>> ___
>>> 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/GGAVCU7PPGITPAPZVABJEROFSF3CKXUD/
>>>
>>
___
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/JGVBMOSM6VBZEUKTEVTDH3LH4SRVDNPK/


[ovirt-users] Re: Windows VMs randomly wont boot after compatibility change

2022-04-25 Thread David Sekne
Hello,

I played around a bit with the emulated machine option and I see we have a
slight misunderstanding. We upgraded the cluster compatibility level to 4.5
last year at which time indeed we had to reconfigure most of the NIC's on
Windows VM's (I forgot we had to do this as it wasnt my task). We changed
from 4.5 to 4.6 not long ago and there were no changes needed on VMs at
that time.

The problem we are seeing and started after the update to 4.5 is that VMs
randomly won't boot at all (reboot is initiated through OS). The VM is
stuck at the boot screen (picture attached) indefinitely and the VM can
only be booted if you stop/start it.

[image: image.png]

Have you seen any similar issues?

Regards,
David

On Fri, Apr 22, 2022 at 7:06 PM Erez Zarum  wrote:

> Hey,
> This only happens to Windows VMs mostly, when you update the cluster
> compatibility level it should alert you on VMs that might have this issues
> and let you know before you resume the upgrade.
>
>
> On Fri, Apr 22, 2022 at 8:04 PM David Sekne  wrote:
>
>> Hello,
>>
>> I followed the documentation on updating the compatibility version. We
>> had no issues with NIC's, all VMs just needed a reboot. No other issues
>> were displayed for VM's after the reboot (we have around 400 VMs) so not
>> sure which changes we would need to do on VM's themselves?
>>
>> I will try to change the emulated machine for Windows VMs to see if it
>> helps (other OS's have no issues).
>>
>> Thank you for the help.
>>
>> Regards,
>> David
>>
>> On Fri, Apr 22, 2022 at 3:02 PM Erez Zarum  wrote:
>>
>>> Hey,
>>> This is noted in the documents:
>>> https://www.ovirt.org/documentation/upgrade_guide/index.html#Changing_the_Cluster_Compatibility_Version_minor_updates
>>> I recommend if you can't cope with it (i.e: logging to console and
>>> reconfiguring the NICs/Disks) it to change the VM custom emulated machine
>>> to "pc-q35-rhel8.1.0", this is the default emulated machine when cluster
>>> compatibility level is set to 4.4.
>>> Also note, if you heavily rely on VNC, there's a bug introduced in
>>> libvirt 8 that won't allow to set password length longer than 8 chars,
>>> oVirt by default tries to set a password length of 12 chars but up until
>>> now libvirt simply ignored that and set the password based on the first 8
>>> chars, i don't know from which version that happened but in 4.4.10 you
>>> won't be able to use VNC so i recommend to use SPICE (which is actually
>>> much better).
>>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:57 PM David Sekne 
>>> wrote:
>>>
 Hello,

 I have noticed that some of our Windows VM's (2012 - 2022)
 randomly won't boot when reboot is initiated from guest OS. As far as I can
 tell this started happening after we raised the cluster compatibility from
 4.4 to 4.5 (it's 4.6 now). To fix it a VM needs to be stopped and started.

 We are running oVirt 4.4.10.

 I cannot really see much from the logs if grepping for a specific VM
 that had these issues.

 Example VM ID is: daf33e97-a76f-4b82-b4f2-20fa4891c88b

 Im attaching logs:

 - Initial hypervisor where VM was running on (reboot is initiated at
 4:06:38 AM): vdsm-1.log
 - Second hypervisor where VM was started after it was stopped and
 started back (this was done 7:45:43 AM): vdsm-2.log
 - Engine log: engine.log

 Has someone noticed any similar issues and can provide some feedback /
 help?

 Regards,
 David
 ___
 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/GGAVCU7PPGITPAPZVABJEROFSF3CKXUD/

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