[Fedora-xen] Re: Windows guest networking
>> Is anyone running a Windows HVM guest with networking? I recently tried >> to connect a Windows 7 HVM guest to my network using vif-nat. For some >> reason, the setup does not work. Oddly, Dom0 lists the vif interface >> associated with the guest as "NO-CARRIER" even though the DomU Windows >> guest seems to recognize its virtual network interface (RTL8139C+). >> >> I have no problem with a similarly configured guest running Linux. >> >> I am using: >> >> xen-4.7.1-6.fc25.x86_64 >> >> The guest configuration is: >> >> name = "windows64" >> memory= 2048 >> vcpus = 1 >> builder = "hvm" >> altp2mhvm = 1 >> vif = [ "script=vif-nat,ip=10.0.0.2/32,gatewaydev=wlp3s0" ] >> disk = [ "tap2:tapdisk:aio:/path/to/disk-windows64.img,xvda,w", >> "tap2:tapdisk:aio:/path/to/spare-vfat.img,xvdb,w" ] >> serial= "pty" >> sdl = 1 > Does it work if you use the default vif bridge? It does indeed. I switched to vif-bridge, and everything worked. I am a little suprised by this, because I thought from the point of view of Xen both of these configurations were rather similar; I thought the difference was in the Dom0 network configuration. The reason I prefer vif-nat is that it makes using my WiFi interface easier. I have to go through some trouble to bridge vif/Ethernet to WiFi. I am left with another question: does this mean there is a bug in Xen or the vif-nat script? If there is a bug, what else could I provide to help fix it? -- Mike :wq ___ xen mailing list -- xen@lists.fedoraproject.org To unsubscribe send an email to xen-le...@lists.fedoraproject.org
[Fedora-xen] Windows guest networking
Is anyone running a Windows HVM guest with networking? I recently tried to connect a Windows 7 HVM guest to my network using vif-nat. For some reason, the setup does not work. Oddly, Dom0 lists the vif interface associated with the guest as "NO-CARRIER" even though the DomU Windows guest seems to recognize its virtual network interface (RTL8139C+). I have no problem with a similarly configured guest running Linux. I am using: xen-4.7.1-6.fc25.x86_64 The guest configuration is: name = "windows64" memory= 2048 vcpus = 1 builder = "hvm" altp2mhvm = 1 vif = [ "script=vif-nat,ip=10.0.0.2/32,gatewaydev=wlp3s0" ] disk = [ "tap2:tapdisk:aio:/path/to/disk-windows64.img,xvda,w", "tap2:tapdisk:aio:/path/to/spare-vfat.img,xvdb,w" ] serial= "pty" sdl = 1 -- Mike :wq ___ xen mailing list -- xen@lists.fedoraproject.org To unsubscribe send an email to xen-le...@lists.fedoraproject.org
[Fedora-xen] Re: Xen utilities hanging on Fedora 24
>> Has anyone else seen things like "xl list" or xentop hang on Fedora 24?
>>
>> # rpm -q kernel xen
>> kernel-4.5.5-300.fc24.x86_64
>> xen-4.6.1-10.fc24.x86_64
>>
>> Running "strace xl list" produces the following, which seems to indicate
>> that the hang occurs when "xl list" writes to /dev/xen/xenbus:
>>
>> access("/dev/xen/xenbus", F_OK) = 0
>> stat("/dev/xen/xenbus", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 62),
>> ...}) = 0
>> open("/dev/xen/xenbus", O_RDWR) = 6
>> open("/etc/xen/xl.conf", O_RDONLY) = 7
>
> I think this depends on having the right DomU running as I have used xl
> list with the above settings without problems (though I don't think
> anything I run depends on xenbus).
>
> I also wonder what your selinux settings are. I had problems with
> xen-4.7.0 which uses /dev/xen/privcmd which had
> system_u:object_r:device_t:s0 permissions rather than
> system_u:object_r:xen_device_t:s0 (now fixed if you have a recent enough
> selinux). If you have selinux enabled could you try
> chcon -t xen_device_t /dev/xen/xenbus
> to see if that makes any difference or alternatively setenforce 0.
Indeed, this looks SELinux related, possibly due to bug #1322625 as
Konrad suggested. I will provide more details as I find them at:
https://bugzilla.redhat.com/show_bug.cgi?id=1341317
Thank you,
--
Mike
:wq
--
xen mailing list
xen@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/xen@lists.fedoraproject.org
[Fedora-xen] Xen utilities hanging on Fedora 24
Has anyone else seen things like "xl list" or xentop hang on Fedora 24?
# rpm -q kernel xen
kernel-4.5.5-300.fc24.x86_64
xen-4.6.1-10.fc24.x86_64
Running "strace xl list" produces the following, which seems to indicate
that the hang occurs when "xl list" writes to /dev/xen/xenbus:
access("/dev/xen/xenbus", F_OK) = 0
stat("/dev/xen/xenbus", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 62), ...}) = 0
open("/dev/xen/xenbus", O_RDWR) = 6
open("/etc/xen/xl.conf", O_RDONLY) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=33, ...}) = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=33, ...}) = 0
read(7, "vif.default.script = \"vif-ethos\""..., 4096) = 33
close(7)= 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 262150
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED,
-1, 0) = 0x7fef0d788000
madvise(0x7fef0d788000, 4096, MADV_DONTFORK) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 4096
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc79e90) = 0
mmap(NULL, 102400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED,
-1, 0) = 0x7fef0d76f000
madvise(0x7fef0d76f000, 102400, MADV_DONTFORK) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc61c70) = 0
madvise(0x7fef0d76f000, 102400, MADV_DOFORK) = 0
munmap(0x7fef0d76f000, 102400) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED,
-1, 0) = 0x7fef0d786000
madvise(0x7fef0d786000, 8192, MADV_DONTFORK) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffdafc60c70) = 0
madvise(0x7fef0d786000, 8192, MADV_DOFORK) = 0
munmap(0x7fef0d786000, 8192)= 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
write(1, "Name"..., 73Name
ID Mem VCPUsState Time(s)
) = 73
rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fef0ca7cc10}, {SIG_DFL, [],
0}, 8) = 0
write(6, "\2\0\0\0\0\0\0\0\0\0\0\0\25\0\0\0", 16) = 16
write(6, "/local/domain/0/name\0", 21 # [ HANGS HERE. ]
--
Mike
:wq
--
xen mailing list
xen@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/xen@lists.fedoraproject.org
[Fedora-xen] Supported file-backed disk formats
What file-backed disk formats are supported by Xen using a Fedora Dom0? I am testing xen-4.6.1-8.fc24.x86_64, and I have not been able to get the "qcow2" and "vhd" formats to work. "Qcow" version 1 works fine with: disk = [ "tap2:qcow:/var/lib/xen/images/test-data.xen-qcow,xvdb,w" ] However, when I try qcow2, the VM detects the disk, but "fdisk /dev/sdb" says: fdisk: cannot open /dev/sdb: No such file or directory When I try vhd, the VM kernel does not even detect the disk. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/xen@lists.fedoraproject.org
[Fedora-xen] Fedora 21 crashes when booted as Dom0
Has anyone else seen this: https://bugzilla.redhat.com/show_bug.cgi?id=1188573 ? The current Fedora 21 kernel crashes on my computer when booted in Dom0. $ uname -a Linux imp.flyn.org 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Xen Test Day next Wednesday (May 22nd 2013)
The second Xen Test Day for the Xen 4.3 release cycle is going to be next Wednesday, the 22nd of May! We'll have the chance to test Xen 4.3 RC2, that will be out tomorrow. For more information see: - On Xen Test Days: http://wiki.xen.org/wiki/Xen_Test_Days - On getting and testing RC2: http://wiki.xen.org/wiki/Xen_4.3_RC2_test_instructions - Generic test information: http://wiki.xen.org/wiki/Testing_Xen See you soon on the #xentest channel on freenode! Will we have a Fedora RPM? -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Updating xen package does not 'refresh' grub.cfg
I've the same exact problem. I had to manually run grub2-mkconfig in my all F17 boxes. Did you update the kernel at the same time? That looks like what you might get with grubby which is run (which doesn't handle xen very well, which is why xen-hypervisor runs grub2-mkconfig). This is also discussed as an aside at: https://bugzilla.redhat.com/show_bug.cgi?id=738085 -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Fedora 18 and EFI
I have successfully installed Fedora 18 Beta as Dom0 on one computer, and am now trying to do the same on another. I am using all of the standard Fedora 18 packages, including xen-4.2.0-6.fc18.x86_64. On the second computer, I ended up with an EFI grub2 install. I used yum to install xen, and noted that the package installation did not update /etc/grub2-efi.cfg. I ran grub2-mkconfig by hand, and this added Xen entries to /etc/grub2-efi.cfg. However, booting failed: grub2 complained that it did not know the multiboot keyword. Does anyone have experience getting EFI grub2 to boot Xen/Fedora 18? Is my trouble expected? Did you try native UEFI boot? So booting the xen.efi binary directly from UEFI ? Also note that F18 kernel doesn't have proper UEFI support for dom0 (yet), because it hasn't been upstreamed yet.. I eventually figured out how to install Fedora 18 using the MBR-style grub2. My Fedora 18 install media was a thumbdrive; what I discovered was that if I did *not* instruct my motherboard firmware's UEFI menu to boot from this USB device, then it seemed to pick it up as an old-style MBR boot instead. From that point on, Anaconda seemed to assume the computer had a BIOS, not UEFI. It appears the Fedora 18 install image supports both BIOS/MBR and UEFI, and the motherboard's firmware picks up the MBR if not explicitly asked to boot the device as UEFI. After picking through Anaconda and finding no option (i.e., a way to install using an MBR boot instead of a UEIF boot), I suspect I could achieve the same effect by manually creating an msdos partition table on the target hard drive instead of a GPT partition table. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Fedora 18 and EFI
I have successfully installed Fedora 18 Beta as Dom0 on one computer, and am now trying to do the same on another. I am using all of the standard Fedora 18 packages, including xen-4.2.0-6.fc18.x86_64. On the second computer, I ended up with an EFI grub2 install. I used yum to install xen, and noted that the package installation did not update /etc/grub2-efi.cfg. I ran grub2-mkconfig by hand, and this added Xen entries to /etc/grub2-efi.cfg. However, booting failed: grub2 complained that it did not know the multiboot keyword. Does anyone have experience getting EFI grub2 to boot Xen/Fedora 18? Is my trouble expected? -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 4.2.0-rc2 available to test
I have done a temporary build of 4.2.0-rc2 for testing which is at http://koji.fedoraproject.org/koji/taskinfo?taskID=4386920 This also adds the efi hypervisor back in for x86_64. Note to other people: fedora kernels still don't have xen dom0 EFI patches included, mainly because dom0 EFI patches are not yet ported to pvops or merged to upstream Linux. So actually testing xen.efi hypervisor on UEFI systems is a bit tricky atm.. (you need to manually build a kernel based on the suse xenlinux sles11sp2 or opensuse patches). I have tried the 4.2.0-rc packages on three machines: one with an AMD Athlon X2, one with an AMD FX 4170 [1], and a MacBook with a Core 2 Duo. The first machine works fine. The FX 4170 and MacBook are unable to load Dom0. I see Xen print its boot messages, but the machines spontaneously reboot before Dom0 prints any output. [1] Same machine referenced at https://bugzilla.redhat.com/show_bug.cgi?id=841330 -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 4.2.0-rc2 available to test
I have done a temporary build of 4.2.0-rc2 for testing which is at http://koji.fedoraproject.org/koji/taskinfo?taskID=4386920 This also adds the efi hypervisor back in for x86_64. Note to other people: fedora kernels still don't have xen dom0 EFI patches included, mainly because dom0 EFI patches are not yet ported to pvops or merged to upstream Linux. So actually testing xen.efi hypervisor on UEFI systems is a bit tricky atm.. (you need to manually build a kernel based on the suse xenlinux sles11sp2 or opensuse patches). I have tried the 4.2.0-rc packages on three machines: one with an AMD Athlon X2, one with an AMD FX 4170 [1], and a MacBook with a Core 2 Duo. The first machine works fine. The FX 4170 and MacBook are unable to load Dom0. I see Xen print its boot messages, but the machines spontaneously reboot before Dom0 prints any output. Is the dom0 different? The 3.5 has an issue where on certain machines it crashes (3.5.3 should have the proper fix). Pfff.. Found the issue. If you boot with 'xsave=off' on the hypervisor line it boots. It looks to be a Fedora kernel issue thought - when I booted a mainline kernel I did not hit this. Yes. all three machines boot if I use xsave=off. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Python misbehaves on Xen/Fedora 17/AMD FX-4170 Processor
Has anyone had similar trouble? No. But it sounds like the AVX disaster. https://bugzilla.redhat.com/show_bug.cgi?id=801650 It seems to be. I booted bare metal and used yum to install gdb and the debug symbols for Python and glibc. Then I rebooted in Xen. I found that gdb itself crashed when the debug symbols were installed, so I removed them. I ran gdb again and obtained a partial backtrace on import random: (gdb) ba #0 0x771474ec in __ieee754_exp_fma4 () from /lib64/libm.so.6 #1 0x7009e415 in ?? () from /usr/lib64/python2.7/lib-dynload/math.so #2 0x77b00053 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #3 0x77b00b2f in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #4 0x77b00c02 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0 #5 0x77b1017d in PyImport_ExecCodeModuleEx () from /lib64/libpython2.7.so.1.0 [...] After looking a little closer, it seems that __ieee754_exp_fma4 is executing vmovsd %xmm0,-0x20(%rsp). I thought booting Xen with xsave=1 might help, but this causes Xen to crash on this hardware. As mentioned above, it looks like there has been Right. That is b/c of Fedora's incorrect extra patch that neuters xsave. work in glibc to properly detect AVX (my understanding is that you have to check that both the processor and OS supports it). Is it possible that this glibc work missed something? Very likely. There was another fix to it that got added in Debian (or Ubuntu) that checked for FMA4 on AMD (which had a different CPUID). Can you open a Red Hat bugzilla please? And CC me on it: ketuzs...@darnok.org The issue in glibc has been fixed by Jeff Law. Please see: https://admin.fedoraproject.org/updates/glibc-2.15-51.fc17 Python works fine with this update, pushed today. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Xl and /dev/null
The old xm command allowed for a domain to be configured from and command line using xm create /dev/null kernel=x ... Xl does not seem to support this: $ sudo xl create /dev/null libxl: error: libxl_utils.c:328:libxl_read_file_contents /dev/null is not a plain file: Success Failed to read config file: /dev/null: Inappropriate ioctl for device Does anyone know the preferred technique to create a domain without an existing domain configuration file (i.e., purely from the command line)? -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Xend not always starting on Fedora 15 Beta
Has anyone else had trouble starting xend when SELinux is enforcing the targeted policy on the various test releases of Fedora 15? I just submitted a bug report at: https://bugzilla.redhat.com/show_bug.cgi?id=706987 -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Xen Dom0 feature pushed to Fedora 16
The Xen Dom0 feature described at http://fedoraproject.org/wiki/Features/XenPvopsDom0 has been pushed to Fedora 16. I don't think this should come as a surprise. A lot of people are working hard on the kernel components, but they did not make the Fedora 15 timeline. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] test 2.6.38 dom0 kernel
I have done an experimental kernel, which is a standard F15 2.6.38 kernel plus the two packages needed to get the xen net backend working. In my testing on an F15 host I could get a guest to boot from a text boot, though X crashed. The build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=2968665 if anyone else wants to test it. I tested this kernel and was able to boot a DomU kernel with networking. In many cases I do not use Xen's block driver, so this kernel is sufficient for a lot on my uses. Of course, some things did not work. For example, Dom0 X crashes on my hardware. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] OProfile and Xen
Is anyone using OProfile with Xen? I am especially interested in the passive profiling of Xen DomU domains. I've attached a Xen patch against the Fedora oprofile package to a report in Bugzilla, #693596. But, even with this patch I am getting mixed results. See also http://www.xen.org/files/summit_3/xenoprof_tutorial.pdf. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 4.1.0-rc8
We got another release candidiate xen-4.1.0-rc8 instead, built at http://koji.fedoraproject.org/koji/taskinfo?taskID=2929815 The final release has slipped to Friday. I am considering building the release candidate as an official rawhide/F15 package so I can be sure to get it into F15 in time for the Beta release. I have now done offical builds of a slightly tidied up version of the above build for rawhide and Fedora 15 which are available at http://koji.fedoraproject.org/koji/packageinfo?packageID=7 . Let me know if there are any problems. No issues with it yet. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Another 2.6.38-rc6 dom0 kernel
Here is another kernel (2.6.38-0.rc6.git6.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2874240 The crash when a domU shuts down seems to be fixed. I just had a chance to test this, along with the xen-4.1.0-0.1.rc6.fc14.x86_64 Xen packages. Two notable things have been fixed by the Xen folks: xl now plays nicely with the vif-route script (see /etc/xen/xl.conf). xl is less picky about where the -c argument to create goes. Both of these issues were previously discussed on this list and the xen-devel list. I'm still having trouble with power management, as noted at: http://lists.fedoraproject.org/pipermail/xen/2011-January/005328.html Other than that, my first impression of 2.6.38-0.rc6.git6.1.xendom0.fc15 is good. I was able to load a PV OpenWrt guest using the QEMU-based network backend. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Odd behavior from OpenSSL benchmark
I sent the following to xen-users, but thought I'd ask the Fedora folks too. I am running the OpenSSL s_server/s_time benchmark between two DomUs. The two DomUs are running on separate machines, and they are the only unprivileged domain running on their machine. Both machines have dual core AMD processors, with Dom0 limited to one core using dom0_max_vcpus=1. I am using xen-4.0.1 and Xen kernel-2.6.32.26. When I run openssl s_time -connect 131.193.36.59:443 I see: No CIPHER specified Collecting connection statistics for 30 seconds tt This command makes SSL connections and prints 't' to indicate success. The t's are printed quickly at first but then they pause. After a pause, things continue again and repeat. It seems that s_time processes for approximately one second and then pauses for three seconds. The same thing happens when I run s_time in Dom0 but s_server in DomU (on the separate machines). When I run both s_server and s_time in Dom0 (on the separate machines), there are no pauses. Also, when I run s_time in DomU and s_server in Dom0 (on the separate machines) there are no pauses. Does anyone have any idea what could be going on? -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.38-rc4 dom0 kernel
I have a new kernel (2.6.38-0.rc4.git3.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2833991 . This uses the Konrad's devel/next-2.6.38 branch (from http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git ), as I have been having trouble which Jeremy's xen/next-2.6.38 branch. It has the revised xen-netback patches, so doesn't need the hack to /etc/sysconfig/modules/xen.modules that the previous kernel needed to avoid backtraces (indeed the hack stops xen-netback loading with this kernel as the netback_kthread parameter has been dropped). I just booted 2.6.38-0.rc4.git3.1.xendom0.fc15 on xen-4.1.0-0.1.rc4.fc14.x86_64. I end up with the xen_netback kernel module loaded: $ lsmod | grep net xen_netback24607 0 [permanent] I'm not sure if this is what you were refering to by indeed the hack stops xen-netback loading... It also seems that my DomU does not have its network facilities set up. I don't end up with a vifX.Y device on Dom0. This is different behavior than what was provided by Michael's previous kernel package. With the previous one, DomU would have network connectivity after booting, although eventually it would seem to break. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] rc3 kernel and xen
On Wed, Feb 02, 2011 at 10:43:18PM +, M A Young wrote: I have builds of a new dom0 kernel (2.6.38-0.rc3.git0.1.xendom0.fc15) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2755802 and xen (4.1.0-0.1.rc3.fc14) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2753907 Here is some feedback. Seems fixed: Red Hat bug #669484, Xen's network-route and vif-route scripts broken Rsync crash (sent a photograph of kernel panic, but didn't see it get to the list) Still broken: Xen bug #1733, vif-route does not support IPv6 Power management and halt, http://lists.fedoraproject.org/pipermail/xen/2011-January/005328.html -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.38-rc dom0 kernel and xen 4.1.0-rc2
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. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.38-rc dom0 kernel and xen 4.1.0-rc2
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 gree...@candelatech.com All bugs added by David S. Miller da...@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. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] 2.6.38-0.rc2.git3.2.xendom0.fc15 and power management
As reported earlier, I have been using 2.6.38-0.rc2.git3.2.xendom0.fc15 with good results. One thing I have come across is that power management does not seem to work. For example, pm-suspend does not suspend my system. Instead, the system merely becomes unresponsive. On the other hand, 2.6.32.26-174.2.xendom0 suspends fine. 2.6.38-0.rc2.git3.2.xendom0.fc15 also does not power down my system when I run shutdown. The last things that is printed to the console is: Halting system... [7962.081194] Power down. - The system halts but does not power down. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.38-rc dom0 kernel and xen 4.1.0-rc2
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 gree...@candelatech.com All bugs added by David S. Miller da...@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 -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Network-route and vif-route scripts broken?
This is something I raised on the upstream xen-devel mailing list. I have not yet received any response, so I though I'd try to ask here: I am using Xen with the included network-route and vif-route scripts. My system runs Fedora 14 with Michael Young's Dom0 kernel. When xend starts and network-route executes, I see the following error: /etc/xen/scripts/network-route: line 28: /proc/sys/net/ipv4/conf/eth/proxy_arp: No such file or directory It seems that the problem is that the vifnum shell variable is not set. Later, when I start an unprivileged domain, I see: physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Are these messages expected? I have submitted a report to the Red Hat Bugzilla system: https://bugzilla.redhat.com/show_bug.cgi?id=669747 The report includes two patches that fix this issue for me. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Re: Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4
This kernel works as expected with one exception. The exception has been a nagging problem, but I have not reported it because 1) we are using a research OS in DomU and 2) we are not clear if the problem is in our code, Linux or Xen. But, here are the symptoms: Occasionally (this seems to correlate to network activity between Dom0 and DomU), the system becomes unresponsive. I am running the Michael Young kernel at runlevel 3 within Dom0 (very little memory used by applications). Our OS runs in DomU and is constrained to 128MB of memory. When the system is unresponsive, typing a character into a Dom0 console take 2-5 seconds to appear on the screen. Likewise, other activity is extremely slow. As I mentioned, we have not been able to isolate where the problem is. Running, for example, an OpenWrt Linux build in DomU does not have this problem. I have seen something similar, though I don't know where the fault lies either. That is somewhat good to hear. I have today solved this problem by running xm vcpu-set Domain-0 1. By default, Xen assigned Dom0 all of my cores (two). Reducing this to one solves the problem for me. I am working on a better write up that I'll send to fedora-xen and possibly the upstream Xen mailing list. I have not decided if this is a bug and am having some discussions locally that may help me formulate a better inquiry. Usually it's better to use dom0_max_vcpus=1 on the grub xen.gz line. So, is this a known issue. Is it typically best practice to limit Dom0 to one core? I've seen systems where this is not a problem (dom0_max_vcpus=n works fine, where n is the number of cores) and others where it is. Why would this be? -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4
I have built what may be my last Fedora 12 kernel (2.6.32.26-174.2.xendom0.fc12) as Fedora 12 EOLs today (this is the same Fedora patch level as the official 2.6.32.26-175.fc12 kernel which has just been released). It is available at http://koji.fedoraproject.org/koji/taskinfo?taskID=2637740 and the repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ and includes a crash on exit fix. I haven't decided whether I am going to build any more 2.6.32.x kernels, I am going to continue building 2.6.37 kernels but these aren't ready for full dom0 use yet. Moving forward and for the purposes of Fedora 15 development, can we get both patched 2.7.37/38 kernels that support DomU and raw upstream kernels? Or does xen/next-2.6.27 not have the requisite features yet anyway? This kernel works as expected with one exception. The exception has been a nagging problem, but I have not reported it because 1) we are using a research OS in DomU and 2) we are not clear if the problem is in our code, Linux or Xen. But, here are the symptoms: Occasionally (this seems to correlate to network activity between Dom0 and DomU), the system becomes unresponsive. I am running the Michael Young kernel at runlevel 3 within Dom0 (very little memory used by applications). Our OS runs in DomU and is constrained to 128MB of memory. When the system is unresponsive, typing a character into a Dom0 console take 2-5 seconds to appear on the screen. Likewise, other activity is extremely slow. As I mentioned, we have not been able to isolate where the problem is. Running, for example, an OpenWrt Linux build in DomU does not have this problem. For those of you that are trying 2.6.37, I have built a vanilla 2.6.37-rc4 kernel (no additional xen patches) at http://koji.fedoraproject.org/koji/taskinfo?taskID=2635700 This kernel is the first from the 37/38 series that I have tested since I tested the initial upstream Xen accept. This seems to work within my expectations with two exceptions: 1. There are some warning related to nouveaufb. When I have time I will investigate a bit more, but 2.6.32 never really worked right for me with the nouveau drivers either. 2. On the positive side, it seems that the console back-end driver works. When I booted a DomU OS I received console messages. This surprised me. Soon after, Xen was unable to set up the networking for DomU, which is what I expected. Dom0 continued to operate fine even though loading an OS in DomU failed. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Xen Dom0 and Fedora 14
I have been investigating the use of Xen with a Fedora 14 (devel)-based Dom0. Until now, I have always used Michael Young's Dom0 kernels. The first thing I did was try to build the current Fedora 14 kernel with Xen Dom0 support. I began porting Michael's RPM specification to the Fedora 14 specification. What I found was that the Xen pvops work seems to be targeting 2.6.32 and possibly 2.6.36. As a result, I was unable to find a straightforward way to create a patch for 2.6.35.4. Am I missing something here? Is building a 2.6.35.4-based kernel difficult in this way? Next, I tried to use Michael's latest Fedora 12 kernel on Fedora 14. Of course, Fedora 14 uses some features that are not available in this kernel. Most notably, I had to provide the kernel with the init=/sbin/upstart option to avoid the use of systemd. Once I booted the system, I found that xend would not start because it did not find what it expected in /sys/bus/pci/devices/\:00\:03.2/config: [...] File /usr/lib/python2.7/site-packages/xen/util/pci.py, line 1050, in detect_dev_info pos = self.find_cap_offset(PCI_CAP_ID_EXP) File /usr/lib/python2.7/site-packages/xen/util/pci.py, line 933, in find_cap_offset id = ord(os.read(fd, 1)) TypeError: ord() expected a character, but string of length 0 found I fixed this by editing pci.py and changing: id = ord(os.read(fd, 1)) to: try: id = ord(os.read(fd, 1)) except: pos = 0 break; Of course, this might not be a good fix, but it was quick and it allowed me to continue and experiment. Does anyone know what is going on here? At this point, I was able to boot a DomU image, although I need to do a lot more testing. Has anyone else experimented with Fedora 14? What is your experience? I am especially interested in hearing about Fedora 14 Dom0 kernels. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] kernel-2.6.32.10-1.2.92.xendom0.fc12.x86_64 X broken on MacBook
I just tried kernel-2.6.32.10-1.2.92.xendom0.fc12.x86_64 from Mike Young's repository on my MacBook and found that the video driver does not seem to work. Lspci reports: 02:00.0 VGA compatible controller: nVidia Corporation GeForce 9400M (rev b1) What is the grub.conf entry? Have you passed nomodeset to the kernel module? I tried adding nomodeset, but that did not help by itself. I ended up doing the following: 1. Add nomodeset to kernel command line. 2. Create an xorg.conf that uses the VESA driver (X -configure, edit). 3. Deactivate dri2 and dri in xorg.conf. 4. Boot Xen Dom0 kernel into runlevel 3. 5. rmmod nouveau; init 5. I was able to simplify this a bit: 1. Add nomodeset to kernel command line. 2. Remove all xorg video drivers except the VESA driver. 3. Add blacklist nouveau to /etc/modprobe.d/blacklist-nouveau.conf. 4. Run dracut --force to rebuild initramfs with new blacklist entry. This avoids the requirement for a hard-coded xorg.conf. I previously had trouble keeping the nouveau module from loading. I had forgotten that it is necessary to rebuild an initramfs to ensure the system does not load blacklisted modules. -- Mike :wq -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
