way of overflowing the buffer).
Please ACK...
--Hugh
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
diff -ruN libvirt.orig/src/xend_internal.c libvirt
not
adding much risk of breakage.
Please ACK.
Take care,
--Hugh
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
diff -ruN libvirt.orig/src
Daniel P. Berrange wrote:
On Thu, Sep 06, 2007 at 11:59:08AM -0400, Daniel Veillard wrote:
On Thu, Sep 06, 2007 at 11:45:39AM -0400, Hugh Brock wrote:
The attached patch adds code to xend_internal.c:xenDomainAttachDevice
that checks to see if the device mentioned in the passed-in XML already
Daniel Veillard wrote:
On Wed, Jul 18, 2007 at 10:40:48AM +0100, Richard W.M. Jones wrote:
Hugh Brock wrote:
I'm looking at ways to replicate xm block-configure at the libvirt
level. xm block-configure is useful in that it allows you to change the
back device for an HVM guest while the guest
Daniel Veillard wrote:
On Wed, Jul 18, 2007 at 09:09:41AM -0400, Hugh Brock wrote:
Daniel Veillard wrote:
It was raised previously that it's okay to recreate an existing domain
to modify its configuration, then allowing virDomainAttachDevice to
override an existing definition would
I go implement it, are
there obvious pitfalls I'm not thinking? And given that
virDomainAttachDevice is not implemented for qemud in libvirt (is it?),
how do we handle the non-xen case?
Thanks,
--Hugh
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock
Daniel Veillard wrote:
On Mon, Jun 04, 2007 at 05:08:14PM -0400, Hugh Brock wrote:
This patch extends libvirt's XML to include a paramater Xen already
supports in sexpr, bootloader_args. The bootloader_args parameter lets
you pass arguments -- mac=aa:12:34:56:78:90 for example
/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
diff -ruN --exclude CVS libvirt/src/xend_internal.c libvirt.new/src/xend_internal.c
--- libvirt/src/xend_internal.c 2007-06-04 15:38:31.0 -0400
+++ libvirt.new
from the config hashes.
If someone more familiar than I with libvirt error handling and style
could look at this and tell me if I've done something horribly wrong,
I'd appreciate it.
Signed-off-by: Hugh Brock [EMAIL PROTECTED]
--
Red Hat Virtualization Group http://redhat.com/virtualization
to compile libvirt with neither qemu nor xen-devel installed.
Signed-off-by: Hugh Brock [EMAIL PROTECTED]
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
ASANO Yuzuru wrote:
Hugh Brock wrote:
Daniel P. Berrange wrote:
Libvirt is really just the lowest level is what I see as a stack of tools
for managing virtual machines. Above libvirt I'd expect to see some form
of 'policy manager' which defines/controls things such as VCPU mapping
Oops, meant to send this to the list...
--H
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
---BeginMessage---
Mark McLoughlin wrote:
Hey,
We
Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
[EMAIL PROTECTED]| virtualization library http://libvirt.org
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Lon Hohberger wrote:
On Fri, 2007-02-09 at 16:18 -0500, Hugh Brock wrote:
Todos:
Investigate gparted, one of the partition management tools we already
have (apis? remote accessibility?) (I believe Jim Meyering volunteered
* Investigate Conga's cluster and non-cluster remotely-accessible
Mark McLoughlin wrote:
On Wed, 2007-01-17 at 06:50 -0500, Daniel Veillard wrote:
Thibgs which were dirt cheap become way more
expensive when they don't need to, this is a severe regression from a
library user standpoint.
Just a small point on this ...
Are you sure that's
Daniel P. Berrange wrote:
On Mon, Jan 15, 2007 at 08:53:43PM +, Mark McLoughlin wrote:
Hi,
One thing which is relevant to Dan's authentication stuff ...
On Mon, 2007-01-15 at 20:06 +, Mark McLoughlin wrote:
* Since virConnect is supposed to be a connection to a specific
Richard W.M. Jones wrote:
Hugh Brock wrote:
Daniel P. Berrange wrote:
3. The way I think you re suggesting - a libvirt server on every remote
host which calls into the regular libvirt internal driver model to
proxy remote calls. So even if the hypervisor in question provides a
remote
Daniel P. Berrange wrote:
Adding support for inactive domains was supposed to make everyone's life
easier, but as luck would have it, its actually made one thing very much
harder. In the virt-inst/virt-manager tools provisioning works something
like this:
In paravirt case:
- Create a guest
18 matches
Mail list logo
