From xen-users-bounces@lists.xen.org Tue Apr 01 07:29:03 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 07:29:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUt6t-0002nJ-Iw; Tue, 01 Apr 2014 07:27:51 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUt6s-0002n9-2j for xen-users@lists.xen.org; Tue, 01 Apr 2014 07:27:50 +0000 Received: from [85.158.137.68:60891] by server-1.bemta-3.messagelabs.com id D9/1E-11134-47A6A335; Tue, 01 Apr 2014 07:27:48 +0000 X-Env-Sender: paul.angus@shapeblue.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1396337266!2924361!1 X-Originating-IP: [213.199.154.80] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_23, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11220 invoked from network); 1 Apr 2014 07:27:47 -0000 Received: from mail-db3lp0080.outbound.protection.outlook.com (HELO emea01-db3-obe.outbound.protection.outlook.com) (213.199.154.80) by server-2.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 1 Apr 2014 07:27:47 -0000 Received: from AMXPR07MB117.eurprd07.prod.outlook.com (10.242.70.142) by AMXPR07MB117.eurprd07.prod.outlook.com (10.242.70.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 1 Apr 2014 07:27:45 +0000 Received: from AMXPR07MB117.eurprd07.prod.outlook.com ([169.254.15.247]) by AMXPR07MB117.eurprd07.prod.outlook.com ([169.254.15.247]) with mapi id 15.00.0898.005; Tue, 1 Apr 2014 07:27:45 +0000 From: Paul Angus To: "xen-users@lists.xen.org" Thread-Topic: The results of your email commands Thread-Index: AQHPSnhvadukPzQsq0yxMgDRWQYvC5r8Yi8g Date: Tue, 1 Apr 2014 07:27:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.36.41.30] x-forefront-prvs: 016885DD9B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13734003)(53754006)(199002)(189002)(4396001)(33646001)(47976001)(20776003)(95666003)(74706001)(47736001)(50986001)(83072002)(54316002)(51856001)(79102001)(63696002)(95416001)(98676001)(49866001)(93516002)(54356001)(46102001)(93136001)(87266001)(85852003)(74876001)(19580395003)(31966008)(81342001)(81686001)(2656002)(59766001)(76576001)(92566001)(90146001)(81816001)(53806001)(87936001)(85306002)(65816001)(74316001)(83322001)(94946001)(56816005)(77982001)(15974865002)(15395725003)(74662001)(19580405001)(80022001)(94316002)(81542001)(97336001)(86362001)(69226001)(74502001)(76482001)(76786001)(47446002)(97186001)(74366001)(77096001)(66066001)(76796001)(56776001)(99396001)(80976001)(224973001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB117; H:AMXPR07MB117.eurprd07.prod.outlook.com; FPR:2CECF3DD.AF365C09.6DE01D4F.4AE36ABD.203DD; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: shapeblue.com does not designate permitted sender hosts) MIME-Version: 1.0 X-OriginatorOrg: shapeblue.com Subject: [Xen-users] FW: The results of your email commands X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi all, Has anyone seen this before? Mar 21 10:00:20 dc1fdtptgcx03 kernel: /local/domain/0/device/vif/0: Connected Mar 21 10:00:20 dc1fdtptgcx03 last message repeated 2 times Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "add vif" domid:0 devid:0 mode:bridge Mar 21 10:00:21 dc1fdtptgcx03 kernel: eth8 renamed to side-12556-eth8 by udevd [6579] Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "online vif" domid:0 devid:0 mode:bridge Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Setting vif0.0 MTU 1500 Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Adding vif0.0 to xapi5 with address fe:ff:ff:ff:ff:ff Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Failed to ip link set vif0.0 address fe:ff:ff:ff:ff:ff Mar 21 10:00:21 dc1fdtptgcx03 kernel: device vif0.0 entered promiscuous mode Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi5: port 7(vif0.0) entering forwarding state Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi42: port 1(bond3.3003) entering disabled state Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi34: port 1(bond3.3022) entering disabled state Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi17: port 1(bond3.3008) entering disabled state Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi33: port 1(bond3.3011) entering disabled state (repeated 40ish times on different interfaces) When it happens, network traffic stops on those ports, vms have to be migrated off, host restarted, then vms migrated back. Regards Paul Angus Senior Consultant / Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus paul.angus@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Support offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 training 18th-19th February 2014, Brazil. Classroom 17th-23rd March 2014, Region A. Instructor led, On-line 24th-28th March 2014, Region B. Instructor led, On-line 16th-20th June 2014, Region A. Instructor led, On-line 23rd-27th June 2014, Region B. Instructor led, On-line This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 07:29:03 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 07:29:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUt6t-0002nJ-Iw; Tue, 01 Apr 2014 07:27:51 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUt6s-0002n9-2j for xen-users@lists.xen.org; Tue, 01 Apr 2014 07:27:50 +0000 Received: from [85.158.137.68:60891] by server-1.bemta-3.messagelabs.com id D9/1E-11134-47A6A335; Tue, 01 Apr 2014 07:27:48 +0000 X-Env-Sender: paul.angus@shapeblue.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1396337266!2924361!1 X-Originating-IP: [213.199.154.80] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_23, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11220 invoked from network); 1 Apr 2014 07:27:47 -0000 Received: from mail-db3lp0080.outbound.protection.outlook.com (HELO emea01-db3-obe.outbound.protection.outlook.com) (213.199.154.80) by server-2.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 1 Apr 2014 07:27:47 -0000 Received: from AMXPR07MB117.eurprd07.prod.outlook.com (10.242.70.142) by AMXPR07MB117.eurprd07.prod.outlook.com (10.242.70.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 1 Apr 2014 07:27:45 +0000 Received: from AMXPR07MB117.eurprd07.prod.outlook.com ([169.254.15.247]) by AMXPR07MB117.eurprd07.prod.outlook.com ([169.254.15.247]) with mapi id 15.00.0898.005; Tue, 1 Apr 2014 07:27:45 +0000 From: Paul Angus To: "xen-users@lists.xen.org" Thread-Topic: The results of your email commands Thread-Index: AQHPSnhvadukPzQsq0yxMgDRWQYvC5r8Yi8g Date: Tue, 1 Apr 2014 07:27:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.36.41.30] x-forefront-prvs: 016885DD9B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13734003)(53754006)(199002)(189002)(4396001)(33646001)(47976001)(20776003)(95666003)(74706001)(47736001)(50986001)(83072002)(54316002)(51856001)(79102001)(63696002)(95416001)(98676001)(49866001)(93516002)(54356001)(46102001)(93136001)(87266001)(85852003)(74876001)(19580395003)(31966008)(81342001)(81686001)(2656002)(59766001)(76576001)(92566001)(90146001)(81816001)(53806001)(87936001)(85306002)(65816001)(74316001)(83322001)(94946001)(56816005)(77982001)(15974865002)(15395725003)(74662001)(19580405001)(80022001)(94316002)(81542001)(97336001)(86362001)(69226001)(74502001)(76482001)(76786001)(47446002)(97186001)(74366001)(77096001)(66066001)(76796001)(56776001)(99396001)(80976001)(224973001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB117; H:AMXPR07MB117.eurprd07.prod.outlook.com; FPR:2CECF3DD.AF365C09.6DE01D4F.4AE36ABD.203DD; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: shapeblue.com does not designate permitted sender hosts) MIME-Version: 1.0 X-OriginatorOrg: shapeblue.com Subject: [Xen-users] FW: The results of your email commands X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi all, Has anyone seen this before? Mar 21 10:00:20 dc1fdtptgcx03 kernel: /local/domain/0/device/vif/0: Connected Mar 21 10:00:20 dc1fdtptgcx03 last message repeated 2 times Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "add vif" domid:0 devid:0 mode:bridge Mar 21 10:00:21 dc1fdtptgcx03 kernel: eth8 renamed to side-12556-eth8 by udevd [6579] Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "online vif" domid:0 devid:0 mode:bridge Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Setting vif0.0 MTU 1500 Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Adding vif0.0 to xapi5 with address fe:ff:ff:ff:ff:ff Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Failed to ip link set vif0.0 address fe:ff:ff:ff:ff:ff Mar 21 10:00:21 dc1fdtptgcx03 kernel: device vif0.0 entered promiscuous mode Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi5: port 7(vif0.0) entering forwarding state Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi42: port 1(bond3.3003) entering disabled state Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi34: port 1(bond3.3022) entering disabled state Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi17: port 1(bond3.3008) entering disabled state Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi33: port 1(bond3.3011) entering disabled state (repeated 40ish times on different interfaces) When it happens, network traffic stops on those ports, vms have to be migrated off, host restarted, then vms migrated back. Regards Paul Angus Senior Consultant / Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus paul.angus@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Support offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 training 18th-19th February 2014, Brazil. Classroom 17th-23rd March 2014, Region A. Instructor led, On-line 24th-28th March 2014, Region B. Instructor led, On-line 16th-20th June 2014, Region A. Instructor led, On-line 23rd-27th June 2014, Region B. Instructor led, On-line This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 08:58:13 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 08:58:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUuV8-0005Wx-Ai; Tue, 01 Apr 2014 08:56:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUuV6-0005Wr-UM for xen-users@lists.xen.org; Tue, 01 Apr 2014 08:56:57 +0000 Received: from [193.109.254.147:46191] by server-11.bemta-14.messagelabs.com id 3F/F3-09902-85F7A335; Tue, 01 Apr 2014 08:56:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1396342614!5474114!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31553 invoked from network); 1 Apr 2014 08:56:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 08:56:55 -0000 X-IronPort-AV: E=Sophos;i="4.97,771,1389744000"; d="scan'208";a="116847995" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 01 Apr 2014 08:56:53 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL03.citrite.net (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 04:56:53 -0400 Message-ID: <1396342612.8667.41.camel@kazak.uk.xensource.com> From: Ian Campbell To: Paul Angus Date: Tue, 1 Apr 2014 09:56:52 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] FW: The results of your email commands X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 07:27 +0000, Paul Angus wrote: > Hi all, > > Has anyone seen this before? Hi Paul, >From the error messages it looks like you are using either XCP or XenServer. This list deals primarily with the toolstacks which ship with the upstream Xen release. XCP is now under the xenserver.org umbrella so whichever you are using you would be better off asking on one of the lists over at that project, or perhaps on the xen-api list (where xapi is developed). Ian. > Mar 21 10:00:20 dc1fdtptgcx03 kernel: /local/domain/0/device/vif/0: Connected > Mar 21 10:00:20 dc1fdtptgcx03 last message repeated 2 times > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "add vif" domid:0 devid:0 mode:bridge > Mar 21 10:00:21 dc1fdtptgcx03 kernel: eth8 renamed to side-12556-eth8 by udevd [6579] > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "online vif" domid:0 devid:0 mode:bridge > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Setting vif0.0 MTU 1500 > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Adding vif0.0 to xapi5 with address fe:ff:ff:ff:ff:ff > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Failed to ip link set vif0.0 address fe:ff:ff:ff:ff:ff > Mar 21 10:00:21 dc1fdtptgcx03 kernel: device vif0.0 entered promiscuous mode > Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi5: port 7(vif0.0) entering forwarding state > Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi42: port 1(bond3.3003) entering disabled state > Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi34: port 1(bond3.3022) entering disabled state > Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi17: port 1(bond3.3008) entering disabled state > Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi33: port 1(bond3.3011) entering disabled state > (repeated 40ish times on different interfaces) > > > When it happens, network traffic stops on those ports, vms have to be migrated off, host restarted, then vms migrated back. > > > > Regards > > Paul Angus > Senior Consultant / Cloud Architect > > S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus > paul.angus@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS > > > Need Enterprise Grade Support for Apache CloudStack? > Our CloudStack Infrastructure Support offers the best 24/7 SLA for CloudStack Environments. > > Apache CloudStack Bootcamp training courses > > **NEW!** CloudStack 4.2.1 training > 18th-19th February 2014, Brazil. Classroom > 17th-23rd March 2014, Region A. Instructor led, On-line > 24th-28th March 2014, Region B. Instructor led, On-line > 16th-20th June 2014, Region A. Instructor led, On-line > 23rd-27th June 2014, Region B. Instructor led, On-line > > This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 08:58:13 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 08:58:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUuV8-0005Wx-Ai; Tue, 01 Apr 2014 08:56:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUuV6-0005Wr-UM for xen-users@lists.xen.org; Tue, 01 Apr 2014 08:56:57 +0000 Received: from [193.109.254.147:46191] by server-11.bemta-14.messagelabs.com id 3F/F3-09902-85F7A335; Tue, 01 Apr 2014 08:56:56 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1396342614!5474114!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31553 invoked from network); 1 Apr 2014 08:56:55 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 08:56:55 -0000 X-IronPort-AV: E=Sophos;i="4.97,771,1389744000"; d="scan'208";a="116847995" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 01 Apr 2014 08:56:53 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL03.citrite.net (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 04:56:53 -0400 Message-ID: <1396342612.8667.41.camel@kazak.uk.xensource.com> From: Ian Campbell To: Paul Angus Date: Tue, 1 Apr 2014 09:56:52 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] FW: The results of your email commands X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 07:27 +0000, Paul Angus wrote: > Hi all, > > Has anyone seen this before? Hi Paul, >From the error messages it looks like you are using either XCP or XenServer. This list deals primarily with the toolstacks which ship with the upstream Xen release. XCP is now under the xenserver.org umbrella so whichever you are using you would be better off asking on one of the lists over at that project, or perhaps on the xen-api list (where xapi is developed). Ian. > Mar 21 10:00:20 dc1fdtptgcx03 kernel: /local/domain/0/device/vif/0: Connected > Mar 21 10:00:20 dc1fdtptgcx03 last message repeated 2 times > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "add vif" domid:0 devid:0 mode:bridge > Mar 21 10:00:21 dc1fdtptgcx03 kernel: eth8 renamed to side-12556-eth8 by udevd [6579] > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Called as "online vif" domid:0 devid:0 mode:bridge > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Setting vif0.0 MTU 1500 > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Adding vif0.0 to xapi5 with address fe:ff:ff:ff:ff:ff > Mar 21 10:00:21 dc1fdtptgcx03 scripts-vif: Failed to ip link set vif0.0 address fe:ff:ff:ff:ff:ff > Mar 21 10:00:21 dc1fdtptgcx03 kernel: device vif0.0 entered promiscuous mode > Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi5: port 7(vif0.0) entering forwarding state > Mar 21 10:00:21 dc1fdtptgcx03 kernel: xapi42: port 1(bond3.3003) entering disabled state > Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi34: port 1(bond3.3022) entering disabled state > Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi17: port 1(bond3.3008) entering disabled state > Mar 21 10:00:22 dc1fdtptgcx03 kernel: xapi33: port 1(bond3.3011) entering disabled state > (repeated 40ish times on different interfaces) > > > When it happens, network traffic stops on those ports, vms have to be migrated off, host restarted, then vms migrated back. > > > > Regards > > Paul Angus > Senior Consultant / Cloud Architect > > S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus > paul.angus@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS > > > Need Enterprise Grade Support for Apache CloudStack? > Our CloudStack Infrastructure Support offers the best 24/7 SLA for CloudStack Environments. > > Apache CloudStack Bootcamp training courses > > **NEW!** CloudStack 4.2.1 training > 18th-19th February 2014, Brazil. Classroom > 17th-23rd March 2014, Region A. Instructor led, On-line > 24th-28th March 2014, Region B. Instructor led, On-line > 16th-20th June 2014, Region A. Instructor led, On-line > 23rd-27th June 2014, Region B. Instructor led, On-line > > This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 09:04:30 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 09:04:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUucE-0005uc-Qg; Tue, 01 Apr 2014 09:04:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUucD-0005uW-7S for xen-users@lists.xen.org; Tue, 01 Apr 2014 09:04:17 +0000 Received: from [85.158.139.211:61096] by server-6.bemta-5.messagelabs.com id BA/94-19576-0118A335; Tue, 01 Apr 2014 09:04:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1396343054!4663494!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10419 invoked from network); 1 Apr 2014 09:04:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 09:04:15 -0000 X-IronPort-AV: E=Sophos;i="4.97,771,1389744000"; d="scan'208";a="116849695" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 01 Apr 2014 09:04:13 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 05:04:13 -0400 Message-ID: <1396343052.8667.45.camel@kazak.uk.xensource.com> From: Ian Campbell To: Saurabh Mishra Date: Tue, 1 Apr 2014 10:04:12 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote: > We are using Xen 4.2.4 > lc-1:~ # xl list > Name ID Mem VCPUs State Time(s) > Domain-0 0 8151 4 r----- 1681.3 > pvm-01-1 1 8187 4 -b---- 256.4 > pool1-slot1 2 98299 32 -b---- 81.6 Here you have 2 ~8GB guest domains and one ~96GB domain, which is a total of 112GB. On your 132GB host that leaves 36GB spare, which is probably why starting a 96GB guest fails (the error message could be clearer, you might have found an additional hint in "xl dmesg"). If the above is anomalous and you think there shou > > lc-1:~ # grep dom0 /boot/efi/efi/SuSE/xen.cfg > > options=crashkernel=256M@16M console=com1 com1=115200 dom0_mem=8192m > iommu=1,sharept extra_guest_irqs=80 dom0_max_vcpus=4 dom0_vcpus_pin > no-bootscrub > > > -------------xl create start Sat Mar 29 13:59:49 UTC > 2014-------------------- > > WARNING: ignoring "kernel" directive for HVM guest. Use > "firmware_override" instead if you really want a non-default firmware > > WARNING: ignoring device_model directive. > > WARNING: Use "device_model_override" instead if you really want a > non-default device_model > > libxl: debug: libxl_create.c:1192:do_domain_create: ao 0x625390: > create: how=(nil) callback=(nil) poller=0x624850 > > libxl: debug: libxl_device.c:245:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=unknown > > libxl: debug: libxl_device.c:191:disk_try_backend: Disk vdev=hda, > backend phy unsuitable as phys path not a block device > > libxl: debug: libxl_device.c:281:libxl__device_disk_set_backend: Disk > vdev=hda, using backend tap > > libxl: debug: libxl_create.c:694:initiate_domain_create: running > bootloader > > libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV > domain, skipping bootloader > > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x625920: deregister unregistered > > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9cc04 > > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19cc04 > > xc: info: VIRTUAL MEMORY ARRANGEMENT: > > Loader: 0000000000100000->000000000019cc04 > > Modules: 0000000000000000->0000000000000000 > > TOTAL: 0000000000000000->00000017ff800000 > > ENTRY ADDRESS: 0000000000100000 > > xc: detail: Failed allocation for dom 2: 2048 extents of order 0 > > xc: error: Could not allocate memory for HVM guest. (16 = Device or > resource busy): Internal error > > libxl: error: libxl_dom.c:656:libxl__build_hvm: hvm building failed > > libxl: error: libxl_create.c:919:domcreate_rebuild_done: cannot > (re-)build domain: -3 > > libxl: error: libxl_dm.c:1262:libxl__destroy_device_model: could not > find device-model's pid for dom 2 > > libxl: error: libxl.c:1419:libxl__destroy_domid: > libxl__destroy_device_model failed for 2 > > libxl: debug: libxl_event.c:1568:libxl__ao_complete: ao 0x625390: > complete, rc=-3 > > libxl: debug: libxl_create.c:1205:do_domain_create: ao 0x625390: > inprogress: poller=0x624850, flags=ic > > libxl: debug: libxl_event.c:1540:libxl__ao__destroy: ao 0x625390: > destroy > > xc: debug: hypercall buffer: total allocations:18274 total > releases:18274 > > xc: debug: hypercall buffer: current allocations:0 maximum > allocations:2 > > xc: debug: hypercall buffer: cache current size:2 > > xc: debug: hypercall buffer: cache hits:18263 misses:2 toobig:9 > > Parsing config from /root/vmmgr/hvmmgr/.hvmmgrd/vms/pool1-vm6.cfg > > -------------xl create end-------------------- > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 09:04:30 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 09:04:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUucE-0005uc-Qg; Tue, 01 Apr 2014 09:04:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUucD-0005uW-7S for xen-users@lists.xen.org; Tue, 01 Apr 2014 09:04:17 +0000 Received: from [85.158.139.211:61096] by server-6.bemta-5.messagelabs.com id BA/94-19576-0118A335; Tue, 01 Apr 2014 09:04:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1396343054!4663494!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10419 invoked from network); 1 Apr 2014 09:04:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 09:04:15 -0000 X-IronPort-AV: E=Sophos;i="4.97,771,1389744000"; d="scan'208";a="116849695" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 01 Apr 2014 09:04:13 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 05:04:13 -0400 Message-ID: <1396343052.8667.45.camel@kazak.uk.xensource.com> From: Ian Campbell To: Saurabh Mishra Date: Tue, 1 Apr 2014 10:04:12 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote: > We are using Xen 4.2.4 > lc-1:~ # xl list > Name ID Mem VCPUs State Time(s) > Domain-0 0 8151 4 r----- 1681.3 > pvm-01-1 1 8187 4 -b---- 256.4 > pool1-slot1 2 98299 32 -b---- 81.6 Here you have 2 ~8GB guest domains and one ~96GB domain, which is a total of 112GB. On your 132GB host that leaves 36GB spare, which is probably why starting a 96GB guest fails (the error message could be clearer, you might have found an additional hint in "xl dmesg"). If the above is anomalous and you think there shou > > lc-1:~ # grep dom0 /boot/efi/efi/SuSE/xen.cfg > > options=crashkernel=256M@16M console=com1 com1=115200 dom0_mem=8192m > iommu=1,sharept extra_guest_irqs=80 dom0_max_vcpus=4 dom0_vcpus_pin > no-bootscrub > > > -------------xl create start Sat Mar 29 13:59:49 UTC > 2014-------------------- > > WARNING: ignoring "kernel" directive for HVM guest. Use > "firmware_override" instead if you really want a non-default firmware > > WARNING: ignoring device_model directive. > > WARNING: Use "device_model_override" instead if you really want a > non-default device_model > > libxl: debug: libxl_create.c:1192:do_domain_create: ao 0x625390: > create: how=(nil) callback=(nil) poller=0x624850 > > libxl: debug: libxl_device.c:245:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=unknown > > libxl: debug: libxl_device.c:191:disk_try_backend: Disk vdev=hda, > backend phy unsuitable as phys path not a block device > > libxl: debug: libxl_device.c:281:libxl__device_disk_set_backend: Disk > vdev=hda, using backend tap > > libxl: debug: libxl_create.c:694:initiate_domain_create: running > bootloader > > libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV > domain, skipping bootloader > > libxl: debug: libxl_event.c:607:libxl__ev_xswatch_deregister: watch > w=0x625920: deregister unregistered > > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9cc04 > > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19cc04 > > xc: info: VIRTUAL MEMORY ARRANGEMENT: > > Loader: 0000000000100000->000000000019cc04 > > Modules: 0000000000000000->0000000000000000 > > TOTAL: 0000000000000000->00000017ff800000 > > ENTRY ADDRESS: 0000000000100000 > > xc: detail: Failed allocation for dom 2: 2048 extents of order 0 > > xc: error: Could not allocate memory for HVM guest. (16 = Device or > resource busy): Internal error > > libxl: error: libxl_dom.c:656:libxl__build_hvm: hvm building failed > > libxl: error: libxl_create.c:919:domcreate_rebuild_done: cannot > (re-)build domain: -3 > > libxl: error: libxl_dm.c:1262:libxl__destroy_device_model: could not > find device-model's pid for dom 2 > > libxl: error: libxl.c:1419:libxl__destroy_domid: > libxl__destroy_device_model failed for 2 > > libxl: debug: libxl_event.c:1568:libxl__ao_complete: ao 0x625390: > complete, rc=-3 > > libxl: debug: libxl_create.c:1205:do_domain_create: ao 0x625390: > inprogress: poller=0x624850, flags=ic > > libxl: debug: libxl_event.c:1540:libxl__ao__destroy: ao 0x625390: > destroy > > xc: debug: hypercall buffer: total allocations:18274 total > releases:18274 > > xc: debug: hypercall buffer: current allocations:0 maximum > allocations:2 > > xc: debug: hypercall buffer: cache current size:2 > > xc: debug: hypercall buffer: cache hits:18263 misses:2 toobig:9 > > Parsing config from /root/vmmgr/hvmmgr/.hvmmgrd/vms/pool1-vm6.cfg > > -------------xl create end-------------------- > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 09:07:33 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 09:07:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUufG-0006BM-5e; Tue, 01 Apr 2014 09:07:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUufF-0006B7-1e for xen-users@lists.xen.org; Tue, 01 Apr 2014 09:07:25 +0000 Received: from [193.109.254.147:62983] by server-12.bemta-14.messagelabs.com id 3A/CE-27473-CC18A335; Tue, 01 Apr 2014 09:07:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1396343241!5469291!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30282 invoked from network); 1 Apr 2014 09:07:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 09:07:23 -0000 X-IronPort-AV: E=Sophos;i="4.97,771,1389744000"; d="scan'208";a="115611085" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 01 Apr 2014 09:07:18 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL02.citrite.net (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 05:07:17 -0400 Message-ID: <1396343236.8667.47.camel@kazak.uk.xensource.com> From: Ian Campbell To: Saurabh Mishra Date: Tue, 1 Apr 2014 10:07:16 +0100 In-Reply-To: <1396343052.8667.45.camel@kazak.uk.xensource.com> References: <1396343052.8667.45.camel@kazak.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 10:04 +0100, Ian Campbell wrote: > On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote: > > > > We are using Xen 4.2.4 > > > > lc-1:~ # xl list > > Name ID Mem VCPUs State Time(s) > > Domain-0 0 8151 4 r----- 1681.3 > > pvm-01-1 1 8187 4 -b---- 256.4 > > pool1-slot1 2 98299 32 -b---- 81.6 > > Here you have 2 ~8GB guest domains and one ~96GB domain, which is a > total of 112GB. On your 132GB host that leaves 36GB spare, which is > probably why starting a 96GB guest fails (the error message could be > clearer, you might have found an additional hint in "xl dmesg"). > > If the above is anomalous and you think there shou Gah, I swear I didn't press send there but off it went. What I was going to say is that if you think there really is enough free RAM then please can you show us the output of "xl info" and "xl dmesg" as well as sharing your guest configuration file. You might also find updating to Xen 4.3.x or Xen 4.4 will help since xl was much improved in those releases. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 09:07:33 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 09:07:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUufG-0006BM-5e; Tue, 01 Apr 2014 09:07:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUufF-0006B7-1e for xen-users@lists.xen.org; Tue, 01 Apr 2014 09:07:25 +0000 Received: from [193.109.254.147:62983] by server-12.bemta-14.messagelabs.com id 3A/CE-27473-CC18A335; Tue, 01 Apr 2014 09:07:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1396343241!5469291!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30282 invoked from network); 1 Apr 2014 09:07:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 09:07:23 -0000 X-IronPort-AV: E=Sophos;i="4.97,771,1389744000"; d="scan'208";a="115611085" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 01 Apr 2014 09:07:18 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL02.citrite.net (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 05:07:17 -0400 Message-ID: <1396343236.8667.47.camel@kazak.uk.xensource.com> From: Ian Campbell To: Saurabh Mishra Date: Tue, 1 Apr 2014 10:07:16 +0100 In-Reply-To: <1396343052.8667.45.camel@kazak.uk.xensource.com> References: <1396343052.8667.45.camel@kazak.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 10:04 +0100, Ian Campbell wrote: > On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote: > > > > We are using Xen 4.2.4 > > > > lc-1:~ # xl list > > Name ID Mem VCPUs State Time(s) > > Domain-0 0 8151 4 r----- 1681.3 > > pvm-01-1 1 8187 4 -b---- 256.4 > > pool1-slot1 2 98299 32 -b---- 81.6 > > Here you have 2 ~8GB guest domains and one ~96GB domain, which is a > total of 112GB. On your 132GB host that leaves 36GB spare, which is > probably why starting a 96GB guest fails (the error message could be > clearer, you might have found an additional hint in "xl dmesg"). > > If the above is anomalous and you think there shou Gah, I swear I didn't press send there but off it went. What I was going to say is that if you think there really is enough free RAM then please can you show us the output of "xl info" and "xl dmesg" as well as sharing your guest configuration file. You might also find updating to Xen 4.3.x or Xen 4.4 will help since xl was much improved in those releases. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 11:53:38 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 11:53:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxFD-0007QV-S9; Tue, 01 Apr 2014 11:52:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUuVx-0005Yj-Em for xen-users@lists.xen.org; Tue, 01 Apr 2014 08:57:49 +0000 Received: from [85.158.139.211:58629] by server-14.bemta-5.messagelabs.com id 1F/98-15696-C8F7A335; Tue, 01 Apr 2014 08:57:48 +0000 X-Env-Sender: bowabos@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1396342667!4649580!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=1.3 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE,MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11460 invoked from network); 1 Apr 2014 08:57:47 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 08:57:47 -0000 Received: by mail-wi0-f182.google.com with SMTP id d1so4692364wiv.15 for ; Tue, 01 Apr 2014 01:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:user-agent:references :in-reply-to:mime-version:fcc:message-id:from:subject:date:to; bh=XRVMK3Xk0RZNOsT0yeXryNCBpNNa1KUaLpEknuQU16c=; b=Lb67uy5M8JVzPK552qxDyoqac6jZrvoN6zsvfxiqMDIFM8JE4BUrtdjD0wkoppBl0W a/LnynO2afJWhZM3OM9cLIVwueKZG2LZKpbwlqg1Y12YGe+Qzkq3dSMrrg/ajGjvEzGU AhvFN4k5xUmP0aqvxMppBeI9lUFsfZKl2BiuZ0al4oTjKZUQevWXlSzQZaUs2Ksnqdqp j0Qfr9rLLWt/51Bq3c8rzAjefHAYTtk/DRxPKEpeqe955eeT+V2o/HZ7/sFFeIq8MVB7 LZOQZfNBS7VyTPG7+Dub1JTgvWjIpeOKlaoGKySSRjorzS1pCdH++Jh8b6CmH/Vg0T6Q AGSw== X-Received: by 10.194.120.101 with SMTP id lb5mr2638871wjb.74.1396342667213; Tue, 01 Apr 2014 01:57:47 -0700 (PDT) Received: from [10.169.212.6] ([85.255.232.229]) by mx.google.com with ESMTPSA id u1sm16940207wjx.16.2014.04.01.01.57.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 01:57:46 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 References: <4F4F1D5B.1060200@gmail.com> In-Reply-To: <4F4F1D5B.1060200@gmail.com> Mime-Version: 1.0 X-Identity-Key: id2 Fcc: imap://bowabos%40gmail.com@imap.googlemail.com/[Gmail]/Sent Mail Message-Id: <084FF983-8FCF-4630-9E7F-B28D34671DC9@gmail.com> From: Alex Dubois X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 Date: Tue, 1 Apr 2014 09:47:17 +0100 To: "xen-users@lists.xen.org" X-Mailer: iPhone Mail (11D169) X-Mailman-Approved-At: Tue, 01 Apr 2014 11:52:42 +0000 Subject: Re: [Xen-users] MacBookPro 6,2 Xen support X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2468473042490013158==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2468473042490013158== Content-Type: multipart/alternative; boundary=Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725 Content-Transfer-Encoding: 7bit --Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 03/01/12 06:55, Alex Dubois wrote: > Hi,=20 >=20 > I am trying to run Qubes (a Xen based desktop OS) on my MacBookPro. Qubes c= urrently use Fedora13 for Dom0 and Fedora15 for domUs.=20 > I am new to Xen/Qubes but have experience as Linux user.=20 >=20 > I am having problems getting a number of devices to operate correctly. I a= m focussing first on the integrated NIC.=20 >=20 > This post is following some exchanges with the Qubes community on this thr= ead:=20 > https://groups.google.com/forum/#!topic/qubes-devel/gwk4JMSJ6Io=20 >=20 > This is the point at which we need your help :-)=20 >=20 > In the dom0 dmesg I have the following messages:=20 > >> pciback 0000:02:00.0: Driver tried to write to a read-only=20 > >> configuration space field at offset 0x68, size 4. This may be=20 > >> harmless, but if you have problems with your device:=20 > >> 1) see permissive attribute in sysfs=20 > >> 2) report problems to the xen-devel mailing list along with details of=20= > >> your device obtained from lspci.=20 >=20 > I found a way to report the quirks for the devices (which AFAIK set the pe= rmission for the domU drivers to read or write)...=20 > > Doing the cat on /sys/bus/pci/drivers/pciback/quirks returns about 30 li= nes:=20 > > 02:00.0=20 > > 14e4:1684:14e4:1684=20 > > 00000000:2:00000000=20 > > 00000002:2:00000000=20 > > 00000004:2:00000000=20 > > 0000003c:1:00000000=20 > > .../...=20 > > 0000004f:1:00000000=20 >=20 > I found some threads on how to play with this when using xend but Qubes is= not using xend to create the domU but libxl.=20 >=20 > Would you be able to help me in identifying how I would set the device in p= ermissive mode via libxl so I can validate that it is a device driver access= right issue to start with.=20 >=20 > It would also help me a lot to find info on how to set sysfs/quirks via li= bxl too so I can identify the exact memory/channel? which probably needs rea= d/write. I reply to myself if someone land on this thread as I have found an answer h= ere: http://technical.bestgrid.org/index.php/Xen:_assigning_PCI_devices_to_a_doma= in For the MacBookPro 6.2 with the version Xen I have I needed to add a line in= /etc/xen/xend-pci-quirks.sxp for my device (from lspci -n) '14e4:1684' # broadcom Tigon3 5764M >=20 > Regards,=20 > Alex --Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 03/01/12 06:55, Alex Dubois wrote:
Hi,

