Linux Mint Forums

by **powerhouse** on Fri Sep 07, 2012 7:41 pm

Xen VGA passthrough how-to for Linux Mint 13 / 14 - release 1.0.4
30.4.2013 - warning re xen hypervisor release 4.1.3-3ubuntu1.5 upgrade
29.4.2013 - added note on alternative method to load xen-pciback using the initramfs
18.4.2013 - added enable VT-d / IOMMU in BIOS step - renumbered steps
16.4.2013 - removed summary of steps, added info on AMD graphics cards
15.4.2013 - changed to consecutive numbering; commented out pae=1 option; added pci power management option and explanation; added additional references
7.04.2013 - Note on keyboard/mouse control using Xen with link to post, blacklisting radeon or nouveau driver
2.04.2013 - Appeal to open "virtualization" forum on LM; AMD CPUs; Intel VT-d; Nvidia modding
17.02.2013 - link to latest GPLPV drivers and new instructions on using them; comment out "auto eth0" entry in /etc/network/interfaces
01.02.2013 - fixed ark.intel.com link to list VT-d enabled CPUs and added a link re VT-d M/B, added glossary
21.01.2013 - additional notes / corrections for Linux Mint 14 Mate
18.01.2013 - additional references and links, cleaning up the text
13.01.2013 - enabled STP in network config; added localtime=1 to domU config file
10.01.2013 - added note on LM 14, added usb-devices command for USB PCI ID identification.
10.12.2012 - note about bridging and the network-manager package.
12.11.2012 - minor changes/additions in part 4, particularly the Windows installation part.
23.10.2012 - changed the title to make it more clear what it's all about: not having to dual-boot anymore and yet getting full graphics performance using a Windows VM (actually, performance is approximately the same or sometimes even better than installing Windows onto bare-metal). At the same time Linux is running and you can switch to it with the press of a button.
18.09.2012 - additions in Part 2 and Part 3 (step 10)

Warning: I updated my Xen hypervisor to the latest version 4.1.3-3ubuntu1.5 [quantal-upgrade] and it gave me an error when trying to load the Windows guest. Don't upgrade to the latest hypervisor and accessory packages. I downgraded the packages and all is fine now. Here the packages that need to be downgraded:

Code: Select all: libvirt-bin libvirt0 libxen-4.1 libxenstore3.0 python-libvirt xen-docs-4.1 xen-hypervisor-4.1-amd64 xen-system-amd64 xen-utils-4.1 xen-utils-common xenstore-utils

Appeal: If you share my opinion that the Linux Mint forum would benefit from a dedicated "Virtualization" forum, please support the following suggestion by leaving your comment: http://forums.linuxmint.com/viewtopic.php?f=29&t=112951

Abstract: This how-to is about running Windows 7 (or other Windows versions) concurrently with Linux Mint on a Xen hypervisor, with FULL graphics acceleration for the Windows guest system.

There are special hardware requirements for this to work. Please make sure your hardware meets these requirements.

Running Windows as a guest in Linux is nothing new. But how about native graphics and near-native CPU performance? Here a little teaser - this is my Windows Experience Index when running Windows on top of Linux / Xen hypervisor, while Linux is fully functional at the same time:

This is with the GPLPV block device driver installed (for disk access) and full VGA graphics passthrough!

Introduction

I've been hoping for a long time to get rid of dual-booting Linux and Windows. But doing photo editing with all the bells and whistles requires Windows and a bunch of software and hardware tools to get it going. So I started to look into virtualization. I needed true graphics acceleration from within Windows, as well as direct access to some USB ports, something VirtualBox cannot provide as of this writing!

Reading reports from users who had installed Windows as a virtual machine (VM) on top of a Xen hypervisor, with full graphics acceleration under Windows, I decided to go for it. After months of planning, hardware purchases and replacements, and many hours installing Linux, Xen hypervisor, and finally Windows, I made it work !

The following is for people who want to run Linux and Windows at the same time - without the need for dual-boot - with both Linux and Windows having native or near native graphics acceleration and performance. With minor modifications these instructions can also be used to run two or more Linux virtual machines on one and the same PC, each having direct access to a graphics card or integrated graphics chip. Gamers rejoice!

Xen employs two related concepts that make it work: PCI passthrough and VGA passthrough.

Glossary
Here a few terms used in the how-to:
domU: This is a Virtual Machine or VM in Xen terminology. In our case it will be Windows.
dom0: This is a special Virtual Machine with administrative privileges. In our case this will be Linux Mint. All other VMs (or domUs in Xen talk) are started and controlled from the dom0.
PCI passthrough (or passthru): This is a technique which allows the dom0 to pass through a PCI device to the guest domU. The guest OS - in our case Windows - then uses its own hardware driver to access the device directly.
VGA passthrough: This is a specialized form of PCI passthrough for graphics cards / GPU. These devices are more complex and so is the interaction with them. Fortunately, using the right hardware together with Xen should take care of that. There are two forms of VGA passthrough:
VGA passthrough to GPU as primary adapter: The guest system (domU) boots and uses the passed through graphics card as its primary or only graphics adapter.
VGA passthrough to GPU as secondary adapter: The guest system first boots using the Qemu-dm virtual Cirrus adapter as the primary graphics adapter (this is where you see the BIOS screen and the Windows boot logo). After installation of the graphics driver under Windows and subsequent reboot of the domU, the system will switch to the secondary graphics adapter at some stage of it's boot process. This is the technique described here in this How-To.

Preparation and hardware selection

First of all you need to check the hardware. This will ONLY work with specific hardware features, if they are not supported, forget this tutorial !!!

Here a short checklist:

