pc 1.0 machine type regressed with -vga vmware

All the differences in xml files, one from installing a new guest VM on a 12.04 server as the host and one installing the same guest again from the same server upgraded / updated to a 14.04 server host.

Thank you for filing this bug.

For further clarification: are you connecting to a vncserver service running within the guest VM? Or are you connecting to the qemu VNC head on the server which hosts the virtual machines? Also, on which host and environment are you seeing the 'low graphics mode' dialog box?

"are you connecting to a vncserver service running within the guest VM? Or are you connecting to the qemu VNC head on the server which hosts the virtual machines?"

I connect to the host server IP address port 5900.

"Also, on which host and environment are you seeing the 'low graphics mode' dialog box?" I see the 'low graphics mode' box on the guest VM running on the 14.04 server host after the upgrade from 12.04 server and before changing the machine type in the .xml file.

Thank you for the info. Can you also collect and post more info about the host using these commands?

dpkg -l | egrep 'qemu|kvm|libvirt'

lsb_release -a

free -m

uname -a

virsh capabilities

qemu-system-x86_64 -machine help

Add'l input from my environment:

I recently upgraded one of my two local hosts from Precise to Trusty, containing a dozen or so guests, including Ubuntu Precise, Trusty, CentOS, and a Windows guest. I had to adjust the machine types in the XML definitions after the upgrade. Other than that, these guests have all been stable and happy. Granted, I generally don't use VNC/VGA to access them, so our scenarios are a bit different in that.

As a quick check, I just tested using VNC (Vinagre client) from my Precise desktop to the Trusty-upgraded server that hosts about half of my VMs. The beloved Windows 8 GUI, LXDE and Openbox displayed flawlessly for me. Display and responsiveness on these was normal.

On the Trusty guests with XFCE, Gnome, and Gnome classic, there were some odd video artifacts and screen drawing issues over the qemu vnc head. I expect this is due to things like gpu acceleration and other fancy gui features, but that may require some more research.

Next, I can hop on a Win 7 laptop and test VNC performance to a couple of those Trusty-hosted VM heads.

By the way, if I do the opposite: On an new Ubuntu 14.04 server installation with a newly installed guest Ubuntu dekstop; Use virsh edit and change the machine type to pc-1.0, then the quest VM has the same issues upon login.

The information requested above:

doug@s15:~$ dpkg -l | egrep 'qemu|kvm|libvirt'
ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1 all PXE boot firmware - ROM images for qemu
ii kvm-ipxe 1.0.0+git-20131111.c3d1e78-2ubuntu1 all transitional dummy package
ii libsys-virt-perl 1.2.1-1 amd64 Perl module providing an extension for the libvirt library
ii libvirt-bin 1.2.2-0ubuntu13 amd64 programs for the libvirt library
ii libvirt0 1.2.2-0ubuntu13 amd64 library for interfacing with different virtualization systems
ii python-libvirt 1.2.2-0ubuntu1 amd64 libvirt Python bindings
ii qemu-common 2.0.0~rc1+dfsg-0ubuntu3 all dummy transitional package from qemu-common to qemu-keymaps
ii qemu-keymaps 2.0.0~rc1+dfsg-0ubuntu3 all QEMU keyboard maps
ii qemu-kvm 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU Full virtualization on x86 hardware (transitional package)
ii qemu-system-common 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU full system emulation binaries (common files)
ii qemu-system-x86 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU full system emulation binaries (x86)
ii qemu-utils 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU utilities

doug@s15:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty

doug@s15:~$ virsh capabilities
<capabilities>

  <host>
    <uuid>c09f3a27-cb5b-d911-9bbf-f46d04652d8e</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Westmere</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='4' threads='2'/>
      <feature name='rdtscp'/>
      <feature name='avx'/>
      <feature name='osxsave'/>
      <feature name='xsave'/>
      <feature name='tsc-deadline'/>
      <feature name='pcid'/>
      <feature name='pdcm'/>
      <feature name='xtpr'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='monitor'/>
      <feature name='dtes64'/>
      <feature name='pclmuldq'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='vme'/>
    </cpu>
    <power_management>
      <suspend_mem/>
      <suspend_disk/>
      <suspend_hybrid/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      <...

