Re: [Fedora-xen] Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4
My apologies for not closing the loop on this one. For the archives... On 02/10/2011 03:11 AM, Pasi Kärkkäinen wrote: On Thu, Feb 10, 2011 at 01:55:57AM -0500, Bill McGonigle wrote: Hi, folks, Has anybody had luck using phy: disks with this version? With*what* version?:) This was(is) 2.6.32 I'm trying to create a new OpenSolaris DomU (nexenta 3.0.4) with two phy: devices, and instead of the expected behavior I'm seeing two disks show up, one as 0GB and one as 64510.04GB. file: devices seem to work OK. Disks are declared like: 'phy:/dev/disk/by-id/scsi-SATA_ST31500341AS_9VS41HND,xvda,w', Did you try with /dev/sdX ? That shouldn't change the behaviour but you never know.. It turns out this was due to the inability of the 32-bit Solaris kernel to handle disks of modern size. Forcing the 64-bit Solaris kernel cleared up the issue. -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle -- 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
On Thu, Feb 10, 2011 at 01:55:57AM -0500, Bill McGonigle wrote: Hi, folks, Has anybody had luck using phy: disks with this version? With *what* version? :) I'm trying to create a new OpenSolaris DomU (nexenta 3.0.4) with two phy: devices, and instead of the expected behavior I'm seeing two disks show up, one as 0GB and one as 64510.04GB. file: devices seem to work OK. Disks are declared like: 'phy:/dev/disk/by-id/scsi-SATA_ST31500341AS_9VS41HND,xvda,w', Did you try with /dev/sdX ? That shouldn't change the behaviour but you never know.. -- Pasi Thanks, -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen -- 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
On Mon, Jan 03, 2011 at 12:05:33AM -0600, W. Michael Petullo wrote: 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? Some people want to dedicate cores for vms, so then it makes sense to also limit and pin dom0 vcpus to specific cores. It all depends on the workload. See: http://wiki.xensource.com/xenwiki/XenBestPractices -- Pasi -- 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
Re: [Fedora-xen] Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4
On Thu, Dec 02, 2010 at 09:17:41PM +, M A Young wrote: On Thu, 2 Dec 2010, W. Michael Petullo wrote: 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? xen/next-2.6.37 doesn't currently have kernel drivers for either block or network backends. Userspace block or network backends may be possible but I don't know how to get them to work, though it is supposed to be possible. Userspace qemu xen_blkback is included in current xen-unstable (4.1), afaik. -- Pasi 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. Michael Young -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