- CPU with VT-d (IOMMU) support (Intel terminology) - see http://ark.intel.com/search/advanced/?s=t&VTD=true for supported Intel CPUs*. When using AMD CPUs, the following chipsets support IOMMU: SR5690/SR5670 server chipsets, AMD 890FX, 990FX, 990X and 970 desktop chipsets. See http://wiki.xen.org/wiki/VTdHowTo for more information.
- Motherboard and BIOS version with option to enable VT-d (beware, some vendors have buggy BIOS versions) - see http://wiki.xen.org/wiki/VTd_HowTo and http://www.overclock.net/t/1338063/vt-d-compatible-motherboards for more!
- Graphics card that supports Xen VGA passthrough - see http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters and http://www.overclock.net/t/1307834/xen-vga-passthrough-compatible-graphics-adapters for more! In most cases, AMD will be a better choice than Nvidia, unless you like patching and compiling kernel and Xen.
- Enough RAM - the more the better, though 8GB should do in most cases
- Linux Mint 13 or later (or Ubuntu 12.04 or later), 64bit version
- Windows 7 (I haven't tested any other Windows version, though Windows XP and even Windows 8 might be a little easier)
- Enough disk space and good cooling if you plan to really make use of it :wink:

* Intel corrected the VTD=true search and the previously unlisted i7 3930K and 3960X are now listed. Both CPUs support VT-d in their newer "C2 stepping" release (spec code = SR0KY), see below.

Here is my hardware list for reference (EDIT: see note re motherboard):

- i7 3930K CPU with C2 stepping! (If you buy new, it should be with C2 stepping, but check!)
- Asus Sabertooth X79 motherboard with BIOS version 1203 - Important note: Don't use the newer BIOS releases 2002 or 2104 - they have broken VT-d support, according to here: http://vip.asus.com/forum/view.aspx?id= ... uage=en-us
- AMD 6450 graphics card as primary graphics adapter for Linux dom0
- Nvidia Quadro 2000 graphics card with "Multi-OS" feature (Nvidia terminology) as secondary graphics adapter for Windows domU - see below for more on that!
- USB KVM switch to connect keyboard/mouse to two different USB hosts and easily switch between them
- A graphics display with two DVI ports (or DVI and HDMI, though I haven't tested HDMI) and the ability to switch between the ports (screen button)
- Enough RAM (I have 32GB) and disk space (I use 1 120GB SSD and several 2TB hard drives, less will do)

EDIT: The Asus Sabertooth X79 has left a mixed impression on me. The Marvell SATA controller doesn't work under Xen dom0. The latest BIOS versions reportedly have broken VT-d support. Last not least, Asus does not support Linux on this board. I therefore can't recommend the product.

Most Nvidia graphics cards are tricky to pass through to the guest OS (Windows domU), only the "Multi-OS" versions are designed to work out of the box. You could try to patch and rebuild the Linux kernel and Xen, and there are some instructions on how to do it, but this is way more demanding than getting my above hardware to work. I have failed with a Nvidia Quadro 600 card, though it may be possible. Most AMD (ATI) graphics cards are easier to get working with VGA passthrough. See http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters and http://wiki.xen.org/wiki/Xen_VGA_Passthrough. If in doubt, get one of the tested AMD graphics adapters that are listed under the above mentioned links!

For the very adventurous, there is a way to modify Nvidia graphics adapters to register as professional Nvidia cards and thus enable VGA passthrough. See here: http://www.eevblog.com/forum/projects/hacking-nvidia-cards-into-their-professional-counterparts/ and http://www.eevblog.com/forum/projects/hacking-nvidia-cards-into-their-professional-counterparts/msg207550/#msg207550. Warning: If you do modify your hardware, you will loose all manufacturer warranty and take a big chance of turning your expensive VGA card into a brick! I won't take any responsibility for that. You have been warned.

If you are planning to build a new PC, this is the time to check for compatible hardware!

To be continued...

by **powerhouse** on Sat Sep 15, 2012 3:23 pm

Part 2

Prereqisites and Installation of Xen Hypervisor

1. Install Linux Mint 13/14 Mate 64 bit with LVM / (root) and /home partitions

See my how-to here: http://forums.linuxmint.com/viewtopic.php?f=42&t=108442.

Note: Linux Mint 15 has a LVM option in the installer, which makes above LVM how-to obsolete.

2. Enable VT-d / IOMMU in BIOS

Reboot your PC and enter your BIOS setup. Look for an IOMMU or VT-d option (check the manual of your motherboard) and enable it. VT-d is an essential prerequisite to make this work!

Note: Most motherboard BIOSes have VT-d disabled by default.

3. Install Xen hypervisor and utilities

After reboot into the installed Linux Mint system, open Synaptic and install the following packages:

Linux Mint 13:

Linux Mint 14:

xen-system-amd64

4. Add boot options to grub

Edit the /etc/default/grub file as root and add or change the following:

Code: Select all: GRUB_CMDLINE_XEN="iommu=1 dom0_mem=2048M"

The above Xen command line tells the hypervisor to use IOMMU (VT-d must be ENABLED in your BIOS) and gives the dom0 (Linux Mint) 2048 MB of RAM.

While at it, comment out the GRUB_HIDDEN_TIMEOUT=0 and GRUB_HIDDEN_TIMEOUT_QUIET=true so that it looks like this:

Code: Select all: GRUB_DEFAULT="Xen 4.1-amd64" # GRUB_HIDDEN_TIMEOUT=0 # GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset" GRUB_CMDLINE_LINUX="" GRUB_CMDLINE_XEN="iommu=1 dom0_mem=2048M"

Note: I changed my GRUB_DEFAULT to load Xen automatically at boot. With the GRUB_HIDDEN... options commented out you will have a grub menu to select your regular Linux kernel if things go bad, or to manually select either Xen or regular boot.

Open a terminal window and run

Code: Select all: sudo update-grub

5. Reboot into the Xen hypervisor

Select the appropriate grub menu option.

by **powerhouse** on Sat Sep 15, 2012 7:54 pm

Part 3

Now that you (I hope) successfully booted into the Xen hypervisor / dom0, it's time for some configurations.

6. Adjust the network settings to use a bridge

The following commands require root permission so we make it stick. Open a terminal window and enter:

Code: Select all: sudo -i

Code: Select all: /etc/init.d/network-manager stop

Linux Mint 14:

Code: Select all: stop network-manager

Stops the network manager so we can configure the bridge and enable it.

If you want to use DHCP to automatically assign an IP address etc. to your network card, replace the content of your /etc/network/interfaces file with this:

Code: Select all: auto lo iface lo inet loopback auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 # auto eth0

For a static IP address, use this configuration in /etc/network/interfaces:

Code: Select all: auto lo iface lo inet loopback auto xenbr0 iface xenbr0 inet static bridge_ports eth0 address 192.168.0.120 # the IP address of the Ethernet port broadcast 192.168.0.255 netmask 255.255.255.0 gateway 192.168.0.1 # the address of the router # bridge_stp off # disable Spanning Tree Protocol - optional bridge_waitport 0 # no delay before a port becomes available - optional, comment out if this gives you troubles bridge_fd 0 # no forwarding delay - optional # There are no IP configurations for eth0, it’s all defined under xenbr0: # auto eth0

Adopt the IP settings above to your requirements.

Enable networking:

Code: Select all: service networking restart

Check that your network connection is working - open Firefox and see if you have Internet access.

Note: The "network-manager" package that is installed by default can create problems with the bridge configuration. If you can't connect to the Internet, or if networking doesn't work, remove the package.

Optional: xend automatically creates a virbr0 NAT bridge. I didn't find any use for that and disabled it by deleting the "default.xml" link in etc/libvirt/qemu/networks/autostart. In case you wish to enable it again, just create the link with ln -s /etc/libvirt/qemu/networks/default.xml /etc/libvirt/qemu/networks/autostart/default.xml.

7. Create missing links

Linux Mint 13/14 requires some fixes for the xen tools to work properly.

For Linux Mint 13 enter the following commands in the terminal window (as root):

Code: Select all: ln -s /usr/lib /usr/lib64 ln -s /usr/lib/xen-default /usr/lib/xen ln -s /usr/share/qemu-linaro /usr/share/qemu

For Linux Mint 14 use these:

Code: Select all: ln -s /usr/lib /usr/lib64 ln -s /usr/lib/xen-4.1 /usr/lib/xen-default ln -s /usr/share/qemu-linaro/qemu/ /usr/share/qemu

Thanks to Nesousx.

8. Determine the PCI IDs of the devices you want to pass through to the domU (guest)

Enter the following command to list your graphics adapters' PCI IDs:

Code: Select all: lspci | grep VGA

You should get something like this:

I have two graphics adapters:

very carefully

Make a note of the PCI ID you want to pass through. Most likely your graphics card will have a second PCI ID for the onboard audio controller. This is typically 02:00.1 (for the card with PCI ID 02:00.0). You need to pass that through as well!

To check, enter the following and scroll through the output:

Code: Select all: lspci | grep 02:00.

You will see something like this:

If you don't get the second line, there is no onboard audio controller you need to pass through, so use only the 02:00.0 PCI ID.

Note: You may get different PCI IDs altogether, so use the ones appropriate to your system.

Next are the USB devices:

Code: Select all: lspci | grep USB

The output on my machine is this:

I have 5 host controllers, and each of mine has 2 or more ports (IIRC).

I decided to pass through the second Intel USB controller for mouse/keyboard, since it's a USB-2 host controller which may give less troubles than USB-3. I also have a USB KVM switch that allows me to switch between two USB ports on the PC - one cable is connected to the passed-through USB port, the other to a USB-2 port that hasn't been passed through (for Linux). Here is my setup:
00.1a.0 is passed through to the domU (Windows 7) guest and one cable of the KVM is connected to this port (see below on how to determine that).
00.1d.0 is used with dom0 (Linux) and the second cable of the KVM is connected to that port.

To find out where your keyboard and mouse is currently connected, open:

Menu -> Control Center -> System Information -> Input Devicesand scroll down to your mouse and keyboard entry - open them and note the PCI ID you find there.

My KVM has two ports to connect both keyboard and mouse to it. If you don't use a KVM switch, it's best to have both keyboard and mouse on the same controller, so you may need to replug them and check again.

Note: If you don't want to use two keyboards and mice, or a KVM switch, see the following post for how to use Xen for mouse/keyboard input: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013&start=80#p706770. Thanks gordon.cooke !

EDIT: The following command is VERY helpful in figuring out which PCI IDs are assigned to which USB ports:

Code: Select all: usb-devices

You will find the PCI-ID for Bus=xx Lev=00 under the "SerialNumber" entry. If a device (such as a USB stick) is plugged in, you get additional entries for Bus=xx Lev=01, Lev=02 etc. with the device listed.

9. Create pciback.conf file

Once you determined the PCI IDs for your graphics adapter and USB ports, create a config file named pciback.conf in /etc/xen with the following content:

Code: Select all: # This file contains the list of pci devices the pciback driver should bind # to at system startup. # Please provide the devices in long BDF notation. # Example: # 0000:08:00.0 # NO EMPTY LINES! # 0000:02:00.0 0000:02:00.1 0000:00:1a.0

Note: Replace the PCI IDs in this file with the ones you determined before! You must enter the long PCI ID notation, with a preceding 0000: for the domain! This configuration file is used by the pciback shell script below.

10. Install and activate pciback script

Save the following pciback script named pciback to /etc/init.d:

Code: Select all: #!/bin/sh # ### BEGIN INIT INFO # Provides: pciback # Required-Start: $local_fs # Required-Stop: $local_fs # Should-Start: # Should-Stop: # X-Start-Before: xend # X-Stop-After: # Default-Start: 2 3 4 5 # Default-Stop: ### END INIT INFO . /lib/lsb/init-functions scriptname=/etc/init.d/pciback configfile=/etc/xen/pciback.conf unbind() { # Unbind a PCI function from its driver as necessary [ ! -e /sys/bus/pci/devices/$1/driver/unbind ] || \ echo -n $1 > /sys/bus/pci/devices/$1/driver/unbind } bind() { # Add a new slot to the PCI Backend’s list echo -n $1 > /sys/bus/pci/drivers/pciback/new_slot # Now that the backend is watching for the slot, bind to it echo -n $1 > /sys/bus/pci/drivers/pciback/bind } case $1 in start) cat $configfile | while read line;do echo $line | grep ^# >/dev/null 2>&1 && continue unbind $line bind $line done ;; stop|status|restart|force-reload) # As we don’t know which driver was bound before, there is not much we can do here ;; *) echo “Usage: $scriptname start” >&2 exit 3 ;; esac

Make the pciback shell script executable

Code: Select all: chmod +x /etc/init.d/pciback

and run

Code: Select all: update-rc.d pciback defaults 21 19

The number 21 means that it will run AFTER xend is started (xend has 20 in the init.d), and stopped before xend will stop.

Note: For some reason, the command insserv didn't work for me. You may try it instead of the above command. insserv doesn't need arguments since it should read the header and determine when to run the script.

11. Make xen-pciback module load at boot

To load the xen-pciback module during boot, edit the /etc/modules file and add on a separate line:

Code: Select all: xen-pciback passthrough=1

Note: The option "passthrough=1" causes the xen-pciback module to use PCI ID passthrough (pass) instead of vpci which would assign different PCI IDs when passing the device through to the guest.

For reference, my /etc/modules file looks like this:

12. Create the Windows 7 guest configuration file

Copy/paste the following configuration file into /etc/xen and name it win7.cfg (or whatever name you choose):

Code: Select all: kernel = “/usr/lib/xen-default/boot/hvmloader” builder=’hvm’ # Memory reserved for Windows domU, in my case 24GB (adjust to your # needs: memory = 24576 # Name of the domU that will be created/used: name = “win7″ vcpus=10 # I gave my Win 7 10 virtual CPUs, out of 12 ( using a 6-core CPU) #pae=1 #only for 32 bit guests - don't use for 64 bit! acpi=1 apic=1 # Here my virtual network interfaces – see /etc/network/interfaces below: vif = [ 'mac=00:16:3e:68:e1:01,bridge=xenbr0' ] # vif = [ 'vifname=win7,type=ioemu,mac=00:16:3e:68:e1:01,bridge=xenbr0' ] # I assigned a static MAC address, else it will be changed each time Windows # boots. The address should start with 00:16:3e., the rest is up to you. # # Specifying the disks and Windows ISO for installation, adjust to your # needs: disk = [ 'phy:/dev/mapper/guest-win7,hda,w' , 'file:/media/install/Win7.iso,hdc:cdrom,r' ] # More disks can be added later using this same method. The path to the # device or a file can be added. After the first comma is how the device will # appear. “hda” is the first, “hdb” the second etc. “hda” will appear as IDE, # sda will appear as SCSI or SATA. After the second comma “r” means read # only and “w” is for write. device_model = ‘/usr/lib/xen-default/bin/qemu-dm’ boot=”dc” # The above should be changed once Windows is installed: boot=”c” to only # show the Windows file system, else it may try to boot from the ISO image. sdl=0 vnc=1 vncpasswd=” stdvga=0 # nographic=1 #!!! only uncomment this if you are using win8 or are trying # to get a Nvidia card to work. In my case – Nvidia Quadro 2000 - this was not # needed. serial=’pty’ tsc_mode=0 viridian=1 #soundhw=’all’ # I commented it out since it’s not relevant to me now. usb=1 # This allows sharing the USB mouse/keyboard. usbdevice=’tablet’ # is recommended; in conjunction with USB=1, else comment out gfx_passthru=0 # Leaving this as 0 is how it works for me with my Quadro 2000 card. # You can change this later for iGPUs or nVdia if needed. # Try it with 0 first. pci=[ '02:00.0', '02:00.1' , '00:1a.0' ] # These values are the ones you found out using the lspci command earlier. # I also passed through an entire USB controller for native support. # You can use usb-devices to find out to which hub/host the keyboard/mouse # is connected. I use a USB KVM switch to connect my keyboard/mouse to two # USB ports residing on different hubs! One – 00:1a.0 – is then passed through # to the domU. # The following lets Windows take the local time from the dom0: localtime=1 #To turn on pci power management globally, use (see remarks under pci=... below): pci_power_mgmt=1

Important: You must edit the file and adjust it to your requirements !!! It most likely won't work for your hardware/setup.

I have commented the configuration file to explain the different configuration options. Here some further explanations about the options you need to change/adopt for your hardware:

memory = # Enter the amount of memory (RAM) in Mbyte your guest will get. For example, if you have 8GB RAM, you could give the guest (Windows) a value of 4096 which is 4GB, leaving the rest for dom0 (Linux) and other Xen guests.

vcpus= # Enter the number of virtual CPUs your guest will get. I have a 6-core CPU with 12 threads and I decided to give Windows 10 of the 12 available threads (virtual CPUs). As long as I run only Linux, it will get all CPUs / VCPUs. Once I start Windows I give it 10 VCPUs, leaving 2 VCPUs for Linux. It's best to leave some CPU resources to the Linux dom0 since Linux still needs to handle I/O, networking, etc. In my case, having a 3930K CPU, 2 VCPUs for dom0 should be enough to handle that.

vif = [ 'vifname=win7,type=ioemu,mac=00:16:3e:68:e1:01,bridge=xenbr0' ] # This defines the networking part for the guest system. vifname=win7 gives a name to the interface (this feature is buggy, so I removed it). iommu means it uses the VT-d functions of the memory controller. mac=... assigns a static MAC address to the bridge so Windows won't complain about "illegal copy" etc. when the MAC changes for each boot. 00:16:3e:68: is reserved for Xen and you should use it too! Change the last two e1:01 to your liking. Just watch out that you don't have the same exact MAC addresses in your LAN or when running two guests simultaneously.

disk = [ 'phy:/dev/mapper/guest-win7,hda,w' , 'file:/media/install/Win7.iso,hdc:cdrom,r' ] # This is the disk configuration for the Windows guest, i.e. as Windows will see it. See below for creating the Windows partition on LVM. The 'file:/media...' option points to the Windows ISO image on your drive, reading it as CDROM.

boot=”dc” # is the boot order for Windows. This entry will first boot from d: then c:. Once Windows is installed you need to edit this file and remove the "d" so it reads: boot="c".

pci=[ '02:00.0', '02:00.1' , '00:1a.0' ] # These are the same PCI IDs specified in the /etc/xen/pciback.conf file we created earlier. If you have problems with the USB ports and power management, and the global "pci_power_mgmt=1" option doesn't work, try this:
pci=[ '02:00.0', '02:00.1' , '00:1a.0,power_mgmt=1' ]
See http://www.overclock.net/t/1205216/guide-create-a-gaming-virtual-machine/550#post_19572876.

The rest should be left as is for now. If, and only if your Windows doesn't boot or you don't get a screen or mouse/keyboard don't work, you may need to change the following, depending on the problem:

# nographic=1 # Uncomment if the Nvidia card doesn't work, or perhaps for Windows 8.

gfx_passthru=0 # Set to 1 may help with some Nvidia cards. Search the Internet for AMD cards and recommendations, though IIRC AMD cards should work with 0.

usb=1
usbdevice=’tablet’ # You may need to comment out one of it to get the keyboard/mouse working during the installation. In my case these settings work just fine.

Documentation on the above guest configuration options can be found here: http://xen.org/files/Support/XenConfigurationDetails.pdf

13. Create a logical volume to install Windows

To make this easier, I assume you are installing on a separate disk named /dev/sdb. Of course you can also use a partition.

Note: The disk (here sdb) MUST be flagged for LVM. You can use gparted for it. Don't format it!

Code: Select all: pvcreate /dev/sdb

Let's check:

Code: Select all: pvdisplay

This shows you the physical LVM volumes (PV). Your newly created PV should show up as empty.

Now we create a logical volume (LV) named "win7", size 100GB for Windows in volume group (VG) "guest":

Code: Select all: vgcreate guest /dev/sdb # assign the PV we created to volume group "guest" lvcreate -L 100G -n win7 guest # create the logical volume named "win7", size 100G in VG "guest"

Let's check the results:

Code: Select all: lvdisplay

See if logical volume "win7" appears.

14. Copy the Windows installation DVD to disk

Make an installation folder for Windows:

Code: Select all: mkdir /media/install

Insert your Windows DVD into your DVD drive and enter:

Code: Select all: dd if=/dev/cdrom of=/media/install/Win7.iso

Note: You will need a Windows retail license to use Windows inside a virtual machine.

15. Reboot the computer into Xen

Important note: After reboot with the PCI devices being detached I had problems with the nouveau driver (Nvidia) for my secondary graphics card (the one to passthrough). My PC got stuck right after login. Blacklisting the nouveau driver worked. See http://community.linuxmint.com/tutorial/view/176 for how to blacklist the nouveau driver.
Comment: In my case the nouveau driver wasn't required, as my Nvidia card is only used by Windows.
EDIT: Similar problems are reported with AMD graphics cards, in which case the solution is to blacklist the radeon driver using the radeon.blacklist=1 grub entry like this:

Code: Select all: GRUB_CMDLINE_LINUX_DEFAULT="radeon.blacklist=1 quiet splash nomodeset"

However, if you choose to use 2 AMD or 2 Nvidia graphics cards, you would need the respective driver for your dom0. In that case the PCI devices should be detached before the driver starts. You may need to run update-rc.d pciback defaults 21 19 with different numbers, or find another way to run this script before the graphics drivers are loaded.

See also earlboy's post here: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013&start=60#p705871.

... to be continued

by **powerhouse** on Sun Sep 16, 2012 8:37 am

Part 4

We are almost there.

16. Install vncviewer and adjust xend config file

We need a VNC viewer for the installation of Windows. In the terminal window:

Code: Select all: sudo apt-get install vncviewer

16a. Alternative to 16.:

You can use virt-manager to install Windows. It's a GUI and has an integrated VNC viewer. In the terminal window:

Code: Select all: sudo apt-get install virt-manager

To use virt-manager, we need to modify the /etc/xen/xend-config.sxp file (as root) as follows. I copied only the relevant entries, with a short explanation below:

Code: Select all: # -*- sh -*- # # Xend configuration file. # (xend-unix-server yes) # If you are using only one bridge, the vif-bridge script will discover that, # so there is no need to specify it explicitly. The default is to use # the bridge which is listed first in the output from brctl. # #(vif-script vif-bridge) # This is a minimum both for auto-ballooning (as enabled by # enable-dom0-ballooning below) and for xm mem-set when applied to # dom0. (dom0-min-mem 196) # Whether to enable auto-ballooning of dom0 to allow domUs to be created. # If enable-dom0-ballooning = no, dom0 will never balloon out. (enable-dom0-ballooning no) # 32-bit paravirtual domains can only consume physical # memory below 168GB. On systems with memory beyond that address, # they’ll be confined to memory below 128GB. # Using total_available_memory (in GB) to specify the amount of memory # reserved in the memory pool exclusively for 32-bit paravirtual domains. # Additionally you should use dom0_mem = as a parameter in # xen kernel to reserve the memory for 32-bit paravirtual domains, default # is “0″ (0GB). (total_available_memory 0) # In SMP system, dom0 will use dom0-cpus # of CPUS # If dom0-cpus = 0, dom0 will take all cpus available (dom0-cpus 0) # Whether to enable core-dumps when domains crash. #(enable-dump no) # The tool used for initiating virtual TPM migration #(external-migration-tool ”) # The interface for VNC servers to listen on. Defaults # to 127.0.0.1 To restore old ‘listen everywhere’ behaviour # set this to 0.0.0.0 #(vnc-listen ’127.0.0.1′) # The default password for VNC console on HVM domain. # Empty string is no authentication. (vncpasswd "")

(xend-unix-server yes) # For virt-manager to work we need to enable the xend-unix-server yes - uncomment the line.

The other configuration lines below are optional and don't need to be changed for installing/running the Windows domU:

#(vif-script vif-bridge) # It should not be necessary to uncomment this line, if you have only one bridge configured.

(dom0-min-mem 196) # Specifies the minimum amount of RAM for dom0. This is used in conjunction with enable-dom0-ballooning below. We already set a minimum memory in the /etc/default/grub file. You may increase it just for safety, but not more than the amount specified under grub.

#(enable-dom0-ballooning yes) # This option, when enabled, allows domU guests to take memory from dom0, when there is not enough unused RAM available. The Xen documentation recommends NOT to use this, as Linux configures its memory during the boot process and does not like a changing memory size, or it may be stuck with large memory mappings when there is in fact much less memory available for dom0. For further information, read here: http://wiki.xen.org/wiki/XenBestPractices.

(dom0-cpus 0) # I give my dom0 all CPUs available when not running the Windows domU. Some Xen.org suggestions are pinning the CPUs to dom0 and perhaps domU. In my system, when Windows is not running, I have all CPUs for Linux. It works quite nicely and I can't complain about Linux performance. Again, check the Best Practices wiki linked above.

(vncpasswd "") # Disables password authentication for VNC.

As mentioned before, the "xend-unix-server yes" is required by virt-manager to work. The other settings define how xend will operate and are also relevant for VNC console access.

17. Verify that pciback works

First check that everything is setup correctly:

Code: Select all: sudo xm pci-list-assignable-devices

should give the list of detached devices that can be assigned (bound) to the Windows guest. My list looks like that:

All devices I configured are ready for passthrough.

Note: If some PCI IDs are missing - namely the PCI IDs for the graphics card - check steps 9 to 11 to make sure you didn't miss anything (also verify the IDs). If all fails, try the method in this post: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013&start=120#p711782. The method described in this post integrates the xen-pciback module into the initramfs so it can be loaded via a grub boot option, before the graphics driver grabs the card.

Code: Select all: sudo xm list

lists the current domains. At the moment only domain0 should be listed.

Note: For debugging purposes this command can come handy:

Code: Select all: sudo xm dmesg

18. Create the Windows domU using its configuration file

Code: Select all: sudo xm create /etc/xen/win7.cfg

and connect to it via VNC:

Code: Select all: sudo vncviewer localhost:0

Note: It may work without sudo.

18a. Alternatively, use virt-manager (see 16a above):

Code: Select all: sudo xm new /etc/xen/win7.cfg # this defines a new domU for xend, using the specified configuration file sudo virt-manager

In virt-manager, select the domU and click "Open". You can check the settings by pressing the "Details" button. If everything looks good, go back to the console display by clicking the "Console" button. Then click ">" (Run).

19. Install Windows guest

Unless there is some configuration error (check your path to the /media/install/Win7.iso file or whatever you name it), the Windows installer should boot now and you should see the screen output in the console (enlarge it if necessary).

Install Windows as you normally would. At some point Windows will reboot the guest domU (not Linux).

20. Access Windows after automatic reboot

After Windows has rebooted, it should come back to the virt-manager or VNC console. If not, close virt-manager or VNCviewer and run again.

If Windows doesn't start and you get a qemu shell screen, it might have passed through your mouse/keyboard and/or your display adapter. Alternatively, you might need to change your /etc/xen/win7.cfg file and specify boot="c".Before you edit the win7.cfg file, shutdown the domU (from within virt-manager or via xm shutdown win7). Edit your win7.cfg file and run xm delete win7, followed by

a) sudo xm new /etc/xen/win7.cfg and virt-manager

or

b) sudo xm create /etc/xen/win7.cfg, and connect via VNC

