[Libvir] Re: [PATCH] xen/?/privcmd.h

Hi, Rich Thank you for writing and committing your patch. I use CVS version as you suggested (use autogen.sh) And current version compiles fine! Thanks Atsushi SAKAI "Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > Atsushi SAKAI wrote: > > Hi, Rich > > > > 　It works fine for me! > > Thank

Re: [Libvir] [PATCH] virDomainMigrate version 4 (for discussion only!)

On Thu, Jul 19, 2007 at 06:03:29PM +0100, Richard W.M. Jones wrote: > Some observations about Xen migration and error handling. It's a horrible mess. I'm in a large group of people who want to see this all fixed (with yet another break) at the same time secure migration is implemented... regards

Re: [Libvir] [PATCH] virDomainMigrate version 4 (for discussion only!)

Some observations about Xen migration and error handling. The Xen migration protocol isn't stable between releases. It changed between 3.0.3 and 3.1.0. There doesn't seem to be any versioning, and incompatible versions of Xen seem happy to attempt migrations between them, even though these w

Re: [Libvir] [PATCH] virDomainMigrate version 4 (for discussion only!)

Attached is an updated patch which adds a "virsh migrate" subcommand. I also rebuilt the API & Python binding using the generator. Two known problems with the auto-generated Python binding at the moment: (1) It's attached to the connection object (conn.migrate (...)) instead of the domain obje

[Libvir] Re: [PATCH] xen/?/privcmd.h

Atsushi SAKAI wrote: Hi, Rich 　It works fine for me! Thank you! Atsushi, thanks for testing this. I've applied that change to CVS. If you are using the CVS version, make sure to run autogen.sh again after the check out. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjon

Re: [Libvir] [PATCH]0/3 OpenVZ driver : Some clean ups

On Thu, Jul 19, 2007 at 09:01:36AM -0400, Daniel Veillard wrote: > On Thu, Jul 19, 2007 at 06:24:57PM +0530, Shuveb Hussain wrote: > > Hi, > > > > Here are some cleanups as per discussions on the list: > > > > Change log: > > * Make sure we are running on OpenVZ enebled kernel in the driver open(

Re: [Libvir] [PATCH]0/3 OpenVZ driver : Some clean ups

> > * Use generic UUID parsing rather than own and scanf() > > okay, I changed the generation function yesterday, using virUUIDGenerate() > if you noticed. > Hello Daniel, Yeah, thanks for that. :-) What I meant was that I removed a horrible looking scanf() and replaced it with the more flexi

Re: [Libvir] Xen reboot does not work with Sys::Virt perl binding

On Thu, Jul 12, 2007 at 02:40:10PM +0100, Daniel P. Berrange wrote: > On Thu, Jul 12, 2007 at 01:46:51PM +0200, Keck, Christian (ext) wrote: > > Hello guys! > > > > I am using the perl bindings (Sys::Virt) to manage my virtual xen hosts. > > Because it directly maps the C api, I thought it's a go

Re: [Libvir] RFC: format for mapping host devices to guest

On Thu, Jul 19, 2007 at 02:28:00PM +0100, Daniel P. Berrange wrote: > On Thu, Jul 19, 2007 at 06:17:29AM -0400, Daniel Veillard wrote: > > > > IMHO you should output both, then depending how you will reuse that XML > > fragment one or the other may be used, this could actually be one argument >

Re: [Libvir] [PATCH] virsh Range check in Credit Scheduler

On Wed, Jul 18, 2007 at 10:40:06PM +0900, Atsushi SAKAI wrote: > Hi, Daniel > > 　I checked it and it works fine! Okay, commited. W.r.t. your question of compatibility with xen-unstable, I didn't looked at it. Seems someone need to check the compatibility again once they produce a new release

Re: [Libvir] RFC: format for mapping host devices to guest

On Thu, Jul 19, 2007 at 06:17:29AM -0400, Daniel Veillard wrote: > On Thu, Jul 19, 2007 at 01:17:37AM +0100, Daniel P. Berrange wrote: > > So to attach a device: > > > > > > > > > > > > Or > > > > > > > > > > > > The first form is useful for live hotplug - where you

Re: [Libvir] [PATCH]0/3 OpenVZ driver : Some clean ups

On Thu, Jul 19, 2007 at 06:24:57PM +0530, Shuveb Hussain wrote: > Hi, > > Here are some cleanups as per discussions on the list: > > Change log: > * Make sure we are running on OpenVZ enebled kernel in the driver open() > method > * Some minor macro cleanups > * Use generic UUID parsing rather th

[Libvir] [PATCH]3/3 OpenVZ driver : qemu_driver.c changes

-- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com Index: src/qemu_driver.c === RCS file: /data/cvs/libvirt/src/qemu_driver.c,v retrieving revision 1.8 diff

[Libvir] [PATCH]2/3 OpenVZ driver : generic utils

-- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com /* * utils.c: common, generic utility functions * * Copyright (C) 2006, 2007 Red Hat, Inc. * Copyright (C) 2006 Daniel P. Berrange * Copyright (C) 2006, 2007 Binary

[Libvir] [PATCH]1/3 OpenVZ driver : Cleanups

Cleanup patch, also adds utils.c and utils.h to Makefile.am -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com Index: include/libvirt/virterror.h === RCS fi

[Libvir] [PATCH]0/3 OpenVZ driver : Some clean ups

Hi, Here are some cleanups as per discussions on the list: Change log: * Make sure we are running on OpenVZ enebled kernel in the driver open() method * Some minor macro cleanups * Use generic UUID parsing rather than own and scanf() * Made private functions static * New files utils.[c,h] added t

Re: [Libvir] RFC: format for mapping host devices to guest

On Thu, Jul 19, 2007 at 01:17:37AM +0100, Daniel P. Berrange wrote: > So we need some form of element under the section per device to > map through. At minimum this will need the source device info. If we are > to support unplugging of USB devices in QEMU it is neccessary to have the > target devi

Re: [Libvir] PATCH: Fix accident close of monitor FD & leak of logfile FD to child

On Thu, Jul 19, 2007 at 01:52:00AM +0100, Daniel P. Berrange wrote: > After the QEMU monitor filehandle has been successfully initialized, we > then promptly close it ! It seems a 'return' statement accidentally got > removed somewhere during previously refactoring. > > Second, the QEMU logfile do