again, do the virsh dumpxml i-xx-yy-VM from the KVM host where the VM is running (with and without reducing the CPU) - and see if there is any difference in the output XML.
Don't necessarily use the latest VirtIO, try different versions (latest STABLE, etc) - i.e. the CPU speed issue would be very silly to have anything to do with stability - but you never know - might be a new thing. Best, On Tue, 18 Aug 2020 at 00:51, Dave Lapointe <[email protected]> wrote: > 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 > >>>> > >> > > > -- Andrija Panić
