[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] Issue with Win8 guest VGA Passthrough

Hello everyone, 

I'd posted this over at the new user forum on xenproject, and was directed here. Hopefully I'm not doing something stupid by copying and pasting my post from there, but here goes:

I have a core i7-4770 on an ASRock Z87 Extreme 4 motherboard. I have a PCI-based USB hub attached to deal with the fact that all the USB ports on the motherboard are on the same controller for passthrough purposes. I am using Debian Jessie with Xen 4.3 and a kernel based on 3.12.9. The card I'm trying to passthrough is an NVIDIA GTX 285 (I've found folks who say it worked fine for them, including on the boards here).

I created a kernel included the flags suggested by the xen wiki, switched my toolstack over to xl (was on xm, and I'm unsure why), and followed the wiki's guides for setting up xen and VGA passthrough. 

I created a Windows 8 (HVM) guest that worked fine, but slowly, before beginning the VGA passthrough guide. Changed my windows.cfg file to the following: 

bootloader = "/usr/bin/pygrub"
memory = 8192
name = "windows8"
vif = ['bridge=xenbr0']
disk = ['phy:/dev/vg0/windows,hda,w','file:/home/kyle/Desktop/Windows.iso,hdc:c$
device_model_version  = "qemu-xen-traditional"
device_model_override = "/usr/bin/qemu-x86_64"
acpi = 1

When the config worked, pci_permissive was commented out, as was the pci tag. The device override was set to qemu rather than qemu-x86_64, and the model version was qemu-xen rather than traditional. I've tried flipping things just to see if I could make it work to no avail. 

The error I get upon running the config is:

libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: domain 2 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1075:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1306:libxl__destroy_device_model: Device Model already exited

When I checked the log under /var/log/xen, I originally had -gfx_passthru: invalid option. After playing with the config file, I now have a hot mess: 

usage: qemu-x86_64 [options] program [arguments...]
Linux CPU emulator (compiled for x86_64 emulation)

Options and associated environment variables:

Argument      Env-variable      Description
-h                              print this help
-g port       QEMU_GDB          wait gdb connection to 'port'
-L path       QEMU_LD_PREFIX    set the elf interpreter prefix to 'path'
-s size       QEMU_STACK_SIZE   set the stack size to 'size' bytes
-cpu model    QEMU_CPU          select CPU (-cpu help for list)
-E var=value  QEMU_SET_ENV      sets targets environment variable (see below)
-U var        QEMU_UNSET_ENV    unsets targets environment variable (see below)
-0 argv0      QEMU_ARGV0        forces target process argv[0] to be 'argv0'
-r uname      QEMU_UNAME        set qemu uname release string to 'uname'
-B address    QEMU_GUEST_BASE   set guest_base address to 'address'
-R size       QEMU_RESERVED_VA  reserve 'size' bytes for guest virtual address $
-d item[,...] QEMU_LOG          enable logging of specified items (use '-d help$
-D logfile    QEMU_LOG_FILENAME write logs to 'logfile' (default stderr)
-p pagesize   QEMU_PAGESIZE     set the host page size to 'pagesize'
-singlestep   QEMU_SINGLESTEP   run in singlestep mode
-strace       QEMU_STRACE       log system calls
-version      QEMU_VERSION      display version information and exit

QEMU_LD_PREFIX  = /etc/qemu-binfmt/x86_64
QEMU_STACK_SIZE = 8388608 byte

You can use -E and -U options or the QEMU_SET_ENV and
QEMU_UNSET_ENV environment variables to set and unset
environment variables for the target process.
It is possible to provide several variables by separating them
by commas in getsubopt(3) style. Additionally it is possible to
provide the -E and -U options multiple times.
The following lines are equivalent:
    -E var1=val2 -E var2=val2 -U LD_PRELOAD -U LD_DEBUG
    -E var1=val2,var2=val2 -U LD_PRELOAD,LD_DEBUG
Note that if you provide several changes to a single variable
the last change will stay in effect.

Does anyone have some insight on this? I feel like I'm very close to getting my passthrough working, and that would be really awesome. 

Additionally, I tried to go graphically after being unsuccessful with my windows.cfg file, and tried the virtual machine manager. When I start it, however, I get this: 

Unable to connect to libvirt.

Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

Verify that:
 - A Xen host kernel was booted
 - The Xen service has been started

and under details : 

Unable to connect to libvirt.

Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

Verify that:
 - A Xen host kernel was booted
 - The Xen service has been started

Libvirt URI is: xen:///

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1027, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1009, in _try_open
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

The virtual machine manager does not, thereby, connect to localhost

I guess I should also mention that Windows 8 didn't always shut down properly, but it wasn't reporting errors and things like the GPLPV drivers seemed to install correctly. 

Thanks for any insight,
Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.