none
"Hyper-V-specific video device" in Linux Guests RRS feed

Answers

  • You might want to verify that the Hyper-V specific video driver is, in fact, loaded and in use. Do this at a shell prompt by running "lsmod | grep hyperv". See if "hyperv_fb" is in the list of modules.

    Also, if you are using the VM Connection window in Hyper-V Manager, check to see whether you have just a single cursor, or whether you have a double cursor, where the 2nd cursor trails behind the 1st cursor.  If the Hyper-V specific video driver is loaded and in use, you should have only a single cursor.

    All of that said, our goal with the Hyper-V specific video driver was to do much better than the performance you get with an emulated video frame buffer, but not necessarily to achieve video performance on par with real hardware.  Our focus with Hyper-V, and with Linux on Hyper-V, has been server and datacenter environments, where a high level of video performance isn't super important.  This decision to not put focus on video performance is a business choice based on the markets we are most pursuing, and not a fundamental technical issue or limitation.


    Michael Kelley, Lead Program Manager, Open Source Technology Center

    • Marked as answer by cottington Sunday, November 30, 2014 4:50 PM
    Tuesday, October 14, 2014 4:50 PM
    Moderator

All replies

  • You might want to verify that the Hyper-V specific video driver is, in fact, loaded and in use. Do this at a shell prompt by running "lsmod | grep hyperv". See if "hyperv_fb" is in the list of modules.

    Also, if you are using the VM Connection window in Hyper-V Manager, check to see whether you have just a single cursor, or whether you have a double cursor, where the 2nd cursor trails behind the 1st cursor.  If the Hyper-V specific video driver is loaded and in use, you should have only a single cursor.

    All of that said, our goal with the Hyper-V specific video driver was to do much better than the performance you get with an emulated video frame buffer, but not necessarily to achieve video performance on par with real hardware.  Our focus with Hyper-V, and with Linux on Hyper-V, has been server and datacenter environments, where a high level of video performance isn't super important.  This decision to not put focus on video performance is a business choice based on the markets we are most pursuing, and not a fundamental technical issue or limitation.


    Michael Kelley, Lead Program Manager, Open Source Technology Center

    • Marked as answer by cottington Sunday, November 30, 2014 4:50 PM
    Tuesday, October 14, 2014 4:50 PM
    Moderator
  • Hi,

    I'm not sure what your target was, but my experience is that on a lightly-loaded mid-range server (2x4core/3Ghz, 64GB) the GUI is essentially unusable even for simple administrative tasks. The drivers seem to be loaded and in use, but mouse tracking is so bad it isn't possible to anticipate the mouse position when attempting to click a button....

    Bruce Wood


    PS: The installation is CentOS 7 on Windows Server 2012R2...
    • Edited by Bruce M Wood Saturday, November 29, 2014 12:44 PM
    • Marked as answer by cottington Sunday, November 30, 2014 4:50 PM
    • Unmarked as answer by cottington Sunday, November 30, 2014 4:50 PM
    Saturday, November 29, 2014 12:38 PM
  • The behavior you describe doesn't sound like it is meeting our target. :-(   Let me ask a few questions about exactly what you are doing.

    1. You are running CentOS 7 as a guest VM on Windows Server 2012 R2 Hyper-V
    2. What are you using as your Linux console?  VM Connect in Hyper-V Manager?  Or something else?
    3. What graphics/desktop package are you running on CentOS 7? 

    Michael Kelley, Lead Program Manager, Open Source Technology Center

    Tuesday, December 2, 2014 6:02 PM
    Moderator
  • Hi Guys,

    I suspect I am experiencing the same issue as described above:

    - Host OS: Win Server 2012 R/2, Hyper-V

    - Guest: CentOS7, running as a gen. 2 VM. "Server with GUI" install, running Gnome3 (default).

    - Using VM Connect as console.

    The CentOS GUI is just painfully slow on this setup. If I enable CPU statistics in CentOS, it shows at or near 100% utilization whenever I move the mouse cursor (or, do any operation in the GUI for that matter). As per an above question: I observe only a single mouse cursor--there is not second cursor or dragging trail.

    I also have a CentOS 6.5 guest on the same host, and here the GUI is much more responsive (although it is still quite sluggish).

    Cheers,

    Kjetil

    Monday, December 29, 2014 12:21 PM
  • We have investigated this issue, and have reproduced the high CPU usage with RHEL 7.1 beta, so the repro should be applicable to CentOS 7 as well.  It looks like the majority (70+ %) of the CPU time is being spent in user mode in "gnome-shell".

    We've filed bug #1178997 with Red Hat on this issue.  A Red Hat tester reported that he observed the same problem when running on VMware ESX as the hypervisor.  So at this point, we don't think the issue is with Hyper-V or the Linux Integration Services for Hyper-V.   That's also consistent with the report that CentOS 6.5 does much better.


    Michael Kelley, Lead Program Manager, Open Source Technology Center

    • Proposed as answer by Kjetil H3 Thursday, January 29, 2015 1:25 PM
    Tuesday, January 6, 2015 5:42 PM
    Moderator
  • Michael,

    Thank you for your prompt actions on this issue! I am looking forward to the Red Hat community hopefully being able to improve the GUI experience on Hyper-V (and ESX).

    Cheers,

    Kjetil

    Thursday, January 29, 2015 1:24 PM
  • As a developer using .NET Core I am increasingly using Linux as my .NET dev platform, but I feel trapped.

    The Linux UI perf in HyperV is unacceptable, and as you note this is expected because it isn't your target scenario.

    So then I use VMWare and perf is great, but I can't have HyperV and VMWare installed on my workstation at the same time - and _that_ prevents me from also using things like the Windows Phone and Microsoft Android emulators.

    At the moment then, I am forced to have two physical machines at all times - one to run Windows/VMWare and another to run Windows/HyperV.

    Nasty, especially when I travel a lot - lugging around two machines because virtualization is so restrictive is very problematic.

    Friday, November 6, 2015 6:29 PM
  • Hello.

    I have the same problem as mentions above. As a reply to Lhotka > Why are you lugging around 2 machines? You can just make a dual boot for every Virtual Machine environment.

    So you can have booth installed on 1 machine ;).

    Back to topic:

    This Lagg as described you all having, is due the HyperV video drivers that are not 100% supported in linux. We have to do with the lagg. Or make a dual boot.

    kind regards Erman den Heijer

    Sunday, November 8, 2015 8:32 AM
  • As a reply:


    I have found out a workaround that eliminates the lag in hyper-v.

    Setup and Rdp session inside your Linux-Distro and then connect to it with your RDP viewer.

    The Hyper-V viewer makes the LAG, not the driver.

    How-To:

    Install XRDP:

    sudo apt-get update
    sudo apt-get install xrdp

    After that we need to install the XFCE4 desktop, this is due the gnome desktop is not compatible for RDP:

    sudo apt-get install xfce4

    And now we need to configure the xrdp to use the XFCE4 desktop environment.
    We can use nano or simply redirect:

    echo xfce4-session >~/.xsession

    And now edit the startup file for Xrdp to use XFCE4:

    nano /etc/xrdp/startwm.sh

    And change the last line into, startxfce4. So it looks like this:

    #!/bin/sh
    
    if [ -r /etc/default/locale ]; then
      . /etc/default/locale
      export LANG LANGUAGE
    fi
    
    startxfce4

    Now you only need to restart the Xrdp service:

    sudo service xrdp restart

    Now connect to your virtual machine using the Remote Desktop Connection and enjoy the lagg free VM.

    i know this is just a work around and i keep waiting for a hotfix from MS.

    kind regards


    Sunday, November 8, 2015 10:00 AM
  • "The Hyper-V viewer makes the LAG, not the driver."

    It's good you've found a work-around, but it's unclear to me why you believe the problem is caused by the Hyper-V viewer (a.k.a. Virtual Machine Connection) when your solution also replaces Gnome with XFCE. It seems to me there are three possible sources:

    - Virtual Machine Connection

    - Gnome desktop

    - The poor interoperation between the two of them

    In fact, the first would seem less likely since you say it works with Remote Desktop, and my understanding is that there's quite a bit of common technology between RDC and VMC.

    In any case, thanks for the tip, I will try it out on a test branch and see if the situation here becomes usable (which it isn't now!).

    PS @ Michael Kelley: I see on the RedHat bugtracking issue you mention that they asked for additional info from the submitter (Haiyang Zhang), but there's not been a reply from him yet. Is there any chance this can be followed up?
    • Edited by Alatar Wednesday, August 31, 2016 10:49 PM Added PS
    Wednesday, August 31, 2016 10:45 PM