cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Lapointe <>
Subject Re: Windows 10 KVM becoming inaccessible
Date Mon, 10 Aug 2020 17:46:55 GMT
I accidentally first sent this reply from a different email address, and am resending with
my correct email address.  I apologize if the reply shows up twice in the list.


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,

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,
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
>> Hope this helps.
>> Regards.
>> ________________________________
>> From: Dave Lapointe <>
>> Sent: Saturday, August 8, 2020 00:48
>> To: <>
>> 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
>> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
>> @shapeblue

View raw message