Re: [CentOS-virt] c7 xen-4.6 crash.

2016-02-04 Thread President 
I wrote about this a couple months back.  George asked me to submit to the Xen 
developers list, but I never had the time due to work demands on getting the 
new server set up.  In my case, I had to use a different server.  The new 
motherboard/CPU had no issues with the second CPU.  If you turn off and unplug 
the second CPU, it will work.



Check the archives for my e-mail address and see George's replies.  If you can 
follow through with reporting it, that would be great.



--

Craig Thompson, President

Caldwell Global Communications, Inc.

+1 (423) 559-5465

caldwellglobal.com

-Original message-
From: Alvin Starr <al...@netvel.net>
Sent: Thursday 4th February 2016 9:30
To: Discussion about the virtualization on CentOS <centos-virt@centos.org>
Subject: [CentOS-virt] c7 xen-4.6 crash.

 
 
 Installing xen on a fairly clean c7.2 system.
 I get a xen kernel panic.
 
 (XEN) Bad console= option 'tty'
  Xen 4.6.0-9.el7
 (XEN) Xen version 4.6.0-9.el7 (mockbu...@centos.org) (gcc (GCC) 4.8.5 20150623 
(Red Hat 4.8.5-4)) debug=n Wed Jan 20 12:25:53 UTC 2016
 (XEN) Latest ChangeSet: Thu Jan 14 15:35:35 2016 + git:6e8597a-dirty
 (XEN) Bootloader: GRUB 2.02~beta2
 (XEN) Command line: placeholder dom0_mem=1024M,max:1024M cpuinfo 