I am trying to run Qubes (a Xen based desktop OS) on my MacBookPro. Qubes currently use Fedora13 for Dom0 and Fedora15 for domUs.
I am new to Xen/Qubes but have experience as Linux user.

I am having problems getting a number of devices to operate correctly. I am focussing first on the integrated NIC.

This post is following some exchanges with the Qubes community on this thread:
https://groups.google.com/forum/#!topic/qubes-devel/gwk4JMSJ6Io

This is the point at which we need your help :-)

In the dom0 dmesg I have the following messages:
>> pciback 0000:02:00.0: Driver tried to write to a read-only
>> configuration space field at offset 0x68, size 4. This may be
>> harmless, but if you have problems with your device:
>> 1) see permissive attribute in sysfs
>> 2) report problems to the xen-devel mailing list along with details of
>> your device obtained from lspci.

I found a way to report the quirks for the devices (which AFAIK set the permission for the domU drivers to read or write)...
> Doing the cat on /sys/bus/pci/drivers/pciback/quirks returns about 30 lines:
> 02:00.0
>   14e4:1684:14e4:1684
>     00000000:2:00000000
>     00000002:2:00000000
>     00000004:2:00000000
>     0000003c:1:00000000
>     .../...
>     0000004f:1:00000000

I found some threads on how to play with this when using xend but Qubes is not using xend to create the domU but libxl.

Would you be able to help me in identifying how I would set the device in permissive mode via libxl so I can validate that it is a device driver access right issue to start with.

It would also help me a lot to find info on how to set sysfs/quirks via libxl too so I can identify the exact memory/channel? which probably needs read/write.
I reply to myself if someone land on this thread as I have found an answer here:
http://technical.bestgrid.org/index.php/Xen:_assigning_PCI_devices_to_a_domain

For the MacBookPro 6.2 with the version Xen I have I needed to add a line in
/etc/xen/xend-pci-quirks.sxp for my device (from lspci -n)
     '14e4:1684'    # broadcom Tigon3 5764M

Regards,
Alex


--Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725-- --===============2468473042490013158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2468473042490013158==-- From xen-users-bounces@lists.xen.org Tue Apr 01 11:53:38 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 11:53:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxFD-0007QV-S9; Tue, 01 Apr 2014 11:52:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUuVx-0005Yj-Em for xen-users@lists.xen.org; Tue, 01 Apr 2014 08:57:49 +0000 Received: from [85.158.139.211:58629] by server-14.bemta-5.messagelabs.com id 1F/98-15696-C8F7A335; Tue, 01 Apr 2014 08:57:48 +0000 X-Env-Sender: bowabos@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1396342667!4649580!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=1.3 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE,MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11460 invoked from network); 1 Apr 2014 08:57:47 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 08:57:47 -0000 Received: by mail-wi0-f182.google.com with SMTP id d1so4692364wiv.15 for ; Tue, 01 Apr 2014 01:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:user-agent:references :in-reply-to:mime-version:fcc:message-id:from:subject:date:to; bh=XRVMK3Xk0RZNOsT0yeXryNCBpNNa1KUaLpEknuQU16c=; b=Lb67uy5M8JVzPK552qxDyoqac6jZrvoN6zsvfxiqMDIFM8JE4BUrtdjD0wkoppBl0W a/LnynO2afJWhZM3OM9cLIVwueKZG2LZKpbwlqg1Y12YGe+Qzkq3dSMrrg/ajGjvEzGU AhvFN4k5xUmP0aqvxMppBeI9lUFsfZKl2BiuZ0al4oTjKZUQevWXlSzQZaUs2Ksnqdqp j0Qfr9rLLWt/51Bq3c8rzAjefHAYTtk/DRxPKEpeqe955eeT+V2o/HZ7/sFFeIq8MVB7 LZOQZfNBS7VyTPG7+Dub1JTgvWjIpeOKlaoGKySSRjorzS1pCdH++Jh8b6CmH/Vg0T6Q AGSw== X-Received: by 10.194.120.101 with SMTP id lb5mr2638871wjb.74.1396342667213; Tue, 01 Apr 2014 01:57:47 -0700 (PDT) Received: from [10.169.212.6] ([85.255.232.229]) by mx.google.com with ESMTPSA id u1sm16940207wjx.16.2014.04.01.01.57.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 01:57:46 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 References: <4F4F1D5B.1060200@gmail.com> In-Reply-To: <4F4F1D5B.1060200@gmail.com> Mime-Version: 1.0 X-Identity-Key: id2 Fcc: imap://bowabos%40gmail.com@imap.googlemail.com/[Gmail]/Sent Mail Message-Id: <084FF983-8FCF-4630-9E7F-B28D34671DC9@gmail.com> From: Alex Dubois X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 Date: Tue, 1 Apr 2014 09:47:17 +0100 To: "xen-users@lists.xen.org" X-Mailer: iPhone Mail (11D169) X-Mailman-Approved-At: Tue, 01 Apr 2014 11:52:42 +0000 Subject: Re: [Xen-users] MacBookPro 6,2 Xen support X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2468473042490013158==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2468473042490013158== Content-Type: multipart/alternative; boundary=Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725 Content-Transfer-Encoding: 7bit --Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 03/01/12 06:55, Alex Dubois wrote: > Hi,=20 >=20 > I am trying to run Qubes (a Xen based desktop OS) on my MacBookPro. Qubes c= urrently use Fedora13 for Dom0 and Fedora15 for domUs.=20 > I am new to Xen/Qubes but have experience as Linux user.=20 >=20 > I am having problems getting a number of devices to operate correctly. I a= m focussing first on the integrated NIC.=20 >=20 > This post is following some exchanges with the Qubes community on this thr= ead:=20 > https://groups.google.com/forum/#!topic/qubes-devel/gwk4JMSJ6Io=20 >=20 > This is the point at which we need your help :-)=20 >=20 > In the dom0 dmesg I have the following messages:=20 > >> pciback 0000:02:00.0: Driver tried to write to a read-only=20 > >> configuration space field at offset 0x68, size 4. This may be=20 > >> harmless, but if you have problems with your device:=20 > >> 1) see permissive attribute in sysfs=20 > >> 2) report problems to the xen-devel mailing list along with details of=20= > >> your device obtained from lspci.=20 >=20 > I found a way to report the quirks for the devices (which AFAIK set the pe= rmission for the domU drivers to read or write)...=20 > > Doing the cat on /sys/bus/pci/drivers/pciback/quirks returns about 30 li= nes:=20 > > 02:00.0=20 > > 14e4:1684:14e4:1684=20 > > 00000000:2:00000000=20 > > 00000002:2:00000000=20 > > 00000004:2:00000000=20 > > 0000003c:1:00000000=20 > > .../...=20 > > 0000004f:1:00000000=20 >=20 > I found some threads on how to play with this when using xend but Qubes is= not using xend to create the domU but libxl.=20 >=20 > Would you be able to help me in identifying how I would set the device in p= ermissive mode via libxl so I can validate that it is a device driver access= right issue to start with.=20 >=20 > It would also help me a lot to find info on how to set sysfs/quirks via li= bxl too so I can identify the exact memory/channel? which probably needs rea= d/write. I reply to myself if someone land on this thread as I have found an answer h= ere: http://technical.bestgrid.org/index.php/Xen:_assigning_PCI_devices_to_a_doma= in For the MacBookPro 6.2 with the version Xen I have I needed to add a line in= /etc/xen/xend-pci-quirks.sxp for my device (from lspci -n) '14e4:1684' # broadcom Tigon3 5764M >=20 > Regards,=20 > Alex --Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 03/01/12 06:55, Alex Dubois wrote:
Hi,

I am trying to run Qubes (a Xen based desktop OS) on my MacBookPro. Qubes currently use Fedora13 for Dom0 and Fedora15 for domUs.
I am new to Xen/Qubes but have experience as Linux user.

I am having problems getting a number of devices to operate correctly. I am focussing first on the integrated NIC.

This post is following some exchanges with the Qubes community on this thread:
https://groups.google.com/forum/#!topic/qubes-devel/gwk4JMSJ6Io

This is the point at which we need your help :-)

In the dom0 dmesg I have the following messages:
>> pciback 0000:02:00.0: Driver tried to write to a read-only
>> configuration space field at offset 0x68, size 4. This may be
>> harmless, but if you have problems with your device:
>> 1) see permissive attribute in sysfs
>> 2) report problems to the xen-devel mailing list along with details of
>> your device obtained from lspci.

I found a way to report the quirks for the devices (which AFAIK set the permission for the domU drivers to read or write)...
> Doing the cat on /sys/bus/pci/drivers/pciback/quirks returns about 30 lines:
> 02:00.0
>   14e4:1684:14e4:1684
>     00000000:2:00000000
>     00000002:2:00000000
>     00000004:2:00000000
>     0000003c:1:00000000
>     .../...
>     0000004f:1:00000000

I found some threads on how to play with this when using xend but Qubes is not using xend to create the domU but libxl.

Would you be able to help me in identifying how I would set the device in permissive mode via libxl so I can validate that it is a device driver access right issue to start with.

It would also help me a lot to find info on how to set sysfs/quirks via libxl too so I can identify the exact memory/channel? which probably needs read/write.
I reply to myself if someone land on this thread as I have found an answer here:
http://technical.bestgrid.org/index.php/Xen:_assigning_PCI_devices_to_a_domain

For the MacBookPro 6.2 with the version Xen I have I needed to add a line in
/etc/xen/xend-pci-quirks.sxp for my device (from lspci -n)
     '14e4:1684'    # broadcom Tigon3 5764M

Regards,
Alex


--Apple-Mail-D85945CA-868D-4253-9A32-74EB59646725-- --===============2468473042490013158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2468473042490013158==-- From xen-users-bounces@lists.xen.org Tue Apr 01 12:26:15 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 12:26:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxkZ-0002QH-Qw; Tue, 01 Apr 2014 12:25:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxkY-0002Q0-Jf for xen-users@lists.xen.org; Tue, 01 Apr 2014 12:25:06 +0000 Received: from [85.158.137.68:54767] by server-11.bemta-3.messagelabs.com id 59/66-19438-120BA335; Tue, 01 Apr 2014 12:25:05 +0000 X-Env-Sender: psilvao@gmail.com X-Msg-Ref: server-9.tower-31.messagelabs.com!1396355102!4257991!1 X-Originating-IP: [209.85.216.54] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4034 invoked from network); 1 Apr 2014 12:25:04 -0000 Received: from mail-qa0-f54.google.com (HELO mail-qa0-f54.google.com) (209.85.216.54) by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:25:04 -0000 Received: by mail-qa0-f54.google.com with SMTP id w8so9327786qac.41 for ; Tue, 01 Apr 2014 05:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sqnPwDzLH5gArg4ctueqhNkXtfvamN97kv7IDiuNnsQ=; b=Xqpm0AUjZuNpddEuMVWO8lTwKxOyjfdZG1zeyMGR2dgSXINPzW2NmJJ5lVMuT0P77T fqmEjxxxrvkAc3i8GyirqYTg/lhGHGETxxChxuocpJlHeQxpDmZW+zc8wuFZPaitzZ/b zAga7rU8dq01lnUmPlaqcF6D2fDLpEMq7rhk1mdwrf7W8Ff2RPSFmzccDC1HPaDxLzf2 aqlTZy/R4ie79+D8Mb5nA0fOblABNi4noBZmRfN38kKhIfnPc0N98ni2VtmgvakE7ntF TgLCPkp50OIe4GG0SXatF2qGfV2vG2WSZ0asHiaYZZaDwDoVNkWorZoOzaDADoc3Yagd 0Ugw== MIME-Version: 1.0 X-Received: by 10.224.164.199 with SMTP id f7mr9974707qay.83.1396355102380; Tue, 01 Apr 2014 05:25:02 -0700 (PDT) Received: by 10.96.85.167 with HTTP; Tue, 1 Apr 2014 05:25:02 -0700 (PDT) Date: Tue, 1 Apr 2014 08:25:02 -0400 Message-ID: From: Pablo Silva To: xen-users@lists.xen.org Subject: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1183780018991464145==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1183780018991464145== Content-Type: multipart/alternative; boundary=089e0149d2e6db97cd04f5fa4183 --089e0149d2e6db97cd04f5fa4183 Content-Type: text/plain; charset=ISO-8859-1 Dear Community: We're surfing the web trying to search any hint for to use gluster as localstorage with XenServer 6.1, without success. Our doubt is , we can use the xen command line as: xe sr-create name-label="GlusterTest" type=xxx content-type=yyyy ..... Thanks in advance for any hint. -Pablo --089e0149d2e6db97cd04f5fa4183 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Community:

=A0 =A0 =A0 = We're surfing the web trying to search any hint for to use gluster as l= ocalstorage with XenServer 6.1, without success.

= =A0 =A0 =A0 Our doubt is , we can use the xen command line as:

=A0 =A0 =A0 xe sr-create name-label=3D"GlusterTest= " type=3Dxxx content-type=3Dyyyy .....

=A0 = =A0 =A0Thanks in advance for any hint.

-Pablo
--089e0149d2e6db97cd04f5fa4183-- --===============1183780018991464145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1183780018991464145==-- From xen-users-bounces@lists.xen.org Tue Apr 01 12:26:15 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 12:26:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxkZ-0002QH-Qw; Tue, 01 Apr 2014 12:25:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxkY-0002Q0-Jf for xen-users@lists.xen.org; Tue, 01 Apr 2014 12:25:06 +0000 Received: from [85.158.137.68:54767] by server-11.bemta-3.messagelabs.com id 59/66-19438-120BA335; Tue, 01 Apr 2014 12:25:05 +0000 X-Env-Sender: psilvao@gmail.com X-Msg-Ref: server-9.tower-31.messagelabs.com!1396355102!4257991!1 X-Originating-IP: [209.85.216.54] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4034 invoked from network); 1 Apr 2014 12:25:04 -0000 Received: from mail-qa0-f54.google.com (HELO mail-qa0-f54.google.com) (209.85.216.54) by server-9.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:25:04 -0000 Received: by mail-qa0-f54.google.com with SMTP id w8so9327786qac.41 for ; Tue, 01 Apr 2014 05:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sqnPwDzLH5gArg4ctueqhNkXtfvamN97kv7IDiuNnsQ=; b=Xqpm0AUjZuNpddEuMVWO8lTwKxOyjfdZG1zeyMGR2dgSXINPzW2NmJJ5lVMuT0P77T fqmEjxxxrvkAc3i8GyirqYTg/lhGHGETxxChxuocpJlHeQxpDmZW+zc8wuFZPaitzZ/b zAga7rU8dq01lnUmPlaqcF6D2fDLpEMq7rhk1mdwrf7W8Ff2RPSFmzccDC1HPaDxLzf2 aqlTZy/R4ie79+D8Mb5nA0fOblABNi4noBZmRfN38kKhIfnPc0N98ni2VtmgvakE7ntF TgLCPkp50OIe4GG0SXatF2qGfV2vG2WSZ0asHiaYZZaDwDoVNkWorZoOzaDADoc3Yagd 0Ugw== MIME-Version: 1.0 X-Received: by 10.224.164.199 with SMTP id f7mr9974707qay.83.1396355102380; Tue, 01 Apr 2014 05:25:02 -0700 (PDT) Received: by 10.96.85.167 with HTTP; Tue, 1 Apr 2014 05:25:02 -0700 (PDT) Date: Tue, 1 Apr 2014 08:25:02 -0400 Message-ID: From: Pablo Silva To: xen-users@lists.xen.org Subject: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1183780018991464145==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1183780018991464145== Content-Type: multipart/alternative; boundary=089e0149d2e6db97cd04f5fa4183 --089e0149d2e6db97cd04f5fa4183 Content-Type: text/plain; charset=ISO-8859-1 Dear Community: We're surfing the web trying to search any hint for to use gluster as localstorage with XenServer 6.1, without success. Our doubt is , we can use the xen command line as: xe sr-create name-label="GlusterTest" type=xxx content-type=yyyy ..... Thanks in advance for any hint. -Pablo --089e0149d2e6db97cd04f5fa4183 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Community:

=A0 =A0 =A0 = We're surfing the web trying to search any hint for to use gluster as l= ocalstorage with XenServer 6.1, without success.

= =A0 =A0 =A0 Our doubt is , we can use the xen command line as:

=A0 =A0 =A0 xe sr-create name-label=3D"GlusterTest= " type=3Dxxx content-type=3Dyyyy .....

=A0 = =A0 =A0Thanks in advance for any hint.