21. Install Windows graphics driver

After the second Windows 7 VM reboot, Windows will tell that "Setup is preparing your computer for first use...". Once booted, still in the VNC console screen, you'll need to install and enable the graphics adapter driver for your display card. Inside Windows under Device Manager, check for graphics adapters. It should list two graphics adapters, one is for the emulated Cirrus VGA adapter that you are currently using, the other one is the real graphics adapter (in my case it had a yellow triangle as the driver was missing).

Before going any further, check the following hardware requirements:

a) A separate screen connected to the secondary graphics adapter to be used by Windows; or a second cable connection to your current screen; or a KVM switch for keyboard, mouse, and optionally display. I use my KVM switch only for keyboard/mouse and connected my secondary graphics adapter via DVI cable to the second DVI port on my screen. Some screens will have VGA ports, or HDMI. Both should work, though I don't care much about VGA because of it's low quality compared to DVI or HDMI. The screen should have a button to select the input source, if using only one screen.
b) If you want to pass through your keyboard/mouse, the best choice is a USB KVM switch. Else you need to unplug and replug your keyboard/mouse to the appropriate USB ports.
c) You could also use your keyboard and mouse without passing the PCI device through (using the USB=1 and/or tablet=1 settings in the win7.cfg file). Frankly I have no experience with this.
Or you could use a second mouse/keyboard just for Windows when using PCI passthrough on the USB port.

