From sacadmin Wed Feb 25 01:57:25 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1P9vPup017061; Wed, 25 Feb 2009 01:57:25 -0800 (PST) Received: (from eh146360@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n1P9vPj7017057; Wed, 25 Feb 2009 01:57:25 -0800 (PST) Date: Wed, 25 Feb 2009 01:57:25 -0800 (PST) From: En-Hua Cecilia Hu Message-Id: <200902250957.n1P9vPj7017057@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Bandwidth Limit for Virtual Interface [PSARC/2009/137 FastTrack timeout 03/04/2009] Status: RO Content-Length: 570 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bandwidth Limit for Virtual Interface 1.2. Name of Document Author/Supplier: Author: Max Zhen 1.3 Date of This Document: 25 February, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Cecilia.Hu@Sun.COM Wed Feb 25 02:57:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PAvKts018818 for ; Wed, 25 Feb 2009 02:57:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1PAvIae022698 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 25 Feb 2009 10:57:19 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM00001BRIGR00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 02:57:18 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00GHQBRFUH70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 02:57:16 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1PAvFtj007125 for ; Wed, 25 Feb 2009 10:57:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFM00E00BQSVC00@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 18:57:15 +0800 (SGT) Received: from [129.158.218.98] ([unknown] [129.158.218.98]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFM00G87BRECAJ0@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 18:57:15 +0800 (SGT) Date: Wed, 25 Feb 2009 18:55:04 +0800 From: Cecilia Hu Subject: PSARC 2009/137 Bandwidth Limit for Virtual Interface Sender: Cecilia.Hu@Sun.COM To: psarc-ext@Sun.COM Cc: Max Zhen Reply-to: Cecilia.Hu@Sun.COM Message-id: <49A52388.2040401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 9642 I am sponsoring this case for Max Zhen. The requested release binding is minor, timer is set to 03/04/2009. All documents are already in case directory for your reference. -Cecilia This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Bandwidth limit for virtual interface 1.2. Name of Document Author/Supplier: Author: Max Zhen 1.3 Date of This Document: 25 February, 2009 4. Technical Description 4.1. Summary In this fast-track, we plan to support applying bandwidth limit for Virtual network interfaces attached to a guest domain running on Xen hypervisor. Minor release binding is requested. 4.2. Discussion After Crossbow(PSARC/2006/357)'s integration into Nevada, it's possible to enforce bandwidth limit for a guest domain from Solaris dom0 by setting bandwidth property of a back end NIC device attached to the domain. In this fast-track, we plan to enhance existing management tools to leverage dladm(1M) and its 'maxbw' property to set bandwidth limit for virtual network interfaces for domains running on top of Xen hypervisor. With the integration of porting Solaris to run on Xen(PSARC/2006/260), three external management tools are also ported and integrated into Solaris: virsh(1M)(PSARC 2007/157), xm(1M)(PSARC/2006/260) and virt-install(1M) (LSARC/2007/175). Virsh(1M) and xm(1M) commands are user interfaces of domain management and virt-install(1M) are used to install guest domains. These three tools currently have user interfaces for specifying configurations for virtual interfaces for a guest domain. So, they are going to be enhanced to support specifying bandwidth limit while defining a configuration of a virtual network interface. I will discuss about each of them in following sections. Note: please refer to the design doc[1] in case directory for detailed information. 4.2.1 Management tool architecture The architecture of management tools for virtual network interface can be illustrated as below: virsh ---------+ v virt-install ----> virtd | V xend --> vif-vnic/vif-dedicated ^ xm ---------+ So, from above graph, we can see that virtual interface configuration will be passed to xend(1M) directly by xm. While, configuration will be passed to virtd (see PSARC 2008/165), who will pass it to xend. But, no matter where does the configuration come from, xend will collect all configuration and pass them to either /usr/lib/xen/scripts/vif-vnic or /usr/lib/xen/scripts/vif-dedicated, which are shell scripts to set up back end NIC device based on the configuraion for the corresponding virtual interface of the guest domain. 4.2.2 Xm(1M) Xm command has already supported specifying bandwidth limit for virtual interface. But, due to the limitation of vif-vnic and vif-dedicated scripts, the bandwidth specified in xm command line or in '.py' configuration file for guest domain has no effect. So, we need to enhance vif-vnic and vif-dedicated scripts to be able to parse out bandwidth information in configuration from xend and issue appropriate dladm command to set bandwidth value as 'maxbw' property for the corresponding NIC device serve as the back end device for the virtual network interface. Thus, we can apply bandwidth limit for a virtual interface of guest domain. There is no intention to do any change to xm UI and the data format of the configuration from xend. The command line tool used by vif-vnic and vif-dedicated will be switched from /usr/lib/vna to /sbin/dladm due to lack of needed functionality of vna. Note: please refer to the xm.man.diff.bw.txt[2] in case directory for the difference. 4.2.3 Virsh(1M) There are two ways for end user to provide bandwidth limit information to virsh: + via 'virsh attach-interface' command line + via guest domain configuration file in XML format But, neither of them support specifying bandwidth limit information. So, we need to enhance both of them. We need to add one more option - "--rate" to 'virsh attach-interface' command line syntax to allow end user to provide bandwidth limit information while adding(attaching) a new virtual interface to a guest domain: --rate , where 'rate_string' is an integer with one of the scale suffixes K, M, or G for Kbps, Mbps, or Gbps (the same format as used by dladm). 'Virsh create' and 'virsh define' are two commands that interact with XML format guest domain configuration file as a whole. So, we also need to extend current configuration file format to allow end user to provide bandwidth limit. In order to insert bandwidth information into XML file, we create a new element, "networkresource", inside "interface" element. Inside "networkresource", users provide bandwidth by setting "rate" element with three attributes, "unit", "period" and "value" to express the bandwidth limit. For example (100Mb/s): [...cut...] [...cut...] The supported unit can be 'gigabit', 'megabit' and 'kilobit'. The supported period can be 'second', 'millisecond' and 'microsecond'. And value is an integer to express the amount of data in unit allowed to be transferred in the specified period of time. We can easily add more network resource limit in it by adding more element inside "networkresource" element in this format later, if needed. We also communicate this extention back to community and there is no objection. Note: please refer to the virsh.man.diff.bw.txt[3] in case directory for the difference. 4.2.4 virt-install(1M) Virt-install currently does not support specifying bandwidth limit. We need to extend its command line syntax to allow it to be specified by end users. We may simply add one more option, "--rate=", to current virt-install option list to allow providing bandwidth information. But, since the option list of virt-install are already too long, keep adding options to it will just make situation worse. After consult with the community, we decide to group network related options into one option, "-w or --network", and turns original options into properties of this option separated by comma. So, before, a virt-install command line can look like: #virt-install ...--mac a:b:c:d:e:f --bridge bge0 --rate 100M/s \ --mac g:h:i:j:k:l --bridge bge1 --rate 200M/s... Now, it looks like: #virt-install ...--network mac=a:b:c:d:e:f,bridge=bge0,rate=100M/s \ --network mac=g:h:i:j:k:l,bridge=bge1,rate=200M/s... So, by using new syntax, it will be easier to add more properties for virtual interfaces in the future and will be clearer when we try to specify configurations for multiple virtual interfaces. Currently, we support three properties of "-w/--network" option: 'mac', 'bridge' and 'rate'. The first two are converted from current options, while the last one, 'rate', is added for specifying bandwidth limit (in the same format used in virsh command line). We will only support specifying bandwidth limit as an property, not as an option. Note: please refer to the virt-install.man.diff.bw.txt[4] in case directory for the difference. 4.3. Interfaces Exported interfaces: ----------------------------------------------------------------------+ | Interface | Stability | Comments | +-------------------------------+---------------+---------------------+ | --rate option for virsh(1M) | Uncommitted | | | | | | | new -w/--network syntax and | | | | 'rate' property of | | | | virt-install(1M) | volatile | | | | | | | "networkresource" and "rate" | | | | elements in XML | | | | configuration file | Uncommitted | | +-------------------------------+---------------+---------------------+ Imported interfaces: ----------------------------------------------------------------------- | Interface | Stability | Comments | +-------------------------------+---------------+---------------------+ | dladm(1M) | Committed | | | | | | | bandwidth representation | | | | from xend(1M) (in xenstore) | External | | +-------------------------------+---------------+---------------------+ 5. References PSARC 2006/260 Solaris on Xen PSARC 2006/357 Crossbow - Network Virtualization and Resource Management PSARC 2007/157 libvirt - a LGPL library to control guest domains PSARC 2008/165 xVM Hypervisor Remote Access (virtd) LSARC 2007/175 Virtual Machine Manager 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open FOOTNOTE: ========= [1] design doc: http://sac.eng/Archives/CaseLog/arc/PSARC/2009/137/spec/design.bw.txt [2] xm.man.diff.bw.txt: http://sac.eng/Archives/CaseLog/arc/PSARC/2009/137/spec/xm.man.diff.bw.txt [3] virsh.man.diff.bw.txt: http://sac.eng/Archives/CaseLog/arc/PSARC/2009/137/spec/virsh.man.diff.bw.txt [4] virt-install.man.diff.bw.txt http://sac.eng/Archives/CaseLog/arc/PSARC/2009/137/spec/virt-install.man.diff.bw.txt From carlsonj@phorcys.east.sun.com Wed Feb 25 07:15:57 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PFFuRf013931 for ; Wed, 25 Feb 2009 07:15:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1PFFimj062181; Wed, 25 Feb 2009 08:15:54 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM00K2TNQHTJ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 07:15:53 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00HUTNQF7TD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Feb 2009 07:15:52 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PFFfkD012895; Wed, 25 Feb 2009 10:15:41 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PFFeCm012892; Wed, 25 Feb 2009 10:15:40 -0500 (EST) Date: Wed, 25 Feb 2009 10:15:40 -0500 From: James Carlson Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49A52388.2040401@sun.com> To: Cecilia.Hu@sun.com Cc: psarc-ext@sun.com, Max Zhen Message-id: <18853.24732.742746.672426@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> Status: RO Content-Length: 1855 Cecilia Hu writes: > So, before, a virt-install command line can look like: > #virt-install ...--mac a:b:c:d:e:f --bridge bge0 --rate 100M/s \ > --mac g:h:i:j:k:l --bridge bge1 --rate 200M/s... > Now, it looks like: > #virt-install ...--network mac=a:b:c:d:e:f,bridge=bge0,rate=100M/s \ > --network mac=g:h:i:j:k:l,bridge=bge1,rate=200M/s... This seems a bit odd to me. If I read this correctly, the underlying problem is that the current parameters have positional significance, and this makes them harder to understand as a grouping. (In other words, you have to specify "--mac" first, and then can specify "--bridge" after.) But why add "--rate" to the mess? The existing command line doesn't support rate, and it seems that you're trying to mark the old usage as "Obsolete," so why not just drop "--rate" and force anyone who wants to set the bandwidth limit to use the new command format? > | Interface | Stability | Comments | Missing from this table is: -m,--mac,-b,--bridge Obsolete Uncommitted Old-style options > | new -w/--network syntax and | | | > | 'rate' property of | | | > | virt-install(1M) | volatile | | "Volatile" means that scripts can't safely use this new option. Is that intended? > | "networkresource" and "rate" | | | > | elements in XML | | | > | configuration file | Uncommitted | | Why do users mess with the XML file? That's what "Uncommitted" implies. I would have expected "Committed Private" instead. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From johnlev@barman.uk.sun.com Wed Feb 25 07:58:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PFwet7015605 for ; Wed, 25 Feb 2009 07:58:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1PFwInf011506 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 25 Feb 2009 15:58:39 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM0041RPPMKY00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 07:58:34 -0800 (PST) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00LBAPPL5R80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 07:58:34 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1PFwTwF029399; Wed, 25 Feb 2009 15:58:29 +0000 (GMT) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1LcMEZ-0001zn-2r; Wed, 25 Feb 2009 16:03:43 +0000 X-URL: http://jurassic.eng/~johnlev/ Date: Wed, 25 Feb 2009 16:03:42 +0000 From: John Levon Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <18853.24732.742746.672426@gargle.gargle.HOWL> Sender: John Levon To: James Carlson Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com, Max Zhen Message-id: <20090225160342.GB7057@barman.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <18853.24732.742746.672426@gargle.gargle.HOWL> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 2321 On Wed, Feb 25, 2009 at 10:15:40AM -0500, James Carlson wrote: > Cecilia Hu writes: > > So, before, a virt-install command line can look like: > > #virt-install ...--mac a:b:c:d:e:f --bridge bge0 --rate 100M/s \ > > --mac g:h:i:j:k:l --bridge bge1 --rate 200M/s... > > Now, it looks like: > > #virt-install ...--network mac=a:b:c:d:e:f,bridge=bge0,rate=100M/s \ > > --network mac=g:h:i:j:k:l,bridge=bge1,rate=200M/s... > > This seems a bit odd to me. If I read this correctly, the underlying > problem is that the current parameters have positional significance, > and this makes them harder to understand as a grouping. (In other > words, you have to specify "--mac" first, and then can specify > "--bridge" after.) > > But why add "--rate" to the mess? The existing command line doesn't > support rate, and it seems that you're trying to mark the old usage as > "Obsolete," so why not just drop "--rate" and force anyone who wants > to set the bandwidth limit to use the new command format? In discussion with Max, this was in fact the plan, this is perhaps not clear in the case. There will be no --rate option (I'm sure Max will confirm). > > | new -w/--network syntax and | | | > > | 'rate' property of | | | > > | virt-install(1M) | volatile | | > > "Volatile" means that scripts can't safely use this new option. Is > that intended? There's some historical confusion around virt-install. It is intended to be usable from scripts. My forthcoming case says this: usr/bin/virt-install Committed usr/bin/virt-install cmdline Committed usr/bin/virt-install output Not-an-interface This reflects upstream intention, as well as how we've actually used it. > > | "networkresource" and "rate" | | | > > | elements in XML | | | > > | configuration file | Uncommitted | | > > Why do users mess with the XML file? That's what "Uncommitted" > implies. I would have expected "Committed Private" instead. The XML is also an external standard and is therefore Committed. In many cases it's the only way to interrogate the domain config sadly. regards john From edward.pilatowicz@sun.com Wed Feb 25 12:05:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PK5b08003673 for ; Wed, 25 Feb 2009 12:05:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1PK5WDY014902; Wed, 25 Feb 2009 13:05:34 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFN0060R158I200@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 12:05:32 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00J4X158K2E0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 12:05:32 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1PK5Ssh961821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 12:05:28 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n1PK5S0S961820; Wed, 25 Feb 2009 12:05:28 -0800 (PST) Date: Wed, 25 Feb 2009 12:05:27 -0800 From: Edward Pilatowicz Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49A52388.2040401@sun.com> To: Cecilia Hu Cc: psarc-ext@sun.com, Max Zhen Message-id: <20090225200527.GA951472@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1392 hey max, so zones already has a standard terminology for creating caps and reservations on various resources. this functionality is documented in the following arc cases: PSARC/2006/496 Improved Zones/RM Integration PSARC/2004/402 CPU caps to sum up the terminology, a resource cap is specified as "capped-XXX" and a resource reservation is specified as "dedicated-XXX", where XXX is the resource. currently zones supports caps and reservations for memory and cpu, but this terminology was designed to allow for easy future enhancements like network caps and reservations. since you're going to be introducing new network bandwidth cap mechanism for xvm, it'd be really nice if we could try to keep the naming conventions consistent between xvm and zones. hence, i was thinking that instead of "rate" (which is actually pretty pretty vague, how do i know that this doesn't set a reservation instead of a cap?) you could use "capped-bandwidth". this update would apply to the "--rate" option to virt-install/virsh, the "rate" option to xm, and the internal xml storage format. if there is already a convention on other xen based platforms for a "rate" option, then instead of eliminating that option, it would probably make sense to add a "capped-bandwidth" option, make "rate" an alias for "capped-bandwidth", and only document the "capped-bandwidth" option on solaris. thanks ed From Max.Zhen@sun.com Wed Feb 25 16:30:34 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1Q0UYMe026978 for ; Wed, 25 Feb 2009 16:30:34 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1Q0UXpG019337 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 25 Feb 2009 16:30:34 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFN00M0HDEX3I00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 16:30:33 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00LJVDEWO700@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Feb 2009 16:30:33 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1Q0UWE4005442 for ; Thu, 26 Feb 2009 00:30:32 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFN00D00DD40W00@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 26 Feb 2009 08:30:32 +0800 (SGT) Received: from [192.168.1.2] ([unknown] [123.117.94.113]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFN00A7SDEUNBC0@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 26 Feb 2009 08:30:32 +0800 (SGT) Date: Thu, 26 Feb 2009 08:30:25 +0800 From: Max Zhen Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <18853.24732.742746.672426@gargle.gargle.HOWL> Sender: Max.Zhen@sun.com To: James Carlson Cc: Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <49A5E2A1.4010706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <18853.24732.742746.672426@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 191 >> | Interface | Stability | Comments | >> > > Missing from this table is: > > -m,--mac,-b,--bridge Obsolete Uncommitted Old-style options > Yes. Thanks, James. Max From Max.Zhen@sun.com Wed Feb 25 16:30:53 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1Q0Urvw027014 for ; Wed, 25 Feb 2009 16:30:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1Q0UpKc050644; Wed, 25 Feb 2009 17:30:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFN00M05DFF4H00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 16:30:51 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00LH7DFEO200@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 16:30:51 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1Q0UnNZ005461; Thu, 26 Feb 2009 00:30:49 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFN00D00DD40W00@mail-apac.sun.com>; Thu, 26 Feb 2009 08:30:49 +0800 (SGT) Received: from [192.168.1.2] ([unknown] [123.117.94.113]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFN00A7YDFCNBC0@mail-apac.sun.com>; Thu, 26 Feb 2009 08:30:49 +0800 (SGT) Date: Thu, 26 Feb 2009 08:30:42 +0800 From: Max Zhen Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <20090225160342.GB7057@barman.uk.sun.com> Sender: Max.Zhen@sun.com To: John Levon Cc: James Carlson , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <49A5E2B2.4040507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <18853.24732.742746.672426@gargle.gargle.HOWL> <20090225160342.GB7057@barman.uk.sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 3321 John Levon at 2009-2-26 0:03 wrote: > On Wed, Feb 25, 2009 at 10:15:40AM -0500, James Carlson wrote: > > >> Cecilia Hu writes: >> >>> So, before, a virt-install command line can look like: >>> #virt-install ...--mac a:b:c:d:e:f --bridge bge0 --rate 100M/s \ >>> --mac g:h:i:j:k:l --bridge bge1 --rate 200M/s... >>> Now, it looks like: >>> #virt-install ...--network mac=a:b:c:d:e:f,bridge=bge0,rate=100M/s \ >>> --network mac=g:h:i:j:k:l,bridge=bge1,rate=200M/s... >>> >> This seems a bit odd to me. If I read this correctly, the underlying >> problem is that the current parameters have positional significance, >> and this makes them harder to understand as a grouping. (In other >> words, you have to specify "--mac" first, and then can specify >> "--bridge" after.) >> >> But why add "--rate" to the mess? The existing command line doesn't >> support rate, and it seems that you're trying to mark the old usage as >> "Obsolete," so why not just drop "--rate" and force anyone who wants >> to set the bandwidth limit to use the new command format? >> > > In discussion with Max, this was in fact the plan, this is perhaps not > clear in the case. There will be no --rate option (I'm sure Max will > confirm). > Exactly. There will be no --rate option for virt-install(1M). Users will be forced to use this new syntax, if they want to set bandwidth to the virtual interface. I listed '--rate' to show the mess we can have, if we take that approach. This is just for people to understand why we take this effort to make the new style. Sorry for any confusion. > >>> | new -w/--network syntax and | | | >>> | 'rate' property of | | | >>> | virt-install(1M) | volatile | | >>> >> "Volatile" means that scripts can't safely use this new option. Is >> that intended? >> > > There's some historical confusion around virt-install. It is intended to > be usable from scripts. My forthcoming case says this: > > usr/bin/virt-install Committed > usr/bin/virt-install cmdline Committed > usr/bin/virt-install output Not-an-interface > > This reflects upstream intention, as well as how we've actually used it. > So, 'committed' makes more sense since it'll be 'committed' later anyway :). > >>> | "networkresource" and "rate" | | | >>> | elements in XML | | | >>> | configuration file | Uncommitted | | >>> >> Why do users mess with the XML file? That's what "Uncommitted" >> implies. I would have expected "Committed Private" instead. >> > > The XML is also an external standard and is therefore Committed. In many > cases it's the only way to interrogate the domain config sadly. > Although it is not necessary, user can also manually create a XML file to describe the configuration for a virtual interface and pass that file to virsh to add the interface to the domU. Since we'll push the change to upstream later, these XML elements will become part of the standard format in the future eventually. So, 'committed' level is more appropriate in this case. Thanks, Max > regards > john > From Max.Zhen@sun.com Wed Feb 25 18:39:56 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1Q2dtUT000531 for ; Wed, 25 Feb 2009 18:39:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1Q2dpaC003374 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Feb 2009 10:39:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFN00B01JEHGN00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 18:39:53 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN007ICJEGUVB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 18:39:53 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1Q2dpAp006048 for ; Thu, 26 Feb 2009 02:39:51 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFN00600JD1EG00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Feb 2009 10:39:51 +0800 (SGT) Received: from [129.158.218.112] ([unknown] [129.158.218.112]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFN008IQJEEFZF0@mail-apac.sun.com>; Thu, 26 Feb 2009 10:39:51 +0800 (SGT) Date: Thu, 26 Feb 2009 10:34:46 +0800 From: Max Zhen Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <20090225200527.GA951472@eng.sun.com> Sender: Max.Zhen@sun.com To: Edward Pilatowicz Cc: Cecilia Hu , PSARC-ext@sun.com Message-id: <49A5FFC6.3020706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090112) Status: RO Content-Length: 1877 Edward Pilatowicz wrote: > hey max, > > so zones already has a standard terminology for creating caps and > reservations on various resources. this functionality is documented in > the following arc cases: > > PSARC/2006/496 Improved Zones/RM Integration > PSARC/2004/402 CPU caps > > to sum up the terminology, a resource cap is specified as "capped-XXX" > and a resource reservation is specified as "dedicated-XXX", where XXX is > the resource. currently zones supports caps and reservations for memory > and cpu, but this terminology was designed to allow for easy future > enhancements like network caps and reservations. > > since you're going to be introducing new network bandwidth cap mechanism > for xvm, it'd be really nice if we could try to keep the naming > conventions consistent between xvm and zones. hence, i was thinking > that instead of "rate" (which is actually pretty pretty vague, how do i > know that this doesn't set a reservation instead of a cap?) you could > use "capped-bandwidth". this update would apply to the "--rate" option > to virt-install/virsh, the "rate" option to xm, and the internal xml > storage format. > > if there is already a convention on other xen based platforms for a > "rate" option, then instead of eliminating that option, it would > probably make sense to add a "capped-bandwidth" option, make "rate" an > alias for "capped-bandwidth", and only document the "capped-bandwidth" > option on solaris. > Thanks Ed! I think 'capped-bandwidth' is a better name for 'rate'. I'll apply this name to virsh/virt-install and the related XMLformat. But, I intend to keep using 'rate' in 'xm' command since: + it is already there + virsh is the way to go, we don't encourage people to use 'xm' in the future, so minimize our maintenance burden seems to be more important here. How does that sound? Max > thanks > ed > From edward.pilatowicz@sun.com Wed Feb 25 23:51:37 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1Q7pagB026065 for ; Wed, 25 Feb 2009 23:51:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1Q7pQj4015257; Thu, 26 Feb 2009 15:51:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFN00305XTWB500@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 23:51:32 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFN00DREXTWYPB0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Feb 2009 23:51:32 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1Q7pREa265844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Feb 2009 23:51:27 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n1Q7pRrO265843; Wed, 25 Feb 2009 23:51:27 -0800 (PST) Date: Wed, 25 Feb 2009 23:51:27 -0800 From: Edward Pilatowicz Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49A5FFC6.3020706@Sun.COM> To: Max Zhen Cc: Cecilia Hu , PSARC-ext@sun.com Message-id: <20090226075127.GA257648@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> <49A5FFC6.3020706@Sun.COM> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 2390 On Thu, Feb 26, 2009 at 10:34:46AM +0800, Max Zhen wrote: > Edward Pilatowicz wrote: >> hey max, >> >> so zones already has a standard terminology for creating caps and >> reservations on various resources. this functionality is documented in >> the following arc cases: >> >> PSARC/2006/496 Improved Zones/RM Integration >> PSARC/2004/402 CPU caps >> >> to sum up the terminology, a resource cap is specified as "capped-XXX" >> and a resource reservation is specified as "dedicated-XXX", where XXX is >> the resource. currently zones supports caps and reservations for memory >> and cpu, but this terminology was designed to allow for easy future >> enhancements like network caps and reservations. >> >> since you're going to be introducing new network bandwidth cap mechanism >> for xvm, it'd be really nice if we could try to keep the naming >> conventions consistent between xvm and zones. hence, i was thinking >> that instead of "rate" (which is actually pretty pretty vague, how do i >> know that this doesn't set a reservation instead of a cap?) you could >> use "capped-bandwidth". this update would apply to the "--rate" option >> to virt-install/virsh, the "rate" option to xm, and the internal xml >> storage format. >> >> if there is already a convention on other xen based platforms for a >> "rate" option, then instead of eliminating that option, it would >> probably make sense to add a "capped-bandwidth" option, make "rate" an >> alias for "capped-bandwidth", and only document the "capped-bandwidth" >> option on solaris. >> > Thanks Ed! > I think 'capped-bandwidth' is a better name for 'rate'. I'll apply this > name to virsh/virt-install and the related XMLformat. sounds great. > But, I intend to keep using 'rate' in 'xm' command since: > + it is already there > + virsh is the way to go, we don't encourage people to use 'xm' in the > future, so minimize our maintenance burden seems to be more important here. > How does that sound? > well, given that xm already has a "rate" command i wouldn't recommend removing it. but out of curiousity, don't we already make lots of changes to xm? (looking at the patches in xen.hg/.hg/patches it seems to me that we do). and wouldn't it be _really_ trivial to add a "capped-bandwidth" option that has the same effect as "rate"? i guess as some point i should learn the virsh commands ans stop using xm. ;) ed From Max.Zhen@Sun.COM Thu Feb 26 00:43:31 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1Q8hVMc018756 for ; Thu, 26 Feb 2009 00:43:31 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1Q8hRJN013303 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Feb 2009 08:43:30 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFO0060R08HI100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Feb 2009 00:43:29 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFO00D7W08FZ4F0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Feb 2009 00:43:28 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1Q8hRDa004044 for ; Thu, 26 Feb 2009 08:43:27 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFO00700080KA00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Feb 2009 16:43:27 +0800 (SGT) Received: from [129.158.218.112] ([unknown] [129.158.218.112]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFO00LVS08A89C0@mail-apac.sun.com>; Thu, 26 Feb 2009 16:43:23 +0800 (SGT) Date: Thu, 26 Feb 2009 16:38:17 +0800 From: Max Zhen Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <20090226075127.GA257648@eng.sun.com> Sender: Max.Zhen@Sun.COM To: Edward Pilatowicz Cc: Cecilia Hu , PSARC-ext@Sun.COM Message-id: <49A654F9.5080407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> <49A5FFC6.3020706@Sun.COM> <20090226075127.GA257648@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090112) Status: RO Content-Length: 3054 Edward Pilatowicz wrote: > On Thu, Feb 26, 2009 at 10:34:46AM +0800, Max Zhen wrote: > >> Edward Pilatowicz wrote: >> >>> hey max, >>> >>> so zones already has a standard terminology for creating caps and >>> reservations on various resources. this functionality is documented in >>> the following arc cases: >>> >>> PSARC/2006/496 Improved Zones/RM Integration >>> PSARC/2004/402 CPU caps >>> >>> to sum up the terminology, a resource cap is specified as "capped-XXX" >>> and a resource reservation is specified as "dedicated-XXX", where XXX is >>> the resource. currently zones supports caps and reservations for memory >>> and cpu, but this terminology was designed to allow for easy future >>> enhancements like network caps and reservations. >>> >>> since you're going to be introducing new network bandwidth cap mechanism >>> for xvm, it'd be really nice if we could try to keep the naming >>> conventions consistent between xvm and zones. hence, i was thinking >>> that instead of "rate" (which is actually pretty pretty vague, how do i >>> know that this doesn't set a reservation instead of a cap?) you could >>> use "capped-bandwidth". this update would apply to the "--rate" option >>> to virt-install/virsh, the "rate" option to xm, and the internal xml >>> storage format. >>> >>> if there is already a convention on other xen based platforms for a >>> "rate" option, then instead of eliminating that option, it would >>> probably make sense to add a "capped-bandwidth" option, make "rate" an >>> alias for "capped-bandwidth", and only document the "capped-bandwidth" >>> option on solaris. >>> >>> >> Thanks Ed! >> I think 'capped-bandwidth' is a better name for 'rate'. I'll apply this >> name to virsh/virt-install and the related XMLformat. >> > > sounds great. > > >> But, I intend to keep using 'rate' in 'xm' command since: >> + it is already there >> + virsh is the way to go, we don't encourage people to use 'xm' in the >> future, so minimize our maintenance burden seems to be more important here. >> How does that sound? >> >> > > well, given that xm already has a "rate" command i wouldn't recommend > removing it. > > but out of curiousity, don't we already make lots of changes to xm? > (looking at the patches in xen.hg/.hg/patches it seems to me that we > do). and wouldn't it be _really_ trivial to add a "capped-bandwidth" > option that has the same effect as "rate"? > I think that if it is something completely new, it will be easier to push it back to community. But, if we keep two options in xm, which has the same effect, it will be hard to push it back to community. So, if that happen, we need to maintain it on our own, which seems to be not worth it to me. And yes, the implementation is trivial, but there are just more things that I'm considering... > i guess as some point i should learn the virsh commands ans stop using > xm. ;) > I don't think virsh can do all things that xm can do now, but virsh can do most of them. So, give it a try :). Max > ed > From carlsonj@phorcys.east.sun.com Thu Feb 26 05:27:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1QDRINT014719 for ; Thu, 26 Feb 2009 05:27:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1QDRD22036284; Thu, 26 Feb 2009 06:27:14 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFO00J0TDDCR800@brm-avmta-1.central.sun.com>; Thu, 26 Feb 2009 06:27:12 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFO00AAIDDAZ980@brm-avmta-1.central.sun.com>; Thu, 26 Feb 2009 06:27:10 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1QDRAXG012665; Thu, 26 Feb 2009 08:27:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1QDRAWx012662; Thu, 26 Feb 2009 08:27:10 -0500 (EST) Date: Thu, 26 Feb 2009 08:27:10 -0500 From: James Carlson Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49A5E2B2.4040507@Sun.COM> To: Max Zhen Cc: John Levon , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <18854.39086.711071.564903@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <18853.24732.742746.672426@gargle.gargle.HOWL> <20090225160342.GB7057@barman.uk.sun.com> <49A5E2B2.4040507@Sun.COM> Status: RO Content-Length: 1480 Max Zhen writes: > > In discussion with Max, this was in fact the plan, this is perhaps not > > clear in the case. There will be no --rate option (I'm sure Max will > > confirm). > > > Exactly. There will be no --rate option for virt-install(1M). Users > will be forced to use this new syntax, if they want to set bandwidth to > the virtual interface. > I listed '--rate' to show the mess we can have, if we take that > approach. This is just for people to understand why we take this effort > to make the new style. Sorry for any confusion. Then I guess my question is why "--rate" is a bad thing for virt-install but it's a good thing for virsh. Shouldn't there be some consistency here? > > The XML is also an external standard and is therefore Committed. In many > > cases it's the only way to interrogate the domain config sadly. > > > Although it is not necessary, user can also manually create a XML file > to describe the configuration for a virtual interface and pass that file > to virsh to add the interface to the domU. > > Since we'll push the change to upstream later, these XML elements will > become part of the standard format in the future eventually. So, > 'committed' level is more appropriate in this case. OK. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Max.Zhen@sun.com Thu Feb 26 05:54:13 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1QDsDha015135 for ; Thu, 26 Feb 2009 05:54:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1QDs8hH003754; Thu, 26 Feb 2009 05:54:12 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFO00M13EMB8J00@brm-avmta-1.central.sun.com>; Thu, 26 Feb 2009 06:54:11 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFO00AHPEM8Z9A0@brm-avmta-1.central.sun.com>; Thu, 26 Feb 2009 06:54:09 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1QDs8rD025365; Thu, 26 Feb 2009 13:54:08 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFO00700EH6K800@mail-apac.sun.com>; Thu, 26 Feb 2009 21:54:08 +0800 (SGT) Received: from [129.150.144.36] ([unknown] [129.150.144.36]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFO00A7OEM7FY40@mail-apac.sun.com>; Thu, 26 Feb 2009 21:54:08 +0800 (SGT) Date: Thu, 26 Feb 2009 21:54:02 +0800 From: Max Zhen Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <18854.39086.711071.564903@gargle.gargle.HOWL> Sender: Max.Zhen@sun.com To: James Carlson Cc: John Levon , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <49A69EFA.7040703@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <18853.24732.742746.672426@gargle.gargle.HOWL> <20090225160342.GB7057@barman.uk.sun.com> <49A5E2B2.4040507@Sun.COM> <18854.39086.711071.564903@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 1965 James Carlson at 2009-2-26 21:27 wrote: > Max Zhen writes: > >>> In discussion with Max, this was in fact the plan, this is perhaps not >>> clear in the case. There will be no --rate option (I'm sure Max will >>> confirm). >>> >>> >> Exactly. There will be no --rate option for virt-install(1M). Users >> will be forced to use this new syntax, if they want to set bandwidth to >> the virtual interface. >> I listed '--rate' to show the mess we can have, if we take that >> approach. This is just for people to understand why we take this effort >> to make the new style. Sorry for any confusion. >> > > Then I guess my question is why "--rate" is a bad thing for > virt-install but it's a good thing for virsh. > > Shouldn't there be some consistency here? > The problem for virsh is different. The '--rate' option is only for 'attach-interface' subcommand. You can only add one virtual interface at a time when you use 'virsh attach-interface' and all options in this command line is solely used for virtual interface configuration, not for cpu, memory, disk, or some other things like we have in virt-install. So, the difference here is in virt-install, we mix all options together, including vcpu, memory, disk, network interface...but in 'virsh attach-interface' the option is only for virtual interface, which is quite clear. Max > >>> The XML is also an external standard and is therefore Committed. In many >>> cases it's the only way to interrogate the domain config sadly. >>> >>> >> Although it is not necessary, user can also manually create a XML file >> to describe the configuration for a virtual interface and pass that file >> to virsh to add the interface to the domU. >> >> Since we'll push the change to upstream later, these XML elements will >> become part of the standard format in the future eventually. So, >> 'committed' level is more appropriate in this case. >> > > OK. > > From carlsonj@phorcys.east.sun.com Thu Feb 26 06:07:17 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1QE7HVN015330 for ; Thu, 26 Feb 2009 06:07:17 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1QE76dJ002489; Thu, 26 Feb 2009 07:07:13 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFO0090DF7ZHA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Feb 2009 06:07:11 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFO00INGF7YC790@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Feb 2009 06:07:11 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1QE7ALd013002; Thu, 26 Feb 2009 09:07:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n1QE7A14012999; Thu, 26 Feb 2009 09:07:10 -0500 (EST) Date: Thu, 26 Feb 2009 09:07:10 -0500 From: James Carlson Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49A69EFA.7040703@Sun.COM> To: Max Zhen Cc: John Levon , Cecilia.Hu@sun.com, psarc-ext@sun.com Message-id: <18854.41486.870688.508502@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <18853.24732.742746.672426@gargle.gargle.HOWL> <20090225160342.GB7057@barman.uk.sun.com> <49A5E2B2.4040507@Sun.COM> <18854.39086.711071.564903@gargle.gargle.HOWL> <49A69EFA.7040703@Sun.COM> Status: RO Content-Length: 1104 Max Zhen writes: > > Then I guess my question is why "--rate" is a bad thing for > > virt-install but it's a good thing for virsh. > > > > Shouldn't there be some consistency here? > > > The problem for virsh is different. > The '--rate' option is only for 'attach-interface' subcommand. > You can only add one virtual interface at a time when you use 'virsh > attach-interface' and all options in this command line is solely used > for virtual interface configuration, not for cpu, memory, disk, or some > other things like we have in virt-install. > So, the difference here is in virt-install, we mix all options together, > including vcpu, memory, disk, network interface...but in 'virsh > attach-interface' the option is only for virtual interface, which is > quite clear. OK; thanks. That clarifies it. +1 with the new "obsolete" notice added to the old options. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From johnlev@barman.uk.sun.com Thu Feb 26 08:05:52 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1QG5qRt028639 for ; Thu, 26 Feb 2009 08:05:52 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1QG5l5I038099 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Feb 2009 09:05:51 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFO00703KPQ1600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Feb 2009 08:05:50 -0800 (PST) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFO006LNKPPPI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Feb 2009 08:05:50 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1QG5jev009923; Thu, 26 Feb 2009 16:05:45 +0000 (GMT) Received: from johnlev by barman.uk.sun.com with local (Exim 4.42) id 1LcipA-0005YF-DW; Thu, 26 Feb 2009 16:11:00 +0000 X-URL: http://jurassic.eng/~johnlev/ Date: Thu, 26 Feb 2009 16:11:00 +0000 From: John Levon Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <20090226075127.GA257648@eng.sun.com> Sender: John Levon To: Edward Pilatowicz Cc: Max Zhen , Cecilia Hu , PSARC-ext@sun.com Message-id: <20090226161100.GA20775@barman.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> <49A5FFC6.3020706@Sun.COM> <20090226075127.GA257648@eng.sun.com> User-Agent: Mutt/1.5.6i Status: RO Content-Length: 761 On Wed, Feb 25, 2009 at 11:51:27PM -0800, Edward Pilatowicz wrote: > > I think 'capped-bandwidth' is a better name for 'rate'. I'll apply this > > name to virsh/virt-install and the related XMLformat. > > sounds great. Of course, we need to check this with the upstream community. If they're against the name, we may well have a problem. > but out of curiousity, don't we already make lots of changes to xm? > (looking at the patches in xen.hg/.hg/patches it seems to me that we > do). and wouldn't it be _really_ trivial to add a "capped-bandwidth" > option that has the same effect as "rate"? > > i guess as some point i should learn the virsh commands ans stop using > xm. ;) Yes - xm has a significant chance of going away altogether. regards john From Cecilia.Hu@sun.com Mon Mar 2 22:27:16 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n236RGjt016013 for ; Mon, 2 Mar 2009 22:27:16 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n236RCKB027477 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Mar 2009 22:27:16 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFX00L3739FI300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Mar 2009 22:27:15 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFX00KUZ39EMH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Mar 2009 22:27:14 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n236RD56024793 for ; Tue, 03 Mar 2009 06:27:13 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFX00M0038D7I00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 14:27:13 +0800 (SGT) Received: from [129.158.218.98] ([unknown] [129.158.218.98]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFX000AH39C2X60@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 14:27:13 +0800 (SGT) Date: Tue, 03 Mar 2009 14:25:00 +0800 From: Cecilia Hu Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <20090226161100.GA20775@barman.uk.sun.com> Sender: Cecilia.Hu@sun.com To: PSARC-ext@sun.com Cc: Max Zhen Reply-to: Cecilia.Hu@sun.com Message-id: <49ACCD3C.9070704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> <49A5FFC6.3020706@Sun.COM> <20090226075127.GA257648@eng.sun.com> <20090226161100.GA20775@barman.uk.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 90 Based on current discussion here, the specification and documents are updated. -Cecilia From Max.Zhen@sun.com Wed Mar 4 08:32:58 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24GWwXc016477 for ; Wed, 4 Mar 2009 08:32:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24GWuje022153 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 09:32:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00D0NPYWLK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:32:56 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ0061NPYT1ZF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:32:54 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n24GWr0u017774 for ; Wed, 04 Mar 2009 16:32:53 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00900PXOBM00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 00:32:53 +0800 (SGT) Received: from [129.150.144.26] ([unknown] [129.150.144.26]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFZ00L61PYSYD50@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 00:32:53 +0800 (SGT) Date: Thu, 05 Mar 2009 00:32:50 +0800 From: Max Zhen Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49ACCD3C.9070704@sun.com> Sender: Max.Zhen@sun.com To: Cecilia.Hu@sun.com Cc: PSARC-ext@sun.com Message-id: <49AEAD32.9000201@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> <49A5FFC6.3020706@Sun.COM> <20090226075127.GA257648@eng.sun.com> <20090226161100.GA20775@barman.uk.sun.com> <49ACCD3C.9070704@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 545 Based on some off-line discussion with John Levon, I'd like to change 'capped-bandwidth' element in XML format to 'cappedbandwidth' (remove the '-'). So that we can keep the meaning of the name clear while make it more like other names in existing XML format standard. This will make it more likely to be accepted by community when we post it to upstream. ARC materials will be updated accordingly. Max Cecilia Hu at 2009-3-3 14:25 wrote: > Based on current discussion here, the specification and documents are > updated. > > -Cecilia From Cecilia.Hu@sun.com Wed Mar 4 19:23:29 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n253NTSZ016724 for ; Wed, 4 Mar 2009 19:23:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n253NRR9034174 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 20:23:28 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KG00000NK33CY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 20:23:27 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KG000A39K32VWC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 20:23:27 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n253NQjd009887 for ; Thu, 05 Mar 2009 03:23:26 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KG000G00K2QMX00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 11:23:26 +0800 (SGT) Received: from [129.158.218.98] ([unknown] [129.158.218.98]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KG0005VKK31D810@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 11:23:26 +0800 (SGT) Date: Thu, 05 Mar 2009 11:21:12 +0800 From: Cecilia Hu Subject: Re: PSARC 2009/137 Bandwidth Limit for Virtual Interface In-reply-to: <49AEAD32.9000201@Sun.COM> Sender: Cecilia.Hu@sun.com To: Max Zhen Cc: PSARC-ext@sun.com Reply-to: Cecilia.Hu@sun.com Message-id: <49AF4528.7070002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49A52388.2040401@sun.com> <20090225200527.GA951472@eng.sun.com> <49A5FFC6.3020706@Sun.COM> <20090226075127.GA257648@eng.sun.com> <20090226161100.GA20775@barman.uk.sun.com> <49ACCD3C.9070704@sun.com> <49AEAD32.9000201@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 122 This case was approved in today's PSARC meeting. Documents were updated as well as to reflect all discussion. -Cecilia