Hi Andrija,

Thanks for your feedback.

I also thought that the configured CPU speed shouldn't make a difference.  And 
KVM is such a stable, well-supported technology that I didn't think the CPU 
speed would cause a problem. I updated the virtio drivers to the latest version 
from Fedora and still the problem persisted.  The only thing that appeared to 
make a difference was reducing the CPU speed.  Although I appear to have a 
solution, it's a bit concerning that there doesn't really seem to be a reason 
why it works.  Maybe this adjustment has only made the problem less likely to 
happen, and I'll have to deal with it again at some point in the future.

Thanks,
Dave

On 08-12-20 1:52 p.m., Andrija Panic wrote:
Hi Dave,

it should not be related to your CPu speed at all, i.e. your VM would not
be able to start (ACS defence mechanisms) and for KVM, assuming no CPU cap
on the compute offerings, it actually doesn't make any difference whether
you start VM with 1Ghz or 2Ghz compute offers (virsh dumpxml to confirm).

I've seen in the past various Windows guest issues on KVM (managed by
cloudstack) freezing, BSOD, network connectivity issue - all due to poor
virtio drivers code. try downgrading to latest stable virtio drivers from
Fedora website, experiment with different versions until you find a stable
one.
In my previous job we had majority of Windows guests on KVM, most of it
worked perfectly.

Best,


On Mon, 10 Aug 2020, 21:42 Dave Lapointe, <[email protected]>
wrote:

Hello,

Thanks for this information.  I think I may have stumbled on a solution
(stumble really is the operative word here).  To follow up on the responses
though:

I've tried both with passthrough and without it, and the results were the
same.

In my searching for a solution I found out about centos-release-qemu-ev
and installed qemu-ev.  It didn't seem to change this behaviour, but it did
appear to reduce the host cpu with idle guests (although not as much as I'd
hoped).

I used the latest virtio.iso from Fedora to install what drivers I could.
Some drivers wouldn't install though (eg. network and graphics)... I got
messages about version incompatibility, or configuration errors.

I decided to do a completely new install (O/S and CloudStack) on a
different, much older machine, and found that I had different behaviour.
The VM's ran without any problems.  Aside from the hardware differences, I
also used just the default "Medium" Compute Offering for the VM's (which I
think is 1GB RAM and 1GHz CPU).  And this is where I stumbled on the
solution.  On the problematic system, I had created a Compute Offering that
I thought was suited to the hardware configuration and the number of
concurrent VM's that would run on it.  So I switched the VM's to the
default "Medium" Compute Offering on this new computer.  And the VM's
didn't freeze.  I experimented with different Compute Offerings and found
that this was what made the difference.  In this case, it looks like the
Compute Offering's CPU speed has to be set somewhat lower than the actual
CPU speed.  Adding cores to the Compute Offering with the lower CPU speed
also worked.

I think this is just my lack of knowledge... I seemed to recall that QEMU
wouldn't start a VM with an incompatible configuration.  But that may not
be the case, as this experience indicates.  It's possible too that the
configuration wasn't incompatible but that it happened to be something that
caused Windows to not play nice because I had no issues with an Ubuntu
Desktop VM using the same Compute Offering.

Thanks for your help,
Dave

On 08-09-20 6:04 p.m., Eric Lee Green wrote:
I will note that we have several Windows 10 / Windows 2018 genre VM's on
Centos 7.8.2003 and are not seeing any guest freezes. But:

1) We are not using CPU host-passthrough.

2) We do have the QEMU Windows guest drivers installed in the VM's.

3) I am running Cloudstack 4.11.3. I tried upgrading to Cloudstack
4.14.0 and the upgrade failed, the agent was unable to ssh into virtual
routers to configure them.

That said, the version of Cloudstack should not matter, since all
Cloudstack does is tell libvirtd to launch the VM. libvirtd handles
everything from there. We are literally using the stock Centos 7.8
libvirtd.conf as modified by the agent configurator.  I wonder if you are
having a hardware problem on your new server, or if there is a Linux OS
problem handling your new server. Use journalctl and see if you're seeing
anything at the Linux OS level when a freeze happens, and check the qemu
log files for the instance also, because normally libvirtd is quite
reliable and Centos 7.8.2003 supports Windows 10 VM's just fine.

On 8/9/2020 8:48 AM, Rohit Yadav wrote:
Hi Dave,

I've not specifically worked with Windows guest VMs on KVM, but what
you've described is largely subject to a guest OS support by the
hypervisor, in this case the specific libvirt/qemu/linux-kernel version and
any guest tools/drivers that must be installed inside the Windows guest VM.
You've yourself acknowledged that the issue is not seen in your older
CentOS6 based environment.

To rule out CloudStack (a) you may add or upgrade hosts in a cluster to
use qemu-ev (enterprise qemu release by CentOS SIG
https://wiki.centos.org/SpecialInterestGroup/Virtualization, i.e. install
the centos-release-qemu-ev pkg) or (b) you may add a new cluster with
Ubuntu 18.04 KVM hosts and recreate your Windows VM setup. Or, it could be
a specific Windows build or requires additional drivers (such as
https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers).


Hope this helps.


Regards.

________________________________
From: Dave Lapointe <[email protected]>
Sent: Saturday, August 8, 2020 00:48
To: [email protected] <[email protected]>
Subject: Windows 10 KVM becoming inaccessible

Hi,

I've been lurking on this group for a few years now and have found the
information that people have posted here to be quite helpful for me to
understand CloudStack better.  I've never replied here because there are
always far more knowledgeable people on this list who can offer much better
insight than I ever could.

An issue has arisen recently that I can't find any solution for.  I
apologize ahead of time if this is the wrong list to post to.

I recently configured a new server to run CloudStack using Centos
7.8.2003 and CloudStack 4.14, and configured some Windows 10 LTSB KVM
guests.  This is a fairly specialized server, so the configuration is a
little unusual.  It's configured to use the "cloudbr0" software bridge for
the guest network which is then routed externally through a single NIC.
Also, because the VM's will never be migrated, I've set
guest.cpu.mode=host-passthrough.

What's been happening though is that the VM's will just freeze
sometimes, apparently randomly.  Sometimes it will happen during boot, or a
couple minutes after connecting by RDP.  And sometimes the VM won't freeze
at all.  I haven't been able to determine a pattern as to when this will
happen.  And I haven't found anything in the logs that might help me
understand what's happening (/var/log/messages and
/var/log/cloudstack/management/management-server.log).  I've checked on the
QEMU and Linux forums, but have only found a bit of information about VM's
freezing for people using specific graphics drivers with passthrough for
their graphics cards.  I tried removing guest.cpu.mode=host-passthrough but
that made no difference.

What's especially odd to me is that this didn't happen with older
systems I've created (eg. CentOS 6 and CloudStack 4.9).  I've setup half a
dozen or so using the same configuration as this system, just older
software.

I can't tell if this is related to CloudStack (maybe there is something
in the guest parameters that is causing this), or if this is strictly a KVM
issue.  And since I can't find anything in the logs I don't know where else
to look.  I'm hoping to get some suggestions from this list so that I can
do some more digging.

Thanks,
Dave

[email protected]
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue



Reply via email to