Now install the driver for your graphics adapter. In my case, I went to the Nvidia support website and ran the Java script to determine the correct driver, downloaded and installed it. The more common option would be to let Windows find the suitable display driver.

Once the installation has finished:

* the screen should reset and switch to the graphics adapter. If at that point you get a black screen, switch your screen to the other display port. If you see the Windows screen - open a bottle of Champagne - you've done it.
* alternatively Windows may ask you to reboot. Do so and watch the boot process in the VNC screen. After loading the graphics driver, and before the login screen, Windows should switch the output to your installed graphics adapter and you should be greeted with a Windows screen on your display.

If you get a black screen when rebooting Windows, or at any point during installation, switch your display to the second input. Do you see a Windows screen - if yes, it's a reason to celebrate.

22. What if VGA passthrough doesn't work?

If you can't get your VGA adapter to pass through to Windows, there are some options you may want to check:

a) First make absolutely sure your graphics adapter is supported !!! See my lengthy introduction to hardware requirements. Unless you have a Nvidia "multi-OS" graphics adapter, AMD will be a better choice. Have a look at the following threads/blogs for more information on VGA passthrough and adapters:

http://www.overclock.net/t/1307834/xen-vga-passthrough-compatible-graphics-adapters

http://gro.solexiv.de/2012/08/pci-passthrough-howto/

