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:
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
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
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
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
$ 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
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
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
> > 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.
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
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
Server Team, which is su
12 matches
Mail list logo
