Xen project Mailing List

Hi, and thanks for the info. You have woken my appetite for a gaming machine, years after I left Windows :-)

Some comments, if I may:

1. VirtualBox is a host-virtualization software. It means that it runs over your current operating system, and uses the interfaces supplied by it (like sound, for example). Bare-metal virtualization, such as Xen (XenServer, VMware ESXi, etc) are meant, in their initial design, for server workload, where sound is insignificant. I know that virtual Windows servers acting as terminal servers under XenServer (family member, right?) do pass sound over RDP connections. I have not tried passing sound from domU through dom0 myself. Maybe some day.

About the file vs. blktap:
File is a buffered device (as far as I recall. If any of the developers here sees a mistake, he/she is more then welcome to correct me!). It uses the operating system buffering mechanism, which results in a sometimes-faster-sometimes-slower behaviour. The blktap is supposed to be unbuffered device, which should guarantee better data integrity in case of power failure (because you don't have to wait for the 'flush' operation), and would result in a consistent behaviour. Better or worse? I believe it depends on your workloads.

One last thing - opening your file:

While your VM is offline, you should be able to do the following. Mind you that the procedure I supply is merely from my memory. I use a whole different mechanism for disk management myself:

1. Map the file to a loop device:

losetup /dev/loop0 /path/to/image/file

2. Scan and map partitions:
kpartx -a /dev/loop0

3. Mount (if you have NTFS installed) your partitions from /dev/mapper/loop0p1 (first partition), or /dev/mapper/loop0p2 (second partition) and so on, and so on.

To release the disk, do:

1. Unmap partitions:

kpartx -d /dev/loop0

2. Release the loop device:
losetup -d /dev/loop0

If /dev/loop0 is in use (because you loop-mounted an ISO, whatever), use /dev/loop1, or find the next free one.
Oh, and when you modify files on Windows XP system disk using Linux, be aware that there is a small, yet existing chance you will destroy your Windows OS. Mind you.

Ez

On Sat, Jan 4, 2014 at 10:38 PM, Zir Blazer <zir_blazer@xxxxxxxxxxx> wrote:

New year, new Xen goals.

After trying unsuccessfully to boot Xen in UEFI mode in this Thread:

http://lists.xen.org/archives/html/xen-users/2013-12/threads.html#00050

I have decided to skip that for now and use Xen with legacy BIOS, as I desperately needed a proper production machine, at least until someone can help me to figure out what isn't working. I have the time, but not the tools or knowledge of both Linux and Xen to press on that without someone telling me what I have to do.

Besides my UEFI issue, there have been a few success histories and some more issues I've had with Xen. At the moment, I'm using Xen 4.3.1-5 builded with the Radeon passthrough patch, using the xl toolset, on top of the Arch Linux ISO release dated 01/12/2013 as Dom0 with Gnome installed. Bootloader is Syslinux, which has GPT support even on legacy BIOS mode. Additionally, I also add the following files contents:

/boot/syslinux/syslinux.cfg - reelevant Xen option

LABEL xen
MENU LABEL Xen
KERNEL mboot.c32
APPEND ../xen-4.3.1.gz --- ../vmlinuz-linux console=tty0 root=/dev/sda5 rw xen-pciback.hide=(01:00.0)(01:00.1) earlyprintk=vga,keep --- ../initramfs-linux.img

VM/DomU CFG file

name = "wxpmain"
builder = 'hvm'
memory = 3584
boot = "c"
vcpus = 4
vif = ['bridge=xenbr0']
pci = ['01:00.0','01:00.1']
xen_platform_pci = 1
device_model_version = "qemu-xen-traditional"
serial = 'pty'

viridian = 1
pae = 1
acpi = 1
apic = 1
disk = ['file:wxp_sp3.img,hda,w','file:gamesvhd.img,hdb,w']
# nographic = 1
soundhw = 'ac97'

opengl = 1
sdl = 1
vnc = 0
vnclisten = ""
vncpasswd = ""
stdvga = 0
gfx_passthru = 0

1) VGA Passthrough

During the last month, besides failing with UEFI I also tinkered with Xen in legacy BIOS mode, but have been unable to pass the Video Card, a Radeon 5770, to a Windows XP SP3 VM. That was until a recent discovery...

At first, I used xl pci-assignable-add to manually add everytime I rebooted Dom0 the GPU and the HDMI device, but decided to add these to the syslinux.cfg file to skip that step. Either way, I didn't had any issues making the Radeon itself free to pass it to the VM (As I was using my Xeon Haswell integrated GPU as main Video Card, and didn't installed the Radeon Drivers on Dom0) when I used xl create and had the pci = option in the VM's CFG file. However, it either BSODed, or Windows was unable to use it as it appeared with a yellow exclamation mark while on Device Manager.

Googling around I found that the latest version of QEMU broke VGA Passthrough, and that using qemu-xen-traditional fixed it, which I through I was using. However, there was a problem with that. Using device_model = qemu-xen-traditional, as told by most Xen VGA Passthrough guides available currently, I got this error:

WARNING: ignoring device_model directive.
WARNING: Use "device_model_override" instead if you really want a non-default device_model

I ignored that because the VM was successfully created, and besides, when I replaced device_model = qemu-dm with device_model_override = qemu-xen-traditional, it throwed another error which made it to not even create the VM. However, I recently discovered that I instead had to use device_model_version = qemu-xen-traditional. It worked pretty much flawlessly with that. Basically, there are a lot of guides, and even the Xen wiki, that are severely outdated in this area. I spend weeks trying to figure out what I was doing wrong due bad documentation, maybe because I didn't digged deep enough earlier, but still, most of the easily accessible data and google results are for older versions, and some critical options like device_model have changed.

http://wiki.xen.org/wiki/Xen_Configuration_File_Options - old parameters which I was using
http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html - what I should have used on first place

This is really worth writing about because I'm sure that someone else will sooner or later stumble here (Saw several people with this issue on google), as some guides assumes you're using an specific Linux distribution with an older Xen version instead of something bleeding edge.

After finally being able to see Windows Desktop on the Monitor plugged to the Radeon 5770, I installed the Radeon 5770 Drivers from Device Manager with an INF file instead of the full Catalyst Control Center, as I hear than that gives more possible BSOD issues. Additionally, after around one week of playing around with the GPU on the VM (Even leaving a game open during all the night), I don't seem to notice issues, and the games I tried (Path of Exile, League of Legends) worked flawlessly with it. I only had a single GPU crash, with lost of Monitor signal and the VM destroying itself, but that may not be necesarrily attributable to Xen.

Also, I didn't notice any issues with the so-called "Soft Reset" or FLR, but maybe that was because I builded Xen with the Radeon patch included. For example, I used xl destroy to abruptly shut down the VM. The Monitor shows a freezed image of the last image before I did that, yet I am able to create it again with the Video Card passing with no issues. I didn't notice either any performance degradation, albeit I'm not sure if that is under reboot scenarios or also applies when you shut down and create again the VM/DomU without restarting Dom0.

Overally, it seems very functional and quite reliable. The only actual issue I find, is that when I create the VM, I need to have the VM window (Check attached file) on the main monitor as the active window, otherwise it seems that after Windows XP splash screen when it changes video resolution it usually either BSODs, or doesn't initialize the Video Card properly, and instead the Monitor stays in Standby while the VM window displays the Windows Desktop as if there was no VGA Passthrough being done.

2) VNC vs SDL, Keyboard and Mouse focus

I have tried with both VNC and SDL and I prefer the later. When I use SDL, the VM window automatically pops up, through that is rather unneeded as it later black screens as the Radeon takes control of the video output in the other Monitor. With VNC I have to manually launch vncviewer to be able to control the VM. Most important is that with SDL, when I click on the VM black window, control of the Keyboard and Mouse goes to the VM, while on VNC I didn't ever managed to get control of the Keyboard. The Mouse pointer works without having to make the VM window the active one as if I was using a freemouse tool on a windowed game, however, the VM black window surface on Dom0 doesn't allow me to travel the entire Desktop surface of the VM, so is rather useless.

The only thing that annoys me from using SDL is that I have the black screen always open while the VM is working, and having to click it everytime I want to switch control to the VM is rather annoying. Isn't there any way to change Keyboard and Mouse focus from Dom0 to a DomU and viceversa like if they were consoles? For example, I may want to use Ctrl + Alt + F1 to get control of Dom0, then use Ctrl + Alt + F2 to switch control to the VM. This would increase usability.

3) Disk Images

As can be seen in the CFG file I copypasted, I'm using file: for my IMG Disk Images. However, on some other documentation like that of blktap2 on the Xen wiki, it mentions that I can use tap:tapdisk:aio:, however, is there any reason why I should pick one over another? Do they also have specific format support or anything I should be careful with?

Besides, is there any easy way to mount the IMG Disk Image files on Linux (Including NTFS partitions) so I can retrieve or add files when the VM is not running? I still didn't learned to setup Networks with Linux and need a workable way to move data from and to the VM Disk Images.

I know about LVM partitions, but find them a bit harder to manage than Disk Images. Plus performance is currently adequate this way.

4) Audio emulation

While the Windows XP VM works nicely with games, I have the issue that there is no audio coming from it, which seems to be the most important missing thing before I can call my VM "production-ready" for playing games as if it were my old computer. I didn't tried to pass the integrated Realtek Sound Card, but that would be rather stupid as I need sound in both the current Linux Dom0, which I'm using for simple task like browsing, and the Windows XP VM for games. This means I have to rely on emulated Audio devices, which as far that I know are common.

soundhw = 'ac97' seems to work, Windows XP recognizes the Sound Card and install the Drivers for it with no issues. It also has the HDMI device passed to it along the GPU. However, after googling a lot, I didn't find any easy to get audio from a DomU to Dom0 to get mixed so I can rely on emulated Sound Cards instead of needing one per VM like you need Video Cards.

As far that I know, there are other VMMs like VirtualBox where you can usually get easily sound from the VMs, and it also uses QEMU-emulated Sound Cards as Xen does. Is there any reason why getting audio doesn't seem to be easy to do on Xen? I know that many people considers USB Sound Card cheap to pass to the VM, but I don't have easy access to those, so I would need a Software way to get sound from multiple VMs using a single Headphone connected to the integrated Realtek Sound Card.

Well, so far, that's all. Thanks for reading, I hope to have everything ready so I can happily jump onto Xen 4.4 when it gets released.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

Re: [Xen-users] Reporting success with VGA Passthrough, and some other question/issues, mainly with Audio