Hi, all
As the $subject says, currently we don't check whether the
PCI device is in use or not by guest when reattaching it
to host, it causes problems, should we prevent reattaching
if the device is in use? if yes, how to detect whether the
device is in use or not?
The easiest way in my mind is
On 12/14/2010 07:34 PM, Wen Congyang wrote:
In addition to Hu's comments, and the fact that you are probably going
to revise the exposed interface anyways, here's some additional points.
* src/util/timer.c src/util/timer.h src/util/timer_linux.c
src/util/timer_win32.c:
timer implementation
On 12/15/2010 08:20 AM, Eric Blake wrote:
On 12/14/2010 07:34 PM, Wen Congyang wrote:
In addition to Hu's comments, and the fact that you are probably going
to revise the exposed interface anyways, here's some additional points.
One other point - how does this relate to the timeouts already
On Wed, Dec 15, 2010 at 08:24:44AM -0700, Eric Blake wrote:
On 12/15/2010 08:20 AM, Eric Blake wrote:
On 12/14/2010 07:34 PM, Wen Congyang wrote:
In addition to Hu's comments, and the fact that you are probably going
to revise the exposed interface anyways, here's some additional points.
On 12/06/2010 01:14 AM, Ken'ichi Ohmichi wrote:
Hi, and sorry for the delayed response,
Hi,
I tested virsh setvcpus command and it did not work like the following:
# virsh setvcpus RHEL5.5GA_Guest.img 2
error: internal error unable to execute QEMU command 'cpu_set': The command
I got some spurious failures when commandhelper won the race and
ran to the point of parent detection prior to the intermediate
daemonizing process getting a chance to exit. This fixes it.
* tests/commandhelper.c (main): Checking for re-parenting to
init(1) is racy; instead check that we belong
When running 'make check' under a multi-cpu Dom0 xen machine,
nodeinfotest had a spurious failure it was reading from
/sys/devices/system/cpu, but xen has no notion of topology. The test
was intended to be isolated from reading any real system files; the
regression was introduced in Mar 2010 with
?Hi,
Can someone explain (or point me to a document that explain) what are the
differences between these two URI :
qemu+tcp://xxx.xxx.xxx.xxx/system
qemu+tcp://xxx.xxx.xxx.xxx/session
Regards,
Arnaud--
libvir-list mailing list
libvir-list@redhat.com
On 11/02/2010 07:08 AM, Daniel P. Berrange wrote:
Migration just seems togo from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
On 12/15/2010 02:19 PM, arnaud.champ...@devatom.fr wrote:
?Hi,
Can someone explain (or point me to a document that explain) what are the
differences between these two URI :
qemu+tcp://xxx.xxx.xxx.xxx/system
qemu+tcp://xxx.xxx.xxx.xxx/session
http://libvirt.org/uri.html#URI_qemu
System
Hi Eric,
Thank you for the explanation.
On Wed, 15 Dec 2010 08:42:12 -0700
Eric Blake ebl...@redhat.com wrote:
I tested virsh setvcpus command and it did not work like the following:
# virsh setvcpus RHEL5.5GA_Guest.img 2
error: internal error unable to execute QEMU command
At 12/15/2010 11:20 PM, Eric Blake Write:
On 12/14/2010 07:34 PM, Wen Congyang wrote:
In addition to Hu's comments, and the fact that you are probably going
to revise the exposed interface anyways, here's some additional points.
* src/util/timer.c src/util/timer.h src/util/timer_linux.c
At 12/15/2010 11:32 PM, Daniel P. Berrange Write:
On Wed, Dec 15, 2010 at 08:24:44AM -0700, Eric Blake wrote:
On 12/15/2010 08:20 AM, Eric Blake wrote:
On 12/14/2010 07:34 PM, Wen Congyang wrote:
In addition to Hu's comments, and the fact that you are probably going
to revise the exposed
13 matches
Mail list logo
