virt

virt@lists.centos.org

2 participants
1612 discussions

c7 xen-4.6 crash.
by Alvin Starr 04 Feb '16

04 Feb '16

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 (mockbuild(a)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 +0000 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) 0000000000000000 - 000000000009ac00 (usable) (XEN) 000000000009ac00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000bffc7280 (usable) (XEN) 00000000bffc7280 - 00000000bffceac0 (ACPI data) (XEN) 00000000bffceac0 - 00000000c0000000 (reserved) (XEN) 00000000e0000000 - 00000000f0000000 (reserved) (XEN) 00000000fec00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000840000000 (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-c0000000 (XEN) SRAT: Node 0 PXM 0 100000000-840000000 (XEN) SRAT: Node 0 PXM 0 840000000-841000000 (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 0xfee00000 (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[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 14, version 32, address 0xfec00000, 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: 0xfed00000 (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 enabled (TM2) (XEN) Intel machine check reporting enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Initializing CPU#0 (XEN) Detected 2992.543 MHz processor. (XEN) Initing memory sharing. (XEN) alt table ffff82d0802b8c50 -> ffff82d0802b9ff4 (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 25 (XEN) PCI: MCFG area at e0000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-25 (XEN) I/O virtualisation disabled (XEN) CPU0: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz stepping 06 (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pde. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000 (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 enabled (TM2) (XEN) Intel machine check reporting enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Initializing CPU#0 (XEN) Detected 2992.579 MHz processor. (XEN) Initing memory sharing. (XEN) alt table ffff82d0802b8c50 -> ffff82d0802b9ff4 (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 25 (XEN) PCI: MCFG area at e0000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-25 (XEN) I/O virtualisation disabled (XEN) CPU0: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz stepping 06 (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 32 KiB. (XEN) mwait-idle: does not run on family 6 model 15 (XEN) VMX: Supported advanced features:ing 06 (XEN) CPU 2 APIC 6 -> Node 0 (XEN) Booting processor 2/6 eip 8a000 (XEN) Initializing CPU#2 (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K (XEN) CPU: L2 cache: 4096K (XEN) CPU: Physical Processor ID: 3 (XEN) CPU: Processor Core ID: 0 (XEN) CMCI: CPU2 has no CMCI support (XEN) CPU2: Thermal monitoring enabled (TM2) (XEN) CPU2: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz stepping 06 (XEN) ----[ Xen-4.6.0-9.el7 x86_64 debug=n Not tainted ]---- (XEN) CPU: 2 (XEN) RIP: e008:[<ffff82d080181c79>] set_cpu_sibling_map+0x39/0x340 (XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor (XEN) rax: 0000000000000020 rbx: 0000000000000200 rcx: 00000037a6cb1580 (XEN) rdx: 0000000000000003 rsi: 0000000000000000 rdi: 0000000000000002 (XEN) rbp: 00000000000000c8 rsp: ffff830826fb7e90 r8: 00000037a6cb1580 (XEN) r9: 00000037a6cb1580 r10: 0000000000000007 r11: 0000000000000001 (XEN) r12: 0000000000000002 r13: 0000000000000002 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000026e0 (XEN) cr3: 00000000bfc70000 cr2: 0000000000000020 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff830826fb7e90: (XEN) ffff82d0802f4380 0000000000000012 0000000000000000 00000100801ad2d1 (XEN) ffff82d0802f4380 0000000000000000 00000000000000c8 0000000000000002 (XEN) 0000000000000002 0000000000000000 0000000000000000 ffff82d08018213c (XEN) 0000000000000000 0000000000000001 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000002 ffff8300bffa5000 (XEN) 00000037a6cb1580 0000000000000000 (XEN) Xen call trace: (XEN) [<ffff82d080181c79>] set_cpu_sibling_map+0x39/0x340 (XEN) [<ffff82d08018213c>] start_secondary+0x1bc/0x260 (XEN) (XEN) Pagetable walk from 0000000000000020: (XEN) L4[0x000] = 000000083d21c063 ffffffffffffffff (XEN) L3[0x000] = 000000083d21b063 ffffffffffffffff (XEN) L2[0x000] = 000000083d21a063 ffffffffffffffff (XEN) L1[0x000] = 0000000000000000 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 2: (XEN) FATAL PAGE FAULT (XEN) [error_code=0002] (XEN) Faulting linear address: 0000000000000020 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin(a)netvel.net ||

1 0

virtio not installing correctly
by isdtor 02 Feb '16

02 Feb '16

I have converted a physical machine to kvm, following instructions on the proxmox wiki. So far so good. Now I'm attempting to convert the vm from ide to virtio following the instructions here, http://www.linux-kvm.org/page/Boot_from_virtio_block_device, with virtio-win-stable from Fedora. The guest is running Windows XP. When the new hardware wizard popped up finding the RedHat VirtIO SCSI controller, I pointed it to the viostor/xp directory on the iso. It appears as if all files have been copied, viostor.sys to C:\Windows\system32\DRIVERS, the green progress bar goes all the way to the right, but it's been sitting there over night with no further progress. There is a vioscsi directory on the iso, but it contains no drivers for XP. >From a previous attempt, I know that if I reboot the vm now and try to enter safe mode, it will hang after loading the agp driver. Host OS is CentOS 6.7.

3 7

When will CentOS 7.1 become available as an AWS AMI?
by Peter Weissbrod 02 Feb '16

02 Feb '16

I am in need of some AWS instances of this version. There are "community" instances of 7.1 but I would strongly prefer an official release from CentOS team over trusting my base image to an unknown publisher. Is there any plan/projection of when CentOS will publish 7.1 to the AWS marketplace?

2 2

How to build CentOS 7 AMI
by Alan Ivey 01 Feb '16

01 Feb '16

I'd like to revisit the thread about how the CentOS 7 AMIs are created ( https://lists.centos.org/pipermail/centos-devel/2015-July/013652.html) and see if the process can be published in the https://github.com/CentOS/sig-cloud-instance-build repository or another relevant location. With CentOS 7 AMIs only being available in the Marketplace, all resulting EC2 instances have the Marketplace codes attached to the EBS volumes. A significant restriction of this is that a resulting image cannot be the non-primary volume of an instance unless it is powered down. This presents itself to be a problem in at least the following scenarios: - Unable to attach a CentOS 7 boot volume to another instance for repair without either creating a temporary instance or shutting down an existing one. For example, if you messed up the /etc/sudoers file and logged out, and wanted to repair, you would not be able to repair by mounting to another instance and editing the file without incurring additional (albeit small) cost, or having an existing instance be temporarily unavailable. - The "amazon-chroot" Packer Builder ( https://www.packer.io/docs/builders/amazon-chroot.html) does not work because it starts by mounting a copy of the snapshot tied to the AMI as part of a scripted operation and therefore cannot power off to do so Custom AMIs, snapshots, copied EBS volumes, etc, all have the marketplace codes copied to them and inherit the restrictions. If an org was to use these features for automating environments and was disconnected from the original Marketplace agreement, they may be unaware of this limitation. I would also appreciate being able to have the additional transparency of seeing how an AWS AMI is created as the docker/openstack/etc images from the repository referenced above. This would be useful in environments with regulatory compliance concerns, such as AWS GovCloud, HIPAA, FedRAMP, etc. I understand the benefit that Marketplace registrations allow for the ability to notify users of any changes, and I am not necessarily advocating for switching away from the Marketplace as the primary AMI location. I would like to be provided the opportunity to build a private AMI in the exact same procedure as the official image so as to avert the restrictions provided by the Marketplace. Thank you, Alan

1 0

hoping to reschedule SIG meetings to Tuesdays 1500 UTC
by Lokesh Mandvekar 26 Jan '16

26 Jan '16

I can't make it to the current schedule for alternate Tuesday 1400 UTC meetings. I was hoping we could reschedule it to 1500 UTC on the same Tuesdays instead, or any other slot which could work for all. What do other members think? -- Lokesh Freenode: lsm5 GPG: 0xC7C3A0DD

3 3

LVM mirror database to ramdisk
by Ed Heron 24 Jan '16

24 Jan '16

I'm still running CentOS 5 with Xen. We recently replaced a virtual host system board with an Intel S1400FP4, so the host went from a 4 core Xeon with 32G RAM to a 6 core Xeon with 48G RAM, max 96G. The drives are SSD. I was recently asked to move an InterBase server from Windows 7 to Windows Server. The database is 30G. I'm speculating that if I put the database on a 35G virtual disk and mirror it to a 35G RAM disk, the speed of database access might improve. I use local LVM for my virtual disks with DRBD on top to mirror the disk to a backup server. If I change grub.conf to increase RAM disk size and increase host RAM, I could create a 35G RAM disk. I'd modify rc.local to add pvcreate /dev/ramdisk vgextend vg /dev/ramdisk lvconvert -m 1 --corelog vg/lv_database /dev/ramdisk Even with lv_database being 35G, it doesn't take long to activate the mirror. I haven't decided where to put the commands to turn off the lvm mirror. lvconvert -m 0 vg/lv_database vgreduce vg /dev/ramdisk pvremove /dev/ramdisk I haven't put this in real world use, yet. On it's face, this might speed up database access. Would we expect it to speed up database access in real world use? Should I document the process so others could know how to do this? I realize new documentation for CentOS 5 virtualization would be considered obsolete before I wrote it but I'm expecting to test CentOS 7 virtualization in the next few months and, when I am comfortable, I'd upgrade my 18 virtual hosts. I would update the documentation, at that time, as well.

3 10

Hostname inside lxc container
by C. L. Martinez 22 Jan '16

22 Jan '16

Hi all, I have installed a CentOS6 lxc guest under a Debian 8.x LXC host. All it is working ok but I can't change the hostname for the centos6 lxc container (it is using the same hostname from Debian host). I have modifyed HOSTNAME under /etc/sysconfig/network and /etc/hosts file, but it doesn't works. Do I need to change anything else?? Thanks.

3 3

DomU Guests not shutting down nicely when Dom0 Hypervisor shuts down
by Francis Greaves 21 Jan '16

21 Jan '16

I am using Xen 4.6.0-8.el7 on CentOS 7 with 3 Linux DomUs. I did have Xen 4.? on CentOS 6.5 on my previous system. I installed using yum install centos-release-xen. On shutting down the Hypervisor it used to wait for the DomUs to shut down gracefully (one can take a minute or more), then on starting up again it would restart the DomUs, all nice and controlled. For some reason the DomUs (CentOS or Ubuntu servers) are not shutting down nicely when the Hypervisor is shutdown, and not restarting. I have the cfg files in /etc/xen/auto so they should start up. If I forget to shut down the DomU guests then the shutdown hangs. I am running this on a Dell Poweredge T430 by the way. Any ideas why, and how to cure this?

3 3

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing
by President 21 Jan '16

21 Jan '16

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 <dunlapg(a)umich.edu> Sent: Thursday 21st January 2016 7:32 To: Discussion about the virtualization on CentOS <centos-virt(a)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 <peter(a)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(a)centos.org https://lists.centos.org/mailman/listinfo/centos-virt

5 11

Re: [CentOS-virt] DomU Guests not shutting down nicely when Dom0 Hypervisor shuts down
by Keith Roberts 21 Jan '16

21 Jan '16

Hi Francis. Personally I would gracefully shutdown all the VM’s first, before attempting to shutdown the xen hypervisor. Are you getting any fsck errors when restarting those VM’s? Kind Regards, Keith On 21 Jan 2016, at 08:48, Francis Greaves <francis(a)choughs.net> wrote: > I am using Xen 4.6.0-8.el7 on CentOS 7 with 3 Linux DomUs. I did have Xen 4.? on CentOS 6.5 on my previous system. I installed using yum install centos-release-xen. > On shutting down the Hypervisor it used to wait for the DomUs to shut down gracefully (one can take a minute or more), then on starting up again it would restart the DomUs, all nice and controlled. > For some reason the DomUs (CentOS or Ubuntu servers) are not shutting down nicely when the Hypervisor is shutdown, and not restarting. I have the cfg files in /etc/xen/auto so they should start up. > If I forget to shut down the DomU guests then the shutdown hangs. > I am running this on a Dell Poweredge T430 by the way. > Any ideas why, and how to cure this? > _______________________________________________ > CentOS-virt mailing list > CentOS-virt(a)centos.org > https://lists.centos.org/mailman/listinfo/centos-virt

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt