[Bug 832507] Re: console.log grows indefinitely

2016-03-10 Thread Daniel Berrange
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

2016-03-02 Thread Daniel Berrange
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

2015-09-15 Thread Daniel Berrange
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

2015-03-02 Thread Daniel Berrange
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

2014-06-27 Thread Daniel Berrange
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

2014-04-08 Thread Daniel Berrange
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'

2012-08-06 Thread Daniel Berrange
$ 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

2012-06-15 Thread Daniel Berrange
  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

2012-06-15 Thread Daniel Berrange
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

2012-06-15 Thread Daniel Berrange
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

2011-10-05 Thread Daniel Berrange
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

2011-10-05 Thread Daniel Berrange
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