I have a new dom0 kernel available for testing (2.6.38-0.rc2.git3.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2742521 This is based on the xen/next-2.6.38 branch with a few extra memory fixes, including one which fixes a problem I had causing a crash during boot. xen/next-2.6.38 adds net and pci backends.
Michael Young
On Wed, 26 Jan 2011, M A Young wrote:
I have a new dom0 kernel available for testing (2.6.38-0.rc2.git3.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2742521
... with a few extra memory fixes, including one which fixes a problem I had causing a crash during boot.
Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376
I also now have a build of xen-4.1.0-rc2 at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744030
Michael Young
27.01.2011 00:50, M A Young wrote:
On Wed, 26 Jan 2011, M A Young wrote:
I have a new dom0 kernel available for testing (2.6.38-0.rc2.git3.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2742521
... with a few extra memory fixes, including one which fixes a problem I had causing a crash during boot.
Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376
Great work :)
I tested with2.6.38-0.rc2.git3.2.xendom0.fc15.x86_64.
Fonts and OpenGL textures work with Radeon card. Games too. Dom0 is now usable as a desktop computer.
I tested with Dom0 memory sizes 1GB and 3GB. I have software IO TLB in use under Dom0.
Regards, Marko Ristola
Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376
I also now have a build of xen-4.1.0-rc2 at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744030
I am presently testing these Xen and kernel packages. My initial impression is very positive. I am able to boot into X within Dom0 on my previously difficult hardware. Previous experiences are documented on this list, beginning with [1]. My WiFi adapter also works. So, I agree with Marko's statement so far, "Dom0 is now usable as a desktop computer." I will continue to use this as my primary environment and will report any issues I come across.
Now, the last issue remaining for me is the backend drivers. My understanding is that, in the absence of backends being accepted upstream, we can use QEMU-based drivers. This would be acceptable for our work. Has anyone been using these with Fedora 15?
[1] http://lists.fedoraproject.org/pipermail/xen/2010-March/005014.html
On Thu, Jan 27, 2011 at 11:51 AM, W. Michael Petullo mike@flyn.org wrote:
Actually it didn't, but (2.6.38-0.rc2.git3.2.xendom0.fc15) does at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744376
I also now have a build of xen-4.1.0-rc2 at http://koji.fedoraproject.org/koji/taskinfo?taskID=2744030
I am presently testing these Xen and kernel packages. My initial impression is very positive. I am able to boot into X within Dom0 on my previously difficult hardware. Previous experiences are documented on this list, beginning with [1]. My WiFi adapter also works. So, I agree with Marko's statement so far, "Dom0 is now usable as a desktop computer." I will continue to use this as my primary environment and will report any issues I come across.
Me too. My "Failsafe KDE" is stable over an hour now!! Video: 01:00.0 VGA compatible controller: ATI Technologies Inc RV610 [Radeon HD 2400 XT] Smolt:: http://www.smolts.org/client/show/pub_10d63815-f25a-45cc-a80a-d16d3f5f4af0
However, my "standard" KDE desktop hangs X after a few minutes. Should I report to bz.r.c? I can easily reproduce this...
thanks, jerry
[ 1336.505] [mi] EQ overflowing. The server is probably stuck in an infinite loop. [ 1336.506] Backtrace: [ 1336.507] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a0488] [ 1336.507] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49f994] [ 1336.507] 2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x47c744] [ 1336.507] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7ff026da1000+0x453f) [0x7ff026da553f] [ 1336.507] 4: /usr/bin/X (0x400000+0x6a447) [0x46a447] [ 1336.507] 5: /usr/bin/X (0x400000+0x118c43) [0x518c43] [ 1336.507] 6: /lib64/libc.so.6 (0x3a96200000+0x34100) [0x3a96234100] [ 1336.507] 7: /lib64/libc.so.6 (0x3a96200000+0x136400) [0x3a96336400] [ 1336.507] 8: /usr/lib64/xorg/modules/libfb.so (fbBlt+0xf8) [0x7ff027bd0118] [ 1336.507] 9: /usr/lib64/xorg/modules/libfb.so (fbBltStip+0x40) [0x7ff027bd0ec0] [ 1336.507] 10: /usr/lib64/xorg/modules/libfb.so (fbGetImage+0x206) [0x7ff027bd6616] [ 1336.507] 11: /usr/lib64/xorg/modules/libexa.so (0x7ff0279a8000+0x13988) [0x7ff0279bb988] [ 1336.507] 12: /usr/lib64/xorg/modules/libexa.so (0x7ff0279a8000+0xbef8) [0x7ff0279b3ef8] [ 1336.507] 13: /usr/bin/X (0x400000+0x1560d8) [0x5560d8] [ 1336.507] 14: /usr/lib64/xorg/modules/libexa.so (exaGetPixmapFirstPixel+0xa9) [0x7ff0279bc839] [ 1336.507] 15: /usr/lib64/xorg/modules/libexa.so (0x7ff0279a8000+0x10731) [0x7ff0279b8731] [ 1336.507] 16: /usr/bin/X (0x400000+0xd6503) [0x4d6503] [ 1336.507] 17: /usr/bin/X (0x400000+0xcf219) [0x4cf219] [ 1336.507] 18: /usr/bin/X (0x400000+0x2d4d1) [0x42d4d1] [ 1336.507] 19: /usr/bin/X (0x400000+0x2152e) [0x42152e] [ 1336.507] 20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3a9621ee7d] [ 1336.507] 21: /usr/bin/X (0x400000+0x210d9) [0x4210d9]
On Thu, 27 Jan 2011, W. Michael Petullo wrote:
Now, the last issue remaining for me is the backend drivers. My understanding is that, in the absence of backends being accepted upstream, we can use QEMU-based drivers. This would be acceptable for our work. Has anyone been using these with Fedora 15?
In theory the block driver should work in 4.1.0, though I am not sure about the net driver. In practise I have failed so far to get the block driver working so far. This post today http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html talks about what block driver configurations should work.
Michael Young
Now, the last issue remaining for me is the backend drivers. My understanding is that, in the absence of backends being accepted upstream, we can use QEMU-based drivers. This would be acceptable for our work. Has anyone been using these with Fedora 15?
In theory the block driver should work in 4.1.0, though I am not sure about the net driver. In practise I have failed so far to get the block driver working so far. This post today http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html talks about what block driver configurations should work.
I have written the following domain config (to try to force the QEMU block backend):
kernel = '/tmp/openwrt-x86-xen_domu-vmlinuz' memory = 32 # NOTE: Generated with qemu-img convert -f raw -O qcow2 input.img output.qcow2 disk = [ 'tap:qcow2:/tmp/openwrt-x86-xen_domu-rootfs-ext2.qcow2,xvda,r', ] vif = [ 'bridge=virbr0' ] name = '2.6.38-DomU-Test' root = '/dev/xvda1' on_crash = 'destroy'
When I boot, I get:
[...] NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear greearb@candelatech.com All bugs added by David S. Miller davem@redhat.com Using IPI No-Shortcut mode XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...
When I try to use:
disk = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
I get:
[No boot] Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/13/51712 state: 1
On Thu, Jan 27, 2011 at 05:03:57PM -0600, W. Michael Petullo wrote:
Now, the last issue remaining for me is the backend drivers. My understanding is that, in the absence of backends being accepted upstream, we can use QEMU-based drivers. This would be acceptable for our work. Has anyone been using these with Fedora 15?
In theory the block driver should work in 4.1.0, though I am not sure about the net driver. In practise I have failed so far to get the block driver working so far. This post today http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html talks about what block driver configurations should work.
I have written the following domain config (to try to force the QEMU block backend):
kernel = '/tmp/openwrt-x86-xen_domu-vmlinuz' memory = 32 # NOTE: Generated with qemu-img convert -f raw -O qcow2 input.img output.qcow2 disk = [ 'tap:qcow2:/tmp/openwrt-x86-xen_domu-rootfs-ext2.qcow2,xvda,r', ] vif = [ 'bridge=virbr0' ] name = '2.6.38-DomU-Test' root = '/dev/xvda1' on_crash = 'destroy'
When I boot, I get:
[...] NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear greearb@candelatech.com All bugs added by David S. Miller davem@redhat.com Using IPI No-Shortcut mode XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...
When I try to use:
disk = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
I get:
[No boot] Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/13/51712 state: 1
Just making sure.. you're running Xen 4.1 ? The userspace qemu blkback implementation is *only* in Xen 4.1 ..
And it should get used automatically if dom0 kernel blkback is not available.
-- Pasi
Now, the last issue remaining for me is the backend drivers. My understanding is that, in the absence of backends being accepted upstream, we can use QEMU-based drivers. This would be acceptable for our work. Has anyone been using these with Fedora 15?
In theory the block driver should work in 4.1.0, though I am not sure about the net driver. In practise I have failed so far to get the block driver working so far. This post today http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01847.html talks about what block driver configurations should work.
I have written the following domain config (to try to force the QEMU block backend):
kernel = '/tmp/openwrt-x86-xen_domu-vmlinuz' memory = 32 # NOTE: Generated with qemu-img convert -f raw -O qcow2 input.img output.qcow2 disk = [ 'tap:qcow2:/tmp/openwrt-x86-xen_domu-rootfs-ext2.qcow2,xvda,r', ] vif = [ 'bridge=virbr0' ] name = '2.6.38-DomU-Test' root = '/dev/xvda1' on_crash = 'destroy'
When I boot, I get:
[...] NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear greearb@candelatech.com All bugs added by David S. Miller davem@redhat.com Using IPI No-Shortcut mode XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...
When I try to use:
disk = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
I get:
[No boot] Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/13/51712 state: 1
Just making sure.. you're running Xen 4.1 ? The userspace qemu blkback implementation is *only* in Xen 4.1 ..
Yes. I am using Michael's Xen 4.1 package.
And it should get used automatically if dom0 kernel blkback is not available.
That was my understanding, but I have not yet been able to get this to work.
On Thu, 27 Jan 2011, W. Michael Petullo wrote:
When I try to use:
disk = [ 'file:/tmp/openwrt-x86-xen_domu-rootfs-ext2.img,xvda,r', ]
I get:
[No boot] Error: Device 51712 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/13/51712 state: 1
I have finally got a domU to boot in this sort of situation, having found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a bootloader. Note that you may have to use xl rather than xm because they are deprecating xm and xm may not have support for qemu block backends.
Michael Young
I have finally got a domU to boot in this sort of situation, having found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a bootloader. Note that you may have to use xl rather than xm because they are deprecating xm and xm may not have support for qemu block backends.
Does anyone know where I can find documentatin on domain configuration for xl? There does not seem to be a man page and a review of the Xen Wiki did not find authoritative documentation. I am trying to figure out how to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
On Sun, Jan 30, 2011 at 6:17 PM, W. Michael Petullo mike@flyn.org wrote:
I have finally got a domU to boot in this sort of situation, having found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a bootloader. Note that you may have to use xl rather than xm because they are deprecating xm and xm may not have support for qemu block backends.
Does anyone know where I can find documentatin on domain configuration for xl? There does not seem to be a man page and a review of the Xen Wiki did not find authoritative documentation. I am trying to figure out how to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
You can pull examples for the Xen test suite, for example, take a look at one of the tests: http://www.chiark.greenend.org.uk/~xensrcts/logs/5501/
The syntax is rather similar, and we'll need to formally document it on the xen wiki soon.
Hope that helps, Todd
On Sun, 30 Jan 2011, W. Michael Petullo wrote:
I have finally got a domU to boot in this sort of situation, having found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a bootloader. Note that you may have to use xl rather than xm because they are deprecating xm and xm may not have support for qemu block backends.
Does anyone know where I can find documentatin on domain configuration for xl? There does not seem to be a man page and a review of the Xen Wiki did not find authoritative documentation. I am trying to figure out how to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
It is supposed to be a direct replacement for xm, the idea being for configuration files for xm to work for xl, though not necessarily the other way around. In practice, you can still find stuff that doesn't yet work.
Michael Young
On Sun, Jan 30, 2011 at 11:52:56PM +0000, M A Young wrote:
On Sun, 30 Jan 2011, W. Michael Petullo wrote:
I have finally got a domU to boot in this sort of situation, having found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a bootloader. Note that you may have to use xl rather than xm because they are deprecating xm and xm may not have support for qemu block backends.
Does anyone know where I can find documentatin on domain configuration for xl? There does not seem to be a man page and a review of the Xen Wiki did not find authoritative documentation. I am trying to figure out how to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
It is supposed to be a direct replacement for xm, the idea being for configuration files for xm to work for xl, though not necessarily the other way around. In practice, you can still find stuff that doesn't yet work.
With the exception that xl doesn't support embedded python code in the cfgfiles.
-- Pasi
I have finally got a domU to boot in this sort of situation, having found a few bugs in 4.1.0-rc2 on the way when trying to use pygrub as a bootloader. Note that you may have to use xl rather than xm because they are deprecating xm and xm may not have support for qemu block backends.
Does anyone know where I can find documentatin on domain configuration for xl? There does not seem to be a man page and a review of the Xen Wiki did not find authoritative documentation. I am trying to figure out how to write an xl configuration, i.e., rewrite xmexample1 to work with xl.
It is supposed to be a direct replacement for xm, the idea being for configuration files for xm to work for xl, though not necessarily the other way around. In practice, you can still find stuff that doesn't yet work.
With the exception that xl doesn't support embedded python code in the cfgfiles.
I am able to boot a DomU kernel using xl with xen-4.1.0-0.1.rc2.fc14.x86_64 and kernel-2.6.38-0.rc2.git3.2.xendom0.fc15.x86_64. Both block and network devices work.
-
Jerry Amundson -
M A Young -
Marko Ristola -
Pasi Kärkkäinen -
Todd Deshane -
W. Michael Petullo