-Pablo
--089e0149d2e6db97cd04f5fa4183-- --===============1183780018991464145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1183780018991464145==-- From xen-users-bounces@lists.xen.org Tue Apr 01 12:31:21 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 12:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxpu-0002zP-LL; Tue, 01 Apr 2014 12:30:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxpt-0002zG-NA for xen-users@lists.xen.org; Tue, 01 Apr 2014 12:30:37 +0000 Received: from [85.158.139.211:59009] by server-2.bemta-5.messagelabs.com id 68/B2-12074-C61BA335; Tue, 01 Apr 2014 12:30:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1396355434!4130985!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27020 invoked from network); 1 Apr 2014 12:30:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:30:35 -0000 X-IronPort-AV: E=Sophos;i="4.97,772,1389744000"; d="scan'208";a="115661551" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 01 Apr 2014 12:30:34 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 08:30:33 -0400 Message-ID: <1396355432.8667.148.camel@kazak.uk.xensource.com> From: Ian Campbell To: Pablo Silva Date: Tue, 1 Apr 2014 13:30:32 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 08:25 -0400, Pablo Silva wrote: > We're surfing the web trying to search any hint for to use > gluster as localstorage with XenServer 6.1, without success. This list deals primarily with the toolstacks which ship with the Xen Project releases. XenServer is a separate project, you will have more luck on the xenserver.org lists I think. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 12:31:21 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 12:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxpu-0002zP-LL; Tue, 01 Apr 2014 12:30:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxpt-0002zG-NA for xen-users@lists.xen.org; Tue, 01 Apr 2014 12:30:37 +0000 Received: from [85.158.139.211:59009] by server-2.bemta-5.messagelabs.com id 68/B2-12074-C61BA335; Tue, 01 Apr 2014 12:30:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1396355434!4130985!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27020 invoked from network); 1 Apr 2014 12:30:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:30:35 -0000 X-IronPort-AV: E=Sophos;i="4.97,772,1389744000"; d="scan'208";a="115661551" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 01 Apr 2014 12:30:34 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 1 Apr 2014 08:30:33 -0400 Message-ID: <1396355432.8667.148.camel@kazak.uk.xensource.com> From: Ian Campbell To: Pablo Silva Date: Tue, 1 Apr 2014 13:30:32 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 08:25 -0400, Pablo Silva wrote: > We're surfing the web trying to search any hint for to use > gluster as localstorage with XenServer 6.1, without success. This list deals primarily with the toolstacks which ship with the Xen Project releases. XenServer is a separate project, you will have more luck on the xenserver.org lists I think. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Apr 01 12:38:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 12:38:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxwq-0003ZE-KW; Tue, 01 Apr 2014 12:37:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxwp-0003Z4-0x for xen-users@lists.xen.org; Tue, 01 Apr 2014 12:37:47 +0000 Received: from [85.158.137.68:44900] by server-11.bemta-3.messagelabs.com id 61/2F-19438-A13BA335; Tue, 01 Apr 2014 12:37:46 +0000 X-Env-Sender: agwells0714@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1396355864!3017580!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9844 invoked from network); 1 Apr 2014 12:37:45 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:37:45 -0000 Received: by mail-vc0-f171.google.com with SMTP id lg15so9866669vcb.30 for ; Tue, 01 Apr 2014 05:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/r5c87d0WiTTgPcaP8pUQ3qLHJyy/Who4lwh4cJNpLw=; b=BOD4AFjwRA7UPPCXENoApdJ0OaL55fMRFnTDQrmMNIMbfkpZ54VntJmkhqcOEe1QwG a+7uQJiwMvzR0hx3VH5VFTQ9aedbwJwOo8/UJx6f3/9GFmFpNr7V3lqfPcfISUc9KMKD GTFdyMFs9U5/E5YTURQROMoIjAlRWtAC3EbYSk6RuqLbFzVY/SKpnfxaO6kDT9iDoV3a T2+nul28EJA/UozNq2nk2qY+ummBBkWw0guXWJGkLWfybCIbQZ/42ljd57gcOGfgX5+v 6bF2mkRnAwerrntEqmF4oK1eimuNSTUJcwX9HPI40VtJc35RyEn6HKz504cZzBDx2+3u zMwQ== X-Received: by 10.52.138.112 with SMTP id qp16mr608778vdb.40.1396355863679; Tue, 01 Apr 2014 05:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.53.3.164 with HTTP; Tue, 1 Apr 2014 05:37:23 -0700 (PDT) In-Reply-To: References: From: Andrew Wells Date: Tue, 1 Apr 2014 08:37:23 -0400 Message-ID: To: Pablo Silva Cc: xen-users Subject: Re: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3183939221185258757==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3183939221185258757== Content-Type: multipart/alternative; boundary=bcaec51b9b173c175c04f5fa6ff9 --bcaec51b9b173c175c04f5fa6ff9 Content-Type: text/plain; charset=ISO-8859-1 I am not entirely sure if I am qualified to answer this question. But glusterfs is a distributed file system. meaning that it is not suitable for local storage. You *might* be able to do something such as creating a distributed disc where the replication number is equal to the number of locations you are using in the gluster cluster. The other option, and more likely way to do this, is to look at the NFS connection for gluster, and connect to xenserver to gluster via the nfs interface. On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva wrote: > Dear Community: > > We're surfing the web trying to search any hint for to use gluster > as localstorage with XenServer 6.1, without success. > > Our doubt is , we can use the xen command line as: > > xe sr-create name-label="GlusterTest" type=xxx content-type=yyyy > ..... > > Thanks in advance for any hint. > > -Pablo > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --bcaec51b9b173c175c04f5fa6ff9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not entirely sure if I am qualified to answer this qu= estion. But glusterfs is a distributed file system. meaning that it is not = suitable for local storage.

You *might* be able to do so= mething such as creating a distributed disc where the replication number is= equal to the number of locations you are using in the gluster cluster.

The other option, and more likely way to do this, is to= look at the NFS connection for gluster, and connect to xenserver to gluste= r via the nfs interface.


On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva <psilvao@gmail.com> wrote:
Dear Community:

=A0 =A0 =A0 = We're surfing the web trying to search any hint for to use gluster as l= ocalstorage with XenServer 6.1, without success.

= =A0 =A0 =A0 Our doubt is , we can use the xen command line as:

=A0 =A0 =A0 xe sr-create name-label=3D"GlusterTest= " type=3Dxxx content-type=3Dyyyy .....

=A0 = =A0 =A0Thanks in advance for any hint.

-Pablo

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec51b9b173c175c04f5fa6ff9-- --===============3183939221185258757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3183939221185258757==-- From xen-users-bounces@lists.xen.org Tue Apr 01 12:38:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 12:38:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxwq-0003ZE-KW; Tue, 01 Apr 2014 12:37:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUxwp-0003Z4-0x for xen-users@lists.xen.org; Tue, 01 Apr 2014 12:37:47 +0000 Received: from [85.158.137.68:44900] by server-11.bemta-3.messagelabs.com id 61/2F-19438-A13BA335; Tue, 01 Apr 2014 12:37:46 +0000 X-Env-Sender: agwells0714@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1396355864!3017580!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9844 invoked from network); 1 Apr 2014 12:37:45 -0000 Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 12:37:45 -0000 Received: by mail-vc0-f171.google.com with SMTP id lg15so9866669vcb.30 for ; Tue, 01 Apr 2014 05:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/r5c87d0WiTTgPcaP8pUQ3qLHJyy/Who4lwh4cJNpLw=; b=BOD4AFjwRA7UPPCXENoApdJ0OaL55fMRFnTDQrmMNIMbfkpZ54VntJmkhqcOEe1QwG a+7uQJiwMvzR0hx3VH5VFTQ9aedbwJwOo8/UJx6f3/9GFmFpNr7V3lqfPcfISUc9KMKD GTFdyMFs9U5/E5YTURQROMoIjAlRWtAC3EbYSk6RuqLbFzVY/SKpnfxaO6kDT9iDoV3a T2+nul28EJA/UozNq2nk2qY+ummBBkWw0guXWJGkLWfybCIbQZ/42ljd57gcOGfgX5+v 6bF2mkRnAwerrntEqmF4oK1eimuNSTUJcwX9HPI40VtJc35RyEn6HKz504cZzBDx2+3u zMwQ== X-Received: by 10.52.138.112 with SMTP id qp16mr608778vdb.40.1396355863679; Tue, 01 Apr 2014 05:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.53.3.164 with HTTP; Tue, 1 Apr 2014 05:37:23 -0700 (PDT) In-Reply-To: References: From: Andrew Wells Date: Tue, 1 Apr 2014 08:37:23 -0400 Message-ID: To: Pablo Silva Cc: xen-users Subject: Re: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3183939221185258757==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3183939221185258757== Content-Type: multipart/alternative; boundary=bcaec51b9b173c175c04f5fa6ff9 --bcaec51b9b173c175c04f5fa6ff9 Content-Type: text/plain; charset=ISO-8859-1 I am not entirely sure if I am qualified to answer this question. But glusterfs is a distributed file system. meaning that it is not suitable for local storage. You *might* be able to do something such as creating a distributed disc where the replication number is equal to the number of locations you are using in the gluster cluster. The other option, and more likely way to do this, is to look at the NFS connection for gluster, and connect to xenserver to gluster via the nfs interface. On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva wrote: > Dear Community: > > We're surfing the web trying to search any hint for to use gluster > as localstorage with XenServer 6.1, without success. > > Our doubt is , we can use the xen command line as: > > xe sr-create name-label="GlusterTest" type=xxx content-type=yyyy > ..... > > Thanks in advance for any hint. > > -Pablo > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --bcaec51b9b173c175c04f5fa6ff9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not entirely sure if I am qualified to answer this qu= estion. But glusterfs is a distributed file system. meaning that it is not = suitable for local storage.

You *might* be able to do so= mething such as creating a distributed disc where the replication number is= equal to the number of locations you are using in the gluster cluster.

The other option, and more likely way to do this, is to= look at the NFS connection for gluster, and connect to xenserver to gluste= r via the nfs interface.


On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva <psilvao@gmail.com> wrote:
Dear Community:

=A0 =A0 =A0 = We're surfing the web trying to search any hint for to use gluster as l= ocalstorage with XenServer 6.1, without success.

= =A0 =A0 =A0 Our doubt is , we can use the xen command line as:

=A0 =A0 =A0 xe sr-create name-label=3D"GlusterTest= " type=3Dxxx content-type=3Dyyyy .....

=A0 = =A0 =A0Thanks in advance for any hint.

-Pablo

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec51b9b173c175c04f5fa6ff9-- --===============3183939221185258757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3183939221185258757==-- From xen-users-bounces@lists.xen.org Tue Apr 01 13:48:08 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 13:48:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUz2C-0000NI-AW; Tue, 01 Apr 2014 13:47:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUz2A-0000Mp-50 for xen-users@lists.xen.org; Tue, 01 Apr 2014 13:47:22 +0000 Received: from [193.109.254.147:2817] by server-2.bemta-14.messagelabs.com id 63/35-21684-963CA335; Tue, 01 Apr 2014 13:47:21 +0000 X-Env-Sender: psilvao@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1396360039!5553305!1 X-Originating-IP: [209.85.192.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14440 invoked from network); 1 Apr 2014 13:47:20 -0000 Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 13:47:20 -0000 Received: by mail-qg0-f43.google.com with SMTP id f51so9090354qge.30 for ; Tue, 01 Apr 2014 06:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bllhItkTbcd3V9VckwPrD3odxgVawvaYTBYiX7aeQSs=; b=ILn1dVFRXwBebmiB1l9qqlrTbWf93qFl/aBD6RkoNgvhPoxNUTrSjhvrMnQ1cPKGtx 50B+N7wmDmXSWjMczoivxxAuk/wEvJ2YxGRfFFO1nMunNMqzCrlLKxOBIqy+NdsJdYPX jMAe9PRn+DTMsyfhch5/TY5kQXPfZbzcMD6dIN+a5fDw/q+ivbrERynF1kMgJK16W7dd HqVdPe8dZddcIWQhFoXO+DfGMwsurMFw8BoOQprEITzH7G39dRXEXhfUvi/duy9+j+nM 2QJ/53D4XmFqQP6IOisyz93fPLWAbwbPEnWZoi3SB+Tx8wwLnQaXpxLsdxwVPko1ETKV +YKA== MIME-Version: 1.0 X-Received: by 10.140.81.112 with SMTP id e103mr2403405qgd.99.1396360039220; Tue, 01 Apr 2014 06:47:19 -0700 (PDT) Received: by 10.96.85.167 with HTTP; Tue, 1 Apr 2014 06:47:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 09:47:19 -0400 Message-ID: From: Pablo Silva To: Andrew Wells Cc: xen-users Subject: Re: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6346127205922024304==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6346127205922024304== Content-Type: multipart/alternative; boundary=001a11c12c3c1dd29804f5fb6844 --001a11c12c3c1dd29804f5fb6844 Content-Type: text/plain; charset=ISO-8859-1 Thanks andrew, and sorry if the question should not be here, but we won't use nfs, we want to use the fault tolerance of gluster as local storage. Today, if you use Xen Center there isn't thie option, perhaps in the future, but we believe that there must be a way to present gluster to xen server as local storage. Greetings Pablo On Tue, Apr 1, 2014 at 8:37 AM, Andrew Wells wrote: > I am not entirely sure if I am qualified to answer this question. But > glusterfs is a distributed file system. meaning that it is not suitable for > local storage. > > You *might* be able to do something such as creating a distributed disc > where the replication number is equal to the number of locations you are > using in the gluster cluster. > > The other option, and more likely way to do this, is to look at the NFS > connection for gluster, and connect to xenserver to gluster via the nfs > interface. > > > On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva wrote: > >> Dear Community: >> >> We're surfing the web trying to search any hint for to use gluster >> as localstorage with XenServer 6.1, without success. >> >> Our doubt is , we can use the xen command line as: >> >> xe sr-create name-label="GlusterTest" type=xxx content-type=yyyy >> ..... >> >> Thanks in advance for any hint. >> >> -Pablo >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > --001a11c12c3c1dd29804f5fb6844 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks andrew, and sorry if the question=A0=A0should not b= e here, but we won't use nfs, we want to use the fault tolerance of glu= ster as local storage.

Today, if you use =A0Xen Center t= here isn't thie option, perhaps in the future, but we believe that ther= e must be a way to present gluster to xen server as local storage.=A0

Greetings Pablo



On Tue, Apr 1, 2014 at 8:3= 7 AM, Andrew Wells <agwells0714@gmail.com> wrote:
I am not entirely sure if I= am qualified to answer this question. But glusterfs is a distributed file = system. meaning that it is not suitable for local storage.

You *might* be able to do something such as creating a distr= ibuted disc where the replication number is equal to the number of location= s you are using in the gluster cluster.

The other option, and more likely way to do this, is to= look at the NFS connection for gluster, and connect to xenserver to gluste= r via the nfs interface.


On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva <psilvao@gmail.com> wrote:
Dear Community:

=A0 =A0 =A0 = We're surfing the web trying to search any hint for to use gluster as l= ocalstorage with XenServer 6.1, without success.

= =A0 =A0 =A0 Our doubt is , we can use the xen command line as:

=A0 =A0 =A0 xe sr-create name-label=3D"GlusterTest= " type=3Dxxx content-type=3Dyyyy .....

=A0 = =A0 =A0Thanks in advance for any hint.
<= div>
-Pablo

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


--001a11c12c3c1dd29804f5fb6844-- --===============6346127205922024304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6346127205922024304==-- From xen-users-bounces@lists.xen.org Tue Apr 01 13:48:08 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 13:48:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUz2C-0000NI-AW; Tue, 01 Apr 2014 13:47:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WUz2A-0000Mp-50 for xen-users@lists.xen.org; Tue, 01 Apr 2014 13:47:22 +0000 Received: from [193.109.254.147:2817] by server-2.bemta-14.messagelabs.com id 63/35-21684-963CA335; Tue, 01 Apr 2014 13:47:21 +0000 X-Env-Sender: psilvao@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1396360039!5553305!1 X-Originating-IP: [209.85.192.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14440 invoked from network); 1 Apr 2014 13:47:20 -0000 Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 13:47:20 -0000 Received: by mail-qg0-f43.google.com with SMTP id f51so9090354qge.30 for ; Tue, 01 Apr 2014 06:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bllhItkTbcd3V9VckwPrD3odxgVawvaYTBYiX7aeQSs=; b=ILn1dVFRXwBebmiB1l9qqlrTbWf93qFl/aBD6RkoNgvhPoxNUTrSjhvrMnQ1cPKGtx 50B+N7wmDmXSWjMczoivxxAuk/wEvJ2YxGRfFFO1nMunNMqzCrlLKxOBIqy+NdsJdYPX jMAe9PRn+DTMsyfhch5/TY5kQXPfZbzcMD6dIN+a5fDw/q+ivbrERynF1kMgJK16W7dd HqVdPe8dZddcIWQhFoXO+DfGMwsurMFw8BoOQprEITzH7G39dRXEXhfUvi/duy9+j+nM 2QJ/53D4XmFqQP6IOisyz93fPLWAbwbPEnWZoi3SB+Tx8wwLnQaXpxLsdxwVPko1ETKV +YKA== MIME-Version: 1.0 X-Received: by 10.140.81.112 with SMTP id e103mr2403405qgd.99.1396360039220; Tue, 01 Apr 2014 06:47:19 -0700 (PDT) Received: by 10.96.85.167 with HTTP; Tue, 1 Apr 2014 06:47:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 09:47:19 -0400 Message-ID: From: Pablo Silva To: Andrew Wells Cc: xen-users Subject: Re: [Xen-users] Gluster as Localstorage in XenServer 6.1 ? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6346127205922024304==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6346127205922024304== Content-Type: multipart/alternative; boundary=001a11c12c3c1dd29804f5fb6844 --001a11c12c3c1dd29804f5fb6844 Content-Type: text/plain; charset=ISO-8859-1 Thanks andrew, and sorry if the question should not be here, but we won't use nfs, we want to use the fault tolerance of gluster as local storage. Today, if you use Xen Center there isn't thie option, perhaps in the future, but we believe that there must be a way to present gluster to xen server as local storage. Greetings Pablo On Tue, Apr 1, 2014 at 8:37 AM, Andrew Wells wrote: > I am not entirely sure if I am qualified to answer this question. But > glusterfs is a distributed file system. meaning that it is not suitable for > local storage. > > You *might* be able to do something such as creating a distributed disc > where the replication number is equal to the number of locations you are > using in the gluster cluster. > > The other option, and more likely way to do this, is to look at the NFS > connection for gluster, and connect to xenserver to gluster via the nfs > interface. > > > On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva wrote: > >> Dear Community: >> >> We're surfing the web trying to search any hint for to use gluster >> as localstorage with XenServer 6.1, without success. >> >> Our doubt is , we can use the xen command line as: >> >> xe sr-create name-label="GlusterTest" type=xxx content-type=yyyy >> ..... >> >> Thanks in advance for any hint. >> >> -Pablo >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > --001a11c12c3c1dd29804f5fb6844 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks andrew, and sorry if the question=A0=A0should not b= e here, but we won't use nfs, we want to use the fault tolerance of glu= ster as local storage.

Today, if you use =A0Xen Center t= here isn't thie option, perhaps in the future, but we believe that ther= e must be a way to present gluster to xen server as local storage.=A0

Greetings Pablo



On Tue, Apr 1, 2014 at 8:3= 7 AM, Andrew Wells <agwells0714@gmail.com> wrote:
I am not entirely sure if I= am qualified to answer this question. But glusterfs is a distributed file = system. meaning that it is not suitable for local storage.

You *might* be able to do something such as creating a distr= ibuted disc where the replication number is equal to the number of location= s you are using in the gluster cluster.

The other option, and more likely way to do this, is to= look at the NFS connection for gluster, and connect to xenserver to gluste= r via the nfs interface.


On Tue, Apr 1, 2014 at 8:25 AM, Pablo Silva <psilvao@gmail.com> wrote:
Dear Community:

=A0 =A0 =A0 = We're surfing the web trying to search any hint for to use gluster as l= ocalstorage with XenServer 6.1, without success.

= =A0 =A0 =A0 Our doubt is , we can use the xen command line as:

=A0 =A0 =A0 xe sr-create name-label=3D"GlusterTest= " type=3Dxxx content-type=3Dyyyy .....

=A0 = =A0 =A0Thanks in advance for any hint.
<= div>
-Pablo

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