So this is happening with the vmware driver. I can use '-M pc-1.0' just fine when i use -vga cirrus

(I do see in the description that yous aid you tested with cirrus; i can't verify that breakage)

pc-1.2 works fine for me. I assume the following:

        },{\
            .driver = "VGA",\
            .property = "vgamem_mb",\
            .value = stringify(8),\
        },{\
            .driver = "vmware-svga",\
            .property = "vgamem_mb",\
            .value = stringify(8)

is the meaningful difference. This then comes down again not to a regression from qemu 1.0 to 2.0, but an unfortunately difference between qemu-kvm and qemu.

Indeed I can work around it by using

 kvm -M pc-1.0 -m 1024 -cdrom ubuntu-13.10-desktop-amd64.iso -vga vmware -monitor stdio -global vmware-svga.vgamem_mb=32

However updating the machine type is probably the safer thing to do.

Thanks again for filing this bug.

I've added a note to https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes . I'm marking this wontfix. We could in fact fix this by upping the memory size for pc-1.0, but that would increase our delta from debian and upstream so unless others think this crucial, I prefer not to.

I agree with the summary change to "pc 1.0 machine type regressed with -vga vmware":

And confirm via two new VM desktop guest installations. One was on a 14.04 server host upgraded from from a 12.04 server. The other was on a new 14.04 server. In both cases the machine type was forced on the command line:

sudo virt-install -n desk_tt3 -r 8192 --disk path=/media/newhd/desk_tt3.img,bus=virtio,size=50 -c trusty-desktop-amd64-20140417.iso --machine pc-1.0 --network bridge=br0,model=virtio --video=vmvga --graphics vnc,listen=0.0.0.0 --noautoconsole -v --vcpus=4

They both had the low graphics issue upon re-boot after the installation completed.

I agree with the recommendation to just change the machine type and this bug being set to "won't fix".

About the cirrus driver:

I was using "virsh edit bla" to change the driver, something I do often. I made a new VM desktop guest from scratch with this command (which will use the cirrus driver, by default):

sudo virt-install -n desk_tt4 -r 8192 --disk path=/home/doug/img/desk_tt4.img,bus=virtio,size=50 -c trusty-desktop-amd64-20140417.iso --machine pc-1.0 --network bridge=br0,model=virtio --graphics vnc,listen=0.0.0.0 --noautoconsole -v --vcpus=4

And it worked fine. (Except that the cirrus driver has never worked quite right for me, and the display size options are not as extensive as the vmvga driver.) I'll come back to this if needed.

I disagree about bumping the memory size as a fix:

For many months (13.10 days) I have always been bumping the memory for the video, as I calculated that it should be more. Typically, I have this in the .xml file:

<model type='vmvga' vram='16384' heads='1'/>

And I even ran this just now:

<model type='vmvga' vram='32768' heads='1'/>

Question:

what file or location that contains this stuff mentioned above? (so that I can look at the bigger context):
        },{\
            .driver = "VGA",\
            .property = "vgamem_mb",\
            .value = stringify(8),\
        },{\
            .driver = "vmware-svga",\
            .property = "vgamem_mb",\
            .value = stringify(8)

Hi Doug,

> I disagree about bumping the memory size as a fix:

In the release notes I only mentioned changing the machine type,
however bumping the memory size does work in the qemu command line.
It's just that ...

> For many months (13.10 days) I have always been bumping the memory for
> the video, as I calculated that it should be more. Typically, I have
> this in the .xml file:
>

> <model type='vmvga' vram='16384' heads='1'/>

Yeah, see http://www.redhat.com/archives/libvir-list/2014-March/msg01118.html
for why that didn't work. What you have ought to work, ideally,
but it doesn't.

> And I even ran this just now:
>
> <model type='vmvga' vram='32768' heads='1'/>
>
> Question:
>
> what file or location that contains this stuff mentioned above? (so that I can look at the bigger context):
> },{\
> .driver = "VGA",\
> .property = "vgamem_mb",\
> .value = stringify(8),\
> },{\
> .driver = "vmware-svga",\
> .property = "vgamem_mb",\
> .value = stringify(8)

hw/i386/pc_piix.c in the qemu source

Serge,

Thanks for the information and the link to even more useful information. So, specifying vram size doesn't work, that is both good to know and explains some things.