How to increase the visualized screen resolution on QEMU / KVM?

Question

I have a 64 bit Ubuntu 9.10 workstation with two virtualized guest OSes using KVM/QEMU. Also both 64-bit. One is Fedora 12 the other is beta of Ubuntu 10.04.

The problem is that I would like to use a larger size display that is configured by default. Both guest OSes have a maximum screen resolution of 1024x768. I would like to increase this to something like 1280x900 or 1440x900. The resolution of the host system is 1920x1080.

This configuration appears to be a result of the installation detecting the resolution being reported by the virtual screen during installation.

The only information I have found on the subject suggests modifying the xorg.conf file in the /etc/X11 directory. Neither guest system has this file.

I tried creating one by hand in the Fedora system and managed to render it completely unusable. Not a big deal as this is recently installed and can be reinstalled easily.

Is what I want to do possible? If so, how do I accomplish it?

Solution 1

Add the '-vga std' flag to the command line

Basically, the virtual machine loads its own virtual driver. Hardware virtualization is necessary because virtual disk images are often copied to many different systems with diverse architectures. By abstracting the hardware the vm images are capable of doing this.

By using the '-vga std' flag you make the GuestOS load a standard VGA device that should be able to support resolution equal-to-or-greater than your physical card can handle.

For more info check out this article.

Note: If you're using an older version of kvm/qemu the you might need to use the '-std-vga' flag instead.

If you aren't able to reach resolutions greater than 1600x1200 note that there are still some issues with this option.

Solution 2

-vga virtio

Using this option allows me to go all the way up to 4096 x 2160.

Of course, this is useless since my display only goes up to 1080p, so I set 1080p.

Then you can toggle fullscreen with Ctrl + Alt + F, or by passing -full-screen.

How I guessed it: virtio in general means: simulate a generic convenient VM machine without normal hardware restrictions.

Tested with this exact setup: https://askubuntu.com/questions/884534/how-to-run-ubuntu-16-04-desktop-on-qemu/1046792#1046792

As explained there, QEMU has a feature which automatically updates the resolution as you increase the host window size e.g. by dragging the borders with your mouse. But it also works if you go into the guest Ubuntu resolution settings. But if you select a huge guest resolution with a tiny host window, that will of course be useless (QEMU will have to sample multiple pixels into one), so generally you just want to let QEMU automatically scale for you.

This screenshot shows how my guest could go up to 4k:

Solution 3

Use the vmvga Video Card

I use virt-manager (as I'm a complete noob to kvm and libvirt).

I was able to get higher resolutions on a Windows 7 guest by changing the video card from vga to vmvga in the virtual machine's settings window.

Solution 4

2021 Solution for virt-manager users

Steps

• Open terminal
• virt-manager
• Open VM settings
• Go to "Video" tab
• Change to "Virtio"
• Run / restart VM
• Open settings in guest OS (eg I run Debian 10 with XFCE so I open XFCE settings)
• Change display resolution

Here's a screenshot of the relevant tab on virt-manager

Solution 5

As of 2014, if you want to get better than the 1024x768 resolution offered by the Cirrus vGPU, and you are running KVM as your hypervisor on an x86_64 hostOS platform, you should look into using the QXL vGPU driver in the guestOS, coupled with the spice-server display. This can be configured from your virt-manager GUI settings (or of course from CLI args).

In my case, I created the VM using virt-install, put the OS on the vHDD using the normal vnc-style control and the normal cirrus-vGPU. Once everything was working, and all guestOS (and hostOS) software updates had been applied, I used virt-manager to change from vnc-display to spice-graphics, and from cirrus-video to QXL-video. It also helps to add the 'channel' to your VM for spice-vdagent[d] running inside the guest, which allows you to cut-n-paste data in between guestOS apps and hostOS apps pretty decently.

Besides offering high resolutions, the QXL/spice setup was a big improvement over the Cirrus/VNC setup when watching videos in the guestOS -- I actually got some thermal-trip warnings from the CPU when attempting to watch fullscreen videos in 1024x768 Cirrus/VNC, but the laptop ran cool and the fans were quiet when doing fullscreen 1920x1080 video with the more-efficient QXL/spice option. There are limitations on what sort of installations are supported by QXL/spice, but if your system(s) can use them, they are recommended for improved 2D and video-playback. http://www.linux-kvm.org/page/SPICE , scroll down to "Enabling SPICE using virt-manager". I wasn't prompted to add the channel, as the page claims, but it wasn't hard to add manually. If you are working with windows-guestOSes, or having trouble with the brief instructions at the linux-kvm.org site, see here -- http://www.spice-space.org/page/Documentation (but beware both the wiki and the main site are WOEFULLY out-of-date with many pages from 2009 through 2012, so tread carefully). The project is actively developed, but not very actively documented.

QXL/spice is not especially straightforward at the moment, and may not work in your desired software/hardware enVironment. Still, with a bit of elbow-grease it can be made to work, and the upside is significant (especially if battery-life and/or fan noise are concerns). You won't get truly high performance graphics -- investigate VFIO and VT-d/IOMMU passthru for that possibility iff you have the specialized CPU+GPU hardware needed and plenty of time to try and get it working. QXL/spice gives decent 2D and video-playback speed, though.

View more solutions

Comments

[Evan Plaice]

+1 This is something I'd also really like to know. My HostOS native resolution is 1920x1080 and my GuestOS (Windows 7) is also stuck @ 1024x768. I'm pretty sure (from what I've read online so far) that qemu handles the hardware virtualization but I have no idea how to configure it to work with the physical graphics card.

[Evan Plaice]

Got it, see my answer.

[jww]

Also see VNC display size on RedHat's libvirt mailing list.

[Matt Connolly]

I have -vga std and can access high resultions from windows guests, but my ubuntu guest is stuck on 1024x768. Those linked posts are pretty old (2008 and 2010 respectively).

[Sean]

Me too ... but that doesn't change (always 1024x768) !

[diffalot]

i going way back in my memory here, but i think i was able to change the screen resolution within the guest OS once it booted using the vmvga card.

[jww]

When you say "Add the '-vga std' flag to the command line", where did you add it? Do you launch the guest with virsh start <machine> -vga std? Or did you do something else?

[Evan Plaice]

@jww On the first boot it can be set temporarily from the grub console. Add it as a kernel flag. After, the system is booted it can be added permanently to grub.conf the same way it was added through the grub console. Don't forget sudo update-grub to lock-in the settings after editing the grub config.

[Ciro Santilli Путлер Капут 六四事]

@MattConnolly -vga virtio allowed me to go up to 4096 x 2160: superuser.com/a/1331924/128124

[Ray Woodcock]

In this answer, I get link rot re "this article." Try the archive: web.archive.org/web/20160126004059/http://www.linux-kvm.com:‌​80/…

[Avindra Goolcharan]

vmvga doesnt seem to exist anymore, but vga seems to work fine, as well as qxl

[Matthias Braun]

This worked great with headless QEMU on Arch Linux, while connected with TigerVNC to the guest OS. Sway (Wayland) is my window manager.

[interestedparty333]

This should probably be the modern accepted answer. The vga option was really laggy with the mouse -- perhaps because it was using software rendering, where as maybe the virtio option is gpu supported.

[Community]

Please add further details to expand on your answer, such as working code or documentation citations.