On Tue, 8 Sep 2009, Dustin Kirkland wrote:
Hi Brent-
Upstream indicates that this is solved in qemu 0.11, which is what we
have in Karmic right now.
Any chance you can test this on a Karmic system running qemu-kvm 0.11?
With regard to your ifup/ifdown question, I'm uploading a fix right
On Tue, 8 Sep 2009, Dustin Kirkland wrote:
Hi Brent-
Upstream indicates that this is solved in qemu 0.11, which is what we
have in Karmic right now.
Any chance you can test this on a Karmic system running qemu-kvm 0.11?
With regard to your ifup/ifdown question, I'm uploading a fix right
The kernel patch and discussion for this issue is here:
http://patchwork.kernel.org/patch/39589/
--
Running karmic as virtual machine with virtio hard disk outputs I/O erros
https://bugs.launchpad.net/bugs/420423
You received this bug notification because you are a member of Ubuntu
Bugs, which
Public bug reported:
Binary package hint: linux-image
This is a known bug in kernels prior to 2.6.25 (not sure when it was
introduced). If you have a long write task (such as a dd) to an NFS
mount, an ls -l on the NFS mount won't complete until the write
finishes. If you are copying a file
Redhat discussion of this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=469848
** Bug watch added: Red Hat Bugzilla #469848
https://bugzilla.redhat.com/show_bug.cgi?id=469848
--
nfs_getattr starvation with heavy NFS write activity
https://bugs.launchpad.net/bugs/420508
You received this
The live migration crashes with KVM:84 are specific to SMP guests. This
is already logged in the KVM bug database. I've seen mention that
KVM:85 is soon to be release, but I do not know whether or not this bug
is fixed.
--
kvm migration fails with large-memory VMs
I tried again to migrate with Hardy PPA KVM:84 and got a different oops.
However, if I first stop the guest VM, and then migrate, it does work
fine, and it's actually pretty quick, such that an ssh would see just a
few seconds delay. So, offline migration does work, and isn't bad. I
would love
Public bug reported:
Binary package hint: kvm
In Hardy, an attempt to migrate a 6GB VM results in:
migration: memory size mismatch: recv 2168467456 mine 2168467456
migrate_incoming_fd failed (rc=232)
Migration failed rc=232
I ran across a thread which suggests that this is a known KVM bug that
I just tried with the Hardy PPA KVM:84. It doesn't have this migration
issue, and migration claims to go to completion, however:
1) The first time I tried migrating, after migration completed, the
guest VM, also running Hardy, had done a fresh boot.
2) I tried migrating again, this time with a
Just another me too, although I get the issue with virt-install,
rather than virt-manager, using the --pxe option.
--
virDomainCreateLinux fails because of unknown parameter -drive
https://bugs.launchpad.net/bugs/240905
You received this bug notification because you are a member of Ubuntu
Bugs,
On Tue, 29 Apr 2008, Sebastien Bacher wrote:
this erroneous assumption is the bug
it's not an assumption but it needs to look on the partition to know if
there a directory there
It may need to look at THE partition (i.e., the partition on which a file
is actually being deleted, although
Ditto, on Hardy Heron. The download site indicates a new version. This
has been a frequent problem over the years, and I wish there was a more
permanent solution for it. Ideally, Adobe would simply archive older
versions, rather than always offering only the latest, without a way to
download by
I am seeing this issue on a fresh Hardy amd64 install. ypbind is
actually failing to register with portmap, even though portmap started
significantly earlier (nis startup is S18 in rc2, while portmap seems to
be starting as S43 in rcS; curiously, portmap is also listed as S17 in
rc2, but that's
I tried again today, with gvfs 0.2.2svn20080403-0ubuntu1. I found that
the mount storm is currently pretty slow, but the gvfsd-trash processes
seem to be accumulating endlessly. After ~45 minutes, it has mounted
everything in our department, and I have over 3000 gvfsd-trash processes
(and 1.1GB
Please also see duplicate bug #210586. gvfsd-trash continuously tries
to access the automount points (and keeps spawning and spawning,
although it does allow old processes to die before spawning more, so it
doesn't consume all available memory). The result is that, as soon as
someone logs in,
Public bug reported:
Binary package hint: gvfs
In gvfs 0.2.2svn20080331-0ubuntu1 on a recent amd64 Hardy install,
gvfsd-trash is triggering all of my NFS automounts. gvfsd-trash spawns
continuously, although the total number doesn't seem to grow beyond
~50-60 something (some exit and new ones
Public bug reported:
Binary package hint: icedtea-gcjwebplugin
icedtea-gcjwebplugin 1.0-0ubuntu5 on a recent amd64 Hardy install does
run the applet at http://www.goes.noaa.gov/GSSLOOPS/ecwv.html. The
applet is supposed to pull in multiple satellite images and display them
in sequence.
17 matches
Mail list logo