http://www.overclock.net/t/1205216/guide-create-a-gaming-virtual-machine

http://wiki.xen.org/wiki/Xen_VGA_Passthrough

http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters
This page seems a bit outdated, but probably the safest reference when purchasing a graphics card. Pay attention to the Xen hypervisor release - Linux Mint is currently (15.04.2013) using version 4.1.3. However, Xen already released the 4.2 hypervisor, which is supposed to bring better support for graphics adapters, including some unto now unsupported graphics cards (see wiki page for details).
Note: Xen 4.2 uses the xl toolstack which is different from the xm toolstack used in this how-to!!! There are some reports about VGA passthrough related issues with xl, so for some it may work, for others not.

http://www.phoronix.com/scan.php?page=news_item&px=MTA3NjA - this is the complicated way to get Xen VGA passthrough with Nvidia cards (see link inside the text). This procedure should work with some Nvidia cards that are NOT "multi-OS".

http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through - this is currently THE resource for instructions and patches when you want or need to compile the Xen hypervisor. This is specifically for Nvidia cards that don't have native support for VGA passthrough.

23. Change Windows boot order in guest config file

After Windows is installed, edit the /etc/xen/win7.cfg file and change the "boot=dc" option to boot="c". This is equivalent to ejecting the installation disk from the DVD drive. If the installation ISO is still required, but you want/need to change the boot order, specify boot="cd".

24. Booting the Windows guest

After everything is installed and VGA / PCI passthrough is working properly, you can use the following command to start your Windows domU:

Code: Select all: sudo xm create /etc/xen/win7.cfg

25. Install GPLPV drivers under Windows

Inside Windows, download and install the latest GPLPV drivers from here: http://www.meadowcourt.org/downloads/*.

