FYI the QEMU change merged in the following pull request changed to
return an EPERM errno for the thread affinity syscalls:
commit 12f067cc14b90aef60b2b7d03e1df74cc50a0459
Merge: 84bdc58c06 035121d23a
Author: Peter Maydell
Date: Thu Mar 28 12:04:52 2019 +
Merge remote-tracking branch '
Switched bug to the ubuntu qemu package, since qemu-system-x86_64-spice
is not an upstream provided binary
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member
> You can't specify an ordering dependency to an object that you create
*right now*, as there is no way to enforce them. So just dropping these
two lines ought to fix it.
You're only considering startup ordering. These properties also apply to
ordering when stopping units, and so these do make sen
> Not sure of the importance of that `Before` close there yet.
The Before/After properties provide the correct ordering of units on
shutdown. Without this dependency, there is no guarantee that libvirt-
guests.service will be invoked before systemd kills the machines, nor
that it will keep libvirt
Hmm, if we know that QEMU guests will crash & burn when > 1 TB mem, when
host-phys-bits/phys-bits are unset, then perhaps libvirt should do the
right thing by default here. eg we can't use host-phys-bits=true due to
migration compat issues, but if we see > 1TB mem, libvirt could
reasonably set phys
If you need OS portability then the "usb-mtp" device is also an option
for adhoc file sharing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/304636
Title:
-hda FAT:. limited to 504MBytes
To manage
Looking at the file list for the entangle package:
https://packages.ubuntu.com/eoan/amd64/entangle/filelist
We can see that the plugin code simply isn't included at all.
Only the gschema files in /usr/share have been installed
The code and registration metadata from /usr/lib(64) are missing.
IMHO that mesa change is not valid. It is settings its affinity to run
on all threads which is definitely *NOT* something we want to be
allowed. Management applications want to control which CPUs QEMU runs
on, and as such Mesa should honour the CPU placement that the QEMU
process has.
This is a g
As & when libvirt & QEMU supports the external vhost processes for this
I expect it will still restrict the CPU affinity and apply seccomp
filters that likely to be as strict as they are today at minimum.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
I did wonder if we could set the action for some syscalls to be "errno"
instead of "kill process", but I worry that could then result in silent
mis-behaviour as processes fail to check return value as they blindly
assume the call cannot fail.
We should probably talk with mesa developers about prov
Libvirt releases once a month, and QEMU is in feature freeze for its
next release. So this will easily be ready before Newton
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/832507
Title:
console.log
Fixed in stable-2.6 branch in
commit 510531ea442a02048b1837fcf574d03559b38c9e
Author: Daniel P. Berrange
Date: Tue Jun 7 12:27:51 2016 +0100
io: remove mistaken call to object_ref on QTask
The QTask struct is just a standalone struct, not a QOM Object,
so calling object_ref()
Looks like this crash is the same root cause as the one fixed in 2.7.0
by
commit 3e7f136d8b4383d99f1b034a045b73f9b12a4eae
Author: Daniel P. Berrange
Date: Tue Aug 2 11:45:25 2016 +0100
vnc: fix crash when vnc_server_info_get has an error
--
You received this bug notification because you
This is almost certainly the kernel bug mentioned in that Fedora BZ.
There is however a workaround added in libvirt now for distros/users
who can't fix their kernel https://www.redhat.com/archives/libvir-
list/2017-September/msg00519.html
--
You received this bug notification because you are a
Having a single QEMU process open the same qcow2 file twice is just as
dangerous as having two separate QEMU processes open the same qcow2 file
concurrently. In both cases you have qcow2 state cached in a
BlockDriverState and nothing is able to invalidate the cache in the
other BlockDriverState. S
Yes, *any* qemu-img command that you run without providing '-f' will try
to guess the image format. Rather than trying to figure out whether a
particular invokation may or may not be susceptible to attack, the safe
approach is to use '-f' every time.
--
You received this bug notification because
** Changed in: qemu
Assignee: (unassigned) => Daniel Berrange (berrange)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589923
Title:
https websockets not working in 2.5 or 2.6
To man
The crash in 2.6 is fixed by
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01885.html
The dropped connection in 2.5 is fixed by
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01884.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, whic
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589923
Title:
https websockets not working in 2.5 or 2.6
To manage notifications about this bug go
FYI, having _get_host_numa_topology() not generate an exception on
reporting is the least of our worries here. The scheduling placement
code for NUMA guests assumes that all NUMA cells have both memory &
cpus. So with the proposed patch you will have silenced the exception,
but Nova will still be b
This is simply user error - OpenStack has a documented list of required
architecture values
http://docs.openstack.org/cli-reference/content/chapter_cli-glance-
property.html
Nova should not have to apply workarounds for every possible way the
user can specify incorrect architecture names.
--
Yo
Patches are ready to solve this entirely in the libvirt layer one & for
all. It'll be fixed with libvirt 1.3.3
https://www.redhat.com/archives/libvir-list/2016-February/msg01449.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
htt
Public bug reported:
The libvirt configure script has a special feature especially for distro
vendors to use when building binary packages which lets them encode a
bit of information about the builds, which then ends up in log files.
This does not appear to be used in Ubuntu builds which makes it
Ok that log is interesting as it shows that Ubuntu have re-named the
QEMU machine types
... -machine trusty,accel=tcg,usb=off ...
See 'trusty' is the machine type there instead of the more usual "pc-
i440fx-1.6"
This unfortunately breaks the ability of libvirt to figure out what type
of base b
Unfortunately the upstream libvirt patches contained a flaw, and
required an additional patch to fix the issue
https://www.redhat.com/archives/libvir-list/2014-March/msg00501.html
https://bugzilla.redhat.com/show_bug.cgi?id=1066801
The issue only appears when you have on the order of 20+ VMs bein
2014-01-21 04:15:07.566+: 27080: debug : virNetClientIO:1714 : Outgoing
message prog=536903814 version=1 serial=5238 proc=181 type=0 length=92
dispatch=0x7f31d4001810
2014-01-21 04:15:07.566+: 27080: debug : virNetClientIO:1740 : Going to
sleep head=0x7f31d4001810 call=0x3ec8050
The int
Unfortunately we can't see what libvirtd is doing because the job lacks
the libvirtd logs - we need these two changes deployed to the gate env
to capture logs
https://review.openstack.org/#/c/65834/
https://review.openstack.org/#/c/61892/
--
You received this bug notification because you are a m
Ah ha, I knew I'd seen this kind of thing somewhere before. There is an
outstanding, unsolved race condition in libvirt wrt nwfilters that can
cause hangs
https://bugzilla.redhat.com/show_bug.cgi?id=929412
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Looking slight further back in the logs before the virNWFilterUndefine
API call, I see an attempt to start a guest:
2014-01-21 04:15:07.124+: 29622: debug :
virDomainCreateWithFlags:9482 : dom=0x7f31a0001900, (VM:
name=instance-0053, uuid=9199131f-7ae8-4e9e-9065-0b47787180c1),
flags=0
the
Thanks, that confirms my earlier guess. I've managed to reproduce the
scenario locally in a way that openstack would definitely hit. Basically
concurrent use of virDomainCreate and virNWFilter{Define,Undefine} is
racey and unsafe as it stands. I'm working on a fix.
--
You received this bug notifi
FYI libvirt master GIT repo has the fixed and it is being backported to
all stable branches.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1228977
Title:
n-cpu seems to crash when running with libvi
> Serge: is there anything we can do on the Nova side of things ? Looks
like this has security implications ?
Providing sVirt support in libvirt, mitigates against the lack of
security for containers in the kernel, but this is at best a band-aid.
Ultimately, we need the usernamespace work complete
FYI This has been fixed upstream for a while now:
commit c6a6dc1d2d04b1d5aeb6978577f4d08a216f93ed
Author: Justin Clift
Date: Fri Jul 9 19:21:39 2010 +1000
libvirtd: add man page for libvirtd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
FYI upstream NetCF now has support for Debian style network config:
http://git.fedorahosted.org/git/?p=netcf.git;a=commit;h=5a84c95bea872d31f66be2ed6353734793a83aed
http://berrange.com/posts/2011/09/28/porting-netcf-to-debianubuntu-suse-and-windows/
this would enable the libvirt network APIs to w
$ virsh define /tmp/foo.xml
error: Failed to define domain from /tmp/foo.xml
error: internal error no supported architecture for os type 'hvm'
This means that libvirt can't find any way to provide the requested domain
configuration. Since your XML shows you requested KVM, most likely this means
** Changed in: nova
Status: Incomplete => Confirmed
** Changed in: nova
Assignee: (unassigned) => Daniel Berrange (berrange)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/996840
@soren I built a copy of libvirt 0.9.8 and tried those two XML examples
you show in comment #18. In both cases hotplug succeeds without error.
Can you actually reproduce the bug using either of those two XML
snippets in combination with 'virsh attach-device' ?
--
You received this bug notificati
You can see here that libvirt is attempting to run the 'drive_add'
command, using QMP (JSON) monitor:
QEMU_MONITOR_IO_WRITE: mon=0x7f242c000a80
buf={"execute":"drive_add","arguments":{"pci_addr":"dummy","opts":"file=/dev/disk
/by-path/ip-XXX.XXX.XXX.XXX:3260-iscsi-iqn.2010-10.org.openstack:volume-
Hmm this log from comment #2
-05-09 15:38:14.311+: 22564: debug : virJSONValueToString:1071 :
result={"execute":"human-monitor-command","arguments":{"command-
line":"drive_add dummy file=/dev/disk/by-path/ip-XXX.XXX.XXX.XXX:3260
-iscsi-iqn.2010-10.org.openstack:volume-002b-lun-1,if=none,id
> > The reason for the qemu-kvm task is that we think qemu-kvm is really the
> > ultimate right place to add a '-serial ringbuffer:640k,file=/path/to/file'
> > flag.
> > All the other attempts are more hacky, but if upstream kvm had this ,
> > libvirt could expose it, and openstack could use it.
Having examined the idea of the libvirt_consoled a bit more, I think it
is not actually required. It is possible to get good support for console
logging, max bounded size, rollover, & secure remote access, simply by
dropping in the standard 'conserver' daemon with a suitable
configuration file. Th
IMHO having fixed size rotated logs per VM with max number of files, is
a better solution that a ringbuffer. It really doesn't complicate the
code that much to have to potentially just read a few lines from a
second rotated logfile.
While I agree that conserver is overkill if satisfying the requi
> As libvirt seems to have threading issues, perhaps we should scope
every libvirt call in a global lock?
This won't solve the problem. The flaw seen here is a deadlock between 1
thread in libvirtd, and a child process it forks during VM startup, so
can be seen even if you serialize all libvirt AP
That commit you mention is confirmed to solve a bug reported against
Fedora with almost the same stack trace you see here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867519
Title:
qemu 4.2 segfa
** Also affects: virt-manager (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838312
Title:
Qem
45 matches
Mail list logo
