* Xen 4.0 Feature Requests
@ 2009-04-21 14:17 Stephen Spector
2009-04-21 14:53 ` R: " Francesco Gallo
` (5 more replies)
0 siblings, 6 replies; 36+ messages in thread
From: Stephen Spector @ 2009-04-21 14:17 UTC (permalink / raw)
To: xen-users, 'xen-devel@lists.xensource.com'
[-- Attachment #1.1: Type: text/plain, Size: 480 bytes --]
With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released.
Please send me your features. Thanks.
Stephen Spector
Community Manager, Xen.org
stephen.spector@xen.org
(772) 621-5062
Blog: http://blog.xen.org
Twitter: http://www.twitter.com/xen_com_mgr
[-- Attachment #1.2: Type: text/html, Size: 5099 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread* R: Xen 4.0 Feature Requests 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector @ 2009-04-21 14:53 ` Francesco Gallo 2009-04-22 14:51 ` Kashif Ali 2009-04-21 16:48 ` Tim Moore ` (4 subsequent siblings) 5 siblings, 1 reply; 36+ messages in thread From: Francesco Gallo @ 2009-04-21 14:53 UTC (permalink / raw) To: 'Stephen Spector', xen-users, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 930 bytes --] I would like to have dynamic memory mangement for overcommitting RAM (like vmware…). Thanks and regards, Francesco Gallo Da: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector Inviato: martedì 21 aprile 2009 16.17 A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' Oggetto: [Xen-users] Xen 4.0 Feature Requests With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released. Please send me your features. Thanks. Stephen Spector Community Manager, Xen.org stephen.spector@xen.org (772) 621-5062 Blog: http://blog.xen.org Twitter: http://www.twitter.com/xen_com_mgr [-- Attachment #1.2: Type: text/html, Size: 6625 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: R: Xen 4.0 Feature Requests 2009-04-21 14:53 ` R: " Francesco Gallo @ 2009-04-22 14:51 ` Kashif Ali 2009-04-22 19:49 ` Alessandro R. 0 siblings, 1 reply; 36+ messages in thread From: Kashif Ali @ 2009-04-22 14:51 UTC (permalink / raw) To: cluster, stephen.spector, xen-users, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1583 bytes --] If there is any way to monitor,limit and control network traffic coming at domUs with xen. I would like xen to have this feature as well. Thanks, Kashif From: cluster@xinet.it To: stephen.spector@citrix.com; xen-users@lists.xensource.com; xen-devel@lists.xensource.com Subject: R: [Xen-users] Xen 4.0 Feature Requests Date: Tue, 21 Apr 2009 16:53:04 +0200 CC: I would like to have dynamic memory mangement for overcommitting RAM (like vmware…). Thanks and regards, Francesco Gallo Da: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector Inviato: martedì 21 aprile 2009 16.17 A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' Oggetto: [Xen-users] Xen 4.0 Feature Requests With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released. Please send me your features. Thanks. Stephen Spector Community Manager, Xen.org stephen.spector@xen.org (772) 621-5062 Blog: http://blog.xen.org Twitter: http://www.twitter.com/xen_com_mgr _________________________________________________________________ Rediscover Hotmail®: Now available on your iPhone or BlackBerry http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile2_042009 [-- Attachment #1.2: Type: text/html, Size: 4045 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: R: Xen 4.0 Feature Requests 2009-04-22 14:51 ` Kashif Ali @ 2009-04-22 19:49 ` Alessandro R. 2009-04-23 7:27 ` Robert Dunkley 0 siblings, 1 reply; 36+ messages in thread From: Alessandro R. @ 2009-04-22 19:49 UTC (permalink / raw) To: Kashif Ali; +Cc: cluster, xen-devel, stephen.spector, xen-users A tool that permit to configure virtual bridge like real switch (e.g. control VLAN, port status etc.) On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> wrote: > If there is any way to monitor,limit and control network traffic coming at > domUs with xen. I would like xen to have this feature as well. > > Thanks, > Kashif > > ________________________________ > From: cluster@xinet.it > To: stephen.spector@citrix.com; xen-users@lists.xensource.com; > xen-devel@lists.xensource.com > Subject: R: [Xen-users] Xen 4.0 Feature Requests > Date: Tue, 21 Apr 2009 16:53:04 +0200 > CC: > > I would like to have dynamic memory mangement for overcommitting RAM (like > vmware…). > > > > Thanks and regards, > > Francesco Gallo > > > > Da: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector > Inviato: martedì 21 aprile 2009 16.17 > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > Oggetto: [Xen-users] Xen 4.0 Feature Requests > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > feature requests for the next release, Xen 4.0. The current product roadmap > is at http://www.xen.org/download/roadmap.html and will be updated with the > new features you submit once Xen 3.4 is released. > > > > Please send me your features. Thanks. > > > > Stephen Spector > > Community Manager, Xen.org > > stephen.spector@xen.org > > (772) 621-5062 > > Blog: http://blog.xen.org > > Twitter: http://www.twitter.com/xen_com_mgr > > > > ________________________________ > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it > out. > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > -- Alessandro R. NOTICE This message is for the named person's use only and it's confidential. If you receive this message in error, please immediately delete it and and notify the sender. Thank you. ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: R: Xen 4.0 Feature Requests 2009-04-22 19:49 ` Alessandro R. @ 2009-04-23 7:27 ` Robert Dunkley 2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro 0 siblings, 1 reply; 36+ messages in thread From: Robert Dunkley @ 2009-04-23 7:27 UTC (permalink / raw) To: Alessandro R., Kashif Ali; +Cc: cluster, xen-devel, stephen.spector, xen-users I second this request, just an easy way of VLan tagging per NIC in the VM config file would be good. Rob -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R. Sent: 22 April 2009 20:50 To: Kashif Ali Cc: cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests A tool that permit to configure virtual bridge like real switch (e.g. control VLAN, port status etc.) On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> wrote: > If there is any way to monitor,limit and control network traffic coming at > domUs with xen. I would like xen to have this feature as well. > > Thanks, > Kashif > > ________________________________ > From: cluster@xinet.it > To: stephen.spector@citrix.com; xen-users@lists.xensource.com; > xen-devel@lists.xensource.com > Subject: R: [Xen-users] Xen 4.0 Feature Requests > Date: Tue, 21 Apr 2009 16:53:04 +0200 > CC: > > I would like to have dynamic memory mangement for overcommitting RAM (like > vmware...). > > > > Thanks and regards, > > Francesco Gallo > > > > Da: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector > Inviato: martedì 21 aprile 2009 16.17 > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > Oggetto: [Xen-users] Xen 4.0 Feature Requests > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > feature requests for the next release, Xen 4.0. The current product roadmap > is at http://www.xen.org/download/roadmap.html and will be updated with the > new features you submit once Xen 3.4 is released. > > > > Please send me your features. Thanks. > > > > Stephen Spector > > Community Manager, Xen.org > > stephen.spector@xen.org > > (772) 621-5062 > > Blog: http://blog.xen.org > > Twitter: http://www.twitter.com/xen_com_mgr > > > > ________________________________ > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it > out. > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > -- Alessandro R. NOTICE This message is for the named person's use only and it's confidential. If you receive this message in error, please immediately delete it and and notify the sender. Thank you. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member Find us in http://www.thebestof.co.uk/petersfield ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: R: Xen 4.0 Feature Requests 2009-04-23 7:27 ` Robert Dunkley @ 2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro 2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley 0 siblings, 1 reply; 36+ messages in thread From: Thiago Camargo Martins Cordeiro @ 2009-04-23 13:38 UTC (permalink / raw) To: Robert Dunkley Cc: xen-devel, Kashif Ali, Alessandro R., xen-users, cluster, stephen.spector [-- Attachment #1.1: Type: text/plain, Size: 3788 bytes --] What about integrating Xen with a Virtual Ethernet Switch (like VDE2)? You can create a switch per client... 2009/4/23 Robert Dunkley <Robert@saq.co.uk> > I second this request, just an easy way of VLan tagging per NIC in the VM > config file would be good. > > Rob > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com [mailto: > xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R. > Sent: 22 April 2009 20:50 > To: Kashif Ali > Cc: cluster@xinet.it; xen-devel@lists.xensource.com; > stephen.spector@citrix.com; xen-users@lists.xensource.com > Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests > > A tool that permit to configure virtual bridge like real switch (e.g. > control VLAN, port status etc.) > > On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> > wrote: > > If there is any way to monitor,limit and control network traffic coming > at > > domUs with xen. I would like xen to have this feature as well. > > > > Thanks, > > Kashif > > > > ________________________________ > > From: cluster@xinet.it > > To: stephen.spector@citrix.com; xen-users@lists.xensource.com; > > xen-devel@lists.xensource.com > > Subject: R: [Xen-users] Xen 4.0 Feature Requests > > Date: Tue, 21 Apr 2009 16:53:04 +0200 > > CC: > > > > I would like to have dynamic memory mangement for overcommitting RAM > (like > > vmware...). > > > > > > > > Thanks and regards, > > > > Francesco Gallo > > > > > > > > Da: xen-users-bounces@lists.xensource.com > > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen > Spector > > Inviato: martedì 21 aprile 2009 16.17 > > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > > Oggetto: [Xen-users] Xen 4.0 Feature Requests > > > > > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > > feature requests for the next release, Xen 4.0. The current product > roadmap > > is at http://www.xen.org/download/roadmap.html and will be updated with > the > > new features you submit once Xen 3.4 is released. > > > > > > > > Please send me your features. Thanks. > > > > > > > > Stephen Spector > > > > Community Manager, Xen.org > > > > stephen.spector@xen.org > > > > (772) 621-5062 > > > > Blog: http://blog.xen.org > > > > Twitter: http://www.twitter.com/xen_com_mgr > > > > > > > > ________________________________ > > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it > > out. > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > > > -- > Alessandro R. > > NOTICE > This message is for the named person's use only and it's confidential. > If you receive this message in error, please immediately delete it and > and notify the sender. Thank you. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > The SAQ Group > > Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ > SAQ is the trading name of SEMTEC Limited. Registered in England & Wales > Company Number: 06481952 > > http://www.saqnet.co.uk AS29219 > > SAQ Group Delivers high quality, honestly priced communication and I.T. > services to UK Business. > > Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : > Backups : Managed Networks : Remote Support. > > ISPA Member > > Find us in http://www.thebestof.co.uk/petersfield > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > [-- Attachment #1.2: Type: text/html, Size: 6048 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: R: [Xen-users] Xen 4.0 Feature Requests 2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro @ 2009-04-23 14:34 ` Robert Dunkley 2009-04-23 15:01 ` R: " Thiago Camargo Martins Cordeiro 2009-04-24 8:50 ` RE: R: [Xen-users] " Kieran Mansley 0 siblings, 2 replies; 36+ messages in thread From: Robert Dunkley @ 2009-04-23 14:34 UTC (permalink / raw) To: Thiago Camargo Martins Cordeiro Cc: xen-devel, Kashif Ali, Alessandro R., xen-users, cluster, stephen.spector [-- Attachment #1.1: Type: text/plain, Size: 4240 bytes --] VDE2 looks good, Fast Spanning tree could be useful but any idea what sort of performance hit would be taken by using VDE2? Lets see if there is any developer feedback, personally I think Vlan tagging needs addressing at some point since current VLan implementations with Xen are quite complex (Eg. Creating multiple bridges) and still have limitations. Rob From: Thiago Camargo Martins Cordeiro [mailto:thiagocmartinsc@gmail.com] Sent: 23 April 2009 14:38 To: Robert Dunkley Cc: Alessandro R.; Kashif Ali; cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests What about integrating Xen with a Virtual Ethernet Switch (like VDE2)? You can create a switch per client... 2009/4/23 Robert Dunkley <Robert@saq.co.uk> I second this request, just an easy way of VLan tagging per NIC in the VM config file would be good. Rob -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R. Sent: 22 April 2009 20:50 To: Kashif Ali Cc: cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests A tool that permit to configure virtual bridge like real switch (e.g. control VLAN, port status etc.) On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> wrote: > If there is any way to monitor,limit and control network traffic coming at > domUs with xen. I would like xen to have this feature as well. > > Thanks, > Kashif > > ________________________________ > From: cluster@xinet.it > To: stephen.spector@citrix.com; xen-users@lists.xensource.com; > xen-devel@lists.xensource.com > Subject: R: [Xen-users] Xen 4.0 Feature Requests > Date: Tue, 21 Apr 2009 16:53:04 +0200 > CC: > > I would like to have dynamic memory mangement for overcommitting RAM (like > vmware...). > > > > Thanks and regards, > > Francesco Gallo > > > > Da: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector > Inviato: martedì 21 aprile 2009 16.17 > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > Oggetto: [Xen-users] Xen 4.0 Feature Requests > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > feature requests for the next release, Xen 4.0. The current product roadmap > is at http://www.xen.org/download/roadmap.html and will be updated with the > new features you submit once Xen 3.4 is released. > > > > Please send me your features. Thanks. > > > > Stephen Spector > > Community Manager, Xen.org > > stephen.spector@xen.org > > (772) 621-5062 > > Blog: http://blog.xen.org > > Twitter: http://www.twitter.com/xen_com_mgr > > > > ________________________________ > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it > out. > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > -- Alessandro R. NOTICE This message is for the named person's use only and it's confidential. If you receive this message in error, please immediately delete it and and notify the sender. Thank you. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member Find us in http://www.thebestof.co.uk/petersfield _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users [-- Attachment #1.2: Type: text/html, Size: 15038 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: R: Xen 4.0 Feature Requests 2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley @ 2009-04-23 15:01 ` Thiago Camargo Martins Cordeiro 2009-04-24 8:50 ` RE: R: [Xen-users] " Kieran Mansley 1 sibling, 0 replies; 36+ messages in thread From: Thiago Camargo Martins Cordeiro @ 2009-04-23 15:01 UTC (permalink / raw) To: Robert Dunkley Cc: xen-devel, Kashif Ali, Alessandro R., xen-users, cluster, stephen.spector [-- Attachment #1.1: Type: text/plain, Size: 5343 bytes --] I have done some benchmarks with VDE2 with KVM and it is really fast! No one notes VDE2... 2009/4/23 Robert Dunkley <Robert@saq.co.uk> > VDE2 looks good, Fast Spanning tree could be useful but any idea what > sort of performance hit would be taken by using VDE2? Lets see if there is > any developer feedback, personally I think Vlan tagging needs addressing at > some point since current VLan implementations with Xen are quite complex > (Eg. Creating multiple bridges) and still have limitations. > > > > Rob > > > > *From:* Thiago Camargo Martins Cordeiro [mailto:thiagocmartinsc@gmail.com] > > *Sent:* 23 April 2009 14:38 > *To:* Robert Dunkley > *Cc:* Alessandro R.; Kashif Ali; cluster@xinet.it; > xen-devel@lists.xensource.com; stephen.spector@citrix.com; > xen-users@lists.xensource.com > > *Subject:* Re: R: [Xen-users] Xen 4.0 Feature Requests > > > > What about integrating Xen with a Virtual Ethernet Switch (like VDE2)? > You can create a switch per client... > > 2009/4/23 Robert Dunkley <Robert@saq.co.uk> > > I second this request, just an easy way of VLan tagging per NIC in the VM > config file would be good. > > Rob > > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com [mailto: > xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R. > Sent: 22 April 2009 20:50 > To: Kashif Ali > Cc: cluster@xinet.it; xen-devel@lists.xensource.com; > stephen.spector@citrix.com; xen-users@lists.xensource.com > Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests > > A tool that permit to configure virtual bridge like real switch (e.g. > control VLAN, port status etc.) > > On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> > wrote: > > If there is any way to monitor,limit and control network traffic coming > at > > domUs with xen. I would like xen to have this feature as well. > > > > Thanks, > > Kashif > > > > ________________________________ > > From: cluster@xinet.it > > To: stephen.spector@citrix.com; xen-users@lists.xensource.com; > > xen-devel@lists.xensource.com > > Subject: R: [Xen-users] Xen 4.0 Feature Requests > > Date: Tue, 21 Apr 2009 16:53:04 +0200 > > CC: > > > > I would like to have dynamic memory mangement for overcommitting RAM > (like > > vmware...). > > > > > > > > Thanks and regards, > > > > Francesco Gallo > > > > > > > > Da: xen-users-bounces@lists.xensource.com > > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen > Spector > > Inviato: martedì 21 aprile 2009 16.17 > > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > > Oggetto: [Xen-users] Xen 4.0 Feature Requests > > > > > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > > feature requests for the next release, Xen 4.0. The current product > roadmap > > is at http://www.xen.org/download/roadmap.html and will be updated with > the > > new features you submit once Xen 3.4 is released. > > > > > > > > Please send me your features. Thanks. > > > > > > > > Stephen Spector > > > > Community Manager, Xen.org > > > > stephen.spector@xen.org > > > > (772) 621-5062 > > > > Blog: http://blog.xen.org > > > > Twitter: http://www.twitter.com/xen_com_mgr > > > > > > > > ________________________________ > > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it > > out. > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > > > -- > Alessandro R. > > NOTICE > This message is for the named person's use only and it's confidential. > If you receive this message in error, please immediately delete it and > and notify the sender. Thank you. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > The SAQ Group > > Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ > SAQ is the trading name of SEMTEC Limited. Registered in England & Wales > Company Number: 06481952 > > http://www.saqnet.co.uk AS29219 > > SAQ Group Delivers high quality, honestly priced communication and I.T. > services to UK Business. > > Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : > Backups : Managed Networks : Remote Support. > > ISPA Member > > Find us in http://www.thebestof.co.uk/petersfield > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > > > ** > > ** *The SAQ Group* > > *Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ* > SAQ is the trading name of SEMTEC Limited. Registered in England & Wales > Company Number: 06481952 > > > > http://www.saqnet.co.uk AS29219 > > SAQ Group Delivers high quality, honestly priced communication and I.T. > services to UK Business. > > Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : > Backups : Managed Networks : Remote Support. > > > > [image: SAQ Group] > > > > *ISPA Member* > > > > <http://www.saq.co.uk> > > Find us in http://www.thebestof.co.uk/petersfield > [-- Attachment #1.2: Type: text/html, Size: 10639 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: R: [Xen-users] Xen 4.0 Feature Requests 2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley 2009-04-23 15:01 ` R: " Thiago Camargo Martins Cordeiro @ 2009-04-24 8:50 ` Kieran Mansley 1 sibling, 0 replies; 36+ messages in thread From: Kieran Mansley @ 2009-04-24 8:50 UTC (permalink / raw) To: xen-users, xen-devel On Thu, 2009-04-23 at 15:34 +0100, Robert Dunkley wrote: > VDE2 looks good, Fast Spanning tree could be useful but any idea what > sort of performance hit would be taken by using VDE2? Lets see if > there is any developer feedback, personally I think Vlan tagging needs > addressing at some point since current VLan implementations with Xen > are quite complex (Eg. Creating multiple bridges) and still have > limitations. This sort of thing interests Solarflare, but in a more general way. With Xen (and other virtualisation technologies) users often end up with a set of bridges, v-switches, hardware switches, and now switches (albeit limited in capabilities) in virtualisation-aware NICs. It would be very useful to develop a control plane over all these devices to allow them to be sensibly configured from a single point. I know there are some people working on bits of this problem but bringing it all together to work on Xen, using open APIs and protocols so that other technologies could be easily integrated, would help a lot. I'll add this to the list on the wiki, but would be happy to hear from others if they have ideas on this topic. Thanks Kieran ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: Xen 4.0 Feature Requests 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector 2009-04-21 14:53 ` R: " Francesco Gallo @ 2009-04-21 16:48 ` Tim Moore 2009-04-21 17:37 ` Paul Schulze ` (2 more replies) 2009-04-21 18:43 ` Pasi Kärkkäinen ` (3 subsequent siblings) 5 siblings, 3 replies; 36+ messages in thread From: Tim Moore @ 2009-04-21 16:48 UTC (permalink / raw) To: 'Stephen Spector', xen-users, 'xen-devel@lists.xensource.com' [-- Attachment #1.1: Type: text/plain, Size: 964 bytes --] 1. PCI VGA Passthrough for VT-d Support for everyday vendor cards from Nvidia primarily, then ATI and others .... (I know there is already limited support for Intel) Thanks! ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Stephen Spector Sent: 21 April 2009 15:17 To: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' Subject: [Xen-devel] Xen 4.0 Feature Requests With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released. Please send me your features. Thanks. Stephen Spector Community Manager, Xen.org stephen.spector@xen.org (772) 621-5062 Blog: http://blog.xen.org Twitter: http://www.twitter.com/xen_com_mgr [-- Attachment #1.2: Type: text/html, Size: 8664 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests 2009-04-21 16:48 ` Tim Moore @ 2009-04-21 17:37 ` Paul Schulze 2009-04-21 19:13 ` Jean Guyader 2009-04-22 1:08 ` Dirk Utterback 2 siblings, 0 replies; 36+ messages in thread From: Paul Schulze @ 2009-04-21 17:37 UTC (permalink / raw) To: Tim Moore Cc: 'xen-devel@lists.xensource.com', 'Stephen Spector', xen-users -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Apr 2009, at 18:48, Tim Moore wrote: > 1. PCI VGA Passthrough for VT-d > Support for everyday vendor cards from Nvidia primarily, then > ATI and others …. (I know there is already limited support for Intel) > > Thanks! I second that, although with the fact, that ATI specs are open, the first more or less proof of concept attempts might be easier to do for ATI graphics cards. Also (and not knowing, how far the work has gone on the subject), I would like to add "Full AMD IOMMU support (at least at the same level as VT-d)" to the list. Stone me, if thats already the case :) . Thanks, Paul. - -- Paul Schulze Mail: avlex82@gmail.com Why can't a programmer tell the difference between Halloween and Christmas? Because OCT31 = DEC25. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAknuBE8ACgkQj2zIQLJNnKPTdwCcCF20q2g7w3Klk46p9DVmvwa7 clEAoPiviHd1NCfJyrPlXVq+eaHl10A2 =1ItS -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests 2009-04-21 16:48 ` Tim Moore 2009-04-21 17:37 ` Paul Schulze @ 2009-04-21 19:13 ` Jean Guyader 2009-04-22 1:08 ` Dirk Utterback 2 siblings, 0 replies; 36+ messages in thread From: Jean Guyader @ 2009-04-21 19:13 UTC (permalink / raw) To: Tim Moore; +Cc: xen-devel, Stephen Spector, xen-users 2009/4/21 Tim Moore <timothy.moore@expidas.net>: > 1. PCI VGA Passthrough for VT-d > > Support for everyday vendor cards from Nvidia primarily, then ATI and > others …. (I know there is already limited support for Intel) > I don't thing that something we can put into a roadmap. Most of the issue we have can most of the time only be solve with new driver or new firmware. However we could commit to put the workaround we currently have in XCI into xen. Thanks, Jean > > > ________________________________ > > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Stephen Spector > Sent: 21 April 2009 15:17 > To: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > Subject: [Xen-devel] Xen 4.0 Feature Requests > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > feature requests for the next release, Xen 4.0. The current product roadmap > is at http://www.xen.org/download/roadmap.html and will be updated with the > new features you submit once Xen 3.4 is released. > > > > Please send me your features. Thanks. > > > > Stephen Spector > > Community Manager, Xen.org > > stephen.spector@xen.org > > (772) 621-5062 > > Blog: http://blog.xen.org > > Twitter: http://www.twitter.com/xen_com_mgr > > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests 2009-04-21 16:48 ` Tim Moore 2009-04-21 17:37 ` Paul Schulze 2009-04-21 19:13 ` Jean Guyader @ 2009-04-22 1:08 ` Dirk Utterback 2009-04-22 1:14 ` Samuel Thibault 2 siblings, 1 reply; 36+ messages in thread From: Dirk Utterback @ 2009-04-22 1:08 UTC (permalink / raw) To: Tim Moore; +Cc: xen-devel, Stephen Spector, xen-users [-- Attachment #1.1: Type: text/plain, Size: 1440 bytes --] It would be very nice if PCI passthrough for all VT machines (not just for VT-d boxes) is available. Thanks, Dirk On Tue, Apr 21, 2009 at 9:48 AM, Tim Moore <timothy.moore@expidas.net>wrote: > 1. PCI VGA Passthrough for VT-d > > Support for everyday vendor cards from Nvidia primarily, then ATI and > others …. (I know there is already limited support for Intel) > > > > Thanks! > > > ------------------------------ > > *From:* xen-devel-bounces@lists.xensource.com [mailto: > xen-devel-bounces@lists.xensource.com] *On Behalf Of *Stephen Spector > *Sent:* 21 April 2009 15:17 > *To:* xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com' > *Subject:* [Xen-devel] Xen 4.0 Feature Requests > > > > With Xen 3.4 in test for final release shortly, it is time to submit your > feature requests for the next release, Xen 4.0. The current product roadmap > is at http://www.xen.org/download/roadmap.html and will be updated with > the new features you submit once Xen 3.4 is released. > > > > Please send me your features. Thanks. > > > > Stephen Spector > > Community Manager, Xen.org > > stephen.spector@xen.org > > (772) 621-5062 > > Blog: http://blog.xen.org > > Twitter: http://www.twitter.com/xen_com_mgr > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > [-- Attachment #1.2: Type: text/html, Size: 5028 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests 2009-04-22 1:08 ` Dirk Utterback @ 2009-04-22 1:14 ` Samuel Thibault 2009-04-22 8:08 ` Dirk Utterback 0 siblings, 1 reply; 36+ messages in thread From: Samuel Thibault @ 2009-04-22 1:14 UTC (permalink / raw) To: Dirk Utterback; +Cc: xen-devel, Tim Moore, Stephen Spector, xen-users Dirk Utterback, le Tue 21 Apr 2009 18:08:41 -0700, a écrit : > It would be very nice if PCI passthrough for all VT machines (not just for > VT-d boxes) is available. Unsafe PCI passthrough is available. Safe PCI passthrough just can not happen without VT-d. Samuel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests 2009-04-22 1:14 ` Samuel Thibault @ 2009-04-22 8:08 ` Dirk Utterback 2009-04-22 8:11 ` Samuel Thibault 0 siblings, 1 reply; 36+ messages in thread From: Dirk Utterback @ 2009-04-22 8:08 UTC (permalink / raw) To: Samuel Thibault, Dirk Utterback, Tim Moore, xen-devel@lists.xensource.com [-- Attachment #1.1: Type: text/plain, Size: 559 bytes --] Samuel, On Tue, Apr 21, 2009 at 6:14 PM, Samuel Thibault < samuel.thibault@ens-lyon.org> wrote: > Dirk Utterback, le Tue 21 Apr 2009 18:08:41 -0700, a écrit : > > It would be very nice if PCI passthrough for all VT machines (not just > for > > VT-d boxes) is available. > > Unsafe PCI passthrough is available. Safe PCI passthrough just can not > happen without VT-d. > I agree PCI passthrough without VT-d has drawbacks. I just want to achieve good performance but not security. Are you saying it is available now? Thanks, Dirk [-- Attachment #1.2: Type: text/html, Size: 918 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests 2009-04-22 8:08 ` Dirk Utterback @ 2009-04-22 8:11 ` Samuel Thibault 0 siblings, 0 replies; 36+ messages in thread From: Samuel Thibault @ 2009-04-22 8:11 UTC (permalink / raw) To: Dirk Utterback; +Cc: xen-devel, Tim Moore, Stephen Spector, xen-users Dirk Utterback, le Wed 22 Apr 2009 01:08:26 -0700, a écrit : > Dirk Utterback, le Tue 21 Apr 2009 18:08:41 -0700, a écrit : > > It would be very nice if PCI passthrough for all VT machines (not just > for > > VT-d boxes) is available. > > Unsafe PCI passthrough is available. Safe PCI passthrough just can not > happen without VT-d. > > > I agree PCI passthrough without VT-d has drawbacks. I just want to achieve > good performance but not security. Are you saying it is available now? Sure, just use pciback and assign the device to a domU. Samuel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector 2009-04-21 14:53 ` R: " Francesco Gallo 2009-04-21 16:48 ` Tim Moore @ 2009-04-21 18:43 ` Pasi Kärkkäinen 2009-04-21 20:03 ` Andy Burns 2009-04-22 0:31 ` Philipp Schmid ` (2 subsequent siblings) 5 siblings, 1 reply; 36+ messages in thread From: Pasi Kärkkäinen @ 2009-04-21 18:43 UTC (permalink / raw) To: Stephen Spector; +Cc: 'xen-devel@lists.xensource.com', xen-users On Tue, Apr 21, 2009 at 10:17:04AM -0400, Stephen Spector wrote: > With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released. > > Please send me your features. Thanks. > Online resizing of domU disks. Earlier discussion about the subject: http://lists.xensource.com/archives/html/xen-devel/2008-09/msg00158.html http://lists.xensource.com/archives/html/xen-users/2008-04/msg00246.html Upstream Linux kernel 2.6.28 supports online resizing of SCSI disks. Also RHEL 5.3 (and CentOS 5.3) supports online resizing of SCSI disks. Should I write more detailed description of this feature request? -- Pasi > Stephen Spector > Community Manager, Xen.org > stephen.spector@xen.org > (772) 621-5062 > Blog: http://blog.xen.org > Twitter: http://www.twitter.com/xen_com_mgr > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-21 18:43 ` Pasi Kärkkäinen @ 2009-04-21 20:03 ` Andy Burns 2009-04-21 20:10 ` Maximilian Wilhelm 0 siblings, 1 reply; 36+ messages in thread From: Andy Burns @ 2009-04-21 20:03 UTC (permalink / raw) To: xen-devel 2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>: > Online resizing of domU disks. +1 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-21 20:03 ` Andy Burns @ 2009-04-21 20:10 ` Maximilian Wilhelm 0 siblings, 0 replies; 36+ messages in thread From: Maximilian Wilhelm @ 2009-04-21 20:10 UTC (permalink / raw) To: xen-devel Anno domini 2009 Andy Burns scripsit: > 2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>: > > > Online resizing of domU disks. > +1 Add me ;) Ciao Max -- Follow the white penguin. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector ` (2 preceding siblings ...) 2009-04-21 18:43 ` Pasi Kärkkäinen @ 2009-04-22 0:31 ` Philipp Schmid 2009-04-22 1:24 ` Akio Takebe 2009-04-22 16:14 ` [Xen-devel] " Thiago Camargo Martins Cordeiro 2009-05-03 18:27 ` Sander Eikelenboom 5 siblings, 1 reply; 36+ messages in thread From: Philipp Schmid @ 2009-04-22 0:31 UTC (permalink / raw) To: xen-users, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1191 bytes --] Hi, I would like to have a way to easily limit I/O for individual disks of virtual machines (pv, hvm and hvm-studom). Maybe in a similar way to the credit scheduler's weight? You can already partition CPU-Time, RAM, Disk space, but not really Disk I/O... William Pitcock seems to do some work on a I/O QoS token-based approach, maybe this is a good start? Best regards, Philipp Schmid +43 699 17246437 http://netmonic.com http://blog.netmonic.com http://twitter.com/netmonic On Apr 21, 2009, at 4:17 PM, Stephen Spector wrote: > With Xen 3.4 in test for final release shortly, it is time to submit > your feature requests for the next release, Xen 4.0. The current > product roadmap is athttp://www.xen.org/download/roadmap.html and > will be updated with the new features you submit once Xen 3.4 is > released. > > Please send me your features. Thanks. > > Stephen Spector > Community Manager, Xen.org > stephen.spector@xen.org > (772) 621-5062 > Blog: http://blog.xen.org > Twitter: http://www.twitter.com/xen_com_mgr > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel [-- Attachment #1.2: Type: text/html, Size: 6779 bytes --] [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-22 0:31 ` Philipp Schmid @ 2009-04-22 1:24 ` Akio Takebe 2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie 2009-04-22 1:57 ` Xen 4.0 Feature Requests Ryo Tsuruta 0 siblings, 2 replies; 36+ messages in thread From: Akio Takebe @ 2009-04-22 1:24 UTC (permalink / raw) To: Philipp Schmid; +Cc: Ryo Tsuruta, xen-devel, xen-users Hi, There are some discussions of I/O QoS feature in upstream of linux. We may be able to use such a feature with dom0 pv_ops of upstreams. e.g. http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/01317.html dm-ioband has rpm package of RHEL/CentOS, so you can use dm-ioband for xen. http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00116.html If you are interested in dm-ioband, please comment to Ryo. He would want feedbacks from many users. Best Regards, Akio Takebe Philipp Schmid wrote: > Hi, > > I would like to have a way to easily limit I/O for individual disks of > virtual machines (pv, hvm and hvm-studom). > Maybe in a similar way to the credit scheduler's weight? > > You can already partition CPU-Time, RAM, Disk space, but not really Disk > I/O... > > William Pitcock seems to do some work on a I/O QoS token-based approach, > maybe this is a good start? > > Best regards, > > Philipp Schmid > +43 699 17246437 > > http://netmonic.com > http://blog.netmonic.com > http://twitter.com/netmonic > > On Apr 21, 2009, at 4:17 PM, Stephen Spector wrote: > >> With Xen 3.4 in test for final release shortly, it is time to submit >> your feature requests for the next release, Xen 4.0. The current >> product roadmap is athttp://www.xen.org/download/roadmap.html and will >> be updated with the new features you submit once Xen 3.4 is released. >> >> Please send me your features. Thanks. >> >> Stephen Spector >> Community Manager, Xen.org >> stephen.spector@xen.org >> (772) 621-5062 >> Blog: http://blog.xen.org >> Twitter: http://www.twitter.com/xen_com_mgr >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* TSC virtualization across different host frequency platform migration 2009-04-22 1:24 ` Akio Takebe @ 2009-04-22 1:32 ` Dong, Eddie 2009-04-22 8:13 ` Keir Fraser 2009-04-22 15:47 ` Dan Magenheimer 2009-04-22 1:57 ` Xen 4.0 Feature Requests Ryo Tsuruta 1 sibling, 2 replies; 36+ messages in thread From: Dong, Eddie @ 2009-04-22 1:32 UTC (permalink / raw) To: xen-devel; +Cc: Tian, Kevin, Dong, Eddie, Keir Fraser, Zhang, Xiantao [-- Attachment #1: Type: text/plain, Size: 647 bytes --] Keir and all: Recently we are considering the potential issue of TSC virtualization across different frequency platform migration. Current approach will lead to synchronization issue between guest TSC and wall clock. Software trap and emulate can solve the problem with the payment of performance overhead which is not optimal. We want to propose smart scaling algorithm which can continuously use HW TSC_OFFSET and maintain long time synchronization of guest TSC. The details are in attached document. Can you have a look and provide comments? Thanks. BTW of course PV time is another solution which is not covered in this proposal. Eddie [-- Attachment #2: tsc-scale2.pdf --] [-- Type: application/pdf, Size: 228149 bytes --] [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: TSC virtualization across different host frequency platform migration 2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie @ 2009-04-22 8:13 ` Keir Fraser 2009-04-22 8:49 ` Dong, Eddie 2009-04-22 15:47 ` Dan Magenheimer 1 sibling, 1 reply; 36+ messages in thread From: Keir Fraser @ 2009-04-22 8:13 UTC (permalink / raw) To: Dong, Eddie, xen-devel; +Cc: Tian, Kevin, Zhang, Xiantao On 22/04/2009 02:32, "Dong, Eddie" <eddie.dong@intel.com> wrote: > Keir and all: > Recently we are considering the potential issue of TSC virtualization across > different frequency platform migration. Current approach will lead to > synchronization issue between guest TSC and wall clock. Software trap and > emulate can solve the problem with the payment of performance overhead which > is not optimal. We want to propose smart scaling algorithm which can > continuously use HW TSC_OFFSET and maintain long time synchronization of guest > TSC. The details are in attached document. Can you have a look and provide > comments? The important questions are: What guests get confused by an out-of-sync TSC? And is coarse-grained re-sync (multi-second quantum?) good enough? As a re-sync strategy well, yes, obviously it works but with some drawbacks. It would be very nice if VT could be extended to scale the host TSC as well as offset it. I would think that would be quite easy to do. -- Keir > Thanks. BTW of course PV time is another solution which is not covered in this > proposal. ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-22 8:13 ` Keir Fraser @ 2009-04-22 8:49 ` Dong, Eddie 0 siblings, 0 replies; 36+ messages in thread From: Dong, Eddie @ 2009-04-22 8:49 UTC (permalink / raw) To: Keir Fraser, xen-devel; +Cc: Tian, Kevin, Dong, Eddie, Zhang, Xiantao Keir Fraser wrote: > On 22/04/2009 02:32, "Dong, Eddie" <eddie.dong@intel.com> wrote: > >> Keir and all: >> Recently we are considering the potential issue of TSC >> virtualization across different frequency platform migration. >> Current approach will lead to synchronization issue between guest >> TSC and wall clock. Software trap and emulate can solve the problem >> with the payment of performance overhead which is not optimal. We >> want to propose smart scaling algorithm which can continuously use >> HW TSC_OFFSET and maintain long time synchronization of guest TSC. >> The details are in attached document. Can you have a look and >> provide comments? > > The important questions are: What guests get confused by an > out-of-sync TSC? And is coarse-grained re-sync (multi-second That is what I am interested too. Is there any report from real deployment which utilize migration frequently? thx, eddie ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie 2009-04-22 8:13 ` Keir Fraser @ 2009-04-22 15:47 ` Dan Magenheimer 2009-04-23 1:28 ` Dong, Eddie 1 sibling, 1 reply; 36+ messages in thread From: Dan Magenheimer @ 2009-04-22 15:47 UTC (permalink / raw) To: Dong, Eddie, xen-devel Cc: Tian, Kevin, dan.magenheimer, Keir Fraser, Zhang, Xiantao Hi Eddie/Kevin -- I'm sorry to be dense, but I don't understand the details of your solution. I'm also not sure I understand the problem you are trying to solve. The problem description doesn't describe a problem, just an event. I'm guessing the problem is: When a guest chooses TSC as its primary clocksource AND a migration later occurs to a host with a different TSC frequency THEN wallclock time (e.g. the "date" command) becomes incorrect. I'm also guessing that you are NOT trying to solve the problem: An application that uses TSC heavily to measure the passage of time AND calibrates TSC on host A AND invisibly migrates to host B with a different TSC frequency THEN will NOT be able to accurately measure the passage of time. However, it will continue to be monotonically increasing. In other words, you are trying to solve the OS problem but not the application problem. Is this correct? If so, then I think I understand your proposal. Also, I think it would be worthwhile to remeasure the cost of trapping every TSC read, using current processors and with some attempt in Xen to make the emulation fast (returning Xen system time). 10% seems like a VERY large number, even if a database is using TSC read to timestamp every transaction. If software-emulated TSC read can be made fast enough, then it solves both the OS and application problem. Dan > -----Original Message----- > From: Dong, Eddie [mailto:eddie.dong@intel.com] > Sent: Tuesday, April 21, 2009 7:33 PM > To: xen-devel@lists.xensource.com > Cc: Tian, Kevin; Dong, Eddie; Keir Fraser; Zhang, Xiantao > Subject: [Xen-devel] TSC virtualization across different host > frequency > platform migration > > > Keir and all: > Recently we are considering the potential issue of TSC > virtualization across different frequency platform migration. > Current approach will lead to synchronization issue between > guest TSC and wall clock. Software trap and emulate can solve > the problem with the payment of performance overhead which is > not optimal. We want to propose smart scaling algorithm which > can continuously use HW TSC_OFFSET and maintain long time > synchronization of guest TSC. The details are in attached > document. Can you have a look and provide comments? > Thanks. BTW of course PV time is another solution which > is not covered in this proposal. > > Eddie ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-22 15:47 ` Dan Magenheimer @ 2009-04-23 1:28 ` Dong, Eddie 2009-04-23 3:20 ` Tian, Kevin 0 siblings, 1 reply; 36+ messages in thread From: Dong, Eddie @ 2009-04-23 1:28 UTC (permalink / raw) To: Dan Magenheimer, xen-devel Cc: Tian, Kevin, Dong, Eddie, Keir Fraser, Zhang, Xiantao Dan Magenheimer wrote: > Hi Eddie/Kevin -- > > I'm sorry to be dense, but I don't understand the > details of your solution. I'm also not sure I > understand the problem you are trying to solve. > The problem description doesn't describe a problem, > just an event. > > I'm guessing the problem is: When a guest chooses > TSC as its primary clocksource AND a migration later > occurs to a host with a different TSC frequency > THEN wallclock time (e.g. the "date" command) > becomes incorrect. Mostly yes though don't know if guest wall clock depends on TSC heavily. > > I'm also guessing that you are NOT trying to solve > the problem: An application that uses TSC > heavily to measure the passage of time AND > calibrates TSC on host A AND invisibly > migrates to host B with a different TSC > frequency THEN will NOT be able to accurately > measure the passage of time. However, it will > continue to be monotonically increasing. Yes, if we don't scale the TSC. The proposal tries to solve the problem. We can use software trap and emulate to scale the TSC so that guest TSC after migration is same with that before migration. But this is not optimial since the overhead may be too high. So we propose to use smart scaling, which continuously use TSC_OFFSET, but adjust the TSC_OFFSET value time to time (today it is fixed), so that an application that uses TSC heavily to measure the passage of time can get correct time. thx, eddie ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-23 1:28 ` Dong, Eddie @ 2009-04-23 3:20 ` Tian, Kevin 2009-04-23 3:39 ` Dan Magenheimer 0 siblings, 1 reply; 36+ messages in thread From: Tian, Kevin @ 2009-04-23 3:20 UTC (permalink / raw) To: Dong, Eddie, Dan Magenheimer, xen-devel; +Cc: Keir Fraser, Zhang, Xiantao [-- Attachment #1: Type: text/plain, Size: 1998 bytes --] >From: Dong, Eddie >Sent: 2009年4月23日 9:29 > >Dan Magenheimer wrote: >> Hi Eddie/Kevin -- >> >> I'm sorry to be dense, but I don't understand the >> details of your solution. I'm also not sure I >> understand the problem you are trying to solve. >> The problem description doesn't describe a problem, >> just an event. >> >> I'm guessing the problem is: When a guest chooses >> TSC as its primary clocksource AND a migration later >> occurs to a host with a different TSC frequency >> THEN wallclock time (e.g. the "date" command) >> becomes incorrect. > >Mostly yes though don't know if guest wall clock depends on >TSC heavily. > >> >> I'm also guessing that you are NOT trying to solve >> the problem: An application that uses TSC >> heavily to measure the passage of time AND >> calibrates TSC on host A AND invisibly >> migrates to host B with a different TSC >> frequency THEN will NOT be able to accurately >> measure the passage of time. However, it will >> continue to be monotonically increasing. > >Yes, if we don't scale the TSC. >The proposal tries to solve the problem. > >We can use software trap and emulate to scale the TSC so >that guest TSC after migration is same with that before migration. > >But this is not optimial since the overhead may be too high. So we >propose to use smart scaling, which continuously use TSC_OFFSET, >but adjust the TSC_OFFSET value time to time (today it is fixed), >so that an application that uses TSC heavily to measure the >passage of time >can get correct time. > So we're really not trying to solve the micro-level accuracy if app tries to use TSC for that purpose, which always bias from bare metal as long as running in a VM. Here we're trying to ensure macro-level accuracy and thus ToD in guest after migration, with performance optimized if app in VM uses gettimeofday frequently. In that way, gap between trap vs. notrap would be orders of magnitude. Thanks Kevin [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-23 3:20 ` Tian, Kevin @ 2009-04-23 3:39 ` Dan Magenheimer 2009-04-23 6:15 ` Tian, Kevin 0 siblings, 1 reply; 36+ messages in thread From: Dan Magenheimer @ 2009-04-23 3:39 UTC (permalink / raw) To: Tian, Kevin, Dong, Eddie, xen-devel; +Cc: Keir Fraser, Zhang, Xiantao OK, I think I understand, but I think you are solving a very limited problem ("make sure that a user/program that requests time-of-day gets an answer which is close to accurate") but not solving the broader class of time problems, and you may be making them worse. If your solution is implemented and the OS or an application reads tsc, the values obtained will be monotonically increasing but will have large gaps, correct? If software-emulated tsc reads is really 10% loss in system performance, I agree that this might be the lesser of two evils. But I don't believe the 10%. > -----Original Message----- > From: Tian, Kevin [mailto:kevin.tian@intel.com] > Sent: Wednesday, April 22, 2009 9:21 PM > To: Dong, Eddie; Dan Magenheimer; xen-devel@lists.xensource.com > Cc: Keir Fraser; Zhang, Xiantao > Subject: RE: [Xen-devel] TSC virtualization across different > host frequency platform migration > > > >From: Dong, Eddie > >Sent: 2009年4月23日 9:29 > > > >Dan Magenheimer wrote: > >> Hi Eddie/Kevin -- > >> > >> I'm sorry to be dense, but I don't understand the > >> details of your solution. I'm also not sure I > >> understand the problem you are trying to solve. > >> The problem description doesn't describe a problem, > >> just an event. > >> > >> I'm guessing the problem is: When a guest chooses > >> TSC as its primary clocksource AND a migration later > >> occurs to a host with a different TSC frequency > >> THEN wallclock time (e.g. the "date" command) > >> becomes incorrect. > > > >Mostly yes though don't know if guest wall clock depends on > >TSC heavily. > > > >> > >> I'm also guessing that you are NOT trying to solve > >> the problem: An application that uses TSC > >> heavily to measure the passage of time AND > >> calibrates TSC on host A AND invisibly > >> migrates to host B with a different TSC > >> frequency THEN will NOT be able to accurately > >> measure the passage of time. However, it will > >> continue to be monotonically increasing. > > > >Yes, if we don't scale the TSC. > >The proposal tries to solve the problem. > > > >We can use software trap and emulate to scale the TSC so > >that guest TSC after migration is same with that before migration. > > > >But this is not optimial since the overhead may be too high. So we > >propose to use smart scaling, which continuously use TSC_OFFSET, > >but adjust the TSC_OFFSET value time to time (today it is fixed), > >so that an application that uses TSC heavily to measure the > >passage of time > >can get correct time. > > > > So we're really not trying to solve the micro-level accuracy if app > tries to use TSC for that purpose, which always bias from bare > metal as long as running in a VM. Here we're trying to ensure > macro-level accuracy and thus ToD in guest after migration, with > performance optimized if app in VM uses gettimeofday frequently. > In that way, gap between trap vs. notrap would be orders of > magnitude. > > Thanks > Kevin ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-23 3:39 ` Dan Magenheimer @ 2009-04-23 6:15 ` Tian, Kevin 2009-04-23 13:58 ` Dan Magenheimer 0 siblings, 1 reply; 36+ messages in thread From: Tian, Kevin @ 2009-04-23 6:15 UTC (permalink / raw) To: Dan Magenheimer, Dong, Eddie, xen-devel Cc: Yang, Xiaowei, Keir Fraser, Zhang, Xiantao [-- Attachment #1: Type: text/plain, Size: 3776 bytes --] >From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com] >Sent: 2009年4月23日 11:40 > >OK, I think I understand, but I think you are >solving a very limited problem ("make sure that >a user/program that requests time-of-day gets >an answer which is close to accurate") but >not solving the broader class of time problems, >and you may be making them worse. If your solution >is implemented and the OS or an application reads tsc, >the values obtained will be monotonically increasing >but will have large gaps, correct? that's always the case even w/o migration, since VM can be preempted at any time. > >If software-emulated tsc reads is really 10% loss >in system performance, I agree that this might be >the lesser of two evils. But I don't believe the >10%. That's really application specific, depending on the frequency of gettimeofday, e.g. in some database transation to stamp each record fastly. I had no exact data though. One of my colleagues (Xiaowei Yang) once solved one severe performance downgrade issue (orders of magnitude, >10%), when guest is observed falling back to use vHPET instead of TSC. The reason for fallback is not important here, but that actually inspires us to pay more attention here. Thanks, Kevin > >> -----Original Message----- >> From: Tian, Kevin [mailto:kevin.tian@intel.com] >> Sent: Wednesday, April 22, 2009 9:21 PM >> To: Dong, Eddie; Dan Magenheimer; xen-devel@lists.xensource.com >> Cc: Keir Fraser; Zhang, Xiantao >> Subject: RE: [Xen-devel] TSC virtualization across different >> host frequency platform migration >> >> >> >From: Dong, Eddie >> >Sent: 2009年4月23日 9:29 >> > >> >Dan Magenheimer wrote: >> >> Hi Eddie/Kevin -- >> >> >> >> I'm sorry to be dense, but I don't understand the >> >> details of your solution. I'm also not sure I >> >> understand the problem you are trying to solve. >> >> The problem description doesn't describe a problem, >> >> just an event. >> >> >> >> I'm guessing the problem is: When a guest chooses >> >> TSC as its primary clocksource AND a migration later >> >> occurs to a host with a different TSC frequency >> >> THEN wallclock time (e.g. the "date" command) >> >> becomes incorrect. >> > >> >Mostly yes though don't know if guest wall clock depends on >> >TSC heavily. >> > >> >> >> >> I'm also guessing that you are NOT trying to solve >> >> the problem: An application that uses TSC >> >> heavily to measure the passage of time AND >> >> calibrates TSC on host A AND invisibly >> >> migrates to host B with a different TSC >> >> frequency THEN will NOT be able to accurately >> >> measure the passage of time. However, it will >> >> continue to be monotonically increasing. >> > >> >Yes, if we don't scale the TSC. >> >The proposal tries to solve the problem. >> > >> >We can use software trap and emulate to scale the TSC so >> >that guest TSC after migration is same with that before migration. >> > >> >But this is not optimial since the overhead may be too high. So we >> >propose to use smart scaling, which continuously use TSC_OFFSET, >> >but adjust the TSC_OFFSET value time to time (today it is fixed), >> >so that an application that uses TSC heavily to measure the >> >passage of time >> >can get correct time. >> > >> >> So we're really not trying to solve the micro-level accuracy if app >> tries to use TSC for that purpose, which always bias from bare >> metal as long as running in a VM. Here we're trying to ensure >> macro-level accuracy and thus ToD in guest after migration, with >> performance optimized if app in VM uses gettimeofday frequently. >> In that way, gap between trap vs. notrap would be orders of >> magnitude. >> >> Thanks >> Kevin > [-- Attachment #2: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration 2009-04-23 6:15 ` Tian, Kevin @ 2009-04-23 13:58 ` Dan Magenheimer 0 siblings, 0 replies; 36+ messages in thread From: Dan Magenheimer @ 2009-04-23 13:58 UTC (permalink / raw) To: Tian, Kevin, Dong, Eddie, xen-devel Cc: Yang, Xiaowei, Keir Fraser, Zhang, Xiantao > that's always the case even w/o migration, since VM can be > preempted at any time. Not if it the vcpu is pinned, and that may often be the case for database apps. > That's really application specific, depending on the frequency > of gettimeofday, e.g. in some database transation to stamp > each record fastly. I had no exact data though. One of my > colleagues (Xiaowei Yang) once solved one severe performance > downgrade issue (orders of magnitude, >10%), when guest > is observed falling back to use vHPET instead of TSC. The > reason for fallback is not important here, but that actually inspires > us to pay more attention here. I'm suggesting that you measure and compare the cycle cost of a TSC read and a vTSC read (and maybe also a vHPET read), and also look at the code to see what the bottleneck is for a vTSC read and if it can be made faster. And since your solution doesn't solve PV time, maybe also measure a vTSC read in a PV guest. I also agree with Keir that a tsc scaler might be a good enhancement to request for future VT-x designs. > -----Original Message----- > From: Tian, Kevin [mailto:kevin.tian@intel.com] > Sent: Thursday, April 23, 2009 12:15 AM > To: Dan Magenheimer; Dong, Eddie; xen-devel@lists.xensource.com > Cc: Keir Fraser; Zhang, Xiantao; Yang, Xiaowei > Subject: RE: [Xen-devel] TSC virtualization across different > host frequency platform migration > > > >From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com] > >Sent: 2009年4月23日 11:40 > > > >OK, I think I understand, but I think you are > >solving a very limited problem ("make sure that > >a user/program that requests time-of-day gets > >an answer which is close to accurate") but > >not solving the broader class of time problems, > >and you may be making them worse. If your solution > >is implemented and the OS or an application reads tsc, > >the values obtained will be monotonically increasing > >but will have large gaps, correct? > > that's always the case even w/o migration, since VM can be > preempted at any time. > > > > >If software-emulated tsc reads is really 10% loss > >in system performance, I agree that this might be > >the lesser of two evils. But I don't believe the > >10%. > > That's really application specific, depending on the frequency > of gettimeofday, e.g. in some database transation to stamp > each record fastly. I had no exact data though. One of my > colleagues (Xiaowei Yang) once solved one severe performance > downgrade issue (orders of magnitude, >10%), when guest > is observed falling back to use vHPET instead of TSC. The > reason for fallback is not important here, but that actually inspires > us to pay more attention here. > > Thanks, > Kevin > > > > >> -----Original Message----- > >> From: Tian, Kevin [mailto:kevin.tian@intel.com] > >> Sent: Wednesday, April 22, 2009 9:21 PM > >> To: Dong, Eddie; Dan Magenheimer; xen-devel@lists.xensource.com > >> Cc: Keir Fraser; Zhang, Xiantao > >> Subject: RE: [Xen-devel] TSC virtualization across different > >> host frequency platform migration > >> > >> > >> >From: Dong, Eddie > >> >Sent: 2009年4月23日 9:29 > >> > > >> >Dan Magenheimer wrote: > >> >> Hi Eddie/Kevin -- > >> >> > >> >> I'm sorry to be dense, but I don't understand the > >> >> details of your solution. I'm also not sure I > >> >> understand the problem you are trying to solve. > >> >> The problem description doesn't describe a problem, > >> >> just an event. > >> >> > >> >> I'm guessing the problem is: When a guest chooses > >> >> TSC as its primary clocksource AND a migration later > >> >> occurs to a host with a different TSC frequency > >> >> THEN wallclock time (e.g. the "date" command) > >> >> becomes incorrect. > >> > > >> >Mostly yes though don't know if guest wall clock depends on > >> >TSC heavily. > >> > > >> >> > >> >> I'm also guessing that you are NOT trying to solve > >> >> the problem: An application that uses TSC > >> >> heavily to measure the passage of time AND > >> >> calibrates TSC on host A AND invisibly > >> >> migrates to host B with a different TSC > >> >> frequency THEN will NOT be able to accurately > >> >> measure the passage of time. However, it will > >> >> continue to be monotonically increasing. > >> > > >> >Yes, if we don't scale the TSC. > >> >The proposal tries to solve the problem. > >> > > >> >We can use software trap and emulate to scale the TSC so > >> >that guest TSC after migration is same with that before migration. > >> > > >> >But this is not optimial since the overhead may be too high. So we > >> >propose to use smart scaling, which continuously use TSC_OFFSET, > >> >but adjust the TSC_OFFSET value time to time (today it is fixed), > >> >so that an application that uses TSC heavily to measure the > >> >passage of time > >> >can get correct time. > >> > > >> > >> So we're really not trying to solve the micro-level accuracy if app > >> tries to use TSC for that purpose, which always bias from bare > >> metal as long as running in a VM. Here we're trying to ensure > >> macro-level accuracy and thus ToD in guest after migration, with > >> performance optimized if app in VM uses gettimeofday frequently. > >> In that way, gap between trap vs. notrap would be orders of > >> magnitude. > >> > >> Thanks > >> Kevin > > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-22 1:24 ` Akio Takebe 2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie @ 2009-04-22 1:57 ` Ryo Tsuruta 1 sibling, 0 replies; 36+ messages in thread From: Ryo Tsuruta @ 2009-04-22 1:57 UTC (permalink / raw) To: takebe_akio; +Cc: xen-devel, xen-users, lists Hi, From: Akio Takebe <takebe_akio@jp.fujitsu.com> Date: Wed, 22 Apr 2009 10:24:20 +0900 > dm-ioband has rpm package of RHEL/CentOS, so you can use dm-ioband for xen. > http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00116.html > > If you are interested in dm-ioband, please comment to Ryo. > He would want feedbacks from many users. Thanks you takebe-san for introducing dm-ioband. I ran some benchmarks with Xen and got goot results. Bandwidth control for Xen - On a per Xen virtual block device basis. http://people.valinux.co.jp/~ryov/dm-ioband/benchmark/xen-partition.html - On a per Xen blktap process basis. http://people.valinux.co.jp/~ryov/dm-ioband/benchmark/xen-blktap.html You can download RPM packages for RHEL/CentOS from the below link. http://people.valinux.co.jp/~ryov/dm-ioband/binary.html And you can find configuration examples on the below link. http://people.valinux.co.jp/~ryov/dm-ioband/manual/examples.html#AEN584 Please try to use dm-ioband and let me know your feedback. Thanks, Ryo Tsuruta ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Xen-devel] Xen 4.0 Feature Requests 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector ` (3 preceding siblings ...) 2009-04-22 0:31 ` Philipp Schmid @ 2009-04-22 16:14 ` Thiago Camargo Martins Cordeiro 2009-05-03 18:27 ` Sander Eikelenboom 5 siblings, 0 replies; 36+ messages in thread From: Thiago Camargo Martins Cordeiro @ 2009-04-22 16:14 UTC (permalink / raw) To: Stephen Spector; +Cc: xen-devel, xen-users [-- Attachment #1.1: Type: text/plain, Size: 1015 bytes --] Hi, I guess Xen needs some kind of Virtual Ethernet Switch, virtual uplinks (through SSH, for example), virtual cables, virtual plugs, so I can create a virtual switch per client on each of my dom0 of my cluster, or maybe it needs a easy way to integrate itself with VDE2. Regards, Thiago 2009/4/21 Stephen Spector <stephen.spector@citrix.com> > With Xen 3.4 in test for final release shortly, it is time to submit your > feature requests for the next release, Xen 4.0. The current product roadmap > is at http://www.xen.org/download/roadmap.html and will be updated with > the new features you submit once Xen 3.4 is released. > > > > Please send me your features. Thanks. > > > > Stephen Spector > > Community Manager, Xen.org > > stephen.spector@xen.org > > (772) 621-5062 > > Blog: http://blog.xen.org > > Twitter: http://www.twitter.com/xen_com_mgr > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > [-- Attachment #1.2: Type: text/html, Size: 1846 bytes --] [-- Attachment #2: Type: text/plain, Size: 137 bytes --] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector ` (4 preceding siblings ...) 2009-04-22 16:14 ` [Xen-devel] " Thiago Camargo Martins Cordeiro @ 2009-05-03 18:27 ` Sander Eikelenboom 2009-05-03 20:12 ` Paul Schulze 5 siblings, 1 reply; 36+ messages in thread From: Sander Eikelenboom @ 2009-05-03 18:27 UTC (permalink / raw) To: Stephen Spector; +Cc: xen-devel The features i'm looking for are: - as many others .. VGA (pci-e/pci) passthrough - complete USB passthrough, (also working for webcams/videograbbers etc) i'm currently working with "USB over IP" from the http://usbip.sourceforge.net/ project. It is working fine for printers/scanners, and almost perfect for webcam (some little distortion left). But functionality within XEN would be better. Keep up the good work, still loving xen , and always happy to test :-) -- Sander Tuesday, April 21, 2009, 4:17:04 PM, you wrote: > With Xen 3.4 in test for final release shortly, it is time to submit > your feature requests for the next release, Xen 4.0. The current product > roadmap is at http://www.xen.org/download/roadmap.html and will be > updated with the new features you submit once Xen 3.4 is released. > Please send me your features. Thanks. > Stephen Spector > Community Manager, Xen.org > stephen.spector@xen.org > (772) 621-5062 > Blog: http://blog.xen.org > Twitter: http://www.twitter.com/xen_com_mgr -- Best regards, Sander mailto:linux@eikelenboom.it ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests 2009-05-03 18:27 ` Sander Eikelenboom @ 2009-05-03 20:12 ` Paul Schulze 2009-05-04 5:54 ` Re[2]: " Sander Eikelenboom 0 siblings, 1 reply; 36+ messages in thread From: Paul Schulze @ 2009-05-03 20:12 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: xen-devel, Stephen Spector -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 3 May 2009, at 20:27, Sander Eikelenboom wrote: > The features i'm looking for are: > > - as many others .. VGA (pci-e/pci) passthrough > - complete USB passthrough, (also working for webcams/videograbbers > etc) Fully functional USB passthrough would be really nice to have, but to be useful, I would also like to also request some sort of device management, that allows automatically assigning devices to a DomU whenever it is connected and a way to have unknown devices assigned to a default DomU. Otherwise, interaction on the Dom0 will be needed for each and every time, a device is connected. Paul. - -- Paul Schulze Mail: avlex82@gmail.com Why can't a programmer tell the difference between Halloween and Christmas? Because OCT31 = DEC25. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkn9+psACgkQj2zIQLJNnKN8qwCfUqKhF7bHRdjyp/r4G9PJjY3u YTQAn37ah5y0bul1FaeT4WrFlGt7ePg7 =BMlM -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re[2]: Xen 4.0 Feature Requests 2009-05-03 20:12 ` Paul Schulze @ 2009-05-04 5:54 ` Sander Eikelenboom 2009-05-05 14:24 ` Ian Jackson 0 siblings, 1 reply; 36+ messages in thread From: Sander Eikelenboom @ 2009-05-04 5:54 UTC (permalink / raw) To: Paul Schulze; +Cc: xen-devel, Stephen Spector Good point, some good and flexible management would be nice to have too. USBIP at the moment can handle: - remove binding to currently loaded modules - binding to usbip at plugin time In some quite simple userspace management tools. For xen it think xend would be the place for normal rules, and xm for hotplug ? It would be nice if you could make the rules for usb passthrough match with both usb port numbers as well as device id's, perhaps even with wildcards. Sunday, May 3, 2009, 10:12:05 PM, you wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > Hi, > On 3 May 2009, at 20:27, Sander Eikelenboom wrote: >> The features i'm looking for are: >> >> - as many others .. VGA (pci-e/pci) passthrough >> - complete USB passthrough, (also working for webcams/videograbbers >> etc) > Fully functional USB passthrough would be really nice to have, but to > be useful, I would also like to also request some sort of device > management, that allows automatically assigning devices to a DomU > whenever it is connected and a way to have unknown devices assigned to > a default DomU. Otherwise, interaction on the Dom0 will be needed for > each and every time, a device is connected. > Paul. -- Best regards, Sander mailto:linux@eikelenboom.it ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Re[2]: Xen 4.0 Feature Requests 2009-05-04 5:54 ` Re[2]: " Sander Eikelenboom @ 2009-05-05 14:24 ` Ian Jackson 0 siblings, 0 replies; 36+ messages in thread From: Ian Jackson @ 2009-05-05 14:24 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: xen-devel, Stephen Spector, Paul Schulze Sander Eikelenboom writes ("Re[2]: [Xen-devel] Xen 4.0 Feature Requests"): > Good point, some good and flexible management would be nice to have too. > > USBIP at the moment can handle: Yes, the usbip management tools are much better than the pvusb setup we have right now. Sadly I didn't find the usbip code worked very well for me (at least, the version I found in upstream 2.6-staging). It would be sensible in the longer term to try to unify usbip with our pvusb support. > It would be nice if you could make the rules for usb passthrough match with > both usb port numbers as well as device id's, perhaps even with wildcards. Yes. Patches will be very welcome, after the 3.4 release :-). Thanks, Ian. ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2009-05-05 14:24 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector 2009-04-21 14:53 ` R: " Francesco Gallo 2009-04-22 14:51 ` Kashif Ali 2009-04-22 19:49 ` Alessandro R. 2009-04-23 7:27 ` Robert Dunkley 2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro 2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley 2009-04-23 15:01 ` R: " Thiago Camargo Martins Cordeiro 2009-04-24 8:50 ` RE: R: [Xen-users] " Kieran Mansley 2009-04-21 16:48 ` Tim Moore 2009-04-21 17:37 ` Paul Schulze 2009-04-21 19:13 ` Jean Guyader 2009-04-22 1:08 ` Dirk Utterback 2009-04-22 1:14 ` Samuel Thibault 2009-04-22 8:08 ` Dirk Utterback 2009-04-22 8:11 ` Samuel Thibault 2009-04-21 18:43 ` Pasi Kärkkäinen 2009-04-21 20:03 ` Andy Burns 2009-04-21 20:10 ` Maximilian Wilhelm 2009-04-22 0:31 ` Philipp Schmid 2009-04-22 1:24 ` Akio Takebe 2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie 2009-04-22 8:13 ` Keir Fraser 2009-04-22 8:49 ` Dong, Eddie 2009-04-22 15:47 ` Dan Magenheimer 2009-04-23 1:28 ` Dong, Eddie 2009-04-23 3:20 ` Tian, Kevin 2009-04-23 3:39 ` Dan Magenheimer 2009-04-23 6:15 ` Tian, Kevin 2009-04-23 13:58 ` Dan Magenheimer 2009-04-22 1:57 ` Xen 4.0 Feature Requests Ryo Tsuruta 2009-04-22 16:14 ` [Xen-devel] " Thiago Camargo Martins Cordeiro 2009-05-03 18:27 ` Sander Eikelenboom 2009-05-03 20:12 ` Paul Schulze 2009-05-04 5:54 ` Re[2]: " Sander Eikelenboom 2009-05-05 14:24 ` Ian Jackson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.