As of this writing, the latest version is 0.11.0.372.

For my Windows 7 64-bit version I downloaded the gplpv_Vista2008x64_0.11.0.372.msi driver. Double-click on it to install under Windows. If the installer requests testsigning to be enabled, quit the installer, open a Windows admin shell and enter

Code: Select all: bcdedit.exe /set TESTSIGNING ON

Then reboot Windows and install the GPLPV drivers.

Important:When using the GPLPV network driver, you need to modify the win7.cfg and remove the "type=ioemu" option from the vif=... line.

* Note: The Univention website (http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers) that I had listed here before does NOT have these latest drivers!

END

Note: Once you successfully installed Windows on a Xen hypervisor, you may like the backup and restore scripts I've written. See http://forums.linuxmint.com/viewtopic.php?f=42&t=133089. Enjoy!

by **powerhouse** on Sun Sep 16, 2012 9:09 am

Edit: New startup script for Windows guest

Once you got everything running and you can boot and shutdown and reboot your Windows guest, with Windows using the graphics card, it's time for a startup script.

Here are the steps to create and launch a startup script without the need to give a root password:

1. If it doesn't exist, create a folder named .bin in your home directory. This is a hidden folder so it won't show up unless you select -> View -> Show hidden files in your file browser.

2. Create a file named "windows.sh" inside /home/myusername/.bin and paste the following shell script into that file:

Code: Select all: #!/bin/sh if xm list | grep -q win7; then zenity --warning --timeout=15 --text="Windows is already running." & exit 1 else xm create /etc/xen/win7.cfg &> /dev/null zenity --info --timeout=15 --text="Starting Windows, please wait." & exit 0 fi

Check that your Windows guest config file is /etc/xen/win7.cfg - if not, replace the win7.cfg name in the script above.

In a terminal window, enter the following:

Code: Select all: cd ~/.bin sudo chown root windows.sh sudo chmod 500 windows.sh

This changes the ownership of the file to root and allows only root to read and execute the script. This is an important security measure. Don't skip it, since the next steps will allow you to run this script without a password!

3. I'm using "zenity" in my script to display screen messages. Check if /usr/bin/zenity exists. If yes, continue with the step 4.
If not and you are using Mate instead of Gnome, the mate-dialogs package should be installed. To make it work under Mate, you can use either of the two methods below:
a) Enter in a terminal window:

Code: Select all: sudo ln -s matedialog /usr/bin/zenity

OR

b) Install the mate-dialogs-gnome package.

4. Warning:
This step is potentially dangerous. It changes the way sudo works. Entering incorrect values here can render the sudo command nonfunctional. Instead of creating the /etc/sudoers.d/permissions file, you may also use sudo visudo and make the changes / additions directly in the /etc/sudoers file, where visudo will check the syntax and prevent syntax errors. You have been warned.

Create a file named permissions in the /etc/sudoers.d folder (you need to be root to do that), and paste the following into the file:

Code: Select all: # Host alias specification Host_Alias HOST = hostname Host_Alias LAN = 192.168.1.0/255.255.255.0 Host_Alias HOME = HOST,LAN # User alias specification User_Alias WIN_USERS = myusername # Cmnd alias specification Cmnd_Alias WIN = /home/myusername/.bin/windows.sh # User privilege specification WIN_USERS HOME=(root) NOPASSWD:WIN

Important ! Replace the following in the /etc/sudoers.d/permissions file before saving it:

hostname: Replace with the hostname of your PC. If you don't know, open a terminal window and type:

Code: Select all: cat /etc/hostname

192.168.1.0: Replace with the IP of your network. To find out, use:

Code: Select all: ifconfig | grep -A 1 xenbr0

The second line reads something like "inet addr:192.168.1.145 Bcast:192.168.1.255 Mask:255.255.255.0". "192.168.1.145" in this example is the IP address of xenbr0 (your virtual network device), so the network IP would be 192.168.1.0. Adjust to what you find.

