[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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to libvirt in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to qemu in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to nova in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 jcl...@redhat.com 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 Server Team, which is subscribed to libvirt in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-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 Server Team, which is subscribed to libvirt in 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-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs