Xen 4.0 Feature Requests

Xen 4.0 Feature Requests

[Stephen Spector]

[-- 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

R: Xen 4.0 Feature Requests

[Francesco Gallo]

[-- 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

RE: Xen 4.0 Feature Requests

[Tim Moore]

[-- 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

Re: RE: Xen 4.0 Feature Requests

[Paul Schulze]

-----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-----

Re: Xen 4.0 Feature Requests

[Pasi Kärkkäinen]

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

Re: RE: Xen 4.0 Feature Requests

[Jean Guyader]

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
>
>
>

Re: Xen 4.0 Feature Requests

[Andy Burns]

2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>:

> Online resizing of domU disks.

+1

Re: Xen 4.0 Feature Requests

[Maximilian Wilhelm]

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.

Re: Xen 4.0 Feature Requests

[Philipp Schmid]

[-- 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

Re: RE: Xen 4.0 Feature Requests

[Dirk Utterback]

[-- 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

Re: RE: Xen 4.0 Feature Requests

[Samuel Thibault]

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

Re: Xen 4.0 Feature Requests

[Akio Takebe]

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

TSC virtualization across different host frequency platform migration

[Dong, Eddie]

[-- 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

Re: Xen 4.0 Feature Requests

[Ryo Tsuruta]

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

Re: RE: Xen 4.0 Feature Requests

[Dirk Utterback]

[-- 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

Re: RE: Xen 4.0 Feature Requests

[Samuel Thibault]

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

Re: TSC virtualization across different host frequency platform migration

[Keir Fraser]

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.

RE: TSC virtualization across different host frequency platform migration

[Dong, Eddie]

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

RE: R: Xen 4.0 Feature Requests

[Kashif Ali]

[-- 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

RE: TSC virtualization across different host frequency platform migration

[Dan Magenheimer]

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

Re: [Xen-devel] Xen 4.0 Feature Requests

[Thiago Camargo Martins Cordeiro]

[-- 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

Re: R: Xen 4.0 Feature Requests

[Alessandro R.]

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.

RE: TSC virtualization across different host frequency platform migration

[Dong, Eddie]

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

RE: TSC virtualization across different host frequency platform migration

[Tian, Kevin]

[-- 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

RE: TSC virtualization across different host frequency platform migration

[Dan Magenheimer]

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

RE: TSC virtualization across different host frequency platform migration

[Tian, Kevin]

[-- 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

RE: R: Xen 4.0 Feature Requests

[Robert Dunkley]

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

Re: R: Xen 4.0 Feature Requests

[Thiago Camargo Martins Cordeiro]

[-- 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

RE: TSC virtualization across different host frequency platform migration

[Dan Magenheimer]

> 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
> >

RE: R: [Xen-users] Xen 4.0 Feature Requests

[Robert Dunkley]

[-- 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

Re: R: Xen 4.0 Feature Requests

[Thiago Camargo Martins Cordeiro]

[-- 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

Re: RE: R: [Xen-users] Xen 4.0 Feature Requests

[Kieran Mansley]

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

Re: Xen 4.0 Feature Requests

[Sander Eikelenboom]

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

Re: Xen 4.0 Feature Requests

[Paul Schulze]

-----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-----

Re[2]: Xen 4.0 Feature Requests

[Sander Eikelenboom]

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

Re: Re[2]: Xen 4.0 Feature Requests

[Ian Jackson]

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.