myusername: Replace with your username. If you forgot your user name, type whoami in a terminal window (isn't it amazing, your PC can tell you who you are).

After you replaced the hostname, IP, and myusername, save the file.

5. Open a terminal window and enter the following:

Code: Select all: cd /etc/sudoers.d/ sudo chmod 440 permissions

to change the file permissions to read-only for root and group.

6. To create a launcher, right-click on the desktop and fill in the prompt. For the Command: prompt, enter

Code: Select all: sudo /home/myusername/.bin/windows.sh

Replace "myusername" with your user name.

The above steps will allow you to run the windows.sh start script from your PC (host) as well as from your home network (LAN). Remove "LAN" from the "Host_Alias HOME = HOST,LAN" line of the permissions file if you do not want to grant password-free access from the LAN (as user myusername). The script also checks if Windows is already running (make sure the domain name win7 in the script matches the name specified in your /etc/xen/win7.cfg file).

by **GizmoChicken** on Sun Sep 16, 2012 11:22 pm

Thanks for the great tutorial! I imagine that I'll be referring to your post many times in the coming weeks.

by **powerhouse** on Mon Sep 17, 2012 2:34 am

GizmoChicken wrote:Thanks for the great tutorial! I imagine that I'll be referring to your post many times in the coming weeks.

Thanks GizmoChicken. Have you tried it, or are you going to try it?

I had to write some parts of it from memory, though I've done these steps several times when trying to get everything working. Still, there could be steps I've missed in this howto. That's why feedback is most welcome.

One thing I know I've left out was my nouveau driver issue after enabling passthrough. Linux Mint had installed the nouveau driver for my secondary (Nvidia) graphics card and used to boot with the driver. The result when detaching the Nvidia card was that the boot process would stop after user sign in and the PC froze. So I blacklisted the nouveau driver and all is fine now.

EDIT: I updated my how-to and mentioned this problem. Still need to find a generic way to avoid this graphics driver issue altogether (I suspect this problem to occur with any graphics driver bound to the passed-through device). Ideas are welcome.

by **GizmoChicken** on Mon Sep 17, 2012 4:40 am

powerhouse wrote:Have you tried it, or are you going to try it?

I haven't tried VGA passthrough yet. My processor (an AMD Phenom II X4) supports AMD-V, so I'm good with many aspects of Xen. But my motherboard (a Gigabyte GA-770TA-UD3) doesn't support IOMMU, so I'm not quite ready for VGA passthrough. When I get around to it, I'll upgrade my motherboard to a Gigabyte GA-990FXA-UD3, which reportedly supports IOMMU.

I currently have a few non-graphical servers running as virtual machines under XCP 1.6, which is an open source version of Citrix XenServer, but with a few more features. But XCP doesn't provide any sort of desktop environment, and so I've been experimenting with other options. For example, in one test configuration, I have my non-graphical servers running as virtual machines under Hyper-V that comes with Windows 8 Release Preview. In another test configuration, I have my non-graphical servers running as virtual machines under Xen with Ubuntu 12.10 Desktop as dom0. But ultimately, I'd like to run Ubuntu Server as a headless dom0 with a graphical desktop on a domU. And so that's why I have an interest in VGA passthrough.

by **powerhouse** on Mon Sep 17, 2012 11:41 am

GizmoChicken wrote:
powerhouse wrote:Have you tried it, or are you going to try it?

I haven't tried VGA passthrough yet. My processor (an AMD Phenom II X4) supports AMD-V, so I'm good with many aspects of Xen. But my motherboard (a Gigabyte GA-770TA-UD3) doesn't support IOMMU, so I'm not quite ready for VGA passthrough. When I get around to it, I'll upgrade my motherboard to a Gigabyte GA-990FXA-UD3, which reportedly supports IOMMU.

I currently have a few non-graphical servers running as virtual machines under XCP 1.5, which is an open source version of Citrix XenServer, but with a few more features. But XCP doesn't provide any sort of desktop environment, and so I've been experimenting with other options. For example, in one test configuration, I have my non-graphical servers running as virtual machines under Hyper-V that comes with Windows 8 Release Preview. In another test configuration, I have my non-graphical servers running as virtual machines under Xen with Ubuntu 12.10 Desktop as dom0. But ultimately, I'd like to run Ubuntu Server as a headless dom0 with a graphical desktop on a domU. And so that's why I have an interest in VGA passthrough.

IOMMU is a must for VGA passthrough on AMD boards. See http://wiki.xen.org/wiki/Xen_VGA_Passthrough and http://wiki.xen.org/wiki/VTdHowTo for more information on IOMMU support. It's probably best to check the motherboard manufacturers' websites for IOMMU support, as well as the release notes for their BIOS releases.

Given the right hardware, your goal should be achievable.

by **powerhouse** on Tue Sep 18, 2012 5:09 pm

Just to add some information for those interested.

My Nvidia Quadro 2000 graphics card works under Windows domU as if I was running bare metal. I have passed through a USB host and I connected my NEC version of the EyeOne spectrometer to one of the passed-through ports under Windows and ran the NEC Spectraview screen calibration program. It works perfect and I calibrated my screen and uploaded the calibration (LUT) to the screen. So, the VGA passthrough works just as if I would have Windows installed on bare metal.

Today I needed to backup my photos on the Windows domU drive/partition (it's a LVM striped formatted logical volume) to an external backup drive. No problem. I just passed through my USB3 ASMedia 09:00.0 PCI ID to Windows, installed the Seagate backup program on Windows, moved the folders to the appropriate drive letters of my current Windows domU on my Seagate external drive (they were different since I had used that drive before on a different PC), installed the Seagate utility and backed up my disk. What can I say, it's just like running Windows on bare metal, perhaps even better.

Using the same USB port I also imported a nearly full 16GB CF card using a Kingston USB2 card reader into Lightroom 4.1 (on Windows). It went smooth, but I will buy a USB3 card reader for the additional speed.

Yesterday I converted ~750 RAW files into jpeg with some curve adjustments, sharpening, resize and color space conversion etc. under Capture NX2. It ttok a while but was at least 5 times as fast as using my old Intel Core2duo machine. I noticed that CaptureNX2 doesn't make use of most of the resources (CPU and memory) that I have. CPU load under Windows maxed at 66% and usually stayed somewhere at 35%. Memory wasn't challenged at all, perhaps 10-15% (I gave 24GB to my Windows domU). Next time I will use Lightroom to see what that does.

OK, I'm not a games freak, but this performance is great!

EDIT: I got myself a USB3 card reader which significantly boosts file transfer speed between memory cards (CF) and the disks.

by **powerhouse** on Thu Sep 20, 2012 6:12 am

Xen 4.2 has just been released (September 17, 2012) !!!

Here some more about it: http://wiki.xen.org/wiki/Xen_4.2_Release_Notes

Hope to find it in the repository soon.

by **powerhouse** on Sun Sep 23, 2012 3:56 am

Another performance update:

I was always wondering how Xen shares CPU time between dom0 (Linux) and domU (guest - Windows in my case). I gave Windows 10 out of 12 threads in the win7.cfg vcpu option, leaving only 2 vcpus to Linux / hypervisor.

Instead of taking some benchmarking tools, I used real live applications. Here is what I ran concurrently:

1. handbrake to rip a DVD using "normal" mode under Linux dom0, and writing to a separate hard drive /dev/sdd1
2. Copy a 1.9GB file from /dev/sdd1 to a remote Samba media streamer connected via router / Fast Ethernet
3. Lightroom 4.2 to convert RAW photos to jpeg under Windows domU, both file types on the same LVM stripped hard drives (similar to RAID0 using /dev/sdb3 and /dev/sdc3)

I used

Code: Select all: sudo xm top

to monitor processor usage of both dom0 and win7.

Results:

1. When I start handbrake without running Lightroom RAW photo conversion, I get above 400fps, while Windows is running. The moment I start Lightroom RAW conversion it goes down to around half that speed or 200fps. Compared to my old Core2Duo 2400 MHz PC running native Linux, this is still 5 times as fast!
2. 4.2MB/s is the average - there is definitely a bottleneck in networking. I have only 1 Ethernet port, though. Still, the result is the same as if nothing else was running, so this can't be attributed to CPU bottlenecks in dom0.
3. Lightroom converted the photos in around 1 photo per second. Both the RAW photos and the jpegs were on the same LVM stripped hard drives (no SSD), and watching the CPU load I guess this speed is limited to disk IO. There wasn't any noticeable slowdown due to handbrake running at the same time.

Once Lightroom had finished the speed under handbrake increased to above 400fps, which shows that Xen is able to utilize the full CPU power even while the guest is running but more or less idle.

The DVD I used was an old one, with scratches. From time to time the speed would go down, probably while trying to read scratched DVD areas at a lower speed and CRC correction. I've seen that with other DVDs when running a native Linux install, so this is expected.

xm top showed a 2:1 to 5:3 relation of CPU usage between domU:dom0. Total CPU usage was close to maximum most of the time. CPU usage went a little down when handbrake tried to read bad DVD sectors at lower speed, but Lightroom didn't use much (or any?) of that extra CPU power, probably due to IO constraints. Since xm top shows CPU usage in %, it was like 630% versus 330% at most times.

The results clearly show that Xen is able to manage the CPU resources in an efficient way, and easily recovers spare CPU time for dom0.

My /etc/xen/xend-config.sxp file has this entry:

Code: Select all: # In SMP system, dom0 will use dom0-cpus # of CPUS # If dom0-cpus = 0, dom0 will take all cpus available (dom0-cpus 0)

My domU Windows guest config file /etc/xen/win7.cfg has this entry:

Code: Select all: vcpus=10 # I gave my Win 7 10 virtual CPUs, out of 12 (6-core CPU)

So, when domU is idle, dom0 will use the full 12 vcpus. This is also how it shows in xm top: 12 vcpus for dom0, 10 vcpus for domU. domU can use up to 10 vcpus when needed. CPU time for both dom0 and domU is assigned dynamically within the specified minimum/maximum values.

I wonder how Xen 4.2 will perform. There have been some improvements in the CPU scheduler to better handle short interrupts / IO tasks from devices requiring realtime support (i.e. audio or perhaps disk?). It may also improve network speed, hopefully.

Next thing I need to do is get network speed on the bridged virtual network up on par with native Linux network speed.

by **powerhouse** on Sun Oct 14, 2012 4:26 am

While I'm still having a bit of a problem with the file transfer speed over the network to other PCs (Samba shares), file transfers between Windows domU and Linux dom0 work great. Yesterday I measured ~130MB/s transfer speed between Windows 7 domU and the Samba share on dom0 (Linux Mint)

. The file transfer speed may have been limited by the disk read/write speed (the source was a SSD, the target a regular HDD, both formatted to LVM).

I'm using now LVM disks exclusively. Performance under Xen is top notch.

by **Draucia** on Sun Oct 14, 2012 10:24 am

I'm considering doing this, but I'm not sure if my motherboard supports it. I couldn't find anything on the manufacturer's website. I have the gigabyte GA-b75m-D3V. I also have an i3-2100 and a Radeon HD 6870. Do you think I should give this a go? Also, I enabled VT-D in my bios.

by **powerhouse** on Tue Oct 16, 2012 3:08 am

Draucia wrote:I'm considering doing this, but I'm not sure if my motherboard supports it. I couldn't find anything on the manufacturer's website. I have the gigabyte GA-b75m-D3V. I also have an i3-2100 and a Radeon HD 6870. Do you think I should give this a go? Also, I enabled VT-D in my bios.

With regard to the CPU, have a look here: http://ark.intel.com/

I checked the i3-2100 and it doesn't support VT-d

. See here http://ark.intel.com/products/53422/Intel-Core-i3-2100-Processor-3M-Cache-3_10-GHz.

In fact, the only i3 I could find that supports VT-d is the i3-2115C - see here http://ark.intel.com/products/68332/Intel-Core-i3-2115C-Processor-3MB-Cache-2_00-GHz.

To get a complete list of Intel CPUs with VT-d support see here: http://ark.intel.com/search/advanced?VTD=true

If you have a VT-d option in the BIOS, chances are your motherboard supports VT-d. Just make sure it's VT-d and NOT VT-x (VT-x should also be enabled, but it's not the same thing).

So unless you got the i3-2115C you won't be able to make it work, at least not with an i3 CPU. Sorry for the bad news.

by **powerhouse** on Mon Nov 12, 2012 6:57 pm

Another update on this ongoing project. This time it's about sound.

Up until recently I didn't have any sound support under Windows 7. Though I don't really need it, I wanted it to work.

I set up pulseaudio under Linux Mint and looked for a Windows 7 client only to find out that the "latest" Windows pulseaudio client is 10 years old

. However, I found some instructions on the Internet that should allow sound forwarding from Windows to Linux (see here http://gleamynode.net/articles/2228/). Yet my experiments failed.

After installing a virtual sound card and some other utilities in Windows and Linux I tried to forward the sound but the driver/virtual sound card wasn't recognized by Windows. Here the Windows command line:

Code: Select all: linco.exe -B 16 -C 2 -R 44100 | plink mylinuxdom0 "cat - | pacat --playback"

Someone else made it work using the steps in the following post (see end of post): http://www.overclock.net/t/1205216/guide-create-a-gaming-virtual-machine/250#post_18525583.

In the end I grabbed a $8 USB sound card (these tiny USB sticks with headphone and mic jacks) and a $4 mini-RCA connection cable and plugged the USB sound stick into one of the passed-through USB2.0 ports I gave to Windows. The cable is connected to the headphone jack on the USB stick side, and to the "line in" port of the motherboard back panel. Not a neat solution (yet another wire), but it works fine for me.

Maybe one day I will give the software based sound solution another try.

by **powerhouse** on Mon Nov 12, 2012 7:37 pm

I am lazy so I wrote a little script that backs up my Windows 7 domU. The script also works while Windows is running, since it uses a LVM feature called "snapshot". Here the script:

Code: Select all: #!/bin/sh mv /media/backup/guest-win7.img /media/backup/guest-win7.img.old lvcreate --size 10G --snapshot -n win7-snap /dev/guest/win7 echo Creating backup copy of win7 domU... pv /dev/guest/win7-snap | dd of=/media/backup/guest-win7.img lvremove -f /dev/guest/win7-snap echo Finished

Here a short explanation:
win7 - name of the Windows 7 domU guest system
win7-snap - name of the snapshot of win7 - I gave it 10GB which should be ample, as only the changes versus the win7 LV need to be stored
guest - name of the volume group where win7 resides
/media/backup - folder where the backup drive (LVM) is mounted
guest.win7.img - the image file (copy) of the Windows 7 domU guest

Notes:
1. The backup drive (in my case a virtual LVM volume) is already mounted at /media/backup.
2. The backup media must have at least twice the capacity of your entire Windows 7 domU partition or image file. If you gave your Windows 7 domU 100GB disk space, the backup drive or partition needs to have at least 200GB capacity.
3. The volume group (VG) "guest" must have at least 10GB unassigned capacity to hold the snapshot.
4. pv /dev/guest... | dd of=... uses dd to make an exact image copy of the Windows 7 guest, with the tweak that pv ... outputs a progress bar, time elapsed, and time to completion, giving you an indiciation on how long it will take.
5. I didn't use any compression, but it would be easy to implement (see next post).

by **powerhouse** on Mon Nov 12, 2012 8:04 pm

Except for the /boot partition, I'm using LVM for everything. Here is a little script for backing up my entire /, /boot, and /home partitions using gzip compression and tar:

Code: Select all: #!/bin/sh mv /media/backup/lm13-root.tgz /media/backup/lm13-root.tgz.old mv /media/backup/lm13-home.tgz /media/backup/lm13-home.tgz.old mv /media/backup/boot.tgz /media/backup/boot.tgz.old lvcreate --size 5G --snapshot -n root-snap /dev/lm13/root lvcreate --size 10G --snapshot -n home-snap /dev/lm13/home echo Creating backup copy of /boot... tar -cf - /boot | pv -s $(du -sb /boot | awk '{print $1}') | gzip > /media/backup/boot.tgz echo Creating backup copy of root... mount /dev/lm13/root-snap /media/snapshot tar -cf - /media/snapshot | pv -s $(du -sb /media/snapshot | awk '{print $1}') | gzip > /media/backup/lm13-root.tgz umount /media/snapshot lvremove -f /dev/lm13/root-snap echo Creating backup copy of /home... mount /dev/lm13/home-snap /media/snapshot tar -cf - /media/snapshot | pv -s $(du -sb /media/snapshot | awk '{print $1}') | gzip > /media/backup/lm13-home.tgz umount /media/snapshot lvremove -f /dev/lm13/home-snap echo Finished

The above script can be used on a running system, as it uses LVM snapshots to create a "snapshot" of the system (kind of an instant "freeze" of the file system and data). This snapshot is then compressed and copied to the backup media. Any file or file system changes after the snapshot are written to disk, but not included in the backup.

You need at least 15GB unassigned capacity under volume group "lm13" for the two snapshots. Note that /boot is NOT a LVM volume, so we can't take a snapshot of it. But it's highly unlikely that it gets modified during the backup.

5GB snapshot size for / is far more than you will need - you can make it much smaller, say 1GB. The snapshot size of the /home partition should be large enough to hold all changes/additions to that partition while backing it up.

by **Oscar799** on Tue Nov 13, 2012 4:13 am

powerhouse,
Rather than keep changing post titles mid-thread,which makes the whole thread confusing,it would be better to post different topics as different threads

by **powerhouse** on Tue Nov 13, 2012 7:44 am

Oscar799 wrote:powerhouse,
Rather than keep changing post titles mid-thread,which makes the whole thread confusing,it would be better to post different topics as different threads

Sorry for the confusion. I didn't want to open new threads as the posts are all related to the original how-to.

It would be a lot easier if there was a "virtualization" section in the forum. If I open a new thread for every different topic (but all related to the one topic Xen VGA passthrough / virtualization), the information would be all over the place and hard to find or relate to.

P.S.: I will stop changing post titles mid-thread, if that causes confusion.

Linux Mint Forums

HOW-TO make dual-boot obsolete using XEN VGA passthrough

HOW-TO make dual-boot obsolete using XEN VGA passthrough

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Re: HOW-TO create the ultimate gaming/graphics machine with

Windows sound output

Backing up the Windows 7 guest system

Re: HOW-TO make dual-boot obsolete using XEN VGA passthrough

Re: HOW-TO make dual-boot obsolete using XEN VGA passthrough

Re: HOW-TO make dual-boot obsolete using XEN VGA passthrough

Who is online