On 2012年04月27日 22:45, Jiri Denemark wrote:
When libvirtd is started, we create libvirt/qemu directories under
hugetlbfs mount point. Only the qemu subdirectory is chowned to qemu
user and libvirt remains owned by root. If umask was too restrictive
when libvirtd started, qemu user may lose access
On 2012年04月12日 22:37, Michal Privoznik wrote:
Currently, qemu GA is not providing 'desc' field for errors like
we are used to from qemu monitor. Therefore, we fall back to this
general 'unknown error' string. However, GA is reporting 'class' which
is not perfect, but much more helpful than
On Tue, Apr 24, 2012 at 20:32, Eduardo Habkost ehabk...@redhat.com wrote:
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
vl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 1e5e593..a4f4676 100644
--- a/vl.c
+++ b/vl.c
@@ -2279,7
On 28.04.2012 09:38, Osier Yang wrote:
On 2012年04月12日 22:37, Michal Privoznik wrote:
Currently, qemu GA is not providing 'desc' field for errors like
we are used to from qemu monitor. Therefore, we fall back to this
general 'unknown error' string. However, GA is reporting 'class' which
is not
It doesn't break out the for loop even if duplicate pool is
found, and thus the matchpool could be overriden as NULL again
if there is different pool afterwards.
To address the problem in libvirt-user list:
https://www.redhat.com/archives/libvirt-users/2012-April/msg00150.html
---
On 28.04.2012 10:22, Osier Yang wrote:
It doesn't break out the for loop even if duplicate pool is
found, and thus the matchpool could be overriden as NULL again
if there is different pool afterwards.
To address the problem in libvirt-user list:
On 04/26/2012 08:50 PM, Eric Blake wrote:
[trimming cc's]
On 04/25/2012 09:18 PM, Alex Jia wrote:
Hello Eric,
I still met this issue on latest upstream HEAD(f78024b)
when compiling libvirt:
Making all in po
make[2]: Entering directory `/home/ajia/Workspace/libvirt/po'
*** error: gettext
refactor qemuPrepareHostdevUSBDevices function, make it focus on
adding usb device to activeUsbHostdevs after check. After that,
the usb hotplug function qemuDomainAttachHostDevice also could use
it.
expand qemuPrepareHostUSBDevices to perform the usb search,
rollback on failure.
---
https://bugzilla.redhat.com/show_bug.cgi?id=815755
The set of patch tries to fix the issue when multiple usb devices with
same idVendor, idProduct are availible on host, the usb device with
lowest bus:device will be attached to guest if usb xml file is given like
this:
hostdev mode='subsystem'
usbFindDevice():get usb device according to
idVendor, idProduct, bus, device
it is the most strict search
usbFindDevByBus():get usb device according to bus, device
it returns only one usb device same as usbFindDevice
usbFindDevByVendor():get usb
One usb device could be allowed to hotplug in at a time. If user
give a xml as follows. Probably there are two usb devices avaiable
but with different value of bus, device
we give a error to let user use address to specify the desired one.
hostdev mode='subsystem' type='usb' managed='yes'
In fact, the 'tapfd' is always NULL, the function 'virNetDevTapCreate()' hasn't
assign 'fd' to 'tapfd', when the function 'virNetDevSetMAC()' is failed then
goto 'error' lable, finally, the VIR_FORCE_CLOSE() will deref a NULL 'tapfd'.
* util/virnetdevtap.c (virNetDevTapCreateInBridgePort): fix a
On 04/27/2012 11:34 PM, Daniel Veillard wrote:
I'm not really able to make a good review of remaining patches sent
on the list and not pushed today, but I would like to check the pvs
driver set patches before entering the freeze, so I'm postponing it
until after the week-end, possibly on
On 04/28/2012 07:01 AM, Alex Jia wrote:
In fact, the 'tapfd' is always NULL, the function 'virNetDevTapCreate()' hasn't
assign 'fd' to 'tapfd', when the function 'virNetDevSetMAC()' is failed then
goto 'error' lable, finally, the VIR_FORCE_CLOSE() will deref a NULL 'tapfd'.
---
Okay, I screwed up the tarball for the first stable release, due to not
building it from a fresh checkout :/ No changes for this one except a
version
bump and dist rebuild.
This release can be downloaded at:
http://libvirt.org/sources/libvirt-0.9.11.2.tar.gz
Thanks,
Cole
--
Okay, I screwed up the tarball for the first stable release, due to not
building it from a fresh checkout :/ No changes for this one except a
version
bump and dist rebuild.
This release can be downloaded at:
http://libvirt.org/sources/libvirt-0.9.11.2.tar.gz
Thanks,
Cole
--
16 matches
Mail list logo