com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
 (XEN) Video information:
 (XEN)  VGA is text mode 80x25, font 8x16
 (XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
 (XEN) Disc information:
 (XEN)  Found 1 MBR signatures
 (XEN)  Found 1 EDD information structures
 (XEN) Xen-e820 RAM map:
 (XEN)   - 0009ac00 (usable)
 (XEN)  0009ac00 - 000a (reserved)
 (XEN)  000e - 0010 (reserved)
 (XEN)  0010 - bffc7280 (usable)
 (XEN)  bffc7280 - bffceac0 (ACPI data)
 (XEN)  bffceac0 - c000 (reserved)
 (XEN)  e000 - f000 (reserved)
 (XEN)  fec0 - 0001 (reserved)
 (XEN)  0001 - 00084000 (usable)
 (XEN) ACPI: RSDP 000FDFD0, 0024 (r2 IBM   )
 (XEN) ACPI: XSDT BFFCE980, 0054 (r1 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) ACPI: FACP BFFCE8C0, 0084 (r2 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) ACPI: DSDT BFFC7280, 2F12 (r2 IBM    SERVALNT 1000 INTL 20041203)
 (XEN) ACPI: FACS BFFCA7C0, 0040
 (XEN) ACPI: APIC BFFCE800, 0084 (r1 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) ACPI: SRAT BFFCE6C0, 00E8 (r1 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) ACPI: HPET BFFCE680, 0038 (r1 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) ACPI: MCFG BFFCE640, 003C (r1 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) ACPI: ERST BFFCA800, 0230 (r1 IBM    SERVALNT 1000 IBM  45444F43)
 (XEN) System RAM: 32767MB (33553796kB)
 (XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
 (XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
 (XEN) SRAT: PXM 0 -> APIC 6 -> Node 0
 (XEN) SRAT: PXM 0 -> APIC 7 -> Node 0
 (XEN) SRAT: Node 0 PXM 0 0-c000
 (XEN) SRAT: Node 0 PXM 0 1-84000
 (XEN) SRAT: Node 0 PXM 0 84000-84100 (hotplug)
 (XEN) NUMA: Using 18 for the hash shift.
 (XEN) Domain heap initialised
 (XEN) found SMP MP-table at 0009ad40
 (XEN) DMI 2.4 present.
 (XEN) Using APIC driver default
 (XEN) ACPI: PM-Timer IO Port: 0x588
 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:584,1:0], pm1x_evt[1:580,1:0]
 (XEN) ACPI: wakeup_vec[bffca7cc], vec_size[20]
 (XEN) ACPI: Local APIC address 0xfee0
 (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
 (XEN) Processor #0 6:15 APIC version 20
 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
 (XEN) Processor #1 6:15 APIC version 20
 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] enabled)
 (XEN) Processor #6 6:15 APIC version 20
 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
 (XEN) Processor #7 6:15 APIC version 20
 (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
 (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
 (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
 (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
 (XEN) ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0])
 (XEN) IOAPIC[0]: apic_id 14, version 32, address 0xfec0, GSI 0-23
 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
 (XEN) ACPI: IRQ0 used by override.
 (XEN) ACPI: IRQ2 used by override.
 (XEN) ACPI: IRQ9 used by override.
 (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
 (XEN) ACPI: HPET id: 0x8086a201 base: 0xfed0
 (XEN) Invalid bit width in GAR
 (XEN) Using ACPI (MADT) for SMP configuration information
 (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs)
 (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
 (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
 (XEN) CPU: L2 cache: 4096K
 (XEN) CPU: Physical Processor ID: 0
 (XEN) CPU: Processor Core ID: 0
 (XEN) CMCI: CPU0 has no CMCI support
 (XEN) CPU0: Thermal monitoring enab

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

2016-01-21 Thread President 
My .02 is to stay the course.  As a server admin, I want to be able to type 
things like:



yum upgrade php

not

yum upgrade php55-epel-rpmforge-fancy-package



Having to remember all the idiosyncrasies of a system is what causes some type 
of major failure in the future whenever (1) you forget something or (2) someone 
else has to pick up the box to adminster.





--

Craig Thompson, President

Caldwell Global Communications, Inc.

+1 (423) 559-5465

caldwellglobal.com



-Original message-
From: George Dunlap <dunl...@umich.edu>
Sent: Thursday 21st January 2016 7:32
To: Discussion about the virtualization on CentOS <centos-virt@centos.org>
Subject: Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in 
centos-virt-xen-testing


On Thu, Jan 21, 2016 at 12:01 PM, Peter <pe...@pajamian.dhs.org> wrote:
> On 15/01/16 05:57, George Dunlap wrote:
>> As mentioned yesterday, Xen 4.6 packages are now available for
>> testing.  These also include an update to libvirt 1.3.0, in line with
>> what's available for CentOS 7.  Please test, particularly the upgrade
>> if you can, and report any problems here.
>
> Per conversation in IRC, Xen 4.6 no longer includes xend and therefore
> no longer has the "xm" command.  This is problematic for people who may
> be using xm in various scripts on their host (such as home-brewed backup
> scripts).
>
> I think it's a bad idea to break this functionality without warning by
> allowing a simple "yum update" to remove it.  You will take a lot of
> people by surprise and cause such scripts to stop working, if people are
> running yum cron the situation becomes even worse.

Thanks, PJ, for your input.

Just to be clear:

1. In the Xen 4.4 packages (first released October 2014), xend was
disabled by default; so anyone using xend at the moment has already
manually intervened to enable deprecated functionality

2. In 4.4, the first time xm was executed, it printed this warning:
---
xend is deprecated and scheduled for removal. Please migrate to another
toolstack ASAP.

See http://wiki.xen.org/wiki/Choice_of_Toolstacks for information on
other alternatives, including xl which is designed to be a drop in
replacement for xm (http://wiki.xen.org/wiki/XL).
---

3. ...and on every subsequent invocation, it printed this warning:
"WARNING: xend/xm is deprecated"

I think this constitutes "warning" that the functionality was going to
break at some point. :-)

Also, in most cases "s/xm/xl/g;" Just Works; most people have reported
that changing from xm -> xl was pretty painless.  So this isn't like
upgrading from Python 2 to Python 3 (or QT 4 to 5, or...).

> I think that due to this lack of backwards compatibility with Xen 4.4
> and earlier versions it would be a good idea to not force the upgrade on
> people who are not wary of it.  I propose that the new packages carry
> the name "xen46" and they purposefully conflict with the old "xen"
> packages.  That will require people to take positive action to do the
> upgrade and hence avoid breaking systems unintentionally.

This would avoid breaking things for people still using xm, which
certainly has some value.  However it has some costs:

* The packages between C6 and C7 will now be slightly different,
increasing the maintenance burden.  This is not only in the spec file,
but also in all the associated scripting machinery for managing
packages in the CBS and smoke-testing packages before pushing them
publicly.

* Instructions for installing Xen are now differend between C6 and C7,
and slightly more complicated, as they have to explain about Xen 4.6
vs alternatives.

* Users who have heeded the warning and switched to xl will have to
make an extra effort to switch to Xen 4.6.  If they don't follow
centos-virt, they may not notice that there's a new package to upgrade
to.

I'm a developer, not a server admin, so I can't gauge how important
this issue is.  Before making such a change, I'd like to hear opinions
from other people in the community about how important (or not) it is
to avoid breaking xm, given the ample warning (>1 year) users have
had.

On the other hand, explicitly moving to a "xen${VER}" (both for C6 and
C7) would make it simpler for people to step up and maintain older
versions in parallel if anybody wanted to do so.

Thanks again, Peter, for bringing this up.

Peace,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] new install of Xen 4.6 hangs on Loading initial ramdisk

2015-12-08 Thread President 
Not sure if this actually made it to the list the first time.  



Here is the SERIAL output (bottom of message after your questions).  Googling 
the error indicates it's something people ran into a few years back but was 
supposedly fixed.  Any ideas?



I can verify that if I REMOVE the second CPU, it boots into Xen kernel no 
problem.  The CPU itself doesn't matter, as I can swap either CPU into the 
first slot, and it boots.  Only if there is a second CPU does it fail.



-Original message-
From: George Dunlap 
Sent: Monday 30th November 2015 6:00
To: Discussion about the virtualization on CentOS 
Subject: Re: [CentOS-virt] new install of Xen 4.6 hangs on Loading initial 
ramdisk



On Fri, Nov 27, 2015 at 11:18 PM, Craig Thompson  > wrote:
First post to this list.  I would appreciate some help on this issue.

As background, I installed CentOS 7 on a Dell server, and then ran the 
following commands:

yum update 
http://buildlogs.centos.org/centos/7/virt/x86_64/xen/centos-release-xen-7-11.el7.x86_64.rpm
 

 
yum --enablerepo=centos-virt-xen-testing update
yum --enablerepo=centos-virt-xen-testing install xen

Doing that, I was able to successfully install Xen, create a virtual machine 
with its own HVM setup, logical volume, etc. and boot it just fine.

I then tried to do the same on an IBM x3550 server I’m trying to install with 
CentOS 7.  The CentOS 7 install went just fine.  I can boot into the standard 
kernel and have a working machine.  But after running the commands above to 
install the Xen hypervisor, the machine hangs on boot for a few moments after 
displaying the lines below and then reboots in a loop over and over and over:

Loading Xen 4.6.0-2.el7 …
Loading Linux 3.18.21-16.el7.x86_64 …
Loading initial ramdisk …

It never gets beyond that.  If I choose the stock kernel (no Xen) from the Grub 
menu, it will continue to boot into that just fine.

My grub.cfg file has these entries of note:

 multiboot /xen-4.6.0-2.el7.gz placeholder  dom0_mem=1024M,max:1024M cpuinfo 
com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all ${xen_rm_opts}
        echo    'Loading Linux 3.18.21-16.el7.x86_64 ...'
        module  /vmlinuz-3.18.21-16.el7.x86_64 placeholder 
root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde ro crashkernel=auto debug 
irqpoll ipv6.disable=1 console=hvc0 earlyprintk=xen nomodeset
        echo    'Loading initial ramdisk ...'
        module  --nounzip   /initramfs-3.18.21-16.el7.x86_64.img


What I have tried:

1) adding debug into the vmlinuz line
2) disabling ipv6 in that line
3) adding root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde to the last line AFTER 
/initramfs ….

Nothing so far has made any difference.  Obviously the process works, as it 
works for me just fine on the Dell server.

Underlying this machine is a SATA RAID 1 PCI card with two SSD drives attached 
in a RAID 1 mirror.  Not that that should matter, but I’m including it for 
reference. As noted previously, it boots into the stock kernel just fine.

Any help would be appreciated.

Thanks for the testing and the report.

Have you tried booting the Xen4CentOS kernel (Linux-3.18.21-16) by itself 
(i.e., not under Xen)?

Also, is there any chance you could get the output of a serial console?  That's 
pretty critical for debugging this sort of thing.
CentOS-virt mailing list


###  No such file or directory opening port
(XEN) Bad console= option 'tty'
 Xen 4.6.0-2.el7
(XEN) Xen version 4.6.0-2.el7 (mockbu...@centos.org) (gcc (GCC) 4.8.3 20140911 
(Red Hat 4.8.3-9)) debug=n Tue Nov  3 17:23:39 UTC 2015
(XEN) Latest ChangeSet: Mon Oct 19 12:05:21 2015 +0100 git:36b6fe9-dirty
(XEN) Bootloader: GRUB 2.02~beta2
(XEN) Command line: placeholder dom0_mem=1024M,max:1024M cpuinfo 
com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - bffcba40 (usable)
(XEN)  bffcba40 - bffcee00 (ACPI data)
(XEN)  bffcee00 - c000 (reserved)
(XEN)  fec0 - 0001 (reserved)
(XEN)  0001 - 0001fee0 (usable)
(XEN)  0001fee0 - 0001fef0 (reserved)
(XEN)  0001fef0 - 0002fee0 (usable)
(XEN)  0002fee0 - 0002fef0 (reserved)
(XEN)  0002fef0 - 0003fee0 (usable)
(XEN)  0003fee0 - 0003fef0 (reserved)
(XEN)  0003fef0 - 00084000 (usable)