cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: Windows 10 KVM becoming inaccessible
Date Tue, 18 Aug 2020 05:53:24 GMT
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 <davel@island.net> 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, <dave@praxistech.com.invalid>
> > 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 <davel@island.net>
> >>>> Sent: Saturday, August 8, 2020 00:48
> >>>> To: users@cloudstack.apache.org <users@cloudstack.apache.org>
> >>>> 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
> >>>>
> >>>> rohit.yadav@shapeblue.com
> >>>> www.shapeblue.com
> >>>> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> >>>> @shapeblue
> >>>>
> >>
> >
>


-- 

Andrija Panić

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message