On Fri, Aug 10, 2007 at 05:10:46PM +0100, Daniel P. Berrange wrote:
> On Fri, Aug 10, 2007 at 12:08:26PM -0400, Daniel Veillard wrote:
> > On Fri, Aug 10, 2007 at 04:39:03PM +0100, Daniel P. Berrange wrote:
> > > The code for dealing with the paravirt framebuffer was missing code to
> > > deal
> >
On Fri, Aug 10, 2007 at 05:06:30PM +0100, Daniel P. Berrange wrote:
> On Fri, Aug 10, 2007 at 12:03:10PM -0400, Daniel Veillard wrote:
> > On Fri, Aug 10, 2007 at 04:36:25PM +0100, Daniel P. Berrange wrote:
> > > The virtual networks stuff was never added to the xm driver for Xen 3.0.3
> > > or ear
On Fri, Aug 10, 2007 at 12:36:05PM -0400, Jim Paris wrote:
> > if it's okay to add a variable lenght data structure at the end, they might
> > want to extend it in the future and that would be hard to handle.
>
> I think appending unrelated data to the migration image is a bit of a
> hack anyway.
On Fri, Aug 10, 2007 at 10:57:50AM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >The Xen implementations of
> >
> > virDomainLookupByID
> > virDomainLookupByUUID
> > virDomainLookupByName
> > virDomainGetOSType
> >
> >all have sub-optimal performance since they speak to Xe
On Fri, Aug 10, 2007 at 05:16:28PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >The code for dealing with the paravirt framebuffer was missing code to deal
> >with an explicit vncdisplay=N setting - only working for vncunused=1. It
> >was also not flexible enough in processing t
On Fri, Aug 10, 2007 at 12:36:05PM -0400, Jim Paris wrote:
> Daniel Veillard wrote:
> > On Thu, Aug 09, 2007 at 10:55:10PM +0100, Daniel P. Berrange wrote:
> > > Just been committed to KVM repos I see. Should be an easy patch to
> > > backport
> > > too. As long as we can detect failure if this is
Daniel Veillard wrote:
> On Thu, Aug 09, 2007 at 10:55:10PM +0100, Daniel P. Berrange wrote:
> > Just been committed to KVM repos I see. Should be an easy patch to backport
> > too. As long as we can detect failure if this is missing & report it back
> > then I'm fine depending on this.
>
> Wou
Daniel P. Berrange wrote:
The virtual networks stuff was never added to the xm driver for Xen 3.0.3
or earlier. This means that if adding a virtual network the bridge device
won't get defined in the config. This patch addreses this, and also fixes
a tiny mem leak in the equivalent code in the xen
Daniel P. Berrange wrote:
The code for dealing with the paravirt framebuffer was missing code to deal
with an explicit vncdisplay=N setting - only working for vncunused=1. It
was also not flexible enough in processing the 2 different styles of FB
config.
I too am having trouble following the e
On Fri, Aug 10, 2007 at 12:08:26PM -0400, Daniel Veillard wrote:
> On Fri, Aug 10, 2007 at 04:39:03PM +0100, Daniel P. Berrange wrote:
> > The code for dealing with the paravirt framebuffer was missing code to deal
> > with an explicit vncdisplay=N setting - only working for vncunused=1. It
> > wa
On Fri, Aug 10, 2007 at 04:39:03PM +0100, Daniel P. Berrange wrote:
> The code for dealing with the paravirt framebuffer was missing code to deal
> with an explicit vncdisplay=N setting - only working for vncunused=1. It
> was also not flexible enough in processing the 2 different styles of FB
> c
On Fri, Aug 10, 2007 at 12:03:10PM -0400, Daniel Veillard wrote:
> On Fri, Aug 10, 2007 at 04:36:25PM +0100, Daniel P. Berrange wrote:
> > The virtual networks stuff was never added to the xm driver for Xen 3.0.3
> > or earlier. This means that if adding a virtual network the bridge device
> > won'
Richard W.M. Jones wrote:
> Jim Paris wrote:
> >+if (strchr(path, '\'') || strchr(path, '\\') ) {
> >+qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
> >+ "invalid filename");
> >+return -1;
> >+}
> [...]
> >+/* Migrate to file. *
On Fri, Aug 10, 2007 at 04:36:25PM +0100, Daniel P. Berrange wrote:
> The virtual networks stuff was never added to the xm driver for Xen 3.0.3
> or earlier. This means that if adding a virtual network the bridge device
> won't get defined in the config. This patch addreses this, and also fixes
> a
The code for dealing with the paravirt framebuffer was missing code to deal
with an explicit vncdisplay=N setting - only working for vncunused=1. It
was also not flexible enough in processing the 2 different styles of FB
config.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +
The virtual networks stuff was never added to the xm driver for Xen 3.0.3
or earlier. This means that if adding a virtual network the bridge device
won't get defined in the config. This patch addreses this, and also fixes
a tiny mem leak in the equivalent code in the xend driver.
Dan.
--
|=- Red
Daniel P. Berrange wrote:
The virbrN / xenbrN devices are bridges so see all traffic from any guest
attached. We need to look at ths individual vifN.N or vnetN devices which
are per-guest. This info isn't included in the XML though. If we can figure
out a efficient way to export vif name in t
Daniel P. Berrange wrote:
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
It includes a couple of virsh commands if you want to play with looking
at the stats.
The network interface stuff isn't quiet correct
+/* Pat
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
> This is the implementation (currently Xen, local only).
>
> It includes a couple of virsh commands if you want to play with looking
> at the stats.
The network interface stuff isn't quiet correct
+/* Paths have the form "virb
On Fri, Aug 10, 2007 at 03:41:54PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >It is probably worthwhile though to
> >ensure that we design the APIs so that the structs are always allocated by
> >the internal driver and not the caller. This allows us to add more fields
> >at a l
Daniel P. Berrange wrote:
It is probably worthwhile though to
ensure that we design the APIs so that the structs are always allocated by
the internal driver and not the caller. This allows us to add more fields
at a later date if needed.
Instead of the above, the caller has to pass in the size
This is the implementation (currently Xen, local only).
It includes a couple of virsh commands if you want to play with looking
at the stats.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Win
On Fri, Aug 10, 2007 at 01:59:34PM +0100, Richard W.M. Jones wrote:
> It was suggested to me that we should provide a way to return bytes read
> and written on block devices (not just requests). Xen doesn't support
> that however, so I have also changed the fields in this structure so
> that th
On Fri, Aug 10, 2007 at 02:58:59PM +0100, Richard W.M. Jones wrote:
> Daniel Veillard wrote:
> > wr_bytes :-)
>
> Duh :-(
>
> >> int64_t errs; // In Xen this returns the mysterious 'oo_req'.
> >>};
> >>typedef struct _virDomainBlockStats *virDomainBlockStatsPtr;
> >
> > then yes that's okay
Daniel Veillard wrote:
wr_bytes :-)
Duh :-(
int64_t errs; // In Xen this returns the mysterious 'oo_req'.
};
typedef struct _virDomainBlockStats *virDomainBlockStatsPtr;
then yes that's okay.
Those interfaces are what I suggested as the low level ones, I guess
they are needed even
On Fri, Aug 10, 2007 at 01:59:34PM +0100, Richard W.M. Jones wrote:
> It was suggested to me that we should provide a way to return bytes read
> and written on block devices (not just requests). Xen doesn't support
> that however, so I have also changed the fields in this structure so
> that th
On Fri, Aug 10, 2007 at 06:39:56AM -0400, Daniel Veillard wrote:
> On Thu, Aug 09, 2007 at 11:13:00PM +0100, Daniel P. Berrange wrote:
> > The Xen implementations of
> >
> >virDomainLookupByID
> >virDomainLookupByUUID
> >virDomainLookupByName
> >virDomainGetOSType
> >
> > all have
On Fri, Aug 10, 2007 at 02:33:28PM +0100, Daniel P. Berrange wrote:
> On Fri, Aug 10, 2007 at 06:39:56AM -0400, Daniel Veillard wrote:
> > Well if you have 100 guests, that may be slower, but in the average
> > situation
> > of only a couple of guests, it could be a real speedup. The problem is
On Fri, Aug 10, 2007 at 11:06:02AM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >>- I append the domain's UUID at the end of the migration image.
> >> This doesn't affect KVM at all (it ignores the extra data).
> >> Does that seem reasonable? It's unclear how the saved image
>
It was suggested to me that we should provide a way to return bytes read
and written on block devices (not just requests). Xen doesn't support
that however, so I have also changed the fields in this structure so
that they can be returned set to -1 to indicate "no data / not supported".
The up
With the very timely question that has been raised about block and
network device stats, I'm posting my proposed interface. I almost have
this working for the Xen case on my test machine.
The idea of this interface is to be optimised for the following case:
* stats need to be fetched frequen
Mindaugas Kiznis wrote:
Thank you for your quick answer. In my opinion, I/O statistics are
critical as CPU, memory usage in data center environment to optimally
plan, arrange, spread VMs in a resource or say Xenhost pool. Since there
are many Xen hosts in my case and this number is growing, it
On Fri, Aug 10, 2007 at 11:10:50AM +0100, Richard W.M. Jones wrote:
> Mindaugas Kiznis wrote:
> >- I am trying to make an application, which would connect to a remote
> >xen host and fetch some information about total (physical) CPU usage,
> >total memory usage, network and disk I/O. I have manag
On Thu, Aug 09, 2007 at 11:13:00PM +0100, Daniel P. Berrange wrote:
> The Xen implementations of
>
>virDomainLookupByID
>virDomainLookupByUUID
>virDomainLookupByName
>virDomainGetOSType
>
> all have sub-optimal performance since they speak to XenD. The lookupXXX
> functions all ba
Thank you for your quick answer. In my opinion, I/O statistics are
critical as CPU, memory usage in data center environment to optimally
plan, arrange, spread VMs in a resource or say Xenhost pool. Since there
are many Xen hosts in my case and this number is growing, it is a need
to monitor eac
On Thu, Aug 09, 2007 at 10:55:10PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 09, 2007 at 05:26:43PM -0400, Jim Paris wrote:
> > Hi,
> >
> > I've implemented save/restore support for KVM using the live migration
> > feature. First, a few patches to KVM to fix bugs:
Very cool :-)
> > Then,
Mindaugas Kiznis wrote:
- I am trying to make an application, which would connect to a remote
xen host and fetch some information about total (physical) CPU usage,
total memory usage, network and disk I/O. I have managed to do a remote
statistics grabber for CPU and memory usage using libvirt.
Daniel P. Berrange wrote:
- I append the domain's UUID at the end of the migration image.
This doesn't affect KVM at all (it ignores the extra data).
Does that seem reasonable? It's unclear how the saved image
is supposed to get associated with a particular VM configuration
without doin
Jim Paris wrote:
+if (strchr(path, '\'') || strchr(path, '\\') ) {
+qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ "invalid filename");
+return -1;
+}
[...]
+/* Migrate to file. */
+if (asprintf (&command, "migrate \"ex
Hello,
- I am trying to make an application, which would connect to a remote
xen host and fetch some information about total (physical) CPU usage,
total memory usage, network and disk I/O. I have managed to do a remote
statistics grabber for CPU and memory usage using libvirt. I couldn't
find
Daniel P. Berrange wrote:
The Xen implementations of
virDomainLookupByID
virDomainLookupByUUID
virDomainLookupByName
virDomainGetOSType
all have sub-optimal performance since they speak to XenD. The lookupXXX
functions all basically require 3 pieces of info in the end (name,id,uuid)
41 matches
Mail list logo
