[Bug 304636] Re: -hda FAT:. limited to 504MBytes
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 notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/304636/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1716656] Re: Plugins not loading
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. A proper install for a plugin install would have 4 files: /usr/lib64/entangle/plugins/shooter/shooter.plugin /usr/lib64/entangle/plugins/shooter/shooter.py /usr/share/entangle/plugins/shooter/schemas/gschemas.compiled /usr/share/entangle/plugins/shooter/schemas/org.entangle-photo.plugins.shooter.gschema.xml NB, /usr/lib64 might be elsewhere on Ubuntu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716656 Title: Plugins not loading To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/entangle/+bug/1716656/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1867519] Re: qemu 4.2 segfaults on VF detach
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 segfaults on VF detach To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1867519/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1838312] Re: Qemu virt-manager Segmentation fault
** 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: Qemu virt-manager Segmentation fault To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838312/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1823152] Re: QEMU not able to boot ubuntu 18.04 as a guest
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 of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1823152 Title: QEMU not able to boot ubuntu 18.04 as a guest To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1823152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
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 'remotes/otubo/tags/pull-seccomp-20190327' into staging pull-seccomp-20190327 # gpg: Signature made Wed 27 Mar 2019 12:12:39 GMT # gpg:using RSA key DF32E7C0F0FFF9A2 # gpg: Good signature from "Eduardo Otubo (Senior Software Engineer) " [full] # Primary key fingerprint: D67E 1B50 9374 86B4 0723 DBAB DF32 E7C0 F0FF F9A2 * remotes/otubo/tags/pull-seccomp-20190327: seccomp: report more useful errors from seccomp seccomp: don't kill process for resource control syscalls Signed-off-by: Peter Maydell IOW, mesa's usage of this syscalls will still be blocked, but it will no longer kill the process. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
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 providing a config option to prevent this affinity change. An env variable is workable if there's no other mechanism they can expose. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1815889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1815889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815889] Re: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new()
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 great example of why QEMU wants to use seccomp to block affinity changes to prevent something silently trying to use more CPUs than are assigned to this QEMU. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815889 Title: qemu-system-x86_64 crashed with signal 31 in __pthread_setaffinity_new() To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1815889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1769053] Re: Cannot start a guest with more than 1TB of RAM
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-bits=NNN for some suitable value of NNN. We should expose this in the XML config for the CPU explicitly too. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1769053 Title: Cannot start a guest with more than 1TB of RAM To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1769053/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722702] Re: libvirt - vnc port selection regression with newer kernels
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 member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722702 Title: libvirt - vnc port selection regression with newer kernels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1722702/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1721468] Re: Free invalid pointer crash in vnc
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 are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1721468 Title: Free invalid pointer crash in vnc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1721468/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1716028] Re: qemu 2.10 locks images with no feature flag
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. So short-circuiting locking if the current pid matches would be wrong. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1716028/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1449062] Re: qemu-img calls need to be restricted by ulimit (CVE-2015-5162)
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 you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1449062 Title: qemu-img calls need to be restricted by ulimit (CVE-2015-5162) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1449062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1589923] Re: https websockets not working in 2.5 or 2.6
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() on it is not appropriate. This results in mangling the 'destroy' field in the QTask struct, causing the later call to qtask_free() to try to call the function at address 0x1, with predictably segfault happy results. There is in fact no need for ref counting with QTask, as the call to qtask_abort() or qtask_complete() will automatically free associated memory. This fixes the crash shown in https://bugs.launchpad.net/qemu/+bug/1589923 Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrange (cherry picked from commit bc35d51077b33e68a0ab10a057f352747214223f) Signed-off-by: Michael Roth -- 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 to: https://bugs.launchpad.net/qemu/+bug/1589923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1529079] Re: Can't start virtual machines with installed systemd-container package on Xenial
> 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 libvirtd.service running until the VMs have been shutdown. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1529079 Title: Can't start virtual machines with installed systemd-container package on Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1529079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1529079] Re: Can't start virtual machines with installed systemd-container package on Xenial
> 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 sense & are required to get correct shutdown ordering for machines. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1529079 Title: Can't start virtual machines with installed systemd-container package on Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1529079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1589923] Re: https websockets not working in 2.5 or 2.6
** 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 to: https://bugs.launchpad.net/qemu/+bug/1589923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1589923] Re: https websockets not working in 2.5 or 2.6
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, 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 to: https://bugs.launchpad.net/qemu/+bug/1589923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1589923] Re: https websockets not working in 2.5 or 2.6
** 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 manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1589923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 832507] Re: console.log grows indefinitely
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 grows indefinitely To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 832507] Re: console.log grows indefinitely
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. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1483159] Re: Canonical naming for non-x86 architectures
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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1483159 Title: Canonical naming for non-x86 architectures To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483159/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1418187] Re: _get_host_numa_topology assumes numa cell has memory
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 broken in practice, because it'll never schedule guests on 1/2 of the CPUs in this host - ie the ones without local memory will never get used. Fixing this is a far more invasive problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1418187 Title: _get_host_numa_topology assumes numa cell has memory To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1418187/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1335221] [NEW] libvirt builds should include packager information
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 impossible to determine exactly which particular build of libvirt was used by the bug reporter For example, on Ubuntu currently if you turn on libvirt logging you'll see a message like this: 2014-06-27 15:12:33.274+: 20830: info : libvirt version: 1.2.2 By comparison on Fedora / RHEL systems you'd see something like this: 2014-06-27 16:30:33.837+: 2454: info : libvirt version: 1.2.2, package: 1.fc20 (Unknown, 2014-06-27-15:41:14, mustard.redhat.com) In particular notice that it includes the precise RPM release number, so that you can figure out exactly which binary package the bug reporter used. eg on Ubuntu this would be the "0ubuntu13" part of the version number in trusty libvirt builds. Debian/ubuntu packages could set this doing something like this when=`date +"%%F-%%T"` where=`hostname` who="Unknown" (or name of the person or entity doing the build) what="0ubuntu13" (or whatever current build is) ./configure --with-packager="$who $when $where" \ --with-packager-version="$what" \ ...other args to configure... And then check that this has then propagated to the log messages ** Affects: libvirt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1335221 Title: libvirt builds should include packager information To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1335221/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1304107] Re: Libvirt error launching instance - Device 'virtio-net-pci' could not be initialized
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 board is used by the VM - it can't distinguish i440fx from q35. I'm guessing Ubuntu was probably inspired by the fact that we did a similar thing in RHEL-6, replacing 'pc' with 'rhel-6.1.0'. The recommendation for distros who want to customize the machine types without breaking libvirt is to *not* replace the entire machine type name, but instead to just replace the upstream version number with a distro specific suffix. eg change 'pc-i440fx-1.6' to be 'pc-i440fx-trusty'. That way libvirt can still see that this is an i440fx machine type and do the right thing with PCI address validation. As a reference point, RHEL7 does this correctly now too, using 'pc- i440fx-rhel7.0.0' as machine type name. Unfortunately there's nothing OpenStack Nova can do to workaround this. Either Ubuntu have to change their QEMU machine type name as illustrated, to maintain the right prefix, or they'll have to hack their libvirt build to cope with the bare name 'trusty' :-( ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1304107 Title: Libvirt error launching instance - Device 'virtio-net-pci' could not be initialized To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1304107/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 being launched in a short period of time, but would definitely affect openstack. ** Bug watch added: Red Hat Bugzilla #1066801 https://bugzilla.redhat.com/show_bug.cgi?id=1066801 -- 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 libvirt 1.1.1 from ubuntu cloud archive To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 libvirt 1.1.1 from ubuntu cloud archive To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 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 libvirt 1.1.1 from ubuntu cloud
archive
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 logs show that this never completes. This pretty much confirms that we're hitting that libvirt race condition between parallel domain start / nwfilter changes. -- 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 libvirt 1.1.1 from ubuntu cloud archive To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1228977 Title: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1228977 Title: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1228977] Re: n-cpu seems to crash when running with libvirt 1.1.1 from ubuntu cloud archive
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 interesting message is the first line here - proc=181 corresponds to REMOTE_PROC_NWFILTER_UNDEFINE = 181, So this client log shows that Nova issued a virNWFilterUndefine API call, and libvirtd never responded with any completion. Nova hasn't hung, it is just waiting for libvirtd to finish what its doing. The question is what's libvirtd doing. -- 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 libvirt 1.1.1 from ubuntu cloud archive To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1228977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088295] Re: lxc container can control other container's cpu share, memory limit, or access of block and character devices
> 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 completed to allow LXC to be considered remotely secure & production ready. We should make sure our release notes explicitly tell people that LXC is not a secure virtualization technology and discourage its use in production environments.. I try to get this message across as widely as possible, but it still gets lost. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1088295 Title: lxc container can control other container's cpu share,memory limit,or access of block and character devices To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1088295/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 996840] Re: Libvirt error when trying to mount ISCSI volumes
@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 notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/996840 Title: Libvirt error when trying to mount ISCSI volumes To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/996840/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 996840] Re: Libvirt error when trying to mount ISCSI volumes
** 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 Title: Libvirt error when trying to mount ISCSI volumes To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/996840/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1031063] Re: internal error no supported architecture for os type 'hvm'
$ 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 that you have not got a KVM binary installed, or /dev/kvm does not exist. Checking 'virsh capabilities' will show what ostype/hvtype/arch combinations libvirt has detected. Once you make virsh capabilities show the hvm+kvm+arch combination needed by the XML, then OpenStack should work as expected -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1031063 Title: internal error no supported architecture for os type 'hvm' To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1031063/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 996840] Re: Libvirt error when trying to mount ISCSI volumes
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=drive-
virtio-disk5,format=raw"},"id":"libvirt-22"}
shows that the reporters' libvirt +QEMU are capable of doing the right
thing and using human-monitor-command. So assuming this virsh demo was
done against the same libvirtd instance, I think the most likely
explanation is that Nova and virsh are somehow generating different XML,
which causes different libvirt behaviour. We need to find out what XML
virsh attach-interface creates.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/996840
Title:
Libvirt error when trying to mount ISCSI volumes
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/996840/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 996840] Re: Libvirt error when trying to mount ISCSI volumes
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-
002b-lun-1,if=none,id=drive-virtio-
disk5,format=raw,cache=none"},"id":"libvirt-7"}
The problem is that although it existed in the HMP monitor, the QEMU
developers decided *not* to make drive_add available in QMP monitor.
They did however add a 'hmp_passthrough' command to let you invoke HMP
commands via QMP. Assuming you have a new enough QEMU and new enough
libvirt, libvirt will not use hmp_passthrough to invoke 'drive_add'.
Since this is not happening for the bug reporter, either their QEMU or
libvirt (or both) packages must be too old.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/996840
Title:
Libvirt error when trying to mount ISCSI volumes
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/996840/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 832507] Re: console.log grows indefinitely
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 requirements of the get_console_output() API contract is all that's required, I am thinking of the bigger picture, improving the console functionality available for the libvirt Nova driver in general. -- 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 grows indefinitely To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 832507] Re: console.log grows indefinitely
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. There'd be no need for any new features in either libvirt or QEMU for this to work. All nova would need todo would be update the conserver.cf file whenever a VM is started or stopped. Reusing existing mature projects like conserver is perferrable to reinventing the wheel with our own half-baked solutions. -- 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 grows indefinitely To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 832507] Re: console.log grows indefinitely
> > 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. > > I do not know whether or not it would be accepted upstream. This is an interesting idea & worth proposing to QEMU upstream to see what their feelings are on this - with this kind of concept, their reaction can be quite unpredictable, so I can't say more than a 50/50 chance they'll go for it. The reason I think they might not go for it, is that it implements just one out of many potential different policies. eg, a viable alternative would be to rotate log files periodically instead of using a ring buffer. If KVM doesn't care todo this, from a libvirt POV, I have long imagined the need for a "libvirt_vmlogd" daemon which would run independently of libvirtd or QEMU. The QEMU guests would be configured with either a PTY or more likely a UNIX socket (eg '-serial unix:/var/lib/libvirt/qemu/serial0.socket'). The libvirt_vmlogd would automatically connect to the sockets as each guest was launched, and log the data according to some policy it is configured with, and handle log rotation / expiration etc. For the sake of the Nova security issue, I think it'd be wise to implement a fix in Nova regardless, since both the upstream approaches could take some time. -- 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 grows indefinitely To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 953656] Re: LibVirtD crashing after many hours (100+)
> 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 API calls. > @Dan: since you are the author of the upstream patch, do you think it applies for us ? Which version of libvirt introduces the fix, > if any ? The fixes are present in libvirt >= 0.9.8. The fixes can be applied to older libvirt releases (eg 0.9.6/0.9.7) without too much trouble. For reference the fixes that Ubuntu libvirt maintainers would need to backport are: commit 3ec128989606278635a7c5dfbeee959692d12e15 Author: Daniel P. Berrange Date: Tue Nov 29 12:11:01 2011 + Add internal APIs for dealing with time commit 32d3ec7466a554f7a4a3e9d4017a24aa540ecf18 Author: Daniel P. Berrange Date: Tue Nov 29 12:32:31 2011 + Make logging async signal safe wrt time stamp generation commit a8bb75a3e65f0ae866f3b3fd60c57b2aa2050017 Author: Daniel P. Berrange Date: Tue Nov 29 12:33:23 2011 + Remove time APIs from src/util/util.h -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/953656 Title: LibVirtD crashing after many hours (100+) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/953656/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 520386] Re: libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge
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 work -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/520386 Title: libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 522710] Re: libvirtd does not have a man page
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/522710 Title: libvirtd does not have a man page To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/522710/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