--001a11c12c3c1dd29804f5fb6844-- --===============6346127205922024304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6346127205922024304==-- From xen-users-bounces@lists.xen.org Tue Apr 01 22:32:16 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 22:32:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WV7Cq-0008Ua-0s; Tue, 01 Apr 2014 22:30:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WV7Co-0008UV-0z for xen-users@lists.xen.org; Tue, 01 Apr 2014 22:30:54 +0000 Received: from [193.109.254.147:16834] by server-14.bemta-14.messagelabs.com id BC/C1-08195-D1E3B335; Tue, 01 Apr 2014 22:30:53 +0000 X-Env-Sender: saurabh.globe@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1396391449!5616715!1 X-Originating-IP: [209.85.220.48] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31188 invoked from network); 1 Apr 2014 22:30:51 -0000 Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 22:30:51 -0000 Received: by mail-pa0-f48.google.com with SMTP id hz1so10489890pad.7 for ; Tue, 01 Apr 2014 15:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H9Boz9QURNYSHrzTO7DmI74ea8qmHj13RIA9JOmbTLs=; b=bb/apF/ypvbyUMyfgfwHyqD4nPYCepQUmRdemFx2JSlLXjBq6smdp5iNROs05IlXU+ 1SrJK7fL/XFNt1ZpOJ4vyQtXI4dgeOBK669Cwf6aSFbSNjrK3WzALMjpZ8JmmvmS+or2 ZynUHBFoWisHyYQxBDp0is71HrM6iAu/rzEUx+5x7ySETkpAUCFmDPVyqZzTiOkO23Bf gY5HkjwIAmUPnPLEuImn69I+hW2p7A48zoqrrQQVDc560bkoEA8ABFo70orCKwocJPxE gvt6shauukun/tsQmTacv+t0T1xqGATLcHRd11Kk0cMb7KhKmi2XeHeKTCqZD6WHoBJ7 ttKQ== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr33786680pbc.5.1396391449383; Tue, 01 Apr 2014 15:30:49 -0700 (PDT) Received: by 10.68.254.10 with HTTP; Tue, 1 Apr 2014 15:30:49 -0700 (PDT) In-Reply-To: <1396343236.8667.47.camel@kazak.uk.xensource.com> References: <1396343052.8667.45.camel@kazak.uk.xensource.com> <1396343236.8667.47.camel@kazak.uk.xensource.com> Date: Tue, 1 Apr 2014 15:30:49 -0700 Message-ID: From: Saurabh Mishra To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3923452687650198881==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3923452687650198881== Content-Type: multipart/alternative; boundary=047d7b86d55c4ed79604f602b87e --047d7b86d55c4ed79604f602b87e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 1, 2014 at 2:07 AM, Ian Campbell wrote: > On Tue, 2014-04-01 at 10:04 +0100, Ian Campbell wrote: > > On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote: > > > > > > > We are using Xen 4.2.4 > > > > > > > lc-1:~ # xl list > > > Name ID Mem VCPUs State > Time(s) > > > Domain-0 0 8151 4 r----- > 1681.3 > > > pvm-01-1 1 8187 4 -b---- > 256.4 > > > pool1-slot1 2 98299 32 -b---- > 81.6 > > > > Here you have 2 ~8GB guest domains and one ~96GB domain, which is a > > total of 112GB. On your 132GB host that leaves 36GB spare, which is > > probably why starting a 96GB guest fails (the error message could be > > clearer, you might have found an additional hint in "xl dmesg"). > > > > If the above is anomalous and you think there shou > > Gah, I swear I didn't press send there but off it went. > > What I was going to say is that if you think there really is enough free > RAM then please can you show us the output of "xl info" and "xl dmesg" > as well as sharing your guest configuration file. > > You might also find updating to Xen 4.3.x or Xen 4.4 will help since xl > was much improved in those releases. > > Ian. > > > Here's xl info. I'm not seeing that failure anymore and hence don't have xl dmesg output right after the problem. Updating to higher Xen is not possible because SuSE 11 does not have them yet. lc-6:~ # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 8151 4 r----- 161.0 pvm-01-6 1 8187 4 -b---- 28.3 pool1-slot6 2 98299 32 -b---- 25.0 lc-6:~ # lc-6:~ # xl info host : lc-6 release : 3.0.101-0.15-xen version : #1 SMP Wed Jan 22 15:49:03 UTC 2014 (5c01f4e) machine : x86_64 nr_cpus : 40 max_cpu_id : 39 nr_nodes : 2 cores_per_socket : 10 threads_per_core : 2 cpu_mhz : 2400 hw_caps : bfebfbff:2c100800:00000000:00007f40:77bee3ff:00000000:00000001:00000281 virt_caps : hvm hvm_directio total_memory : 131059 free_memory : 13614 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .4_02-0.7.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : 26280 xen_commandline : crashkernel=256M@16M console=com1 com1=115200 dom0_mem=8192m iommu=1,sharept extra_guest_irqs=80 dom0_max_vcpus=4 dom0_vcpus_pin no-bootscrub cc_compiler : gcc-4.6 (SUSE Linux) 4.6.1 20110701 [gcc-4_6-branch revision 17 cc_compile_by : abuild cc_compile_domain : cc_compile_date : Thu Feb 27 18:05:27 UTC 2014 xend_config_format : 4 *name = "pool1-slot6"* boot = "c" memory = 98304 vcpus = 32 disk = [ 'file:/root/PSVs/mnt_local_ssd/local_ssd/avm-d0:f0:db:0b:48:00-pool1-slot6-disk1/avm-1-eBuilder_vm-vm_ssc_wkr-disk1,hda,w' ] vif = [ 'model=e1000, mac=06:00:02:00:00:00, bridge=br0', 'model=e1000, mac=06:00:03:00:00:00, bridge=br1' ] cpuid="host,page1gb=k" nomigrate=1 xen_platform_pci=0 pci = [ '0000:07:10.0@0a', '0000:07:10.2@0b', '0000:07:10.4@0c', '0000:07:10.6@0d', '0000:07:11.0@0e', '0000:07:11.2@0f', '0000:07:10.1@10', '0000:07:10.3@11', '0000:07:10.5@12', '0000:07:10.7@13', '0000:07:11.1@14', '0000:88:10.0@15', '0000:88:10.2@16', '0000:88:10.4@17', '0000:88:10.6@18', '0000:88:11.0@19', '0000:88:11.2@1a', '0000:88:10.1@1b', '0000:88:10.3@1c', '0000:88:10.5@1d', '0000:88:10.7@1e', '0000:88:11.1@1f' ] cpus = [ '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24', '25', '26', '27', '28', '29', '30', '31', '32', '33', '34', '35' ] kernel = "hvmloader" builder = "hvm" device_model = "qemu-dm" acpi = 1 serial = "pty" vnc = 1 vnclisten = "0.0.0.0" pci_msitranslate = 0 on_reboot = "destroy" *name = "pvm-01-6"* boot = "c" memory = 8192 vcpus = 4 disk = [ 'file:/root/PSVs/mnt_local_ssd/local_ssd/pvm-6/ssc_pvm_01.img,hda,w', ',hdc:cdrom,r' ] vif = [ 'model=e1000, mac=00:16:3e:00:05:00, bridge=br0', 'model=e1000, mac=00:16:3f:00:05:01, bridge=br1' ] nomigrate=1 xen_platform_pci=0 pci = [ '0000:08:00.0@0b', '0000:01:00.0@0c', '0000:07:11.6@1a', '0000:07:11.7@1b', '0000:88:11.6@1c', '0000:88:11.7@1d' ] cpus = [ '36', '37', '38', '39' ] kernel = "hvmloader" builder = "hvm" device_model = "qemu-dm" acpi = 1 serial = "pty" vnc = 1 vnclisten = "0.0.0.0" pci_msitranslate = 0 on_reboot = "destroy" Thanks, /Saurabh --047d7b86d55c4ed79604f602b87e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 1, 2014 at 2:07 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Tue, 2014-04-01 at 10:04 +0100, Ian Cam= pbell wrote:
> On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote:
>
>
> > We are using Xen 4.2.4
>
>
> > lc-1:~ # xl list
> > Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUs =A0 =A0 =A0State =A0 Time(s)
> > Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 0 =A08151 =A0 =A0 4 =A0 =A0 r----- =A0 =A01681.3
> > pvm-01-1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 1 =A08187 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 256.4
> > pool1-slot1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A02 98299 =A0 =A032 =A0 =A0 -b---- =A0 =A0 =A081.6
>
> Here you have 2 ~8GB guest domains and one ~96GB domain, which is a > total of 112GB. On your 132GB host that leaves 36GB spare, which is > probably why starting a 96GB guest fails (the error message could be > clearer, you might have found an additional hint in "xl dmesg&quo= t;).
>
> If the above is anomalous and you think there shou

Gah, I swear I didn't press send there but off it went.

What I was going to say is that if you think there really is enough free RAM then please can you show us the output of "xl info" and "= ;xl dmesg"
as well as sharing your guest configuration file.

You might also find updating to Xen 4.3.x or Xen 4.4 will help since xl
was much improved in those releases.

Ian.



Here&= #39;s xl info. I'm not seeing that failure anymore and hence don't = have xl dmesg output right after the problem. Updating to higher Xen is not= possible because SuSE 11 does not have them yet.

lc-6:~ # xl list
Name =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= ID =A0 Mem VCPUs =A0 =A0 =A0State =A0 Time(s)
Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A08151 =A0 =A0 4 =A0 =A0 r----- =A0 =A0 161.0
pvm-01-6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 1 =A08187 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 =A028.3
pool1-slot6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 98299 =A0 =A032 =A0 =A0 -b---- =A0 =A0 = =A025.0
lc-6:~ #=A0

=
lc-6:~ # xl inf= o
host =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : lc-6
=
release =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 3.0.101= -0.15-xen
version =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0: #1 SMP Wed Jan 22 15:49:03 UTC 2014 (5c01f4e)
machine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: x86_64
nr_cpus =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 40
max_cpu_id =A0 =A0 =A0 =A0 =A0 =A0 : 39
nr_nodes =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 2
cores_per_socket =A0 =A0 =A0 : 10
threads_per_core =A0 =A0 =A0 : 2
cpu_mhz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2400
hw_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: bfebfbff:2c100= 800:00000000:00007f40:77bee3ff:00000000:00000001:00000281
virt_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0: hvm hvm_d= irectio
total_memory =A0 =A0 =A0 =A0 =A0 : = 131059
free_memory =A0 =A0 =A0 =A0 =A0 =A0:= 13614
sharing_freed_memory =A0 : 0
sharing_used_memory =A0 =A0: 0
free_cpus =A0 =A0 =A0 =A0 =A0 =A0 =A0: 0
xen_major =A0 =A0 =A0 =A0 =A0 =A0 =A0: 4
xen_minor =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2
xen_extra =A0 =A0 =A0 =A0 =A0 =A0 =A0: .4_02-0.7= .1
xen_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 : x= en-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64= =A0
xen_scheduler =A0 =A0 =A0 =A0 =A0: credit
x= en_pagesize =A0 =A0 =A0 =A0 =A0 : 4096
plat= form_params =A0 =A0 =A0 =A0: virt_start=3D0xffff800000000000
xen_changeset =A0 =A0 =A0 =A0 =A0: 26280
xen_commandline =A0 =A0 =A0 =A0: crashkernel=3D2= 56M@16M console=3Dcom1 com1=3D115200 dom0_mem=3D8192m iommu=3D1,sharept ext= ra_guest_irqs=3D80 dom0_max_vcpus=3D4 dom0_vcpus_pin no-bootscrub
cc_compiler =A0 =A0 =A0 =A0 =A0 =A0: gcc-4.6 (SUSE Linux) 4.6.1 20110701 [g= cc-4_6-branch revision 17
cc_compile_by =A0= =A0 =A0 =A0 =A0: abuild
cc_compile_domain = =A0 =A0 =A0:=A0
cc_compile_date =A0 =A0 =A0 =A0: Thu Feb 27 18:05:27 UTC 2014
xend_config_format =A0 =A0 : 4

=

name =3D "pool1-slot6"<= /div>
boot =3D "c"
memory =3D 98304
vcpus =3D 32
disk =3D [ 'file= :/root/PSVs/mnt_local_ssd/local_ssd/avm-d0:f0:db:0b:48:00-pool1-slot6-disk1= /avm-1-eBuilder_vm-vm_ssc_wkr-disk1,hda,w' ]
vif =3D [ 'm= odel=3De1000, mac=3D06:00:02:00:00:00, bridge=3Dbr0', 'model=3De100= 0, mac=3D06:00:03:00:00:00, bridge=3Dbr1' ]
cpuid=3D"host,page1gb=3Dk"
nomigrate=3D1
xen_platform_pci=3D0
pci =3D [ =A0'0000:07:10.0@0a', = 9;0000:07:10.2@0b', '0000:07:10.4@0c', '0000:07:10.6@0d'= ;, '0000:07:11.0@0e', '0000:07:11.2@0f', '0000:07:10.1@= 10', '0000:07:10.3@11', '0000:07:10.5@12', '0000:07= :10.7@13', '0000:07:11.1@14', '0000:88:10.0@15', '0= 000:88:10.2@16', '0000:88:10.4@17', '0000:88:10.6@18', = '0000:88:11.0@19', '0000:88:11.2@1a', '0000:88:10.1@1b&= #39;, '0000:88:10.3@1c', '0000:88:10.5@1d', '0000:88:10= .7@1e', '0000:88:11.1@1f' ]
cpus =3D [ =A0'4', '5', '6', '7', '= ;8', '9', '10', '11', '12', '13'= ;, '14', '15', '16', '17', '18', &#= 39;19', '20', '21', '22', '23', '24= ', '25', '26', '27', '28', '29'= , '30', '31', '32', '33', '34', = 9;35' ]
kernel =3D "hvmloader"
builder =3D "hvm&q= uot;
device_model =3D "qemu-dm"
acpi =3D 1
serial =3D "pty"
vnc =3D 1
vnclisten =3D "0.0.0.0"
pci_msitranslate =3D 0
on_reboot =3D "destroy"=



vcpus =3D 4
disk =3D [ 'file:/root/PSVs/mnt_local_ssd/lo= cal_ssd/pvm-6/ssc_pvm_01.img,hda,w', ',hdc:cdrom,r' ]
vif =3D [ 'model=3De1000, mac=3D00:16:3e:00:05:00, bridge=3Dbr0', = 'model=3De1000, mac=3D00:16:3f:00:05:01, bridge=3Dbr1' ]
nomigrate=3D1
xen_platform_pci=3D0
pci =3D [ =A0&#= 39;0000:08:00.0@0b', '0000:01:00.0@0c', '0000:07:11.6@1a= 9;, '0000:07:11.7@1b', '0000:88:11.6@1c', '0000:88:11.7= @1d' ]
cpus =3D [ =A0'36', '37', '38', '39' ]=
kernel =3D "hvmloader"
builder =3D "= ;hvm"
device_model =3D "qemu-dm"
acpi = =3D 1
serial =3D "pty"
vnc =3D 1
vncli= sten =3D "0.0.0.0"
pci_msitranslate =3D 0
on_reboot =3D "destroy"


<= /div>

Thanks,
/Saurabh
--047d7b86d55c4ed79604f602b87e-- --===============3923452687650198881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3923452687650198881==-- From xen-users-bounces@lists.xen.org Tue Apr 01 22:32:16 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Apr 2014 22:32:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WV7Cq-0008Ua-0s; Tue, 01 Apr 2014 22:30:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WV7Co-0008UV-0z for xen-users@lists.xen.org; Tue, 01 Apr 2014 22:30:54 +0000 Received: from [193.109.254.147:16834] by server-14.bemta-14.messagelabs.com id BC/C1-08195-D1E3B335; Tue, 01 Apr 2014 22:30:53 +0000 X-Env-Sender: saurabh.globe@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1396391449!5616715!1 X-Originating-IP: [209.85.220.48] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31188 invoked from network); 1 Apr 2014 22:30:51 -0000 Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Apr 2014 22:30:51 -0000 Received: by mail-pa0-f48.google.com with SMTP id hz1so10489890pad.7 for ; Tue, 01 Apr 2014 15:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H9Boz9QURNYSHrzTO7DmI74ea8qmHj13RIA9JOmbTLs=; b=bb/apF/ypvbyUMyfgfwHyqD4nPYCepQUmRdemFx2JSlLXjBq6smdp5iNROs05IlXU+ 1SrJK7fL/XFNt1ZpOJ4vyQtXI4dgeOBK669Cwf6aSFbSNjrK3WzALMjpZ8JmmvmS+or2 ZynUHBFoWisHyYQxBDp0is71HrM6iAu/rzEUx+5x7ySETkpAUCFmDPVyqZzTiOkO23Bf gY5HkjwIAmUPnPLEuImn69I+hW2p7A48zoqrrQQVDc560bkoEA8ABFo70orCKwocJPxE gvt6shauukun/tsQmTacv+t0T1xqGATLcHRd11Kk0cMb7KhKmi2XeHeKTCqZD6WHoBJ7 ttKQ== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr33786680pbc.5.1396391449383; Tue, 01 Apr 2014 15:30:49 -0700 (PDT) Received: by 10.68.254.10 with HTTP; Tue, 1 Apr 2014 15:30:49 -0700 (PDT) In-Reply-To: <1396343236.8667.47.camel@kazak.uk.xensource.com> References: <1396343052.8667.45.camel@kazak.uk.xensource.com> <1396343236.8667.47.camel@kazak.uk.xensource.com> Date: Tue, 1 Apr 2014 15:30:49 -0700 Message-ID: From: Saurabh Mishra To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3923452687650198881==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3923452687650198881== Content-Type: multipart/alternative; boundary=047d7b86d55c4ed79604f602b87e --047d7b86d55c4ed79604f602b87e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 1, 2014 at 2:07 AM, Ian Campbell wrote: > On Tue, 2014-04-01 at 10:04 +0100, Ian Campbell wrote: > > On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote: > > > > > > > We are using Xen 4.2.4 > > > > > > > lc-1:~ # xl list > > > Name ID Mem VCPUs State > Time(s) > > > Domain-0 0 8151 4 r----- > 1681.3 > > > pvm-01-1 1 8187 4 -b---- > 256.4 > > > pool1-slot1 2 98299 32 -b---- > 81.6 > > > > Here you have 2 ~8GB guest domains and one ~96GB domain, which is a > > total of 112GB. On your 132GB host that leaves 36GB spare, which is > > probably why starting a 96GB guest fails (the error message could be > > clearer, you might have found an additional hint in "xl dmesg"). > > > > If the above is anomalous and you think there shou > > Gah, I swear I didn't press send there but off it went. > > What I was going to say is that if you think there really is enough free > RAM then please can you show us the output of "xl info" and "xl dmesg" > as well as sharing your guest configuration file. > > You might also find updating to Xen 4.3.x or Xen 4.4 will help since xl > was much improved in those releases. > > Ian. > > > Here's xl info. I'm not seeing that failure anymore and hence don't have xl dmesg output right after the problem. Updating to higher Xen is not possible because SuSE 11 does not have them yet. lc-6:~ # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 8151 4 r----- 161.0 pvm-01-6 1 8187 4 -b---- 28.3 pool1-slot6 2 98299 32 -b---- 25.0 lc-6:~ # lc-6:~ # xl info host : lc-6 release : 3.0.101-0.15-xen version : #1 SMP Wed Jan 22 15:49:03 UTC 2014 (5c01f4e) machine : x86_64 nr_cpus : 40 max_cpu_id : 39 nr_nodes : 2 cores_per_socket : 10 threads_per_core : 2 cpu_mhz : 2400 hw_caps : bfebfbff:2c100800:00000000:00007f40:77bee3ff:00000000:00000001:00000281 virt_caps : hvm hvm_directio total_memory : 131059 free_memory : 13614 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .4_02-0.7.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : 26280 xen_commandline : crashkernel=256M@16M console=com1 com1=115200 dom0_mem=8192m iommu=1,sharept extra_guest_irqs=80 dom0_max_vcpus=4 dom0_vcpus_pin no-bootscrub cc_compiler : gcc-4.6 (SUSE Linux) 4.6.1 20110701 [gcc-4_6-branch revision 17 cc_compile_by : abuild cc_compile_domain : cc_compile_date : Thu Feb 27 18:05:27 UTC 2014 xend_config_format : 4 *name = "pool1-slot6"* boot = "c" memory = 98304 vcpus = 32 disk = [ 'file:/root/PSVs/mnt_local_ssd/local_ssd/avm-d0:f0:db:0b:48:00-pool1-slot6-disk1/avm-1-eBuilder_vm-vm_ssc_wkr-disk1,hda,w' ] vif = [ 'model=e1000, mac=06:00:02:00:00:00, bridge=br0', 'model=e1000, mac=06:00:03:00:00:00, bridge=br1' ] cpuid="host,page1gb=k" nomigrate=1 xen_platform_pci=0 pci = [ '0000:07:10.0@0a', '0000:07:10.2@0b', '0000:07:10.4@0c', '0000:07:10.6@0d', '0000:07:11.0@0e', '0000:07:11.2@0f', '0000:07:10.1@10', '0000:07:10.3@11', '0000:07:10.5@12', '0000:07:10.7@13', '0000:07:11.1@14', '0000:88:10.0@15', '0000:88:10.2@16', '0000:88:10.4@17', '0000:88:10.6@18', '0000:88:11.0@19', '0000:88:11.2@1a', '0000:88:10.1@1b', '0000:88:10.3@1c', '0000:88:10.5@1d', '0000:88:10.7@1e', '0000:88:11.1@1f' ] cpus = [ '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24', '25', '26', '27', '28', '29', '30', '31', '32', '33', '34', '35' ] kernel = "hvmloader" builder = "hvm" device_model = "qemu-dm" acpi = 1 serial = "pty" vnc = 1 vnclisten = "0.0.0.0" pci_msitranslate = 0 on_reboot = "destroy" *name = "pvm-01-6"* boot = "c" memory = 8192 vcpus = 4 disk = [ 'file:/root/PSVs/mnt_local_ssd/local_ssd/pvm-6/ssc_pvm_01.img,hda,w', ',hdc:cdrom,r' ] vif = [ 'model=e1000, mac=00:16:3e:00:05:00, bridge=br0', 'model=e1000, mac=00:16:3f:00:05:01, bridge=br1' ] nomigrate=1 xen_platform_pci=0 pci = [ '0000:08:00.0@0b', '0000:01:00.0@0c', '0000:07:11.6@1a', '0000:07:11.7@1b', '0000:88:11.6@1c', '0000:88:11.7@1d' ] cpus = [ '36', '37', '38', '39' ] kernel = "hvmloader" builder = "hvm" device_model = "qemu-dm" acpi = 1 serial = "pty" vnc = 1 vnclisten = "0.0.0.0" pci_msitranslate = 0 on_reboot = "destroy" Thanks, /Saurabh --047d7b86d55c4ed79604f602b87e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 1, 2014 at 2:07 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Tue, 2014-04-01 at 10:04 +0100, Ian Cam= pbell wrote:
> On Mon, 2014-03-31 at 12:59 -0700, Saurabh Mishra wrote:
>
>
> > We are using Xen 4.2.4
>
>
> > lc-1:~ # xl list
> > Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUs =A0 =A0 =A0State =A0 Time(s)
> > Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 0 =A08151 =A0 =A0 4 =A0 =A0 r----- =A0 =A01681.3
> > pvm-01-1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 1 =A08187 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 256.4
> > pool1-slot1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A02 98299 =A0 =A032 =A0 =A0 -b---- =A0 =A0 =A081.6
>
> Here you have 2 ~8GB guest domains and one ~96GB domain, which is a > total of 112GB. On your 132GB host that leaves 36GB spare, which is > probably why starting a 96GB guest fails (the error message could be > clearer, you might have found an additional hint in "xl dmesg&quo= t;).
>
> If the above is anomalous and you think there shou

Gah, I swear I didn't press send there but off it went.

What I was going to say is that if you think there really is enough free RAM then please can you show us the output of "xl info" and "= ;xl dmesg"
as well as sharing your guest configuration file.

You might also find updating to Xen 4.3.x or Xen 4.4 will help since xl
was much improved in those releases.

Ian.



Here&= #39;s xl info. I'm not seeing that failure anymore and hence don't = have xl dmesg output right after the problem. Updating to higher Xen is not= possible because SuSE 11 does not have them yet.

lc-6:~ # xl list
Name =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= ID =A0 Mem VCPUs =A0 =A0 =A0State =A0 Time(s)
Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A08151 =A0 =A0 4 =A0 =A0 r----- =A0 =A0 161.0
pvm-01-6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 1 =A08187 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 =A028.3
pool1-slot6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02 98299 =A0 =A032 =A0 =A0 -b---- =A0 =A0 = =A025.0
lc-6:~ #=A0

=
lc-6:~ # xl inf= o
host =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : lc-6
=
release =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 3.0.101= -0.15-xen
version =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0: #1 SMP Wed Jan 22 15:49:03 UTC 2014 (5c01f4e)
machine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: x86_64
nr_cpus =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 40
max_cpu_id =A0 =A0 =A0 =A0 =A0 =A0 : 39
nr_nodes =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 2
cores_per_socket =A0 =A0 =A0 : 10
threads_per_core =A0 =A0 =A0 : 2
cpu_mhz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2400
hw_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: bfebfbff:2c100= 800:00000000:00007f40:77bee3ff:00000000:00000001:00000281
virt_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0: hvm hvm_d= irectio
total_memory =A0 =A0 =A0 =A0 =A0 : = 131059
free_memory =A0 =A0 =A0 =A0 =A0 =A0:= 13614
sharing_freed_memory =A0 : 0
sharing_used_memory =A0 =A0: 0
free_cpus =A0 =A0 =A0 =A0 =A0 =A0 =A0: 0
xen_major =A0 =A0 =A0 =A0 =A0 =A0 =A0: 4
xen_minor =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2
xen_extra =A0 =A0 =A0 =A0 =A0 =A0 =A0: .4_02-0.7= .1
xen_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 : x= en-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64= =A0
xen_scheduler =A0 =A0 =A0 =A0 =A0: credit
x= en_pagesize =A0 =A0 =A0 =A0 =A0 : 4096
plat= form_params =A0 =A0 =A0 =A0: virt_start=3D0xffff800000000000
xen_changeset =A0 =A0 =A0 =A0 =A0: 26280
xen_commandline =A0 =A0 =A0 =A0: crashkernel=3D2= 56M@16M console=3Dcom1 com1=3D115200 dom0_mem=3D8192m iommu=3D1,sharept ext= ra_guest_irqs=3D80 dom0_max_vcpus=3D4 dom0_vcpus_pin no-bootscrub
cc_compiler =A0 =A0 =A0 =A0 =A0 =A0: gcc-4.6 (SUSE Linux) 4.6.1 20110701 [g= cc-4_6-branch revision 17
cc_compile_by =A0= =A0 =A0 =A0 =A0: abuild
cc_compile_domain = =A0 =A0 =A0:=A0
cc_compile_date =A0 =A0 =A0 =A0: Thu Feb 27 18:05:27 UTC 2014
xend_config_format =A0 =A0 : 4

=

name =3D "pool1-slot6"<= /div>
boot =3D "c"
memory =3D 98304
vcpus =3D 32
disk =3D [ 'file= :/root/PSVs/mnt_local_ssd/local_ssd/avm-d0:f0:db:0b:48:00-pool1-slot6-disk1= /avm-1-eBuilder_vm-vm_ssc_wkr-disk1,hda,w' ]
vif =3D [ 'm= odel=3De1000, mac=3D06:00:02:00:00:00, bridge=3Dbr0', 'model=3De100= 0, mac=3D06:00:03:00:00:00, bridge=3Dbr1' ]
cpuid=3D"host,page1gb=3Dk"
nomigrate=3D1
xen_platform_pci=3D0
pci =3D [ =A0'0000:07:10.0@0a', = 9;0000:07:10.2@0b', '0000:07:10.4@0c', '0000:07:10.6@0d'= ;, '0000:07:11.0@0e', '0000:07:11.2@0f', '0000:07:10.1@= 10', '0000:07:10.3@11', '0000:07:10.5@12', '0000:07= :10.7@13', '0000:07:11.1@14', '0000:88:10.0@15', '0= 000:88:10.2@16', '0000:88:10.4@17', '0000:88:10.6@18', = '0000:88:11.0@19', '0000:88:11.2@1a', '0000:88:10.1@1b&= #39;, '0000:88:10.3@1c', '0000:88:10.5@1d', '0000:88:10= .7@1e', '0000:88:11.1@1f' ]
cpus =3D [ =A0'4', '5', '6', '7', '= ;8', '9', '10', '11', '12', '13'= ;, '14', '15', '16', '17', '18', &#= 39;19', '20', '21', '22', '23', '24= ', '25', '26', '27', '28', '29'= , '30', '31', '32', '33', '34', = 9;35' ]
kernel =3D "hvmloader"
builder =3D "hvm&q= uot;
device_model =3D "qemu-dm"
acpi =3D 1
serial =3D "pty"
vnc =3D 1
vnclisten =3D "0.0.0.0"
pci_msitranslate =3D 0
on_reboot =3D "destroy"=



vcpus =3D 4
disk =3D [ 'file:/root/PSVs/mnt_local_ssd/lo= cal_ssd/pvm-6/ssc_pvm_01.img,hda,w', ',hdc:cdrom,r' ]
vif =3D [ 'model=3De1000, mac=3D00:16:3e:00:05:00, bridge=3Dbr0', = 'model=3De1000, mac=3D00:16:3f:00:05:01, bridge=3Dbr1' ]
nomigrate=3D1
xen_platform_pci=3D0
pci =3D [ =A0&#= 39;0000:08:00.0@0b', '0000:01:00.0@0c', '0000:07:11.6@1a= 9;, '0000:07:11.7@1b', '0000:88:11.6@1c', '0000:88:11.7= @1d' ]
cpus =3D [ =A0'36', '37', '38', '39' ]=
kernel =3D "hvmloader"
builder =3D "= ;hvm"
device_model =3D "qemu-dm"
acpi = =3D 1
serial =3D "pty"
vnc =3D 1
vncli= sten =3D "0.0.0.0"
pci_msitranslate =3D 0
on_reboot =3D "destroy"


<= /div>

Thanks,
/Saurabh
--047d7b86d55c4ed79604f602b87e-- --===============3923452687650198881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3923452687650198881==-- From xen-users-bounces@lists.xen.org Wed Apr 02 09:29:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 09:29:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVHSe-0007pH-Jk; Wed, 02 Apr 2014 09:27:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVHSc-0007pC-VL for xen-users@lists.xen.org; Wed, 02 Apr 2014 09:27:55 +0000 Received: from [85.158.139.211:10233] by server-9.bemta-5.messagelabs.com id F0/AD-04350-A18DB335; Wed, 02 Apr 2014 09:27:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1396430872!4924738!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12476 invoked from network); 2 Apr 2014 09:27:53 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Apr 2014 09:27:53 -0000 X-IronPort-AV: E=Sophos;i="4.97,779,1389744000"; d="scan'208";a="116023389" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Apr 2014 09:27:51 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Wed, 2 Apr 2014 05:27:50 -0400 Message-ID: <1396430870.8667.267.camel@kazak.uk.xensource.com> From: Ian Campbell To: Saurabh Mishra Date: Wed, 2 Apr 2014 10:27:50 +0100 In-Reply-To: References: <1396343052.8667.45.camel@kazak.uk.xensource.com> <1396343236.8667.47.camel@kazak.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 15:30 -0700, Saurabh Mishra wrote: > I'm not seeing that failure anymore In which case I'm going to assume that you originally just didn't have sufficient free ram to start the VM and not persue the matter further. Thanks, Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Apr 02 09:29:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 09:29:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVHSe-0007pH-Jk; Wed, 02 Apr 2014 09:27:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVHSc-0007pC-VL for xen-users@lists.xen.org; Wed, 02 Apr 2014 09:27:55 +0000 Received: from [85.158.139.211:10233] by server-9.bemta-5.messagelabs.com id F0/AD-04350-A18DB335; Wed, 02 Apr 2014 09:27:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1396430872!4924738!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12476 invoked from network); 2 Apr 2014 09:27:53 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Apr 2014 09:27:53 -0000 X-IronPort-AV: E=Sophos;i="4.97,779,1389744000"; d="scan'208";a="116023389" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Apr 2014 09:27:51 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Wed, 2 Apr 2014 05:27:50 -0400 Message-ID: <1396430870.8667.267.camel@kazak.uk.xensource.com> From: Ian Campbell To: Saurabh Mishra Date: Wed, 2 Apr 2014 10:27:50 +0100 In-Reply-To: References: <1396343052.8667.45.camel@kazak.uk.xensource.com> <1396343236.8667.47.camel@kazak.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.8.5-2+b3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] XL ballooning issue with 96gb VM X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2014-04-01 at 15:30 -0700, Saurabh Mishra wrote: > I'm not seeing that failure anymore In which case I'm going to assume that you originally just didn't have sufficient free ram to start the VM and not persue the matter further. Thanks, Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Apr 02 11:50:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 11:50:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJev-0007Cb-0d; Wed, 02 Apr 2014 11:48:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJep-0007BB-Kx; Wed, 02 Apr 2014 11:48:39 +0000 Received: from [85.158.143.35:51001] by server-1.bemta-4.messagelabs.com id 94/85-09853-619FB335; Wed, 02 Apr 2014 11:48:38 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1396439316!6447488!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8384 invoked from network); 2 Apr 2014 11:48:37 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2014 11:48:37 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJeh-0005zk-SP; Wed, 02 Apr 2014 11:48:31 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1WVJeh-00063L-MQ; Wed, 02 Apr 2014 11:48:31 +0000 Date: Wed, 02 Apr 2014 11:48:31 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 89 (CVE-2014-2599) - HVMOP_set_mem_access is not preemptible X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-2599 / XSA-89 version 3 HVMOP_set_mem_access is not preemptible UPDATES IN VERSION 3 ==================== This issue has been assigned CVE-2014-2599. ISSUE DESCRIPTION ================= Processing of the HVMOP_set_mem_access HVM control operations does not check the size of its input and can tie up a physical CPU for extended periods of time. IMPACT ====== In a configuration where device models run with limited privilege (for example, stubdom device models), a guest attacker who successfully finds and exploits an unfixed security flaw in qemu-dm could leverage the other flaw into a Denial of Service affecting the whole host. In the more general case, in more abstract terms: a malicious administrator of a domain privileged with regard to an HVM guest can cause Xen to become unresponsive leading to a Denial of Service. VULNERABLE SYSTEMS ================== All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not available in 32-bit hypervisors). The vulnerability is only exposed to service domains for HVM guests which have privilege over the guest. In a usual configuration that means only device model emulators (qemu-dm). In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable. The situation is more subtle for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by "device_model_stubdomain_override=1" in the xl domain configuration file). The same applies with a qemu-dm in a dom0 process subjected to some kind kernel-based process privilege limitation (eg the chroot technique as found in some versions of XCP/XenServer). In those latter situations this issue means that the extra isolation does not provide as good a defence (against denial of service) as intended. That is the essence of this vulnerability. However, the security is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm. Finally, in a radically disaggregated system: where the HVM service domain software (probably, the device model domain image) is not always supplied by the host administrator, a malicious service domain administrator can excercise this vulnerability. MITIGATION ========== Running only PV guests will avoid this vulnerability. In a radically disaggregated system, restricting HVM service domains to software images approved by the host administrator will avoid the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa89.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa89-4.1.patch Xen 4.1.x $ sha256sum xsa89*.patch 741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6 xsa89.patch 7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e xsa89-4.1.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw nmxJR+CIaIRhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/ sdqLT+TIVXElukse1CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa 4UhqMzU5zXnRi+53Ljn3dBximU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK /ZrxoP89VRiSZq0GiGrSouF6FjU6fWyP3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW63MT1tACToCf8ObT3RMTuAgfa0= =vHm/ -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa89.patch" Content-Disposition: attachment; filename="xsa89.patch" Content-Transfer-Encoding: base64 eDg2OiBlbmZvcmNlIHByZWVtcHRpb24gaW4gSFZNX3NldF9tZW1fYWNjZXNz IC8gcDJtX3NldF9tZW1fYWNjZXNzKCkKClByb2Nlc3NpbmcgdXAgdG8gNEcg UEZOcyBtYXkgdGFrZSBhbG1vc3QgYXJiaXRyYXJpbHkgbG9uZywgc28KcHJl ZW1wdGlvbiBpcyBuZWVkZWQgaGVyZS4KClRoaXMgaXMgWFNBLTg5LgoKU2ln bmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpS ZXZpZXdlZC1ieTogVGltIERlZWdhbiA8dGltQHhlbi5vcmc+CgotLS0gYS94 ZW4vYXJjaC94ODYvaHZtL2h2bS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0v aHZtLmMKQEAgLTQ1OTMsNiArNDU5MywxNSBAQCBsb25nIGRvX2h2bV9vcCh1 bnNpZ25lZCBsb25nIG9wLCBYRU5fR1VFCiAgICAgICAgICAgICBnb3RvIHBh cmFtX2ZhaWw1OwogICAgICAgICAgICAgCiAgICAgICAgIHJjID0gcDJtX3Nl dF9tZW1fYWNjZXNzKGQsIGEuZmlyc3RfcGZuLCBhLm5yLCBhLmh2bW1lbV9h Y2Nlc3MpOworICAgICAgICBpZiAoIHJjID4gMCApCisgICAgICAgIHsKKyAg ICAgICAgICAgIGEuZmlyc3RfcGZuICs9IGEubnIgLSByYzsKKyAgICAgICAg ICAgIGEubnIgPSByYzsKKyAgICAgICAgICAgIGlmICggX19jb3B5X3RvX2d1 ZXN0KGFyZywgJmEsIDEpICkKKyAgICAgICAgICAgICAgICByYyA9IC1FRkFV TFQ7CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgcmMgPSAt RUFHQUlOOworICAgICAgICB9CiAKICAgICBwYXJhbV9mYWlsNToKICAgICAg ICAgcmN1X3VubG9ja19kb21haW4oZCk7Ci0tLSBhL3hlbi9hcmNoL3g4Ni9t bS9wMm0uYworKysgYi94ZW4vYXJjaC94ODYvbW0vcDJtLmMKQEAgLTEzMzMs MTUgKzEzMzMsMTQgQEAgdm9pZCBwMm1fbWVtX2FjY2Vzc19yZXN1bWUoc3Ry dWN0IGRvbWFpbgogCiAvKiBTZXQgYWNjZXNzIHR5cGUgZm9yIGEgcmVnaW9u IG9mIHBmbnMuCiAgKiBJZiBzdGFydF9wZm4gPT0gLTF1bCwgc2V0cyB0aGUg ZGVmYXVsdCBhY2Nlc3MgdHlwZSAqLwotaW50IHAybV9zZXRfbWVtX2FjY2Vz cyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBsb25nIHN0YXJ0X3Bmbiwg Ci0gICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IG5yLCBodm1tZW1f YWNjZXNzX3QgYWNjZXNzKSAKK2xvbmcgcDJtX3NldF9tZW1fYWNjZXNzKHN0 cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgcGZuLCB1aW50MzJfdCBu ciwKKyAgICAgICAgICAgICAgICAgICAgICAgIGh2bW1lbV9hY2Nlc3NfdCBh Y2Nlc3MpCiB7CiAgICAgc3RydWN0IHAybV9kb21haW4gKnAybSA9IHAybV9n ZXRfaG9zdHAybShkKTsKLSAgICB1bnNpZ25lZCBsb25nIHBmbjsKICAgICBw Mm1fYWNjZXNzX3QgYSwgX2E7CiAgICAgcDJtX3R5cGVfdCB0OwogICAgIG1m bl90IG1mbjsKLSAgICBpbnQgcmMgPSAwOworICAgIGxvbmcgcmM7CiAKICAg ICAvKiBOLkIuIF9ub3RfIHN0YXRpYzogaW5pdGlhbGl6ZXIgZGVwZW5kcyBv biBwMm0tPmRlZmF1bHRfYWNjZXNzICovCiAgICAgcDJtX2FjY2Vzc190IG1l bWFjY2Vzc1tdID0gewpAQCAtMTM2NCwxNCArMTM2MywxNyBAQCBpbnQgcDJt X3NldF9tZW1fYWNjZXNzKHN0cnVjdCBkb21haW4gKmQsCiAgICAgYSA9IG1l bWFjY2Vzc1thY2Nlc3NdOwogCiAgICAgLyogSWYgcmVxdWVzdCB0byBzZXQg ZGVmYXVsdCBhY2Nlc3MgKi8KLSAgICBpZiAoIHN0YXJ0X3BmbiA9PSB+MHVs bCApIAorICAgIGlmICggcGZuID09IH4wdWwgKQogICAgIHsKICAgICAgICAg cDJtLT5kZWZhdWx0X2FjY2VzcyA9IGE7CiAgICAgICAgIHJldHVybiAwOwog ICAgIH0KIAorICAgIGlmICggIW5yICkKKyAgICAgICAgcmV0dXJuIDA7CisK ICAgICBwMm1fbG9jayhwMm0pOwotICAgIGZvciAoIHBmbiA9IHN0YXJ0X3Bm bjsgcGZuIDwgc3RhcnRfcGZuICsgbnI7IHBmbisrICkKKyAgICBmb3IgKCA7 IDsgKytwZm4gKQogICAgIHsKICAgICAgICAgbWZuID0gcDJtLT5nZXRfZW50 cnkocDJtLCBwZm4sICZ0LCAmX2EsIDAsIE5VTEwpOwogICAgICAgICBpZiAo IHAybS0+c2V0X2VudHJ5KHAybSwgcGZuLCBtZm4sIFBBR0VfT1JERVJfNEss IHQsIGEpID09IDAgKQpAQCAtMTM3OSw2ICsxMzgxLDEzIEBAIGludCBwMm1f c2V0X21lbV9hY2Nlc3Moc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAg IHJjID0gLUVOT01FTTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9 CisKKyAgICAgICAgLyogQ2hlY2sgZm9yIGNvbnRpbnVhdGlvbiBpZiBpdCdz IG5vdCB0aGUgbGFzdCBpbnRlcmF0aW9uLiAqLworICAgICAgICBpZiAoICEt LW5yIHx8IGh5cGVyY2FsbF9wcmVlbXB0X2NoZWNrKCkgKQorICAgICAgICB7 CisgICAgICAgICAgICByYyA9IG5yOworICAgICAgICAgICAgYnJlYWs7Cisg ICAgICAgIH0KICAgICB9CiAgICAgcDJtX3VubG9jayhwMm0pOwogICAgIHJl dHVybiByYzsKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9wMm0uaAorKysg Yi94ZW4vaW5jbHVkZS9hc20teDg2L3AybS5oCkBAIC01NzYsOCArNTc2LDgg QEAgdm9pZCBwMm1fbWVtX2FjY2Vzc19yZXN1bWUoc3RydWN0IGRvbWFpbgog CiAvKiBTZXQgYWNjZXNzIHR5cGUgZm9yIGEgcmVnaW9uIG9mIHBmbnMuCiAg KiBJZiBzdGFydF9wZm4gPT0gLTF1bCwgc2V0cyB0aGUgZGVmYXVsdCBhY2Nl c3MgdHlwZSAqLwotaW50IHAybV9zZXRfbWVtX2FjY2VzcyhzdHJ1Y3QgZG9t YWluICpkLCB1bnNpZ25lZCBsb25nIHN0YXJ0X3BmbiwgCi0gICAgICAgICAg ICAgICAgICAgICAgIHVpbnQzMl90IG5yLCBodm1tZW1fYWNjZXNzX3QgYWNj ZXNzKTsKK2xvbmcgcDJtX3NldF9tZW1fYWNjZXNzKHN0cnVjdCBkb21haW4g KmQsIHVuc2lnbmVkIGxvbmcgc3RhcnRfcGZuLAorICAgICAgICAgICAgICAg ICAgICAgICAgdWludDMyX3QgbnIsIGh2bW1lbV9hY2Nlc3NfdCBhY2Nlc3Mp OwogCiAvKiBHZXQgYWNjZXNzIHR5cGUgZm9yIGEgcGZuCiAgKiBJZiBwZm4g PT0gLTF1bCwgZ2V0cyB0aGUgZGVmYXVsdCBhY2Nlc3MgdHlwZSAqLwo= --=separator Content-Type: application/octet-stream; name="xsa89-4.1.patch" Content-Disposition: attachment; filename="xsa89-4.1.patch" Content-Transfer-Encoding: base64 eDg2OiBlbmZvcmNlIHByZWVtcHRpb24gaW4gSFZNX3NldF9tZW1fYWNjZXNz IC8gcDJtX3NldF9tZW1fYWNjZXNzKCkKClByb2Nlc3NpbmcgdXAgdG8gNEcg UEZOcyBtYXkgdGFrZSBhbG1vc3QgYXJiaXRyYXJpbHkgbG9uZywgc28KcHJl ZW1wdGlvbiBpcyBuZWVkZWQgaGVyZS4KClRoaXMgaXMgWFNBLTg5LgoKU2ln bmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpS ZXZpZXdlZC1ieTogVGltIERlZWdhbiA8dGltQHhlbi5vcmc+CgotLS0gYS94 ZW4vYXJjaC94ODYvaHZtL2h2bS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0v aHZtLmMKQEAgLTM3NTUsNyArMzc1NSw3IEBAIGxvbmcgZG9faHZtX29wKHVu c2lnbmVkIGxvbmcgb3AsIFhFTl9HVUUKICAgICAgICAgICAgICAoKGEuZmly c3RfcGZuICsgYS5uciAtIDEpID4gZG9tYWluX2dldF9tYXhpbXVtX2dwZm4o ZCkpICkKICAgICAgICAgICAgIGdvdG8gcGFyYW1fZmFpbDU7CiAgICAgICAg ICAgICAKLSAgICAgICAgZm9yICggcGZuID0gYS5maXJzdF9wZm47IHBmbiA8 IGEuZmlyc3RfcGZuICsgYS5ucjsgcGZuKysgKQorICAgICAgICBmb3IgKCBw Zm4gPSBhLmZpcnN0X3BmbjsgYS5ucjsgKytwZm4gKQogICAgICAgICB7CiAg ICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAgICAgICAgICAgICBtZm5fdCBt Zm47CkBAIC0zNzY4LDYgKzM3NjgsMTcgQEAgbG9uZyBkb19odm1fb3AodW5z aWduZWQgbG9uZyBvcCwgWEVOX0dVRQogICAgICAgICAgICAgcDJtX3VubG9j ayhwMm0pOwogICAgICAgICAgICAgaWYgKCAhc3VjY2VzcyApCiAgICAgICAg ICAgICAgICAgZ290byBwYXJhbV9mYWlsNTsKKworICAgICAgICAgICAgLyog Q2hlY2sgZm9yIGNvbnRpbnVhdGlvbiBpZiBpdCdzIG5vdCB0aGUgbGFzdCBp bnRlcmF0aW9uLiAqLworICAgICAgICAgICAgaWYgKCAtLWEubnIgJiYgaHlw ZXJjYWxsX3ByZWVtcHRfY2hlY2soKSApCisgICAgICAgICAgICB7CisgICAg ICAgICAgICAgICAgYS5maXJzdF9wZm4gPSBwZm4gKyAxOworICAgICAgICAg ICAgICAgIGlmICggY29weV90b19ndWVzdChhcmcsICZhLCAxKSApCisgICAg ICAgICAgICAgICAgICAgIHJjID0gLUVGQVVMVDsKKyAgICAgICAgICAgICAg ICBlbHNlCisgICAgICAgICAgICAgICAgICAgIHJjID0gLUVBR0FJTjsKKyAg ICAgICAgICAgICAgICBnb3RvIHBhcmFtX2ZhaWw1OworICAgICAgICAgICAg fQogICAgICAgICB9CiAKICAgICAgICAgcmMgPSAwOwo= --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Wed Apr 02 11:50:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 11:50:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJev-0007Cb-0d; Wed, 02 Apr 2014 11:48:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJep-0007BB-Kx; Wed, 02 Apr 2014 11:48:39 +0000 Received: from [85.158.143.35:51001] by server-1.bemta-4.messagelabs.com id 94/85-09853-619FB335; Wed, 02 Apr 2014 11:48:38 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-5.tower-21.messagelabs.com!1396439316!6447488!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8384 invoked from network); 2 Apr 2014 11:48:37 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-5.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2014 11:48:37 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJeh-0005zk-SP; Wed, 02 Apr 2014 11:48:31 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1WVJeh-00063L-MQ; Wed, 02 Apr 2014 11:48:31 +0000 Date: Wed, 02 Apr 2014 11:48:31 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 89 (CVE-2014-2599) - HVMOP_set_mem_access is not preemptible X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-2599 / XSA-89 version 3 HVMOP_set_mem_access is not preemptible UPDATES IN VERSION 3 ==================== This issue has been assigned CVE-2014-2599. ISSUE DESCRIPTION ================= Processing of the HVMOP_set_mem_access HVM control operations does not check the size of its input and can tie up a physical CPU for extended periods of time. IMPACT ====== In a configuration where device models run with limited privilege (for example, stubdom device models), a guest attacker who successfully finds and exploits an unfixed security flaw in qemu-dm could leverage the other flaw into a Denial of Service affecting the whole host. In the more general case, in more abstract terms: a malicious administrator of a domain privileged with regard to an HVM guest can cause Xen to become unresponsive leading to a Denial of Service. VULNERABLE SYSTEMS ================== All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not available in 32-bit hypervisors). The vulnerability is only exposed to service domains for HVM guests which have privilege over the guest. In a usual configuration that means only device model emulators (qemu-dm). In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable. The situation is more subtle for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by "device_model_stubdomain_override=1" in the xl domain configuration file). The same applies with a qemu-dm in a dom0 process subjected to some kind kernel-based process privilege limitation (eg the chroot technique as found in some versions of XCP/XenServer). In those latter situations this issue means that the extra isolation does not provide as good a defence (against denial of service) as intended. That is the essence of this vulnerability. However, the security is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm. Finally, in a radically disaggregated system: where the HVM service domain software (probably, the device model domain image) is not always supplied by the host administrator, a malicious service domain administrator can excercise this vulnerability. MITIGATION ========== Running only PV guests will avoid this vulnerability. In a radically disaggregated system, restricting HVM service domains to software images approved by the host administrator will avoid the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa89.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa89-4.1.patch Xen 4.1.x $ sha256sum xsa89*.patch 741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6 xsa89.patch 7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e xsa89-4.1.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw nmxJR+CIaIRhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/ sdqLT+TIVXElukse1CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa 4UhqMzU5zXnRi+53Ljn3dBximU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK /ZrxoP89VRiSZq0GiGrSouF6FjU6fWyP3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW63MT1tACToCf8ObT3RMTuAgfa0= =vHm/ -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa89.patch" Content-Disposition: attachment; filename="xsa89.patch" Content-Transfer-Encoding: base64 eDg2OiBlbmZvcmNlIHByZWVtcHRpb24gaW4gSFZNX3NldF9tZW1fYWNjZXNz IC8gcDJtX3NldF9tZW1fYWNjZXNzKCkKClByb2Nlc3NpbmcgdXAgdG8gNEcg UEZOcyBtYXkgdGFrZSBhbG1vc3QgYXJiaXRyYXJpbHkgbG9uZywgc28KcHJl ZW1wdGlvbiBpcyBuZWVkZWQgaGVyZS4KClRoaXMgaXMgWFNBLTg5LgoKU2ln bmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpS ZXZpZXdlZC1ieTogVGltIERlZWdhbiA8dGltQHhlbi5vcmc+CgotLS0gYS94 ZW4vYXJjaC94ODYvaHZtL2h2bS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0v aHZtLmMKQEAgLTQ1OTMsNiArNDU5MywxNSBAQCBsb25nIGRvX2h2bV9vcCh1 bnNpZ25lZCBsb25nIG9wLCBYRU5fR1VFCiAgICAgICAgICAgICBnb3RvIHBh cmFtX2ZhaWw1OwogICAgICAgICAgICAgCiAgICAgICAgIHJjID0gcDJtX3Nl dF9tZW1fYWNjZXNzKGQsIGEuZmlyc3RfcGZuLCBhLm5yLCBhLmh2bW1lbV9h Y2Nlc3MpOworICAgICAgICBpZiAoIHJjID4gMCApCisgICAgICAgIHsKKyAg ICAgICAgICAgIGEuZmlyc3RfcGZuICs9IGEubnIgLSByYzsKKyAgICAgICAg ICAgIGEubnIgPSByYzsKKyAgICAgICAgICAgIGlmICggX19jb3B5X3RvX2d1 ZXN0KGFyZywgJmEsIDEpICkKKyAgICAgICAgICAgICAgICByYyA9IC1FRkFV TFQ7CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgcmMgPSAt RUFHQUlOOworICAgICAgICB9CiAKICAgICBwYXJhbV9mYWlsNToKICAgICAg ICAgcmN1X3VubG9ja19kb21haW4oZCk7Ci0tLSBhL3hlbi9hcmNoL3g4Ni9t bS9wMm0uYworKysgYi94ZW4vYXJjaC94ODYvbW0vcDJtLmMKQEAgLTEzMzMs MTUgKzEzMzMsMTQgQEAgdm9pZCBwMm1fbWVtX2FjY2Vzc19yZXN1bWUoc3Ry dWN0IGRvbWFpbgogCiAvKiBTZXQgYWNjZXNzIHR5cGUgZm9yIGEgcmVnaW9u IG9mIHBmbnMuCiAgKiBJZiBzdGFydF9wZm4gPT0gLTF1bCwgc2V0cyB0aGUg ZGVmYXVsdCBhY2Nlc3MgdHlwZSAqLwotaW50IHAybV9zZXRfbWVtX2FjY2Vz cyhzdHJ1Y3QgZG9tYWluICpkLCB1bnNpZ25lZCBsb25nIHN0YXJ0X3Bmbiwg Ci0gICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IG5yLCBodm1tZW1f YWNjZXNzX3QgYWNjZXNzKSAKK2xvbmcgcDJtX3NldF9tZW1fYWNjZXNzKHN0 cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgcGZuLCB1aW50MzJfdCBu ciwKKyAgICAgICAgICAgICAgICAgICAgICAgIGh2bW1lbV9hY2Nlc3NfdCBh Y2Nlc3MpCiB7CiAgICAgc3RydWN0IHAybV9kb21haW4gKnAybSA9IHAybV9n ZXRfaG9zdHAybShkKTsKLSAgICB1bnNpZ25lZCBsb25nIHBmbjsKICAgICBw Mm1fYWNjZXNzX3QgYSwgX2E7CiAgICAgcDJtX3R5cGVfdCB0OwogICAgIG1m bl90IG1mbjsKLSAgICBpbnQgcmMgPSAwOworICAgIGxvbmcgcmM7CiAKICAg ICAvKiBOLkIuIF9ub3RfIHN0YXRpYzogaW5pdGlhbGl6ZXIgZGVwZW5kcyBv biBwMm0tPmRlZmF1bHRfYWNjZXNzICovCiAgICAgcDJtX2FjY2Vzc190IG1l bWFjY2Vzc1tdID0gewpAQCAtMTM2NCwxNCArMTM2MywxNyBAQCBpbnQgcDJt X3NldF9tZW1fYWNjZXNzKHN0cnVjdCBkb21haW4gKmQsCiAgICAgYSA9IG1l bWFjY2Vzc1thY2Nlc3NdOwogCiAgICAgLyogSWYgcmVxdWVzdCB0byBzZXQg ZGVmYXVsdCBhY2Nlc3MgKi8KLSAgICBpZiAoIHN0YXJ0X3BmbiA9PSB+MHVs bCApIAorICAgIGlmICggcGZuID09IH4wdWwgKQogICAgIHsKICAgICAgICAg cDJtLT5kZWZhdWx0X2FjY2VzcyA9IGE7CiAgICAgICAgIHJldHVybiAwOwog ICAgIH0KIAorICAgIGlmICggIW5yICkKKyAgICAgICAgcmV0dXJuIDA7CisK ICAgICBwMm1fbG9jayhwMm0pOwotICAgIGZvciAoIHBmbiA9IHN0YXJ0X3Bm bjsgcGZuIDwgc3RhcnRfcGZuICsgbnI7IHBmbisrICkKKyAgICBmb3IgKCA7 IDsgKytwZm4gKQogICAgIHsKICAgICAgICAgbWZuID0gcDJtLT5nZXRfZW50 cnkocDJtLCBwZm4sICZ0LCAmX2EsIDAsIE5VTEwpOwogICAgICAgICBpZiAo IHAybS0+c2V0X2VudHJ5KHAybSwgcGZuLCBtZm4sIFBBR0VfT1JERVJfNEss IHQsIGEpID09IDAgKQpAQCAtMTM3OSw2ICsxMzgxLDEzIEBAIGludCBwMm1f c2V0X21lbV9hY2Nlc3Moc3RydWN0IGRvbWFpbiAqZCwKICAgICAgICAgICAg IHJjID0gLUVOT01FTTsKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICB9 CisKKyAgICAgICAgLyogQ2hlY2sgZm9yIGNvbnRpbnVhdGlvbiBpZiBpdCdz IG5vdCB0aGUgbGFzdCBpbnRlcmF0aW9uLiAqLworICAgICAgICBpZiAoICEt LW5yIHx8IGh5cGVyY2FsbF9wcmVlbXB0X2NoZWNrKCkgKQorICAgICAgICB7 CisgICAgICAgICAgICByYyA9IG5yOworICAgICAgICAgICAgYnJlYWs7Cisg ICAgICAgIH0KICAgICB9CiAgICAgcDJtX3VubG9jayhwMm0pOwogICAgIHJl dHVybiByYzsKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9wMm0uaAorKysg Yi94ZW4vaW5jbHVkZS9hc20teDg2L3AybS5oCkBAIC01NzYsOCArNTc2LDgg QEAgdm9pZCBwMm1fbWVtX2FjY2Vzc19yZXN1bWUoc3RydWN0IGRvbWFpbgog CiAvKiBTZXQgYWNjZXNzIHR5cGUgZm9yIGEgcmVnaW9uIG9mIHBmbnMuCiAg KiBJZiBzdGFydF9wZm4gPT0gLTF1bCwgc2V0cyB0aGUgZGVmYXVsdCBhY2Nl c3MgdHlwZSAqLwotaW50IHAybV9zZXRfbWVtX2FjY2VzcyhzdHJ1Y3QgZG9t YWluICpkLCB1bnNpZ25lZCBsb25nIHN0YXJ0X3BmbiwgCi0gICAgICAgICAg ICAgICAgICAgICAgIHVpbnQzMl90IG5yLCBodm1tZW1fYWNjZXNzX3QgYWNj ZXNzKTsKK2xvbmcgcDJtX3NldF9tZW1fYWNjZXNzKHN0cnVjdCBkb21haW4g KmQsIHVuc2lnbmVkIGxvbmcgc3RhcnRfcGZuLAorICAgICAgICAgICAgICAg ICAgICAgICAgdWludDMyX3QgbnIsIGh2bW1lbV9hY2Nlc3NfdCBhY2Nlc3Mp OwogCiAvKiBHZXQgYWNjZXNzIHR5cGUgZm9yIGEgcGZuCiAgKiBJZiBwZm4g PT0gLTF1bCwgZ2V0cyB0aGUgZGVmYXVsdCBhY2Nlc3MgdHlwZSAqLwo= --=separator Content-Type: application/octet-stream; name="xsa89-4.1.patch" Content-Disposition: attachment; filename="xsa89-4.1.patch" Content-Transfer-Encoding: base64 eDg2OiBlbmZvcmNlIHByZWVtcHRpb24gaW4gSFZNX3NldF9tZW1fYWNjZXNz IC8gcDJtX3NldF9tZW1fYWNjZXNzKCkKClByb2Nlc3NpbmcgdXAgdG8gNEcg UEZOcyBtYXkgdGFrZSBhbG1vc3QgYXJiaXRyYXJpbHkgbG9uZywgc28KcHJl ZW1wdGlvbiBpcyBuZWVkZWQgaGVyZS4KClRoaXMgaXMgWFNBLTg5LgoKU2ln bmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpS ZXZpZXdlZC1ieTogVGltIERlZWdhbiA8dGltQHhlbi5vcmc+CgotLS0gYS94 ZW4vYXJjaC94ODYvaHZtL2h2bS5jCisrKyBiL3hlbi9hcmNoL3g4Ni9odm0v aHZtLmMKQEAgLTM3NTUsNyArMzc1NSw3IEBAIGxvbmcgZG9faHZtX29wKHVu c2lnbmVkIGxvbmcgb3AsIFhFTl9HVUUKICAgICAgICAgICAgICAoKGEuZmly c3RfcGZuICsgYS5uciAtIDEpID4gZG9tYWluX2dldF9tYXhpbXVtX2dwZm4o ZCkpICkKICAgICAgICAgICAgIGdvdG8gcGFyYW1fZmFpbDU7CiAgICAgICAg ICAgICAKLSAgICAgICAgZm9yICggcGZuID0gYS5maXJzdF9wZm47IHBmbiA8 IGEuZmlyc3RfcGZuICsgYS5ucjsgcGZuKysgKQorICAgICAgICBmb3IgKCBw Zm4gPSBhLmZpcnN0X3BmbjsgYS5ucjsgKytwZm4gKQogICAgICAgICB7CiAg ICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAgICAgICAgICAgICBtZm5fdCBt Zm47CkBAIC0zNzY4LDYgKzM3NjgsMTcgQEAgbG9uZyBkb19odm1fb3AodW5z aWduZWQgbG9uZyBvcCwgWEVOX0dVRQogICAgICAgICAgICAgcDJtX3VubG9j ayhwMm0pOwogICAgICAgICAgICAgaWYgKCAhc3VjY2VzcyApCiAgICAgICAg ICAgICAgICAgZ290byBwYXJhbV9mYWlsNTsKKworICAgICAgICAgICAgLyog Q2hlY2sgZm9yIGNvbnRpbnVhdGlvbiBpZiBpdCdzIG5vdCB0aGUgbGFzdCBp bnRlcmF0aW9uLiAqLworICAgICAgICAgICAgaWYgKCAtLWEubnIgJiYgaHlw ZXJjYWxsX3ByZWVtcHRfY2hlY2soKSApCisgICAgICAgICAgICB7CisgICAg ICAgICAgICAgICAgYS5maXJzdF9wZm4gPSBwZm4gKyAxOworICAgICAgICAg ICAgICAgIGlmICggY29weV90b19ndWVzdChhcmcsICZhLCAxKSApCisgICAg ICAgICAgICAgICAgICAgIHJjID0gLUVGQVVMVDsKKyAgICAgICAgICAgICAg ICBlbHNlCisgICAgICAgICAgICAgICAgICAgIHJjID0gLUVBR0FJTjsKKyAg ICAgICAgICAgICAgICBnb3RvIHBhcmFtX2ZhaWw1OworICAgICAgICAgICAg fQogICAgICAgICB9CiAKICAgICAgICAgcmMgPSAwOwo= --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Wed Apr 02 11:50:29 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 11:50:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJgU-0007Zr-RZ; Wed, 02 Apr 2014 11:50:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJgS-0007Z1-0r; Wed, 02 Apr 2014 11:50:20 +0000 Received: from [85.158.143.35:9878] by server-1.bemta-4.messagelabs.com id 9E/D8-09853-B79FB335; Wed, 02 Apr 2014 11:50:19 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1396439417!6476970!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22099 invoked from network); 2 Apr 2014 11:50:17 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2014 11:50:17 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJgK-00061B-Ph; Wed, 02 Apr 2014 11:50:12 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1WVJg9-0006Ma-A2; Wed, 02 Apr 2014 11:50:02 +0000 Date: Wed, 02 Apr 2014 11:50:01 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 90 (CVE-2014-2580) - Linux netback crash trying to disable due to malformed packet X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-2580 / XSA-90 version 2 Linux netback crash trying to disable due to malformed packet UPDATES IN VERSION 2 ==================== This issue has been assigned CVE-2014-2580. A fix has been accepted into the Linux network subsystem maintainer's tree. The final fix differs substantially from the initial patch, which calls xenvif_carrier_off from an invalid context resulting in a kernel panic in the backend. The updated patch defers this work to kthread context and ensures that no traffic is processed in the meantime. The attached patches have been updated accordingly. Since the patch in v1 of the advisory does not eliminate the vulnerability, users are strongly encouraged to update to the latest patch. ISSUE DESCRIPTION ================= When Linux's netback sees a malformed packet, it tries to disable the interface which serves the misbehaving frontend. This involves taking a mutex, which might sleep. But in recent versions of Linux the guest transmit path is handled by NAPI in softirq context, where sleeping is not allowed. The end result is that the backend domain (often, Dom0) crashes with "scheduling while atomic". IMPACT ====== Malicious guest administrators can cause denial of service. If driver domains are not in use, the impact is a host crash. VULNERABLE SYSTEMS ================== This bug affects systems using Linux as the driver domain, including non-disaggregated systems using Linux as dom0. Only versions of Linux whose netback uses NAPI are affected. In Linux mainline this is all versions of Linux containing git changeset b3f980bd82, which was introduced between Linux 3.11 and 3.12-rc1. Systems using a different OS as dom0 (eg, NetBSD, Solaris) are not vulnerable. Both x86 and ARM systems are affected. MITIGATION ========== Using driver domains may limit the scope of the denial of service, and may make it possible to resume service without restarting guests (by restarting the driver domain). Advice on reconfiguring a system to use driver domains is beyond the reasonable scope of this advisory. In the case of an x86 HVM guest, the exploit can be prevented by disabling the PV IO paths; normally this would come with a substantial performance cost, and it may involve reconfiguring the guest as well as the host. This is not recommended. NOTE REGARDING LACK OF EMBARGO ============================== This bug was publicly reported on xen-devel, before it was appreciated that there was a security problem. The public mailing list thread nevertheless contains information strongly suggestive of a security bug, and a different security bug (with CVE) is suggested as seeming "similar". For these reasons we (the Xen Project Security Team) have concluded that the presence of this bug, as a security problem, is not (any longer) a secret. CREDITS ======= This issue was discovered as a bug by Török Edwin and analysed by Wei Liu of Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. $ sha256sum xsa90*.patch 364d94db6dc2b151eb1bb359dc90c71cbb8c5e3dc99b73fc01d981c018777ff4 xsa90.patch $ This patch has also been applied to the network subsystem maintainer's git tree: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=e9d8b2c2968499c1f96563e6522c56958d5a1d0d -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTO/lVAAoJEIP+FMlX6CvZkYAH/1DY0nKcCsG718IFOdtuu1LA tWhoEACOkqCrqfg/L/6/Tljd0okBlOa15v9amBAJvy7amxAIzlGHDgD3BgQ1w5Te Rc+GDVIoHhYq/LdqSj2Jr4TFXCuekOxTER3idvg+E1RrCOoEqNEFbIKey16vo/ll tn7qKs+qZ7LlQHhjLmwFuDfSromYzOoSiS43nqy4vFHgFXC1Zmk/K8p8DLHxz92y gt6EvMdoDIdgk9hZdLkRIPlqvprV6wQ69pX3MVB6WKIWwW6OYDxbMLfICbubESST 7af33QABFimadkalnN+4+xGblS1WRC5wz2XpSfNNe1bbaKkbPhXe7o9j0+mLX8g= =FL5w -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa90.patch" Content-Disposition: attachment; filename="xsa90.patch" Content-Transfer-Encoding: base64 RnJvbSBlOWQ4YjJjMjk2ODQ5OWMxZjk2NTYzZTY1MjJjNTY5NThkNWExZDBk IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgTGl1IDx3ZWku bGl1MkBjaXRyaXguY29tPgpEYXRlOiBUdWUsIDEgQXByIDIwMTQgMTI6NDY6 MTIgKzAxMDAKU3ViamVjdDogW1BBVENIXSB4ZW4tbmV0YmFjazogZGlzYWJs ZSByb2d1ZSB2aWYgaW4ga3RocmVhZCBjb250ZXh0Ck1JTUUtVmVyc2lvbjog MS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOApD b250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpXaGVuIG5ldGJhY2sg ZGlzY292ZXJzIGZyb250ZW5kIGlzIHNlbmRpbmcgbWFsZm9ybWVkIHBhY2tl dCBpdCB3aWxsCmRpc2FibGVzIHRoZSBpbnRlcmZhY2Ugd2hpY2ggc2VydmVz IHRoYXQgZnJvbnRlbmQuCgpIb3dldmVyIGRpc2FibGluZyBhIG5ldHdvcmsg aW50ZXJmYWNlIGludm9sdmluZyB0YWtpbmcgYSBtdXRleCB3aGljaApjYW5u b3QgYmUgZG9uZSBpbiBzb2Z0aXJxIGNvbnRleHQsIHNvIHdlIG5lZWQgdG8g ZGVmZXIgdGhpcyBwcm9jZXNzIHRvCmt0aHJlYWQgY29udGV4dC4KClRoaXMg cGF0Y2ggZG9lcyB0aGUgZm9sbG93aW5nOgoxLiBpbnRyb2R1Y2UgYSBmbGFn IHRvIGluZGljYXRlIHRoZSBpbnRlcmZhY2UgaXMgZGlzYWJsZWQuCjIuIGNo ZWNrIHRoYXQgZmxhZyBpbiBUWCBwYXRoLCBkb24ndCBkbyBhbnkgd29yayBp ZiBpdCdzIHRydWUuCjMuIGNoZWNrIHRoYXQgZmxhZyBpbiBSWCBwYXRoLCB0 dXJuIG9mZiB0aGF0IGludGVyZmFjZSBpZiBpdCdzIHRydWUuCgpUaGUgcmVh c29uIHRvIGRpc2FibGUgaXQgaW4gUlggcGF0aCBpcyBiZWNhdXNlIFJYIHVz ZXMga3RocmVhZC4gQWZ0ZXIKdGhpcyBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9m IG5ldGJhY2sgaXMgc3RpbGwgY29uc2lzdGVudCAtLSBpdCB3b24ndCBkbwph bnkgVFggd29yayBmb3IgYSByb2d1ZSBmcm9udGVuZCwgYW5kIHRoZSBpbnRl cmZhY2Ugd2lsbCBiZSBldmVudHVhbGx5CnR1cm5lZCBvZmYuCgpBbHNvIGNo YW5nZSBhICJjb250aW51ZSIgdG8gImJyZWFrIiBhZnRlciB4ZW52aWZfZmF0 YWxfdHhfZXJyLCBhcyBpdApkb2Vzbid0IG1ha2Ugc2Vuc2UgdG8gY29udGlu dWUgcHJvY2Vzc2luZyBwYWNrZXRzIGlmIGZyb250ZW5kIGlzIHJvZ3VlLgoK VGhpcyBpcyBhIGZpeCBmb3IgWFNBLTkwLgoKUmVwb3J0ZWQtYnk6IFTDtnLD tmsgRWR3aW4gPGVkd2luQGV0b3Jvay5uZXQ+ClNpZ25lZC1vZmYtYnk6IFdl aSBMaXUgPHdlaS5saXUyQGNpdHJpeC5jb20+CkNjOiBJYW4gQ2FtcGJlbGwg PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogRGF2aWQg VnJhYmVsIDxkYXZpZC52cmFiZWxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElh biBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+ClNpZ25lZC1v ZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4K LS0tCiBkcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaCAgICB8ICAg IDUgKysrKysKIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2ludGVyZmFjZS5j IHwgICAxMSArKysrKysrKysrKwogZHJpdmVycy9uZXQveGVuLW5ldGJhY2sv bmV0YmFjay5jICAgfCAgIDE2ICsrKysrKysrKysrKysrLS0KIDMgZmlsZXMg Y2hhbmdlZCwgMzAgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRp ZmYgLS1naXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaCBi L2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oCmluZGV4IDg5YjJk NDIuLjg5ZDFkMDUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRi YWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2Nv bW1vbi5oCkBAIC0xMDQsNiArMTA0LDExIEBAIHN0cnVjdCB4ZW52aWYgewog CWRvbWlkX3QgICAgICAgICAgZG9taWQ7CiAJdW5zaWduZWQgaW50ICAgICBo YW5kbGU7CiAKKwkvKiBJcyB0aGlzIGludGVyZmFjZSBkaXNhYmxlZD8gVHJ1 ZSB3aGVuIGJhY2tlbmQgZGlzY292ZXJzCisJICogZnJvbnRlbmQgaXMgcm9n dWUuCisJICovCisJYm9vbCBkaXNhYmxlZDsKKwogCS8qIFVzZSBOQVBJIGZv ciBndWVzdCBUWCAqLwogCXN0cnVjdCBuYXBpX3N0cnVjdCBuYXBpOwogCS8q IFdoZW4gZmVhdHVyZS1zcGxpdC1ldmVudC1jaGFubmVscyA9IDAsIHR4X2ly cSA9IHJ4X2lycS4gKi8KZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1u ZXRiYWNrL2ludGVyZmFjZS5jIGIvZHJpdmVycy9uZXQveGVuLW5ldGJhY2sv aW50ZXJmYWNlLmMKaW5kZXggY2RjMjk4ZS4uZWYwNWM1YyAxMDA2NDQKLS0t IGEvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svaW50ZXJmYWNlLmMKKysrIGIv ZHJpdmVycy9uZXQveGVuLW5ldGJhY2svaW50ZXJmYWNlLmMKQEAgLTYzLDYg KzYzLDE1IEBAIHN0YXRpYyBpbnQgeGVudmlmX3BvbGwoc3RydWN0IG5hcGlf c3RydWN0ICpuYXBpLCBpbnQgYnVkZ2V0KQogCXN0cnVjdCB4ZW52aWYgKnZp ZiA9IGNvbnRhaW5lcl9vZihuYXBpLCBzdHJ1Y3QgeGVudmlmLCBuYXBpKTsK IAlpbnQgd29ya19kb25lOwogCisJLyogVGhpcyB2aWYgaXMgcm9ndWUsIHdl IHByZXRlbmQgd2UndmUgdGhlcmUgaXMgbm90aGluZyB0byBkbworCSAqIGZv ciB0aGlzIHZpZiB0byBkZXNjaGVkdWxlIGl0IGZyb20gTkFQSS4gQnV0IHRo aXMgaW50ZXJmYWNlCisJICogd2lsbCBiZSB0dXJuZWQgb2ZmIGluIHRocmVh ZCBjb250ZXh0IGxhdGVyLgorCSAqLworCWlmICh1bmxpa2VseSh2aWYtPmRp c2FibGVkKSkgeworCQluYXBpX2NvbXBsZXRlKG5hcGkpOworCQlyZXR1cm4g MDsKKwl9CisKIAl3b3JrX2RvbmUgPSB4ZW52aWZfdHhfYWN0aW9uKHZpZiwg YnVkZ2V0KTsKIAogCWlmICh3b3JrX2RvbmUgPCBidWRnZXQpIHsKQEAgLTM2 Myw2ICszNzIsOCBAQCBzdHJ1Y3QgeGVudmlmICp4ZW52aWZfYWxsb2Moc3Ry dWN0IGRldmljZSAqcGFyZW50LCBkb21pZF90IGRvbWlkLAogCXZpZi0+aXBf Y3N1bSA9IDE7CiAJdmlmLT5kZXYgPSBkZXY7CiAKKwl2aWYtPmRpc2FibGVk ID0gZmFsc2U7CisKIAl2aWYtPmNyZWRpdF9ieXRlcyA9IHZpZi0+cmVtYWlu aW5nX2NyZWRpdCA9IH4wVUw7CiAJdmlmLT5jcmVkaXRfdXNlYyAgPSAwVUw7 CiAJaW5pdF90aW1lcigmdmlmLT5jcmVkaXRfdGltZW91dCk7CmRpZmYgLS1n aXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMgYi9kcml2 ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKaW5kZXggYWUzNGY1Zi4u M2YwMjFlMCAxMDA2NDQKLS0tIGEvZHJpdmVycy9uZXQveGVuLW5ldGJhY2sv bmV0YmFjay5jCisrKyBiL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJh Y2suYwpAQCAtNzExLDcgKzcxMSw4IEBAIHN0YXRpYyB2b2lkIHhlbnZpZl90 eF9lcnIoc3RydWN0IHhlbnZpZiAqdmlmLAogc3RhdGljIHZvaWQgeGVudmlm X2ZhdGFsX3R4X2VycihzdHJ1Y3QgeGVudmlmICp2aWYpCiB7CiAJbmV0ZGV2 X2Vycih2aWYtPmRldiwgImZhdGFsIGVycm9yOyBkaXNhYmxpbmcgZGV2aWNl XG4iKTsKLQl4ZW52aWZfY2Fycmllcl9vZmYodmlmKTsKKwl2aWYtPmRpc2Fi bGVkID0gdHJ1ZTsKKwl4ZW52aWZfa2lja190aHJlYWQodmlmKTsKIH0KIAog c3RhdGljIGludCB4ZW52aWZfY291bnRfcmVxdWVzdHMoc3RydWN0IHhlbnZp ZiAqdmlmLApAQCAtMTIxMiw3ICsxMjEzLDcgQEAgc3RhdGljIHVuc2lnbmVk IHhlbnZpZl90eF9idWlsZF9nb3BzKHN0cnVjdCB4ZW52aWYgKnZpZiwgaW50 IGJ1ZGdldCkKIAkJCQkgICB2aWYtPnR4LnNyaW5nLT5yZXFfcHJvZCwgdmlm LT50eC5yZXFfY29ucywKIAkJCQkgICBYRU5fTkVUSUZfVFhfUklOR19TSVpF KTsKIAkJCXhlbnZpZl9mYXRhbF90eF9lcnIodmlmKTsKLQkJCWNvbnRpbnVl OworCQkJYnJlYWs7CiAJCX0KIAogCQl3b3JrX3RvX2RvID0gUklOR19IQVNf VU5DT05TVU1FRF9SRVFVRVNUUygmdmlmLT50eCk7CkBAIC0xODA4LDcgKzE4 MDksMTggQEAgaW50IHhlbnZpZl9rdGhyZWFkX2d1ZXN0X3J4KHZvaWQgKmRh dGEpCiAJd2hpbGUgKCFrdGhyZWFkX3Nob3VsZF9zdG9wKCkpIHsKIAkJd2Fp dF9ldmVudF9pbnRlcnJ1cHRpYmxlKHZpZi0+d3EsCiAJCQkJCSByeF93b3Jr X3RvZG8odmlmKSB8fAorCQkJCQkgdmlmLT5kaXNhYmxlZCB8fAogCQkJCQkg a3RocmVhZF9zaG91bGRfc3RvcCgpKTsKKworCQkvKiBUaGlzIGZyb250ZW5k IGlzIGZvdW5kIHRvIGJlIHJvZ3VlLCBkaXNhYmxlIGl0IGluCisJCSAqIGt0 aHJlYWQgY29udGV4dC4gQ3VycmVudGx5IHRoaXMgaXMgb25seSBzZXQgd2hl bgorCQkgKiBuZXRiYWNrIGZpbmRzIG91dCBmcm9udGVuZCBzZW5kcyBtYWxm b3JtZWQgcGFja2V0LAorCQkgKiBidXQgd2UgY2Fubm90IGRpc2FibGUgdGhl IGludGVyZmFjZSBpbiBzb2Z0aXJxCisJCSAqIGNvbnRleHQgc28gd2UgZGVm ZXIgaXQgaGVyZS4KKwkJICovCisJCWlmICh1bmxpa2VseSh2aWYtPmRpc2Fi bGVkICYmIG5ldGlmX2NhcnJpZXJfb2sodmlmLT5kZXYpKSkKKwkJCXhlbnZp Zl9jYXJyaWVyX29mZih2aWYpOworCiAJCWlmIChrdGhyZWFkX3Nob3VsZF9z dG9wKCkpCiAJCQlicmVhazsKIAotLSAKMS43LjEwLjQKCg== --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Wed Apr 02 11:50:29 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 11:50:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJgU-0007Zr-RZ; Wed, 02 Apr 2014 11:50:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJgS-0007Z1-0r; Wed, 02 Apr 2014 11:50:20 +0000 Received: from [85.158.143.35:9878] by server-1.bemta-4.messagelabs.com id 9E/D8-09853-B79FB335; Wed, 02 Apr 2014 11:50:19 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-14.tower-21.messagelabs.com!1396439417!6476970!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22099 invoked from network); 2 Apr 2014 11:50:17 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-14.tower-21.messagelabs.com with AES256-SHA encrypted SMTP; 2 Apr 2014 11:50:17 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVJgK-00061B-Ph; Wed, 02 Apr 2014 11:50:12 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1WVJg9-0006Ma-A2; Wed, 02 Apr 2014 11:50:02 +0000 Date: Wed, 02 Apr 2014 11:50:01 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 90 (CVE-2014-2580) - Linux netback crash trying to disable due to malformed packet X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-2580 / XSA-90 version 2 Linux netback crash trying to disable due to malformed packet UPDATES IN VERSION 2 ==================== This issue has been assigned CVE-2014-2580. A fix has been accepted into the Linux network subsystem maintainer's tree. The final fix differs substantially from the initial patch, which calls xenvif_carrier_off from an invalid context resulting in a kernel panic in the backend. The updated patch defers this work to kthread context and ensures that no traffic is processed in the meantime. The attached patches have been updated accordingly. Since the patch in v1 of the advisory does not eliminate the vulnerability, users are strongly encouraged to update to the latest patch. ISSUE DESCRIPTION ================= When Linux's netback sees a malformed packet, it tries to disable the interface which serves the misbehaving frontend. This involves taking a mutex, which might sleep. But in recent versions of Linux the guest transmit path is handled by NAPI in softirq context, where sleeping is not allowed. The end result is that the backend domain (often, Dom0) crashes with "scheduling while atomic". IMPACT ====== Malicious guest administrators can cause denial of service. If driver domains are not in use, the impact is a host crash. VULNERABLE SYSTEMS ================== This bug affects systems using Linux as the driver domain, including non-disaggregated systems using Linux as dom0. Only versions of Linux whose netback uses NAPI are affected. In Linux mainline this is all versions of Linux containing git changeset b3f980bd82, which was introduced between Linux 3.11 and 3.12-rc1. Systems using a different OS as dom0 (eg, NetBSD, Solaris) are not vulnerable. Both x86 and ARM systems are affected. MITIGATION ========== Using driver domains may limit the scope of the denial of service, and may make it possible to resume service without restarting guests (by restarting the driver domain). Advice on reconfiguring a system to use driver domains is beyond the reasonable scope of this advisory. In the case of an x86 HVM guest, the exploit can be prevented by disabling the PV IO paths; normally this would come with a substantial performance cost, and it may involve reconfiguring the guest as well as the host. This is not recommended. NOTE REGARDING LACK OF EMBARGO ============================== This bug was publicly reported on xen-devel, before it was appreciated that there was a security problem. The public mailing list thread nevertheless contains information strongly suggestive of a security bug, and a different security bug (with CVE) is suggested as seeming "similar". For these reasons we (the Xen Project Security Team) have concluded that the presence of this bug, as a security problem, is not (any longer) a secret. CREDITS ======= This issue was discovered as a bug by Török Edwin and analysed by Wei Liu of Citrix. RESOLUTION ========== Applying the attached patch resolves this issue. $ sha256sum xsa90*.patch 364d94db6dc2b151eb1bb359dc90c71cbb8c5e3dc99b73fc01d981c018777ff4 xsa90.patch $ This patch has also been applied to the network subsystem maintainer's git tree: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=e9d8b2c2968499c1f96563e6522c56958d5a1d0d -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTO/lVAAoJEIP+FMlX6CvZkYAH/1DY0nKcCsG718IFOdtuu1LA tWhoEACOkqCrqfg/L/6/Tljd0okBlOa15v9amBAJvy7amxAIzlGHDgD3BgQ1w5Te Rc+GDVIoHhYq/LdqSj2Jr4TFXCuekOxTER3idvg+E1RrCOoEqNEFbIKey16vo/ll tn7qKs+qZ7LlQHhjLmwFuDfSromYzOoSiS43nqy4vFHgFXC1Zmk/K8p8DLHxz92y gt6EvMdoDIdgk9hZdLkRIPlqvprV6wQ69pX3MVB6WKIWwW6OYDxbMLfICbubESST 7af33QABFimadkalnN+4+xGblS1WRC5wz2XpSfNNe1bbaKkbPhXe7o9j0+mLX8g= =FL5w -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa90.patch" Content-Disposition: attachment; filename="xsa90.patch" Content-Transfer-Encoding: base64 RnJvbSBlOWQ4YjJjMjk2ODQ5OWMxZjk2NTYzZTY1MjJjNTY5NThkNWExZDBk IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgTGl1IDx3ZWku bGl1MkBjaXRyaXguY29tPgpEYXRlOiBUdWUsIDEgQXByIDIwMTQgMTI6NDY6 MTIgKzAxMDAKU3ViamVjdDogW1BBVENIXSB4ZW4tbmV0YmFjazogZGlzYWJs ZSByb2d1ZSB2aWYgaW4ga3RocmVhZCBjb250ZXh0Ck1JTUUtVmVyc2lvbjog MS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOApD b250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpXaGVuIG5ldGJhY2sg ZGlzY292ZXJzIGZyb250ZW5kIGlzIHNlbmRpbmcgbWFsZm9ybWVkIHBhY2tl dCBpdCB3aWxsCmRpc2FibGVzIHRoZSBpbnRlcmZhY2Ugd2hpY2ggc2VydmVz IHRoYXQgZnJvbnRlbmQuCgpIb3dldmVyIGRpc2FibGluZyBhIG5ldHdvcmsg aW50ZXJmYWNlIGludm9sdmluZyB0YWtpbmcgYSBtdXRleCB3aGljaApjYW5u b3QgYmUgZG9uZSBpbiBzb2Z0aXJxIGNvbnRleHQsIHNvIHdlIG5lZWQgdG8g ZGVmZXIgdGhpcyBwcm9jZXNzIHRvCmt0aHJlYWQgY29udGV4dC4KClRoaXMg cGF0Y2ggZG9lcyB0aGUgZm9sbG93aW5nOgoxLiBpbnRyb2R1Y2UgYSBmbGFn IHRvIGluZGljYXRlIHRoZSBpbnRlcmZhY2UgaXMgZGlzYWJsZWQuCjIuIGNo ZWNrIHRoYXQgZmxhZyBpbiBUWCBwYXRoLCBkb24ndCBkbyBhbnkgd29yayBp ZiBpdCdzIHRydWUuCjMuIGNoZWNrIHRoYXQgZmxhZyBpbiBSWCBwYXRoLCB0 dXJuIG9mZiB0aGF0IGludGVyZmFjZSBpZiBpdCdzIHRydWUuCgpUaGUgcmVh c29uIHRvIGRpc2FibGUgaXQgaW4gUlggcGF0aCBpcyBiZWNhdXNlIFJYIHVz ZXMga3RocmVhZC4gQWZ0ZXIKdGhpcyBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9m IG5ldGJhY2sgaXMgc3RpbGwgY29uc2lzdGVudCAtLSBpdCB3b24ndCBkbwph bnkgVFggd29yayBmb3IgYSByb2d1ZSBmcm9udGVuZCwgYW5kIHRoZSBpbnRl cmZhY2Ugd2lsbCBiZSBldmVudHVhbGx5CnR1cm5lZCBvZmYuCgpBbHNvIGNo YW5nZSBhICJjb250aW51ZSIgdG8gImJyZWFrIiBhZnRlciB4ZW52aWZfZmF0 YWxfdHhfZXJyLCBhcyBpdApkb2Vzbid0IG1ha2Ugc2Vuc2UgdG8gY29udGlu dWUgcHJvY2Vzc2luZyBwYWNrZXRzIGlmIGZyb250ZW5kIGlzIHJvZ3VlLgoK VGhpcyBpcyBhIGZpeCBmb3IgWFNBLTkwLgoKUmVwb3J0ZWQtYnk6IFTDtnLD tmsgRWR3aW4gPGVkd2luQGV0b3Jvay5uZXQ+ClNpZ25lZC1vZmYtYnk6IFdl aSBMaXUgPHdlaS5saXUyQGNpdHJpeC5jb20+CkNjOiBJYW4gQ2FtcGJlbGwg PGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogRGF2aWQg VnJhYmVsIDxkYXZpZC52cmFiZWxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElh biBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+ClNpZ25lZC1v ZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4K LS0tCiBkcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaCAgICB8ICAg IDUgKysrKysKIGRyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2ludGVyZmFjZS5j IHwgICAxMSArKysrKysrKysrKwogZHJpdmVycy9uZXQveGVuLW5ldGJhY2sv bmV0YmFjay5jICAgfCAgIDE2ICsrKysrKysrKysrKysrLS0KIDMgZmlsZXMg Y2hhbmdlZCwgMzAgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRp ZmYgLS1naXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9jb21tb24uaCBi L2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2NvbW1vbi5oCmluZGV4IDg5YjJk NDIuLjg5ZDFkMDUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRi YWNrL2NvbW1vbi5oCisrKyBiL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL2Nv bW1vbi5oCkBAIC0xMDQsNiArMTA0LDExIEBAIHN0cnVjdCB4ZW52aWYgewog CWRvbWlkX3QgICAgICAgICAgZG9taWQ7CiAJdW5zaWduZWQgaW50ICAgICBo YW5kbGU7CiAKKwkvKiBJcyB0aGlzIGludGVyZmFjZSBkaXNhYmxlZD8gVHJ1 ZSB3aGVuIGJhY2tlbmQgZGlzY292ZXJzCisJICogZnJvbnRlbmQgaXMgcm9n dWUuCisJICovCisJYm9vbCBkaXNhYmxlZDsKKwogCS8qIFVzZSBOQVBJIGZv ciBndWVzdCBUWCAqLwogCXN0cnVjdCBuYXBpX3N0cnVjdCBuYXBpOwogCS8q IFdoZW4gZmVhdHVyZS1zcGxpdC1ldmVudC1jaGFubmVscyA9IDAsIHR4X2ly cSA9IHJ4X2lycS4gKi8KZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3hlbi1u ZXRiYWNrL2ludGVyZmFjZS5jIGIvZHJpdmVycy9uZXQveGVuLW5ldGJhY2sv aW50ZXJmYWNlLmMKaW5kZXggY2RjMjk4ZS4uZWYwNWM1YyAxMDA2NDQKLS0t IGEvZHJpdmVycy9uZXQveGVuLW5ldGJhY2svaW50ZXJmYWNlLmMKKysrIGIv ZHJpdmVycy9uZXQveGVuLW5ldGJhY2svaW50ZXJmYWNlLmMKQEAgLTYzLDYg KzYzLDE1IEBAIHN0YXRpYyBpbnQgeGVudmlmX3BvbGwoc3RydWN0IG5hcGlf c3RydWN0ICpuYXBpLCBpbnQgYnVkZ2V0KQogCXN0cnVjdCB4ZW52aWYgKnZp ZiA9IGNvbnRhaW5lcl9vZihuYXBpLCBzdHJ1Y3QgeGVudmlmLCBuYXBpKTsK IAlpbnQgd29ya19kb25lOwogCisJLyogVGhpcyB2aWYgaXMgcm9ndWUsIHdl IHByZXRlbmQgd2UndmUgdGhlcmUgaXMgbm90aGluZyB0byBkbworCSAqIGZv ciB0aGlzIHZpZiB0byBkZXNjaGVkdWxlIGl0IGZyb20gTkFQSS4gQnV0IHRo aXMgaW50ZXJmYWNlCisJICogd2lsbCBiZSB0dXJuZWQgb2ZmIGluIHRocmVh ZCBjb250ZXh0IGxhdGVyLgorCSAqLworCWlmICh1bmxpa2VseSh2aWYtPmRp c2FibGVkKSkgeworCQluYXBpX2NvbXBsZXRlKG5hcGkpOworCQlyZXR1cm4g MDsKKwl9CisKIAl3b3JrX2RvbmUgPSB4ZW52aWZfdHhfYWN0aW9uKHZpZiwg YnVkZ2V0KTsKIAogCWlmICh3b3JrX2RvbmUgPCBidWRnZXQpIHsKQEAgLTM2 Myw2ICszNzIsOCBAQCBzdHJ1Y3QgeGVudmlmICp4ZW52aWZfYWxsb2Moc3Ry dWN0IGRldmljZSAqcGFyZW50LCBkb21pZF90IGRvbWlkLAogCXZpZi0+aXBf Y3N1bSA9IDE7CiAJdmlmLT5kZXYgPSBkZXY7CiAKKwl2aWYtPmRpc2FibGVk ID0gZmFsc2U7CisKIAl2aWYtPmNyZWRpdF9ieXRlcyA9IHZpZi0+cmVtYWlu aW5nX2NyZWRpdCA9IH4wVUw7CiAJdmlmLT5jcmVkaXRfdXNlYyAgPSAwVUw7 CiAJaW5pdF90aW1lcigmdmlmLT5jcmVkaXRfdGltZW91dCk7CmRpZmYgLS1n aXQgYS9kcml2ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMgYi9kcml2 ZXJzL25ldC94ZW4tbmV0YmFjay9uZXRiYWNrLmMKaW5kZXggYWUzNGY1Zi4u M2YwMjFlMCAxMDA2NDQKLS0tIGEvZHJpdmVycy9uZXQveGVuLW5ldGJhY2sv bmV0YmFjay5jCisrKyBiL2RyaXZlcnMvbmV0L3hlbi1uZXRiYWNrL25ldGJh Y2suYwpAQCAtNzExLDcgKzcxMSw4IEBAIHN0YXRpYyB2b2lkIHhlbnZpZl90 eF9lcnIoc3RydWN0IHhlbnZpZiAqdmlmLAogc3RhdGljIHZvaWQgeGVudmlm X2ZhdGFsX3R4X2VycihzdHJ1Y3QgeGVudmlmICp2aWYpCiB7CiAJbmV0ZGV2 X2Vycih2aWYtPmRldiwgImZhdGFsIGVycm9yOyBkaXNhYmxpbmcgZGV2aWNl XG4iKTsKLQl4ZW52aWZfY2Fycmllcl9vZmYodmlmKTsKKwl2aWYtPmRpc2Fi bGVkID0gdHJ1ZTsKKwl4ZW52aWZfa2lja190aHJlYWQodmlmKTsKIH0KIAog c3RhdGljIGludCB4ZW52aWZfY291bnRfcmVxdWVzdHMoc3RydWN0IHhlbnZp ZiAqdmlmLApAQCAtMTIxMiw3ICsxMjEzLDcgQEAgc3RhdGljIHVuc2lnbmVk IHhlbnZpZl90eF9idWlsZF9nb3BzKHN0cnVjdCB4ZW52aWYgKnZpZiwgaW50 IGJ1ZGdldCkKIAkJCQkgICB2aWYtPnR4LnNyaW5nLT5yZXFfcHJvZCwgdmlm LT50eC5yZXFfY29ucywKIAkJCQkgICBYRU5fTkVUSUZfVFhfUklOR19TSVpF KTsKIAkJCXhlbnZpZl9mYXRhbF90eF9lcnIodmlmKTsKLQkJCWNvbnRpbnVl OworCQkJYnJlYWs7CiAJCX0KIAogCQl3b3JrX3RvX2RvID0gUklOR19IQVNf VU5DT05TVU1FRF9SRVFVRVNUUygmdmlmLT50eCk7CkBAIC0xODA4LDcgKzE4 MDksMTggQEAgaW50IHhlbnZpZl9rdGhyZWFkX2d1ZXN0X3J4KHZvaWQgKmRh dGEpCiAJd2hpbGUgKCFrdGhyZWFkX3Nob3VsZF9zdG9wKCkpIHsKIAkJd2Fp dF9ldmVudF9pbnRlcnJ1cHRpYmxlKHZpZi0+d3EsCiAJCQkJCSByeF93b3Jr X3RvZG8odmlmKSB8fAorCQkJCQkgdmlmLT5kaXNhYmxlZCB8fAogCQkJCQkg a3RocmVhZF9zaG91bGRfc3RvcCgpKTsKKworCQkvKiBUaGlzIGZyb250ZW5k IGlzIGZvdW5kIHRvIGJlIHJvZ3VlLCBkaXNhYmxlIGl0IGluCisJCSAqIGt0 aHJlYWQgY29udGV4dC4gQ3VycmVudGx5IHRoaXMgaXMgb25seSBzZXQgd2hl bgorCQkgKiBuZXRiYWNrIGZpbmRzIG91dCBmcm9udGVuZCBzZW5kcyBtYWxm b3JtZWQgcGFja2V0LAorCQkgKiBidXQgd2UgY2Fubm90IGRpc2FibGUgdGhl IGludGVyZmFjZSBpbiBzb2Z0aXJxCisJCSAqIGNvbnRleHQgc28gd2UgZGVm ZXIgaXQgaGVyZS4KKwkJICovCisJCWlmICh1bmxpa2VseSh2aWYtPmRpc2Fi bGVkICYmIG5ldGlmX2NhcnJpZXJfb2sodmlmLT5kZXYpKSkKKwkJCXhlbnZp Zl9jYXJyaWVyX29mZih2aWYpOworCiAJCWlmIChrdGhyZWFkX3Nob3VsZF9z dG9wKCkpCiAJCQlicmVhazsKIAotLSAKMS43LjEwLjQKCg== --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Wed Apr 02 12:16:23 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 12:16:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVK4V-0001an-4j; Wed, 02 Apr 2014 12:15:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVK4S-0001aU-2u; Wed, 02 Apr 2014 12:15:08 +0000 Received: from [85.158.137.68:32570] by server-2.bemta-3.messagelabs.com id 44/D4-23530-B4FFB335; Wed, 02 Apr 2014 12:15:07 +0000 X-Env-Sender: Wuendsch@targosoft.de X-Msg-Ref: server-11.tower-31.messagelabs.com!1396440905!4509903!1 X-Originating-IP: [85.182.148.34] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23468 invoked from network); 2 Apr 2014 12:15:06 -0000 Received: from mail2.targosoft.de (HELO mail.targosoft.de) (85.182.148.34) by server-11.tower-31.messagelabs.com with SMTP; 2 Apr 2014 12:15:06 -0000 Received: from mail.targosoft.de (192.168.1.3) by mail.targosoft.de (192.168.1.7) GWAVA SMTP; Wed, 02 Apr 2014 14:15:06 +0200 X-Spam_ID: str=0001.0A0C0203.533BFF49.01EF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-GWAVADAT: MtCkVSJ3lTxI7aGu918f75a158ad3e950d3ca7de091b4360ce7c9b624f65bac31f0a9d6a097c513b16veoit.16veu5r.1c Received: from TargoSoft-MTA by mail.targosoft.de with Novell_GroupWise; Wed, 02 Apr 2014 14:15:05 +0200 Message-Id: <533C1B64020000D8000347FC@mail.targosoft.de> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 02 Apr 2014 14:15:00 +0200 From: "=?ISO-8859-15?Q?W=FCndsch=20Wolfgang?=" To: ,, , , "team Xen.org security" References: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartAB99CE54.2__=" Subject: [Xen-users] Antw: [Xen-announce] Xen Security Advisory 89 (CVE-2014-2599) - HVMOP_set_mem_access is not preemptible X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartAB99CE54.2__= Content-Type: multipart/alternative; boundary="=__PartAB99CE54.3__=" --=__PartAB99CE54.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable unsubscribe >>> Xen.org security team 02.04.2014 13:48 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-2599 / XSA-89 version 3 HVMOP_set_mem_access is not preemptible UPDATES IN VERSION 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This issue has been assigned CVE-2014-2599. ISSUE DESCRIPTION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Processing of the HVMOP_set_mem_access HVM control operations does not check the size of its input and can tie up a physical CPU for extended periods of time. IMPACT =3D=3D=3D=3D=3D=3D In a configuration where device models run with limited privilege (for example, stubdom device models), a guest attacker who successfully finds and exploits an unfixed security flaw in qemu-dm could leverage the other flaw into a Denial of Service affecting the whole host. In the more general case, in more abstract terms: a malicious administrator of a domain privileged with regard to an HVM guest can cause Xen to become unresponsive leading to a Denial of Service. VULNERABLE SYSTEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not available in 32-bit hypervisors). The vulnerability is only exposed to service domains for HVM guests which have privilege over the guest. In a usual configuration that means only device model emulators (qemu-dm). In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable. The situation is more subtle for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by "device_model_stubdomain_override=3D1" in the xl domain configuration file). The same applies with a qemu-dm in a dom0 process subjected to some kind kernel-based process privilege limitation (eg the chroot technique as found in some versions of XCP/XenServer). In those latter situations this issue means that the extra isolation does not provide as good a defence (against denial of service) as intended. That is the essence of this vulnerability. However, the security is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm. Finally, in a radically disaggregated system: where the HVM service domain software (probably, the device model domain image) is not always supplied by the host administrator, a malicious service domain administrator can excercise this vulnerability. MITIGATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Running only PV guests will avoid this vulnerability. In a radically disaggregated system, restricting HVM service domains to software images approved by the host administrator will avoid the vulnerability. CREDITS =3D=3D=3D=3D=3D=3D=3D This issue was discovered by Jan Beulich. RESOLUTION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Applying the appropriate attached patch resolves this issue. xsa89.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa89-4.1.patch Xen 4.1.x $ sha256sum xsa89*.patch 741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6 = xsa89.patch 7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e = xsa89-4.1.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw nmxJR+CIaIRhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/ sdqLT+TIVXElukse1CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa 4UhqMzU5zXnRi+53Ljn3dBximU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK /ZrxoP89VRiSZq0GiGrSouF6FjU6fWyP3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW63MT1tACToCf8ObT3RMTuAgfa0=3D =3DvHm/ -----END PGP SIGNATURE----- --=__PartAB99CE54.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML unsubscribe
>>> Xen.org security team <security@xen.org> 02.04.2014 = 13:48 >>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

          &nb= sp;  Xen Security Advisory CVE-2014-2599 / XSA-89
   = ;            &n= bsp;            = ;  version 3

        &n= bsp;     HVMOP_set_mem_access is not preemptible
UPDATES IN VERSION 3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

This issue has been assigned CVE-2014-2599.

ISSU= E DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Processing of the HVMOP_set_mem_access HVM control operations does = not
check the size of its input and can tie up a physical CPU for = extended
periods of time.

IMPACT
=3D=3D=3D=3D=3D=3D

In = a configuration where device models run with limited privilege (for
exam= ple, stubdom device models), a guest attacker who successfully
finds = and exploits an unfixed security flaw in qemu-dm could leverage
the = other flaw into a Denial of Service affecting the whole host.

In = the more general case, in more abstract terms: a malicious
administrator= of a domain privileged with regard to an HVM guest can
cause Xen to = become unresponsive leading to a Denial of Service.

VULNERABLE = SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Al= l Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit
versi= ons of the hypervisor are vulnerable (HVMOP_set_mem_access is not
availa= ble in 32-bit hypervisors).

The vulnerability is only exposed to = service domains for HVM guests
which have privilege over the guest. = ; In a usual configuration that
means only device model emulators = (qemu-dm).

In the case of HVM guests whose device model is running = in an
unrestricted dom0 process, qemu-dm already has the ability to = cause
problems for the whole system.  So in that case the = vulnerability is
not applicable.

The situation is more subtle = for an HVM guest with a stub qemu-dm.
That is, where the device model = runs in a separate domain (in the case
of xl, as requested by "device_mo= del_stubdomain_override=3D1" in the xl
domain configuration file). = The same applies with a qemu-dm in a dom0
process subjected to some = kind kernel-based process privilege
limitation (eg the chroot technique = as found in some versions of
XCP/XenServer).

In those latter = situations this issue means that the extra isolation
does not provide = as good a defence (against denial of service) as
intended.  That = is the essence of this vulnerability.

However, the security is = still better than with a qemu-dm running as
an unrestricted dom0 = process.  Therefore users with these
configurations should not = switch to an unrestricted dom0 qemu-dm.

Finally, in a radically = disaggregated system: where the HVM service
domain software (probably, = the device model domain image) is not
always supplied by the host = administrator, a malicious service domain
administrator can excercise = this vulnerability.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
Running only PV guests will avoid this vulnerability.

In a = radically disaggregated system, restricting HVM service domains
to = software images approved by the host administrator will avoid the
vulner= ability.

CREDITS
=3D=3D=3D=3D=3D=3D=3D

This issue was = discovered by Jan Beulich.

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Applying the appropriate attached patch resolves this issue.
=
xsa89.patch        xen-unstable, = Xen 4.4.x, Xen 4.3.x, Xen 4.2.x
xsa89-4.1.patch    Xen = 4.1.x

$ sha256sum xsa89*.patch
741c8fbbfa8e425d8debba17135d4c2e1e= 962d15717769bc93d68a65b5dc5ea6  xsa89.patch
7d965e9bf1894b7d909bfad= dbc6b7bdcee0ba91b86942ce85e0ae80464f2463e  xsa89-4.1.patch
$
---= --BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQE= cBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw
nmxJR+CIaI= RhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/
sdqLT+TIVXElukse1= CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa
4UhqMzU5zXnRi+53Ljn3dBxi= mU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK
/ZrxoP89VRiSZq0GiGrSouF6FjU6fWy= P3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C
dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW6= 3MT1tACToCf8ObT3RMTuAgfa0=3D
=3DvHm/
-----END PGP SIGNATURE-----
<= /BODY> --=__PartAB99CE54.3__=-- --=__PartAB99CE54.2__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=__PartAB99CE54.2__=-- From xen-users-bounces@lists.xen.org Wed Apr 02 12:16:23 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 12:16:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVK4V-0001an-4j; Wed, 02 Apr 2014 12:15:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVK4S-0001aU-2u; Wed, 02 Apr 2014 12:15:08 +0000 Received: from [85.158.137.68:32570] by server-2.bemta-3.messagelabs.com id 44/D4-23530-B4FFB335; Wed, 02 Apr 2014 12:15:07 +0000 X-Env-Sender: Wuendsch@targosoft.de X-Msg-Ref: server-11.tower-31.messagelabs.com!1396440905!4509903!1 X-Originating-IP: [85.182.148.34] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23468 invoked from network); 2 Apr 2014 12:15:06 -0000 Received: from mail2.targosoft.de (HELO mail.targosoft.de) (85.182.148.34) by server-11.tower-31.messagelabs.com with SMTP; 2 Apr 2014 12:15:06 -0000 Received: from mail.targosoft.de (192.168.1.3) by mail.targosoft.de (192.168.1.7) GWAVA SMTP; Wed, 02 Apr 2014 14:15:06 +0200 X-Spam_ID: str=0001.0A0C0203.533BFF49.01EF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-GWAVADAT: MtCkVSJ3lTxI7aGu918f75a158ad3e950d3ca7de091b4360ce7c9b624f65bac31f0a9d6a097c513b16veoit.16veu5r.1c Received: from TargoSoft-MTA by mail.targosoft.de with Novell_GroupWise; Wed, 02 Apr 2014 14:15:05 +0200 Message-Id: <533C1B64020000D8000347FC@mail.targosoft.de> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 02 Apr 2014 14:15:00 +0200 From: "=?ISO-8859-15?Q?W=FCndsch=20Wolfgang?=" To: ,, , , "team Xen.org security" References: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartAB99CE54.2__=" Subject: [Xen-users] Antw: [Xen-announce] Xen Security Advisory 89 (CVE-2014-2599) - HVMOP_set_mem_access is not preemptible X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartAB99CE54.2__= Content-Type: multipart/alternative; boundary="=__PartAB99CE54.3__=" --=__PartAB99CE54.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable unsubscribe >>> Xen.org security team 02.04.2014 13:48 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-2599 / XSA-89 version 3 HVMOP_set_mem_access is not preemptible UPDATES IN VERSION 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This issue has been assigned CVE-2014-2599. ISSUE DESCRIPTION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Processing of the HVMOP_set_mem_access HVM control operations does not check the size of its input and can tie up a physical CPU for extended periods of time. IMPACT =3D=3D=3D=3D=3D=3D In a configuration where device models run with limited privilege (for example, stubdom device models), a guest attacker who successfully finds and exploits an unfixed security flaw in qemu-dm could leverage the other flaw into a Denial of Service affecting the whole host. In the more general case, in more abstract terms: a malicious administrator of a domain privileged with regard to an HVM guest can cause Xen to become unresponsive leading to a Denial of Service. VULNERABLE SYSTEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit versions of the hypervisor are vulnerable (HVMOP_set_mem_access is not available in 32-bit hypervisors). The vulnerability is only exposed to service domains for HVM guests which have privilege over the guest. In a usual configuration that means only device model emulators (qemu-dm). In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable. The situation is more subtle for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by "device_model_stubdomain_override=3D1" in the xl domain configuration file). The same applies with a qemu-dm in a dom0 process subjected to some kind kernel-based process privilege limitation (eg the chroot technique as found in some versions of XCP/XenServer). In those latter situations this issue means that the extra isolation does not provide as good a defence (against denial of service) as intended. That is the essence of this vulnerability. However, the security is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm. Finally, in a radically disaggregated system: where the HVM service domain software (probably, the device model domain image) is not always supplied by the host administrator, a malicious service domain administrator can excercise this vulnerability. MITIGATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Running only PV guests will avoid this vulnerability. In a radically disaggregated system, restricting HVM service domains to software images approved by the host administrator will avoid the vulnerability. CREDITS =3D=3D=3D=3D=3D=3D=3D This issue was discovered by Jan Beulich. RESOLUTION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Applying the appropriate attached patch resolves this issue. xsa89.patch xen-unstable, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa89-4.1.patch Xen 4.1.x $ sha256sum xsa89*.patch 741c8fbbfa8e425d8debba17135d4c2e1e962d15717769bc93d68a65b5dc5ea6 = xsa89.patch 7d965e9bf1894b7d909bfaddbc6b7bdcee0ba91b86942ce85e0ae80464f2463e = xsa89-4.1.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw nmxJR+CIaIRhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/ sdqLT+TIVXElukse1CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa 4UhqMzU5zXnRi+53Ljn3dBximU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK /ZrxoP89VRiSZq0GiGrSouF6FjU6fWyP3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW63MT1tACToCf8ObT3RMTuAgfa0=3D =3DvHm/ -----END PGP SIGNATURE----- --=__PartAB99CE54.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML unsubscribe
>>> Xen.org security team <security@xen.org> 02.04.2014 = 13:48 >>>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

          &nb= sp;  Xen Security Advisory CVE-2014-2599 / XSA-89
   = ;            &n= bsp;            = ;  version 3

        &n= bsp;     HVMOP_set_mem_access is not preemptible
UPDATES IN VERSION 3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

This issue has been assigned CVE-2014-2599.

ISSU= E DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Processing of the HVMOP_set_mem_access HVM control operations does = not
check the size of its input and can tie up a physical CPU for = extended
periods of time.

IMPACT
=3D=3D=3D=3D=3D=3D

In = a configuration where device models run with limited privilege (for
exam= ple, stubdom device models), a guest attacker who successfully
finds = and exploits an unfixed security flaw in qemu-dm could leverage
the = other flaw into a Denial of Service affecting the whole host.

In = the more general case, in more abstract terms: a malicious
administrator= of a domain privileged with regard to an HVM guest can
cause Xen to = become unresponsive leading to a Denial of Service.

VULNERABLE = SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Al= l Xen versions from 4.1 onwards are vulnerable. In 4.2 only 64-bit
versi= ons of the hypervisor are vulnerable (HVMOP_set_mem_access is not
availa= ble in 32-bit hypervisors).

The vulnerability is only exposed to = service domains for HVM guests
which have privilege over the guest. = ; In a usual configuration that
means only device model emulators = (qemu-dm).

In the case of HVM guests whose device model is running = in an
unrestricted dom0 process, qemu-dm already has the ability to = cause
problems for the whole system.  So in that case the = vulnerability is
not applicable.

The situation is more subtle = for an HVM guest with a stub qemu-dm.
That is, where the device model = runs in a separate domain (in the case
of xl, as requested by "device_mo= del_stubdomain_override=3D1" in the xl
domain configuration file). = The same applies with a qemu-dm in a dom0
process subjected to some = kind kernel-based process privilege
limitation (eg the chroot technique = as found in some versions of
XCP/XenServer).

In those latter = situations this issue means that the extra isolation
does not provide = as good a defence (against denial of service) as
intended.  That = is the essence of this vulnerability.

However, the security is = still better than with a qemu-dm running as
an unrestricted dom0 = process.  Therefore users with these
configurations should not = switch to an unrestricted dom0 qemu-dm.

Finally, in a radically = disaggregated system: where the HVM service
domain software (probably, = the device model domain image) is not
always supplied by the host = administrator, a malicious service domain
administrator can excercise = this vulnerability.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
Running only PV guests will avoid this vulnerability.

In a = radically disaggregated system, restricting HVM service domains
to = software images approved by the host administrator will avoid the
vulner= ability.

CREDITS
=3D=3D=3D=3D=3D=3D=3D

This issue was = discovered by Jan Beulich.

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Applying the appropriate attached patch resolves this issue.
=
xsa89.patch        xen-unstable, = Xen 4.4.x, Xen 4.3.x, Xen 4.2.x
xsa89-4.1.patch    Xen = 4.1.x

$ sha256sum xsa89*.patch
741c8fbbfa8e425d8debba17135d4c2e1e= 962d15717769bc93d68a65b5dc5ea6  xsa89.patch
7d965e9bf1894b7d909bfad= dbc6b7bdcee0ba91b86942ce85e0ae80464f2463e  xsa89-4.1.patch
$
---= --BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQE= cBAEBAgAGBQJTO+8wAAoJEIP+FMlX6CvZ5esH/3T+ajm7vltauel3SR3+wQAw
nmxJR+CIaI= RhIdjER/EPJ8HRqCl8DvY1yY8MM9qo70RIGu9eHSxkKbPQzNa1ye8/
sdqLT+TIVXElukse1= CxSPnHkw0NYOjysdTxDs9XGFzTA2qzYj9cLu6qKbh8wKOqa
4UhqMzU5zXnRi+53Ljn3dBxi= mU2Fch7ibN5Ea5C2e4uPJHR8aNn31lCESnsUfwbK
/ZrxoP89VRiSZq0GiGrSouF6FjU6fWy= P3pTfvrFtQ0/K7a+HuA3ZgT35iGVdVW2C
dV35iNqIn+yC8vUrcEZkdfp/KapRP3WqCetoW6= 3MT1tACToCf8ObT3RMTuAgfa0=3D
=3DvHm/
-----END PGP SIGNATURE-----
<= /BODY> --=__PartAB99CE54.3__=-- --=__PartAB99CE54.2__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=__PartAB99CE54.2__=-- From xen-users-bounces@lists.xen.org Wed Apr 02 14:46:35 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 14:46:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVMPw-0003IK-UV; Wed, 02 Apr 2014 14:45:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVMPv-0003Hy-9H for xen-users@lists.xenproject.org; Wed, 02 Apr 2014 14:45:27 +0000 Received: from [85.158.143.35:14795] by server-1.bemta-4.messagelabs.com id 39/65-09853-6822C335; Wed, 02 Apr 2014 14:45:26 +0000 X-Env-Sender: Ian.Jackson@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1396449924!6486931!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1816 invoked from network); 2 Apr 2014 14:45:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Apr 2014 14:45:25 -0000 X-IronPort-AV: E=Sophos;i="4.97,780,1389744000"; d="scan'208";a="116119341" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Apr 2014 14:45:25 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Wed, 2 Apr 2014 10:45:23 -0400 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1WVMPr-0004GH-O8; Wed, 02 Apr 2014 14:45:23 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80) (envelope-from ) id 1WVMPc-0003T8-Ng; Wed, 02 Apr 2014 15:45:08 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <21308.8800.653127.798603@mariner.uk.xensource.com> Date: Wed, 2 Apr 2014 15:44:48 +0100 To: Atom2 , Konrad Rzeszutek Wilk , Boris Ostrovsky , David Vrabel In-Reply-To: <532C9556.9070806@web2web.at> References: <5325B828.1060303@web2web.at> <1395050430.4122.29.camel@kazak.uk.xensource.com> <53273B3C.40707@web2web.at> <1395137709.12847.29.camel@kazak.uk.xensource.com> <5328439B.8050807@web2web.at> <1395155249.12847.66.camel@kazak.uk.xensource.com> <5328E403.8010506@web2web.at> <1395228384.10203.65.camel@kazak.uk.xensource.com> <20140319130002.GC8694@phenom.dumpdata.com> <5329A3C0.3000609@web2web.at> <21289.48007.604643.322509@mariner.uk.xensource.com> <532A530D.1050504@web2web.at> <21290.54937.269235.163107@mariner.uk.xensource.com> <532B425F.4010701@web2web.at> <21292.32952.592138.804266@mariner.uk.xensource.com> <532C9556.9070806@web2web.at> X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu) X-DLP: MIA2 Cc: xen-users@lists.xenproject.org, xen-devel , Ian Campbell , Roger Pau Monne Subject: Re: [Xen-users] [Xen-devel] substantial shutdown delay for PV guests with PCI -passthrough X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Atom2 writes ("Re: [Xen-devel] [Xen-users] substantial shutdown delay for PV guests with PCI -passthrough"): > Am 21.03.14 19:11, schrieb Ian Jackson: > > Can you run it again with this, on top of the previous patch, please ? > > Sure, the new output of xl -vvv create -F domain is again attached to > this e-Mail. Sorry for the delay replying. I have been ill :-(. > > libxl: error: libxl_device.c:1134:libxl__wait_for_backend_deprecated: Backend /local/domain/0/backend/pci/4/0 not ready (state 7) > libxl: error: libxl_device.c:1138:libxl__wait_for_backend_deprecated: FE /local/domain/4/device/pci/0 state 6 > libxl: debug: libxl_pci.c:204:libxl__device_pci_remove_xenstore: pci backend at /local/domain/0/backend/pci/4/0 is not ready > libxl: error: libxl_pci.c:1250:do_pci_remove: xc_domain_irq_permission irq=16 So the backend here is in state 7 (Reconfiguring), but the frontend is in state 6 (Closed). I think this is a bug in pciback. I looked at drivers/xen/xen-pciback/xenbus.c in Linux 3.13 and found xen_pcibk_frontend_changed which seems to do roughly what I would expect. Has this changed at some point ? Atom, what kernel are you using ? Thanks, Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Apr 02 14:46:35 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Apr 2014 14:46:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVMPw-0003IK-UV; Wed, 02 Apr 2014 14:45:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVMPv-0003Hy-9H for xen-users@lists.xenproject.org; Wed, 02 Apr 2014 14:45:27 +0000 Received: from [85.158.143.35:14795] by server-1.bemta-4.messagelabs.com id 39/65-09853-6822C335; Wed, 02 Apr 2014 14:45:26 +0000 X-Env-Sender: Ian.Jackson@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1396449924!6486931!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1816 invoked from network); 2 Apr 2014 14:45:25 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Apr 2014 14:45:25 -0000 X-IronPort-AV: E=Sophos;i="4.97,780,1389744000"; d="scan'208";a="116119341" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Apr 2014 14:45:25 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Wed, 2 Apr 2014 10:45:23 -0400 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1WVMPr-0004GH-O8; Wed, 02 Apr 2014 14:45:23 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.80) (envelope-from ) id 1WVMPc-0003T8-Ng; Wed, 02 Apr 2014 15:45:08 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <21308.8800.653127.798603@mariner.uk.xensource.com> Date: Wed, 2 Apr 2014 15:44:48 +0100 To: Atom2 , Konrad Rzeszutek Wilk , Boris Ostrovsky , David Vrabel In-Reply-To: <532C9556.9070806@web2web.at> References: <5325B828.1060303@web2web.at> <1395050430.4122.29.camel@kazak.uk.xensource.com> <53273B3C.40707@web2web.at> <1395137709.12847.29.camel@kazak.uk.xensource.com> <5328439B.8050807@web2web.at> <1395155249.12847.66.camel@kazak.uk.xensource.com> <5328E403.8010506@web2web.at> <1395228384.10203.65.camel@kazak.uk.xensource.com> <20140319130002.GC8694@phenom.dumpdata.com> <5329A3C0.3000609@web2web.at> <21289.48007.604643.322509@mariner.uk.xensource.com> <532A530D.1050504@web2web.at> <21290.54937.269235.163107@mariner.uk.xensource.com> <532B425F.4010701@web2web.at> <21292.32952.592138.804266@mariner.uk.xensource.com> <532C9556.9070806@web2web.at> X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu) X-DLP: MIA2 Cc: xen-users@lists.xenproject.org, xen-devel , Ian Campbell , Roger Pau Monne Subject: Re: [Xen-users] [Xen-devel] substantial shutdown delay for PV guests with PCI -passthrough X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Atom2 writes ("Re: [Xen-devel] [Xen-users] substantial shutdown delay for PV guests with PCI -passthrough"): > Am 21.03.14 19:11, schrieb Ian Jackson: > > Can you run it again with this, on top of the previous patch, please ? > > Sure, the new output of xl -vvv create -F domain is again attached to > this e-Mail. Sorry for the delay replying. I have been ill :-(. > > libxl: error: libxl_device.c:1134:libxl__wait_for_backend_deprecated: Backend /local/domain/0/backend/pci/4/0 not ready (state 7) > libxl: error: libxl_device.c:1138:libxl__wait_for_backend_deprecated: FE /local/domain/4/device/pci/0 state 6 > libxl: debug: libxl_pci.c:204:libxl__device_pci_remove_xenstore: pci backend at /local/domain/0/backend/pci/4/0 is not ready > libxl: error: libxl_pci.c:1250:do_pci_remove: xc_domain_irq_permission irq=16 So the backend here is in state 7 (Reconfiguring), but the frontend is in state 6 (Closed). I think this is a bug in pciback. I looked at drivers/xen/xen-pciback/xenbus.c in Linux 3.13 and found xen_pcibk_frontend_changed which seems to do roughly what I would expect. Has this changed at some point ? Atom, what kernel are you using ? Thanks, Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Apr 03 14:40:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Apr 2014 14:40:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVin7-0006Ks-Qe; Thu, 03 Apr 2014 14:38:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVin6-0006Kg-68 for xen-users@lists.xen.org; Thu, 03 Apr 2014 14:38:52 +0000 Received: from [85.158.143.35:56890] by server-1.bemta-4.messagelabs.com id 40/CA-09853-B727D335; Thu, 03 Apr 2014 14:38:51 +0000 X-Env-Sender: aasthakm@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1396535929!6069631!1 X-Originating-IP: [209.85.216.177] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20322 invoked from network); 3 Apr 2014 14:38:50 -0000 Received: from mail-qc0-f177.google.com (HELO mail-qc0-f177.google.com) (209.85.216.177) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Apr 2014 14:38:50 -0000 Received: by mail-qc0-f177.google.com with SMTP id w7so1935553qcr.22 for ; Thu, 03 Apr 2014 07:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N4lwCAG5elj23wlI2OE92GKcuFvpQAJPpfweS/5RjMA=; b=d0gWa6GOXEiDRoGlxdVx3jKu61iG36UKiG1yKVho9DQ0IReeJqWmBPRIWwX1fKOdPL yk2qOnsOR92KFnlLg2YI6CT2Y53iiRU90zBEpkXJqz2QkVpEi21hOkBRtIMd8a78TQK3 6sEuTuZjQ4Whz7BquuZb9WDAyOhOHOE+8S3PoV0qSIRsykLqu+Fe0f9o6MqlK2ITtzO0 k1Dx1rs/xR0W+0Vbs98grBUtm4QDuCBL4alPuQnTxhB3arUVoYVDexsxpzz2bUR3htUj oJTt9fFf2/YUv9YCgndmdhU/8QmovCQ40ueOrEnHO+uSEpU20dpipX1LBLRvsjBPy3ed 7E5Q== X-Received: by 10.140.97.137 with SMTP id m9mr2337813qge.95.1396535929626; Thu, 03 Apr 2014 07:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.92.107 with HTTP; Thu, 3 Apr 2014 07:38:29 -0700 (PDT) In-Reply-To: <1396266837.8667.18.camel@kazak.uk.xensource.com> References: <1395939526.22909.210.camel@kazak.uk.xensource.com> <1396263585.8667.8.camel@kazak.uk.xensource.com> <1396266837.8667.18.camel@kazak.uk.xensource.com> From: Aastha Mehta Date: Thu, 3 Apr 2014 16:38:29 +0200 Message-ID: To: Ian Campbell Cc: xen-users Subject: Re: [Xen-users] pv-grub installation problem X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 31 March 2014 13:53, Ian Campbell wrote: > On Mon, 2014-03-31 at 13:44 +0200, Aastha Mehta wrote: >> I tried few grub commands, but it doesn't find any of the files, >> devices, anything. What you hinted at may be true - that the config >> file is not being read at all. I will investigate from that point. > > I just booted and at the grubdom prompt tried the "menu (hd" command and > tab, which said: > > grubdom> root (hd > Possible disks are: hd0 hd1 > > so I tried hd0: > grubdom> root (hd0) > Filesystem type unknown, using whole disk > > No good. So I tried hd1: > grubdom> root (hd1) > Filesystem type is ext2fs, using whole disk > > This is using > disk = [ > 'phy:/dev/cam-st16/debian.guest.osstest-disk,xvda2,w', > 'phy:/dev/cam-st16/debian.guest.osstest-swap,xvda1,w', > ] > > I think what has happened is that xvda1 => hd0 and xvda2 => hd1. > > My guest is setup for booting from a dom0 kernel, so my /boot is empty, > so I can't go much further, but perhaps this will help you make > progress. > > Ian. > Wow, I didn't think of trying that. And indeed it works! Thanks a lot! Regards, Aastha. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Apr 03 14:40:12 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Apr 2014 14:40:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVin7-0006Ks-Qe; Thu, 03 Apr 2014 14:38:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVin6-0006Kg-68 for xen-users@lists.xen.org; Thu, 03 Apr 2014 14:38:52 +0000 Received: from [85.158.143.35:56890] by server-1.bemta-4.messagelabs.com id 40/CA-09853-B727D335; Thu, 03 Apr 2014 14:38:51 +0000 X-Env-Sender: aasthakm@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1396535929!6069631!1 X-Originating-IP: [209.85.216.177] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20322 invoked from network); 3 Apr 2014 14:38:50 -0000 Received: from mail-qc0-f177.google.com (HELO mail-qc0-f177.google.com) (209.85.216.177) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Apr 2014 14:38:50 -0000 Received: by mail-qc0-f177.google.com with SMTP id w7so1935553qcr.22 for ; Thu, 03 Apr 2014 07:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N4lwCAG5elj23wlI2OE92GKcuFvpQAJPpfweS/5RjMA=; b=d0gWa6GOXEiDRoGlxdVx3jKu61iG36UKiG1yKVho9DQ0IReeJqWmBPRIWwX1fKOdPL yk2qOnsOR92KFnlLg2YI6CT2Y53iiRU90zBEpkXJqz2QkVpEi21hOkBRtIMd8a78TQK3 6sEuTuZjQ4Whz7BquuZb9WDAyOhOHOE+8S3PoV0qSIRsykLqu+Fe0f9o6MqlK2ITtzO0 k1Dx1rs/xR0W+0Vbs98grBUtm4QDuCBL4alPuQnTxhB3arUVoYVDexsxpzz2bUR3htUj oJTt9fFf2/YUv9YCgndmdhU/8QmovCQ40ueOrEnHO+uSEpU20dpipX1LBLRvsjBPy3ed 7E5Q== X-Received: by 10.140.97.137 with SMTP id m9mr2337813qge.95.1396535929626; Thu, 03 Apr 2014 07:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.92.107 with HTTP; Thu, 3 Apr 2014 07:38:29 -0700 (PDT) In-Reply-To: <1396266837.8667.18.camel@kazak.uk.xensource.com> References: <1395939526.22909.210.camel@kazak.uk.xensource.com> <1396263585.8667.8.camel@kazak.uk.xensource.com> <1396266837.8667.18.camel@kazak.uk.xensource.com> From: Aastha Mehta Date: Thu, 3 Apr 2014 16:38:29 +0200 Message-ID: To: Ian Campbell Cc: xen-users Subject: Re: [Xen-users] pv-grub installation problem X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 31 March 2014 13:53, Ian Campbell wrote: > On Mon, 2014-03-31 at 13:44 +0200, Aastha Mehta wrote: >> I tried few grub commands, but it doesn't find any of the files, >> devices, anything. What you hinted at may be true - that the config >> file is not being read at all. I will investigate from that point. > > I just booted and at the grubdom prompt tried the "menu (hd" command and > tab, which said: > > grubdom> root (hd > Possible disks are: hd0 hd1 > > so I tried hd0: > grubdom> root (hd0) > Filesystem type unknown, using whole disk > > No good. So I tried hd1: > grubdom> root (hd1) > Filesystem type is ext2fs, using whole disk > > This is using > disk = [ > 'phy:/dev/cam-st16/debian.guest.osstest-disk,xvda2,w', > 'phy:/dev/cam-st16/debian.guest.osstest-swap,xvda1,w', > ] > > I think what has happened is that xvda1 => hd0 and xvda2 => hd1. > > My guest is setup for booting from a dom0 kernel, so my /boot is empty, > so I can't go much further, but perhaps this will help you make > progress. > > Ian. > Wow, I didn't think of trying that. And indeed it works! Thanks a lot! Regards, Aastha. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Apr 03 20:29:51 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Apr 2014 20:29:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVoFR-0006vh-IN; Thu, 03 Apr 2014 20:28:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVikJ-0006Ig-4I; Thu, 03 Apr 2014 14:35:59 +0000 Received: from [85.158.139.211:13152] by server-16.bemta-5.messagelabs.com id 5E/9F-19700-CC17D335; Thu, 03 Apr 2014 14:35:56 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1396535755!5277948!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17213 invoked from network); 3 Apr 2014 14:35:55 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Apr 2014 14:35:55 -0000 Received: by mail-lb0-f171.google.com with SMTP id w7so1397490lbi.2 for ; Thu, 03 Apr 2014 07:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=p2s3fFDEiNEY+nQXwehdSOnBQsfgzPpElLF2m4cOsj8=; b=X4xSdCY7IEAKX65plHvKlFCF0Ln09+MF4FbQH+eWA4rReRRg71kyciB5mhBFmwObDk Mo+g0TqbDAIQgtOL14tTmX989DL1hXLVjvEJ6peJgf1XQIh/7+SwGMv4EtV2LbRqtQZk ZSH6iyHjcOIDvXqKWE7QzrMJ+VdT0nnMfOkl5r0kIK9tamm1Mmw3K5TE4DgTwFNCD+Wt +Vb2p5pDskbxw0hEt+RuyiEfpKnDG6c/P6xCeo6RbmDl5GzU80SDyGECur0luZRWogsC K3UXKkj3g8tKnODokB9n8VOCRB7sbmwYlVWU+FiiSUQ6S9VkY4On5QFMznbiSS9/cqoq 772g== MIME-Version: 1.0 X-Received: by 10.112.131.65 with SMTP id ok1mr1548458lbb.51.1396535755177; Thu, 03 Apr 2014 07:35:55 -0700 (PDT) Received: by 10.112.29.49 with HTTP; Thu, 3 Apr 2014 07:35:55 -0700 (PDT) Date: Thu, 3 Apr 2014 10:35:55 -0400 X-Google-Sender-Auth: ufXXJu2ROKftmlfZCS85OdouvHg Message-ID: From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-api@lists.xen.org, cl-mirage@lists.cam.ac.uk, xs-devel@lists.xenserver.org X-Mailman-Approved-At: Thu, 03 Apr 2014 20:28:28 +0000 Subject: [Xen-users] Biggest contributors to Xen Project Documentation Day X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Monday, March 31, was Xen Project Documentation Day. Thank you to all who participated! Some of the most notable contributors included: George Dunlap, whose work included improvements to the http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen . Ian Campbell, who worked on http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling and Lars Kurth, who modified a few pages including grooming of the TODO list at http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO If you didn't get a chance to join in this time, please join us on April 28 for our next Documentation Day. Thank you again! Russ _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Apr 03 20:29:51 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Apr 2014 20:29:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVoFR-0006vh-IN; Thu, 03 Apr 2014 20:28:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVikJ-0006Ig-4I; Thu, 03 Apr 2014 14:35:59 +0000 Received: from [85.158.139.211:13152] by server-16.bemta-5.messagelabs.com id 5E/9F-19700-CC17D335; Thu, 03 Apr 2014 14:35:56 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1396535755!5277948!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=2.5 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17213 invoked from network); 3 Apr 2014 14:35:55 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Apr 2014 14:35:55 -0000 Received: by mail-lb0-f171.google.com with SMTP id w7so1397490lbi.2 for ; Thu, 03 Apr 2014 07:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=p2s3fFDEiNEY+nQXwehdSOnBQsfgzPpElLF2m4cOsj8=; b=X4xSdCY7IEAKX65plHvKlFCF0Ln09+MF4FbQH+eWA4rReRRg71kyciB5mhBFmwObDk Mo+g0TqbDAIQgtOL14tTmX989DL1hXLVjvEJ6peJgf1XQIh/7+SwGMv4EtV2LbRqtQZk ZSH6iyHjcOIDvXqKWE7QzrMJ+VdT0nnMfOkl5r0kIK9tamm1Mmw3K5TE4DgTwFNCD+Wt +Vb2p5pDskbxw0hEt+RuyiEfpKnDG6c/P6xCeo6RbmDl5GzU80SDyGECur0luZRWogsC K3UXKkj3g8tKnODokB9n8VOCRB7sbmwYlVWU+FiiSUQ6S9VkY4On5QFMznbiSS9/cqoq 772g== MIME-Version: 1.0 X-Received: by 10.112.131.65 with SMTP id ok1mr1548458lbb.51.1396535755177; Thu, 03 Apr 2014 07:35:55 -0700 (PDT) Received: by 10.112.29.49 with HTTP; Thu, 3 Apr 2014 07:35:55 -0700 (PDT) Date: Thu, 3 Apr 2014 10:35:55 -0400 X-Google-Sender-Auth: ufXXJu2ROKftmlfZCS85OdouvHg Message-ID: From: Russ Pavlicek To: xen-devel@lists.xen.org, "xen-users@lists.xen.org" , xen-api@lists.xen.org, cl-mirage@lists.cam.ac.uk, xs-devel@lists.xenserver.org X-Mailman-Approved-At: Thu, 03 Apr 2014 20:28:28 +0000 Subject: [Xen-users] Biggest contributors to Xen Project Documentation Day X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Monday, March 31, was Xen Project Documentation Day. Thank you to all who participated! Some of the most notable contributors included: George Dunlap, whose work included improvements to the http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen . Ian Campbell, who worked on http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling and Lars Kurth, who modified a few pages including grooming of the TODO list at http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO If you didn't get a chance to join in this time, please join us on April 28 for our next Documentation Day. Thank you again! Russ _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Apr 03 22:21:19 2014 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Apr 2014 22:21:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVpzY-0007Y6-FW; Thu, 03 Apr 2014 22:20:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WVpzW-0007Y1-Lc for xen-users@lists.xen.org; Thu, 03 Apr 2014 22:20:10 +0000 Received: from [193.109.254.147:50513] by server-8.bemta-14.messagelabs.com id 75/EC-01877-99EDD335; Thu, 03 Apr 2014 22:20:09 +0000 X-Env-Sender: chris@teria.org X-Msg-Ref: server-4.tower-27.messagelabs.com!1396563609!6184063!1 X-Originating-IP: [212.83.166.54] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15175 invoked from network); 3 Apr 2014 22:20:09 -0000 Received: from mail.thinkrosystem.com (HELO thinkrosystem.com) (212.83.166.54) by server-4.tower-27.messagelabs.com with SMTP; 3 Apr 2014 22:20:09 -0000 Received: from localhost (localhost [127.0.0.1]) by thinkrosystem.com (Postfix) with ESMTP id 0875F9194; Fri, 4 Apr 2014 00:20:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at thinkrosystem.com Received: from thinkrosystem.com ([127.0.0.1]) by localhost (mail.thinkrosystem.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ5VefpLz1z7; Fri, 4 Apr 2014 00:20:04 +0200 (CEST) Received: from station.paris.ld (unknown [78.193.164.81]) by thinkrosystem.com (Postfix) with ESMTPSA id BB49B919D; Fri, 4 Apr 2014 00:20:04 +0200 (CEST) Date: Fri, 4 Apr 2014 00:20:02 +0200 From: Chris To: kevin.zhang@octlink.com" Message-ID: <20140404002002.593eef2f@station.paris.ld> In-Reply-To: <2014033111243700162056@octlink.com> References: <2014033111243700162056@octlink.com> Organization: Teria X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-slackware-linux-gnu) Mime-Version: 1.0 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Does anyone create HVM with libvirt successfully with xl of Xen 4.3+ X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 31 Mar 2014 11:24:38 +0800 "kevin.zhang@octlink.com" wrote: > Hi, Everyone, > > I sent a email about questions on libvirt configuration guide for Xen 4.4, but received no further information. > Could anyone give me any libvirt examples to make libvirt create HVM vm based on xen 4.4-xl? > Thank you very much! > > Hi, This example works with Xen 4.4.0, Libvirt 1.2.2 and Openvswitch 2.0.0 : example 524288 524288 1 hvm /usr/lib/xen/boot/hvmloader destroy restart restart /usr/lib/xen/bin/qemu-system-i386