On Mon, Nov 18, 2019 at 05:12:23PM +0100, Bjoern Walk wrote:
> Hey all,
>
> commit 4ac47730: Use g_mkstemp_full instead of mkostemp(s) broke `virsh
> edit` (at least on S390):
This change didn't request any access bits so the temp files are
all being created with O_RDONLY.
openat(AT_FDCWD, "/tmp
On Mon, Nov 18, 2019 at 05:12:23PM +0100, Bjoern Walk wrote:
Hey all,
commit 4ac47730: Use g_mkstemp_full instead of mkostemp(s) broke `virsh
Oops,
edit` (at least on S390):
virsh # edit test
error: write: /tmp/virshQ7SXB0.xml: failed to write to temporary file: Bad
file descriptorx
Hey all,
commit 4ac47730: Use g_mkstemp_full instead of mkostemp(s) broke `virsh
edit` (at least on S390):
virsh # edit test
error: write: /tmp/virshQ7SXB0.xml: failed to write to temporary file: Bad
file descriptorx
I didn't find out why, everything looks normal:
# ls -l /proc
On Fri, Aug 30, 2019 at 10:14:17AM +0200, Michal Privoznik wrote:
On 8/30/19 8:51 AM, wujing (O) wrote:
On 8/28/19 11:42 AM, wujing (O) wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
That possibly might be out of scope, but autofilling the mac
address as early as virDomainNetDefPar
On 8/30/19 8:51 AM, wujing (O) wrote:
On 8/28/19 11:42 AM, wujing (O) wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
That possibly might be out of scope, but autofilling the mac
address as early as virDomainNetDefParseXML also is not ideal.
We have pushed a patch bellow that can r
> On 8/28/19 11:42 AM, wujing (O) wrote:
> > On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
> That possibly might be out of scope, but autofilling the mac
> address as early as virDomainNetDefParseXML also is not ideal.
> >>>
> >>> We have pushed a patch bellow that can restore t
> >>> On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
> >> That possibly might be out of scope, but autofilling the mac address
> >> as early as virDomainNetDefParseXML also is not ideal.
> >
> > We have pushed a patch bellow that can restore the situation to an older
> state.
> >
> > Subject:
On 8/28/19 11:42 AM, wujing (O) wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
That possibly might be out of scope, but autofilling the mac address
as early as virDomainNetDefParseXML also is not ideal.
We have pushed a patch bellow that can restore the situation to an older
state
On 8/28/19 9:55 AM, Xu Yandong wrote:
On 2019/8/27 20:44, Ján Tomko wrote:
On Tue, Aug 27, 2019 at 02:13:28PM +0200, Michal Privoznik wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
Hi,
When plug a bridge interface to an active VM with both LIVE AND CONFIG flags,
libvirt generate
On 8/27/19 2:44 PM, Ján Tomko wrote:
On Tue, Aug 27, 2019 at 02:13:28PM +0200, Michal Privoznik wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
Hi,
When plug a bridge interface to an active VM with both LIVE AND
CONFIG flags,
libvirt generate different mac address to LIVE and CONFI
On 2019/8/27 20:44, Ján Tomko wrote:
> On Tue, Aug 27, 2019 at 02:13:28PM +0200, Michal Privoznik wrote:
>> On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
>>> Hi,
>>>
>>> When plug a bridge interface to an active VM with both LIVE AND CONFIG
>>> flags,
>>> libvirt generate different mac ad
On Tue, Aug 27, 2019 at 02:13:28PM +0200, Michal Privoznik wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
Hi,
When plug a bridge interface to an active VM with both LIVE AND CONFIG flags,
libvirt generate different mac address to LIVE and CONFIG instance, so After
I reboot the VM, D
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:
Hi,
When plug a bridge interface to an active VM with both LIVE AND CONFIG flags,
libvirt generate different mac address to LIVE and CONFIG instance, so After
I reboot the VM, DHCP server doesn't assign the same IP address to the new
bridge int
Hi,
When plug a bridge interface to an active VM with both LIVE AND CONFIG flags,
libvirt generate different mac address to LIVE and CONFIG instance, so After
I reboot the VM, DHCP server doesn't assign the same IP address to the new
bridge interface.
Steps:
1. Having running VM
## virsh list
I
Jiri Denemark writes:
> On Thu, Jul 25, 2019 at 11:09:28 +0200, Vitaly Kuznetsov wrote:
>> Jiri Denemark writes:
>>
>> > On Wed, Jul 24, 2019 at 18:48:38 +0200, Vitaly Kuznetsov wrote:
>> >> Hi,
>> >>
>> >> when some Hyper-V enlightenments are added to the domain configuration,
>> >> e.g.
>> >
On Thu, Jul 25, 2019 at 11:09:28 +0200, Vitaly Kuznetsov wrote:
> Jiri Denemark writes:
>
> > On Wed, Jul 24, 2019 at 18:48:38 +0200, Vitaly Kuznetsov wrote:
> >> Hi,
> >>
> >> when some Hyper-V enlightenments are added to the domain configuration,
> >> e.g.
> >>
> >>
> >> ...
> >>
Jiri Denemark writes:
> On Wed, Jul 24, 2019 at 18:48:38 +0200, Vitaly Kuznetsov wrote:
>> Hi,
>>
>> when some Hyper-V enlightenments are added to the domain configuration,
>> e.g.
>>
>>
>> ...
>>
>> ..
>>
>>
>> ...
>>
>> I'm observing the following:
>>
>> # vi
On Wed, Jul 24, 2019 at 18:48:38 +0200, Vitaly Kuznetsov wrote:
> Hi,
>
> when some Hyper-V enlightenments are added to the domain configuration,
> e.g.
>
>
> ...
>
> ..
>
>
> ...
>
> I'm observing the following:
>
> # virsh create /etc/libvirt/qemu/win2k16.xml
Hi,
when some Hyper-V enlightenments are added to the domain configuration,
e.g.
...
..
...
I'm observing the following:
# virsh create /etc/libvirt/qemu/win2k16.xml
error: Failed to create domain from /etc/libvirt/qemu/win2k16.xml
error: unsupported configurati
On Fri, Jun 28, 2019 at 10:26:49AM +, Yuchen wrote:
only the last numa node
/sys/devices/system/node/node*/cpu*/topology/physical_package_id
nodeinfo 'CPU socket(s)' is not equal to lscpu 'Socket(s)'
See `man virsh`, an exceprt here:
nodeinfo
Returns basic information about the node,
only the last numa node
/sys/devices/system/node/node*/cpu*/topology/physical_package_id
nodeinfo 'CPU socket(s)' is not equal to lscpu 'Socket(s)'
# virsh nodeinfo
CPU model: x86_64
CPU(s): 32
CPU frequency: 2393 MHz
CPU socket(s): 1
Core(s) per socket: 8
Thre
On Mon, Dec 10, 2018 at 08:39:37 +, 吴 雨霖 wrote:
> 1.Description of problem:
>
> It report use migration with shmem device is not supported , when I use
> the command "virsh migrate --live" to migrate a VM to another host.
Migration with shmem was specifically forbidden by commit:
commi
1.Description of problem:
It report use migration with shmem device is not supported , when I use
the command "virsh migrate --live" to migrate a VM to another host.
2.Version-Release number of selected component (if applicable):
libvirt 3.9.0
qemu-kvm 2.8.1
3.Steps to Rep
Hello,
Am 27.11.18 um 15:29 schrieb Daniel P. Berrangé:
> On Mon, Nov 26, 2018 at 05:12:06PM +0100, Philipp Hahn wrote:
>> Am 26.11.18 um 16:28 schrieb Michal Privoznik:
>>> On 11/21/18 8:17 AM, Philipp Hahn wrote:
while working on the Python type annotations for the Python libvirt
bindi
On Mon, Nov 26, 2018 at 05:12:06PM +0100, Philipp Hahn wrote:
> Hello,
>
> Am 26.11.18 um 16:28 schrieb Michal Privoznik:
> > On 11/21/18 8:17 AM, Philipp Hahn wrote:
> >> while working on the Python type annotations for the Python libvirt
> >> binding I noticed the following code in
> >> libvirt-
Hello,
Am 26.11.18 um 16:28 schrieb Michal Privoznik:
> On 11/21/18 8:17 AM, Philipp Hahn wrote:
>> while working on the Python type annotations for the Python libvirt
>> binding I noticed the following code in
>> libvirt-override-virDomainSnapshot.py:
>>
>>> def listAllChildren(self, flags=0)
On 11/21/18 8:17 AM, Philipp Hahn wrote:
> Hi,
>
> while working on the Python type annotations for the Python libvirt
> binding I noticed the following code in
> libvirt-override-virDomainSnapshot.py:
>
>> def listAllChildren(self, flags=0):
>> """List all child snapshots and returns
Hi,
while working on the Python type annotations for the Python libvirt
binding I noticed the following code in
libvirt-override-virDomainSnapshot.py:
> def listAllChildren(self, flags=0):
> """List all child snapshots and returns a list of snapshot objects"""
...
> raise
On Thu, Jun 07, 2018 at 10:02:41 +0200, Xen Mann wrote:
> Hey there!
>
> I'm experiencing a strange behavior with libvirt and backing chains.
> Getting higher than the first overlay results in a permission denied to the
> base image and I can't start any machine.
>
>
> # Results while attemptin
Hey there!
I'm experiencing a strange behavior with libvirt and backing chains.
Getting higher than the first overlay results in a permission denied to the
base image and I can't start any machine.
# Results while attempting to start machine
(after every attemt the whole files from ./house
Hi,
I notice that monitor.sock still exist when I send SIGKILL to qemu process by
accident, and I can't find the qemu process
through `ps -ef |grep qemu` command.
Then I execute `virsh list --all`, libvirt just show that the vm still in
running state. I can't find log "Received EOF on xxx" eithe
Steps to reproduce
1 virsh create testvm
2 gdb attch qemu,and not continue
3 virsh destroy testvm ，then destory failed。
4 gdb qemu continue and exit,then qemu exit.
[root@host-120-51 home]# ps -aux |grep qemu
root 2814 0.0 0.0 112644 956 pts/3S+ 11:40 0:00
We use virsh attach-device to hot-plug vhost-user nic with the following xml:
We can successfully hot plug more than one vhost-user nics with
the same unix path ('/var/run/vhost-user/port1') which is a chardev backend.
However, only one nic attached can work, because the unix path
On Tue, Jun 13, 2017 at 10:30:59AM +0200, Philipp Hahn wrote:
Hello,
Am 13.06.2017 um 06:13 schrieb Philipp Hahn:
I'm using the libvirt event mechanism and noticed, that several events
are reported twice:
...
$ virsh event --loop --event lifecycle
event 'lifecycle' for domain installer: Star
Hello,
Am 13.06.2017 um 06:13 schrieb Philipp Hahn:
> I'm using the libvirt event mechanism and noticed, that several events
> are reported twice:
...
>> $ virsh event --loop --event lifecycle
>> event 'lifecycle' for domain installer: Started Booted
>> event 'lifecycle' for domain installer: Sus
On Wed, 15 Mar 2017 10:11:50 +0100
Andrea Bolognani wrote:
> On Wed, 2017-03-15 at 08:59 +0100, Jiri Denemark wrote:
> > > > Removing all memory locking limits should be something that
> > > > admins very carefully opt-in into, because of the potential
> > > > host DoS consequences. Certainly not
On Wed, 15 Mar 2017 14:29:13 -0400
Luiz Capitulino wrote:
> > ... we could consider to be the explicit request for
> > setting an infinite memory locking limit and letting users set a lower
> > limit with hard_limit if they want.
>
> That's exactly how I see it! It seems we're total agreement
On Wed, 15 Mar 2017 08:59:34 +0100
Jiri Denemark wrote:
> On Tue, Mar 14, 2017 at 15:54:25 -0400, Luiz Capitulino wrote:
> > On Tue, 14 Mar 2017 20:28:12 +0100
> > Andrea Bolognani wrote:
> >
> > > On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote:
> > > > > It's unfortunate that the
On Wed, 2017-03-15 at 08:59 +0100, Jiri Denemark wrote:
> > > Removing all memory locking limits should be something that
> > > admins very carefully opt-in into, because of the potential
> > > host DoS consequences. Certainly not the default.
> >
> > There's no opt-in with , it is mandatory to in
On Tue, Mar 14, 2017 at 15:54:25 -0400, Luiz Capitulino wrote:
> On Tue, 14 Mar 2017 20:28:12 +0100
> Andrea Bolognani wrote:
>
> > On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote:
> > > > It's unfortunate that the current, buggy behavior made
> > > > it look like you didn't necessarily
On Tue, 14 Mar 2017 20:28:12 +0100
Andrea Bolognani wrote:
> On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote:
> > > It's unfortunate that the current, buggy behavior made
> > > it look like you didn't necessarily have to worry about
> > > this. If we fix it, existing guests will fail to
On Tue, 2017-03-14 at 14:54 -0400, Luiz Capitulino wrote:
> > It's unfortunate that the current, buggy behavior made
> > it look like you didn't necessarily have to worry about
> > this. If we fix it, existing guests will fail to start
> > right away instead of possibly crashing in the future:
> >
On Tue, 14 Mar 2017 19:40:38 +0100
Andrea Bolognani wrote:
> It's unfortunate that the current, buggy behavior made
> it look like you didn't necessarily have to worry about
> this. If we fix it, existing guests will fail to start
> right away instead of possibly crashing in the future:
> while t
On Tue, 2017-03-14 at 15:55 +0100, Peter Krempa wrote:
> > NB if we did enforce $RAM + $LARGE_NUMBER, then I'd suggest we did
> > set a default hard_limit universally once more, not only set a mlock
>
> We were already attempting to do this and we reverted it since there's
> no deterministic $LARG
On Mon, Mar 13, 2017 at 18:16:49 +, Daniel Berrange wrote:
> On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote:
> > On Mon, 13 Mar 2017 13:53:33 -0400
> > Luiz Capitulino wrote:
> >
> > > OK, you're right. I personally don't like we're putting a random cap
> > > on QEMU memory a
On Mon, 2017-03-13 at 14:24 -0400, Luiz Capitulino wrote:
> > NB if we did enforce $RAM + $LARGE_NUMBER, then I'd suggest we did
> > set a default hard_limit universally once more, not only set a mlock
> > limit when using . This would at least ensure we see consistent
> > (bad) behaviour rather th
On Mon, 13 Mar 2017 18:16:49 +
"Daniel P. Berrange" wrote:
> On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote:
> > On Mon, 13 Mar 2017 13:53:33 -0400
> > Luiz Capitulino wrote:
> >
> > > OK, you're right. I personally don't like we're putting a random cap
> > > on QEMU memo
On Mon, Mar 13, 2017 at 02:08:30PM -0400, Luiz Capitulino wrote:
> On Mon, 13 Mar 2017 13:53:33 -0400
> Luiz Capitulino wrote:
>
> > OK, you're right. I personally don't like we're putting a random cap
> > on QEMU memory allocations, but if it's large enough it shouldn't be
> > a problem (I hope)
On Mon, 13 Mar 2017 13:53:33 -0400
Luiz Capitulino wrote:
> OK, you're right. I personally don't like we're putting a random cap
> on QEMU memory allocations, but if it's large enough it shouldn't be
> a problem (I hope).
The I hope part meaning, if we do find legitimate reasons for QEMU's
addre
On Mon, 13 Mar 2017 16:43:46 +
"Daniel P. Berrange" wrote:
> On Mon, Mar 13, 2017 at 12:35:42PM -0400, Luiz Capitulino wrote:
> > On Mon, 13 Mar 2017 16:08:58 +
> > "Daniel P. Berrange" wrote:
> >
> > > > 2. Drop change c2e60ad0e51 and automtically increase memory
> > > > locking
On Mon, Mar 13, 2017 at 12:35:42PM -0400, Luiz Capitulino wrote:
> On Mon, 13 Mar 2017 16:08:58 +
> "Daniel P. Berrange" wrote:
>
> > > 2. Drop change c2e60ad0e51 and automtically increase memory
> > > locking limit to infinity when seeing
> > >
> > >pros: make all cases work, no m
On Mon, 13 Mar 2017 16:08:58 +
"Daniel P. Berrange" wrote:
> On Mon, Mar 13, 2017 at 11:58:24AM -0400, Luiz Capitulino wrote:
> >
> > Libvirt commit c2e60ad0e51 added a new check to the XML validation
> > logic where XMLs containing must also
> > contain . This causes two breakages where
>
On Mon, Mar 13, 2017 at 11:58:24AM -0400, Luiz Capitulino wrote:
>
> Libvirt commit c2e60ad0e51 added a new check to the XML validation
> logic where XMLs containing must also
> contain . This causes two breakages where
> working guests won't start anymore:
>
> 1. Systems where mlock limit was s
Libvirt commit c2e60ad0e51 added a new check to the XML validation
logic where XMLs containing must also
contain . This causes two breakages where
working guests won't start anymore:
1. Systems where mlock limit was set in /etc/security/limits.conf
2. Guests using hugeTLB pages. In this case, g
On Thu, Dec 01, 2016 at 06:37:02PM -0500, CESAR DAVID VASQUEZ ROMERO wrote:
Hi, I'm having a problem with libvirt.
Since a few days, when I try to create a virtual machine I get the
following error and I could not solve it
" Imposible completar la instalación: 'internal error: Cannot find suita
Hello.
On Thu, Dec 01, 2016 at 18:37:02 -0500, CESAR DAVID VASQUEZ ROMERO wrote:
> Hi, I'm having a problem with libvirt.
What version of libvirt and virt-manager do you use?
> Since a few days, when I try to create a virtual machine I get the
> following error and I could not solve it
Did anyt
Hi, I'm having a problem with libvirt.
Since a few days, when I try to create a virtual machine I get the
following error and I could not solve it
" Imposible completar la instalación: 'internal error: Cannot find suitable
CPU model for given data' "
-
On Mon, Jun 27, 2016 at 01:23:46PM +0200, Michal Privoznik wrote:
On 27.06.2016 10:05, Daniel P. Berrange wrote:
On Sat, Jun 25, 2016 at 04:32:21PM -0600, Eric Blake wrote:
[moderator note: the mail server balked at 1.3 megabytes of attachments,
so I've stripped them in my reply]
On 12/31/1969
On Mon, Jun 27, 2016 at 01:23:46PM +0200, Michal Privoznik wrote:
> On 27.06.2016 10:05, Daniel P. Berrange wrote:
> > On Sat, Jun 25, 2016 at 04:32:21PM -0600, Eric Blake wrote:
> >> [moderator note: the mail server balked at 1.3 megabytes of attachments,
> >> so I've stripped them in my reply]
>
On 27.06.2016 10:05, Daniel P. Berrange wrote:
> On Sat, Jun 25, 2016 at 04:32:21PM -0600, Eric Blake wrote:
>> [moderator note: the mail server balked at 1.3 megabytes of attachments,
>> so I've stripped them in my reply]
>>
>> On 12/31/1969 05:00 PM, wrote:
>>> Hello everybody,
>>>
>>> I set up
ave a functional
effect on our code, besides outputting the log messages.
> which explicitly exists to change the verbosity of the testsuite itself,
> but not affect libvirt. If the testsuite passes without LIBVIRT_DEBUG
> set, then that's the solution :) But if you still get failures with
>
ut LIBVIRT_DEBUG
set, then that's the solution :) But if you still get failures with
LIBVIRT_DEBUG removed from the environment on your particular platform,
then it is worth investigating how we can fix those failures (it may be
a weakness in the testsuite, or an actual libvirt bug).
--
Eri
Hello everybody,
I am resending this email as I suppose that the previous one
wasn’t accepted due to a big attachment inside. If I create a double post,
please excuse me, I didn’t mean to.
I set up a clean libvirt repo with:
git clone
./autogen.sh
make
and then executed tests with various values
On Thu, Nov 26, 2015 at 04:10:40PM +, Ben Gray wrote:
Hi,
Occasionally when trying to start LXC containers with fds I get
the following error:
Wow, this is here for a while... Sorry for the delay.
virNetMessageDupFD:562 : Unable to duplicate FD -1: Bad file
descriptor
It's
On 12/17/2015 10:45 AM, Hailiang Zhang wrote:
Hi all,
We came across a problem, qemu was accidently killed by libvirtd after
we restart libvirtd by service command.
Steps to reproduce:
1） Attach net device to VM by 'virsh attach-device' command
2） Detach the net device that added before by 'vi
Hi all,
We came across a problem, qemu was accidently killed by libvirtd after we
restart libvirtd by service command.
Steps to reproduce:
1） Attach net device to VM by 'virsh attach-device' command
2） Detach the net device that added before by 'virsh detach-device' command
3) Do the above two s
Hi,
Occasionally when trying to start LXC containers with fds I get the
following error:
virNetMessageDupFD:562 : Unable to duplicate FD -1: Bad file
descriptor
I tracked it down to the code that handles EAGAIN errors from
recvfd. In such cases the virNetMessageDecodeNumFD
On Tue, Jun 23, 2015 at 02:13:21PM +0200, Piotr Rybicki wrote:
Hello.
Problem description:
When i start qemu via libvirt with vnc websocket defined, it is not
possible to live migrate to host where other qemu process is running
with the same display id.
migration error is:
error: internal err
Hello.
Problem description:
When i start qemu via libvirt with vnc websocket defined, it is not
possible to live migrate to host where other qemu process is running
with the same display id.
migration error is:
error: internal error: early end of file from monitor: possible problem:
王松波你好,
Thanks a lot for reporting a bug and providing a patch for it. However,
you will need to send the patch using git send-email to this mailing
list: it will ease the review and integration in master.
Thanks a lot for your help,
--
Cedric
On Tue, 2015-06-02 at 20:27 +0800, 王松波 wrote:
> I re
I report a bug [Bug 1227257] . In the environment libvirt-1.2.16.tar.gz
+ qemu-img version 2.1.2 + ceph version 0.94.1.
libvirt pool will become inactive after one client does vol.delete and the
other does pool.refresh in the same pool simultaneously.
The reason is that rbd_list and rbd_open are
Thanks Peter,
It looks good but I did no deep introspection of the code.
Should I rebase my patch [1] on that? I can test your code as well then.
[1] https://github.com/paboldin/libvirt/commits/master
Pavel
On Tue, Apr 28, 2015 at 4:42 PM, Peter Krempa wrote:
> On Tue, Apr 28, 2015 at 11:24:
On Tue, Apr 28, 2015 at 11:24:37 +0200, Michal Privoznik wrote:
> On 28.04.2015 11:06, Pavel Boldin wrote:
> > Well, actually that seems to be quite a different bug in there.
> >
> > I will start a new thread.
> >
> > In short: migration seems to be broken by commit
> > 1a92c719101e5bfa6fe2b78006
On 28.04.2015 11:06, Pavel Boldin wrote:
> Well, actually that seems to be quite a different bug in there.
>
> I will start a new thread.
>
> In short: migration seems to be broken by commit
> 1a92c719101e5bfa6fe2b78006ad04c7f075ea28. This is because introduced job
> _MODIFY waits while MIGRATION
Well, actually that seems to be quite a different bug in there.
I will start a new thread.
In short: migration seems to be broken by commit
1a92c719101e5bfa6fe2b78006ad04c7f075ea28. This is because introduced job
_MODIFY waits while MIGRATION_OUT is finished to change `mirrorState'
variable. This
Dear Libvirt Developers,
There seems to be a bug or at least a bad behavior in
`src/qemu/qemu_monitor.c' lines 683-689 function `qemuMonitorIO':
if (qemuMonitorIOWrite(mon) < 0) {
error = true;
if (errno == ECONNRESET)
hangup = true;
[redirecting to libvirt; a continuation of
https://www.redhat.com/archives/libvir-list/2015-February/msg01227.html]
On 03/27/2015 02:43 PM, Pavel Raiskup wrote:
> [+cc back libtool bug; as fixing automake does not seem to be enough]
>
>>
>> Hmm. How hard is it to change ARFLAGS to 'cr' instead of
On Fri, 27 Feb 2015, Eric Blake wrote:
Is it worth teaching libtool to change ARFLAGS to be 'crD' instead of
'cru' when it is detected that ar is new enough to support deterministic
libraries, in part to shut up the warning message being printed on every
single libtool link line? (Note that I w
On 30.01.2015 10:20, linxxnil wrote:
> Dear:
>
> I think there was a bug, when attach-interface using xen driver.
You're right. I've proposed a patch:
https://www.redhat.com/archives/libvir-list/2015-January/msg01088.html
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.
Dear:
I think there was a bug, when attach-interface using xen driver.
when I use xen driver to attach interface for domain, the libvirtd will crash.
the info with GDB:
#0 0x77571815 in virDomainDiskGetDriver () from /usr/lib/libvirt.so.0
#1 0x7fffeb9ad471 in ?? () from
/usr/lib/
Hi ,
I hit a bug with libvirt+ qemu+kvm when doing follow steps:
1.initial status :vm = base+z(z is a snapshot)
2. call snapshotCreateXML( ): vm = base+z +z'
3. call blockRebase( ): vm = base+z''(z rebase to z')
4 .(after rebasing work done) vm shutdown and then start
an error accord like this:
On 22.09.2014 16:02, Gerald Palmer wrote:
Description of problem: Fail to compile
Version-Release number of selected component (if applicable):
Version 1.0.3 through 1.1.1
How reproducible:
Steps to Reproduce:
1./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
2.make
Actual
Description of problem: Fail to compile
Version-Release number of selected component (if applicable):
Version 1.0.3 through 1.1.1
How reproducible:
Steps to Reproduce:
1./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
2.make
Actual results:
libvirt_lxc-lxc_monitor_protocol.o
Hi. I am using libvirt for some time and I have found the following problem.
When I try opening two connections with the same credentials to the same
host but using different transport(TCP and TLS) I get the following error
when trying to free the TLS one:
"*** Error in `./test': double free or cor
On 06/24/2014 03:21 PM, Eric Blake wrote:
On 06/24/2014 08:07 AM, Jason J. Herne wrote:
During a recent managed save operation I received the following error
message:
error: operation failed: domain save job: unexpectedly failed.
It turns out that I had run out of disk space. After a bri
On 06/24/2014 08:07 AM, Jason J. Herne wrote:
> During a recent managed save operation I received the following error
> message:
>
> error: operation failed: domain save job: unexpectedly failed.
>
> It turns out that I had run out of disk space. After a brief
> investigation I
> discovered
During a recent managed save operation I received the following error
message:
error: operation failed: domain save job: unexpectedly failed.
It turns out that I had run out of disk space. After a brief investigation I
discovered that libvirt_iohelper is exec'ed and is used to handle all
I
On 05/20/2014 02:08 PM, Jason J. Herne wrote:
During a recent managed save operation I received the following error
message:
error: operation failed: domain save job: unexpectedly failed.
It turns out that I had run out of disk space. After a brief
investigation I
discovered that libvirt_i
On 05/28/2014 02:13 AM, Chris Friesen wrote:
>
> I've got a libvirt-created instance where I've been messing with affinity, and
> now something is strange.
>
> I did the following in python:
>
import libvirt
conn=libvirt.open("qemu:///system")
dom = conn.lookupByName('instance-000
I've got a libvirt-created instance where I've been messing with
affinity, and now something is strange.
I did the following in python:
>>> import libvirt
>>> conn=libvirt.open("qemu:///system")
>>> dom = conn.lookupByName('instance-0027')
>>> dom.vcpus()
([(0, 1, 52815000L, 2), (1, 1
During a recent managed save operation I received the following error
message:
error: operation failed: domain save job: unexpectedly failed.
It turns out that I had run out of disk space. After a brief investigation I
discovered that libvirt_iohelper is exec'ed and is used to handle all
I
Hi,
I was playing around with vcpupin and emulatorpin and managed to get
into a strange state.
From within python I get the following:
(Pdb) dom = self._lookup_by_name(instance.name)
(Pdb) dom.vcpus()
([(0, 1, 597000L, 2), (1, 1, 458000L, 3)], [(False, False, True,
False), (False, F
Hello,
There seems to be a double-free bug in libvirt; I've checked libvirt
0.9.12 and 1.2.3:
With 0.9.12 xenUnifiedOpen() passes a pointer of "conn" to
xenInotifyOpen(), which passes it to virEventAddHandle(...opaque=conn...).
After successfully defining a new domain inotify picks up the newly
I have a case where I'm creating a virtio channel between the host and
guest using something like this:
When qemu is started up this gets created as expected, but when qemu is
shut down the unix socket is left in the filesystem.
It seems to me that libvirt should be delet
On Mon, Mar 10, 2014 at 10:59:08AM +0800, Wangpan wrote:
> >Please try out this patch
> >
> >https://www.redhat.com/archives/libvir-list/2014-March/msg00501.html
>
> I have tested this patch on master branch, and it works OK now, thanks Daniel
> !
Thanks for testing. I'll get this back onto th
>Please try out this patch
>
>https://www.redhat.com/archives/libvir-list/2014-March/msg00501.html
I have tested this patch on master branch, and it works OK now, thanks Daniel !
2014-03-10
Wangpan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/lib
On Fri, Mar 07, 2014 at 01:06:10PM +0800, Wangpan wrote:
> bug address: https://bugzilla.redhat.com/show_bug.cgi?id=1066801
> I can reproduce it at master/v1.2.1-maint/v1.1.4-maint/v1.1.3.4 release
> branches everytime,
> but cann't reproduce it at v1.2.1，so I believe this bug is imported by the
On Fri, Mar 07, 2014 at 01:06:10PM +0800, Wangpan wrote:
> bug address: https://bugzilla.redhat.com/show_bug.cgi?id=1066801
> I can reproduce it at master/v1.2.1-maint/v1.1.4-maint/v1.1.3.4 release
> branches everytime,
> but cann't reproduce it at v1.2.1，so I believe this bug is imported by the
bug address: https://bugzilla.redhat.com/show_bug.cgi?id=1066801
I can reproduce it at master/v1.2.1-maint/v1.1.4-maint/v1.1.3.4 release
branches everytime,
but cann't reproduce it at v1.2.1，so I believe this bug is imported by the
maintain patches after v1.2.1 release.
Steps to Reproduce:
1.cre
Hi experts,
Is there anybody could help me to fix this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1066801
my libvirt version is 1.1.4-manit without the newest patches after this one:
13 days ago Eric Blake event: move event filtering to daemon
(regression fix)
Description of probl
1 - 100 of 287 matches
Mail list logo
