virt

virt@lists.centos.org

1608 discussions

Garbled screen after RAM Scrub on boot
by Francis Greaves 23 Feb '16

23 Feb '16

Dear All I am using Centos 7 with Xen 4.6 on a Dell Poweredge T430 When the machine boots, after the 'Scrubbing Free RAM' message, I get a screen filled with little white squares until the login prompt, so I cannot see what is happening as the machine boots. Also there is nothing on the screen when I reboot. My /etc/default/grub is GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_CMDLINE_LINUX="crashkernel=auto rhgb intremap=no_x2apic_optout" GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=13312M,max:14336M dom0_max_vcpus=6 dom0_vcpus_pin" GRUB_GFXMODE=1024x768 GRUB_GFXPAYLOAD_LINUX=keep GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen nomodeset" I have tried setting (for a 1024x768 resolution) vga=792 in the GRUB_CMDLINE_LINUX and commenting out GRUB_GFXMODE and GRUB_GFXPAYLOAD_LINUX, but this makes no difference What am I doing wrong? Regards Francis

5 8

Reminder: Virt SIG meeting today at 1500 UTC (note changed time)
by George Dunlap 23 Feb '16

23 Feb '16

Just a reminder, we'll be having the regular Virt SIG meeting today at the new time -- 1500 UTC. -George

1 0

Asking to join CentOS virt-sig for oVirt
by Rafael Martins 23 Feb '16

23 Feb '16

Hi all, I'm Rafael Martins, from oVirt integration team, and I'd like to join the CentOS virt-sig to help with oVirt packaging and maintenance. Please let me know if you have any questions. Thanks, Rafael Martins.

4 3

Kernel 3.18.21-17 and 3.18.21-18 kernel panics
by Shaun Reitan 22 Feb '16

22 Feb '16

I've seen this issue on about 15 different servers now. Anybody else seeing this? Screenshot: http://imgur.com/cBcwr8l I also have a video of the boot process if that will be helpful. -- Shaun Reitan

3 2

ssh access to vmware vm from outside
by Eric Tagtick 21 Feb '16

21 Feb '16

Hi, I have a centos 7 host server, which hosts vmware vms with various Os. I want to reach a ubuntu 14.04 vm through ssh and x2go (ssh as well). What I did. 1/ open a 2296 port in firewalld. 2/ add 2296=internalvmip:22 in tcp section of /etc/vmware/vmnet8/nat/nat.conf (vmnet8 being the vms network) >From the host server I can ssh the vm, but from outside, a ssh -p 2296 user@hostserverip gives me a connection refused. I tried a firewall-cmd --zone=external --add-forward-port=port=2296:proto=tcp:toport=22:toaddr=internalvmip but it does not change anything. What am I missing ?

1 0

Xen guests loose network
by Scot P. Floess 16 Feb '16

16 Feb '16

All, Just installed and got Xen working on CentOS 7 on my Dell Precision 470. I had been using Fedora 23 (with Xen) and saw what I'm now seeing with CentOS 7. For some odd reason the network just stops on the guests. I can "xl console vm" and start the network (ifup eth0 or service network restart) - but I can't figure out why it just stops. I'm not seeing anything odd in my /var/log/messages. Anything I can try or look at when this happens? Its happened to both a CentOS 7 guest and Fedora 23 guest... I did do an "ip addr" and sure enough there is no IP associated with eth0 until I bounce the network. I should probably do some more digging, but nothing obvious appears to be at issue. This is a home machine really, and its more annoying than pressing. Appreciate the help ahead of time! Scot P. Floess RHCT (Certificate Number 605010084735240) Chief Architect FlossWare http://sourceforge.net/projects/flossware http://flossware.sourceforge.net https://github.com/organizations/FlossWare

1 0

Proposal: Version-specific centos-release-xen-NN packages
by George Dunlap 15 Feb '16

15 Feb '16

Thank you for those who raised the issue of upgrading across potentially disruptive major versions (like the Xen 4.4 -> 4.6 update), and for everyone who weighed in. After discussing options with users here on this list (as well as in the IRC channel), further discussing things in the Virt SIG IRC meeting, and also raising the issue with other SIGs on the centos-devel list, here are my thoughts. (Skip down to the "Proposal" sections for the TLDR version.) = The issue = To summarize the issue: * Some users want to get whatever the latest supported version of Xen automatically via yum, without having to do anything but a "yum update". They want "yum update" to give them a new major version when one is available. We can call this group "auto-upgrade", because they expect a major version upgrade to happen automatically. * Other users want "yum update" to have fairly strong guarantees not to break their systems -- and thus want "yum update" *not* to give them a new major version, but want to have to manually do something specific (such as installing a different package) to get the updated version. Or at very least, they expect not to get a new major version that is expected to break things. We can call this group "manual-upgrade", because they want to manually upgrade major versions. * At the moment, the Virt SIG is only committed to making security updates to one version of Xen at a time * The 4.4 -> 4.6 update may be particularly disruptive for some users, since xend/xm will no longer be available. * Many users may not follow this mailing list, so may not know about the impending update * There are new XSAs coming out in 2 days (17 February). There are basically two "problems" to solve. The first thing to look at is what we would like things to look long-term, given that some users want auto-upgrade and some users want manual-upgrade. The second thing to look at is what to do in the current situation, given that we have users from both camps with the same set of packages installed, who may not read this mailing list. A couple of goals (some of which are on conflict): * We'd like to support both types of users * We want to minimize breakage for people who do don't follow this list, and do "yum update" without noticing the major upgrade that gets pushed out. * We want to minimize the security exposure for people who don't follow this list, and who don't notice that there haven't been any updates in response to XSAs. Additionally, we'd like if possible to be able to make it possible for anyone who wants to maintain older versions of Xen to do so in parallel with the newer versions. = Proposal: Long term = Going forward, this is what I propose we aim for: * Have separate repos for each version of Xen; at the present, this means xen-44 and xen-46. * Have version-specific centos-release-xen-NN pakcages which will always point to that version of the repo. So centos-release-xen-44 will point to xen-44, centos-release-xen-46 will point to xen-46. Users in the "manual-upgrade" camp can install one of these versions, knowing that a simple "yum update" will never move them across versions. When they're ready to upgrade, they can just install the newer version; yum will choose the newest version from all the repos available to it. * Have a generic centos-release-xen package which will always point to the most recent 'released' Virt SIG version of Xen. Users in the "auto-upgrade" camp can install this version, knowing that they'll always get the version with the latest security fixes. This will also make it simple for community members to step up and support older versions if they desire. = Discussion: Short term = For those who do not follow the list, we have to essentially choose one update policy for them. Will the current users expecting "manual-upgrade" have "auto-upgrade" imposed on them (potentially breaking on update)? Or will the current users expecting "auto-upgrade" have "manual-upgrade" imposed on them (potentially missing important security updates)? For someone to be negatively affected by the "manual-upgrade" choice, they only have to be running Xen in any configuration. For someone to be negatively affected by the "auto-upgrade" choice, they have to * still be running xend (in spite of having a warning printed on every xm command invocation for the last 18 months) * update their systems without checking / noticing the new major version Even then, they should have the option of downgrading with "yum downgrade"; there should only be major carnage if they automatically update large numbers of servers at once. When I brought this question up with the other SIGs, the general sentiment was that, as community-run projects, we do not have nearly the testing effort required to make it possible for users to simply run "yum update" without checking first. So on the whole, I think the aggregate risk is minimized if we go with the "auto-upgrade" option for those who don't specifically make a choice. = Proposal: Short term = * I'll try to get the new xen-NN repos, along with centos-release-xen-NN packages up and working tomorrow (Tuesday) * Wednesday I'll push updates for the 4.6 packages to the xen-46 repos. * centos-release-xen will point to the xen-44 repos for two weeks. During that time, those who want the XSA updates will have to install centos-release-xen-46. Those who don't want to update to 4.6 should install the centos-release-xen-44 package *and remove* the centos-release-xen package. * After those two weeks, centos-release-xen will switch to the xen-46 repos, giving the XSA updates to everyone who hasn't yet updated. I know this doesn't make everyone happy, but I've tried to make the best of a tricky situation. Thank you all for the input you've given. -George

1 0

Updated centos-release-xen packages (fixes missing initrd issue on upgrade)
by George Dunlap 14 Feb '16

14 Feb '16

I've pushed an update to the centos-release-xen package, centos-release-xen-7-12.el6, to centos-virt-xen-testing, which should fix the "missing initrd" issue people have been seeing. Please test and see if it fixes your issue (and that it makes no other issues). If everything works well, I'll get it pushed to centos-extras. Thanks, -George

2 1

xen-4.6.1-1 packages for C6 and C6 in centos-virt-xen-testing
by George Dunlap 11 Feb '16

11 Feb '16

Xen 4.6.1 packages are available in centos-virt-xen-testing; please test, I'll probably be pushing it to the mirrors sometime early next week (before the upcoming XSAs are due to go public). To use (assuming you've installed already): yum --enablerepo=centos-virt-xen-testing update Please report any bugs here. -George

1 0

Re: [CentOS-virt] c7 xen-4.6 crash.
by President 11 Feb '16

11 Feb '16

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 <alvin(a)netvel.net> Sent: Thursday 4th February 2016 9:30 To: Discussion about the virtualization on CentOS <centos-virt(a)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 (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 || _______________________________________________ CentOS-virt mailing list CentOS-virt(a)centos.org https://lists.centos.org/mailman/listinfo/centos-virt

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt