Unfortunately, no, that doesn't seem to work either. I managed to
compile qemu-kvm-1.0+noroms (required a few minor changes, linking with
librt and a documentation difference) and the supporting bios and pxe
files on Trusty. Migration now seems to work (Completed 100 %), but then
the target
Ok, I understand. Please note that this was also an issue for 10.04 - 12.04,
so it's definitely a good idea to have it fixed for future upgrades (aka
trusty specific machine type).
I'm not sure about the extra qemu. The next action after migration would be to
install the real qemu, right? After
Otoh, now we're facing a non-migrateable 12.04 in general, because you cannot
move your VMs out of the way :-(
Anyway, proper documentation is helpful in any case. Finally: there is no real
workaround now, or is there? What would you do, having several 12.04 host
machines? Just migrate
Hi,
Adding qemu:commandline tags needs a namespace. What you do is:
12.04~# virsh edit machine
Now add the namespace. The resulting first line of the domain xml-file should
read:
domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'
After that, adding qemu:commandline tags
Please note my comment #5: removing the vga adapter showed up a new
mismatch, this time for the virtio network adapter. I did not look into
that but you might want to check if there's more memory mismatches that
should be addressed before you start adding code.
--
You received this bug
Hi, is there anything I can do to help this bug's status?
--
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/1291321
Title:
migration fails between 12.04 Precise and 14.04 Trusty
To
When you add a machine with virt-manager, the display setting is model
type='cirrus' vram='9216' heads='1'/. I tried to set it to 10240 (which
is 10mb) but that didn't help - the error is the same.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
BTW, that last test was with the regular qemu-kvm in trusty, which is
1.7.0+dfsg-3ubuntu6. I upgraded to the ppa-version again and ... it
seems to do something. BRB.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
error: Unable to read from monitor: Connection reset by peer and the machine
crashed :-(
Next try, same as always: Length mismatch: vga.vram: 100 in != 80
That's a weird side effect, sometimes not only migration fails, but the machine
on the source host crashes, too. Did you reproduce
Hi,
Installed qemu-common qemu-keymaps qemu-kvm qemu-system-common
qemu-system-x86 qemu-utils from the ppa, same error:
source (12.04): # error: operation failed: migration job: unexpectedly
failed
Log file on target (14.04, log_level = 1) says:
2014-03-13 07:03:56.550+: starting up
The 100 comes from vga.h in the source for qemu-kvm-1.0+noroms: #define
VGA_RAM_SIZE (16 * 1024 * 1024)
I could not find the 80 value - as far as I can see, vga ram size is not
fixed anymore in the qemu-1.7.0+dfsg source - but I did not fully understand
the code.
Anyway, I tried
Public bug reported:
We're trying to live migrate machine fhdhvalentijn to a server named ranja.
This used to work perfectly when both systems ran 12.04 Precise. After
upgrading the target machine (ranja) to Trusty, migration fails; sometimes,
migration results in shutting down the VM.
Yes, that's possible. Should I install the ppa on source, target or
both?
V.
--
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/1291321
Title:
migration fails between 12.04 Precise and
Hmm. If libvirt shuts down the virtual machines it monitors, then these
virtual machines will also be shut down when updating libvirt.
--
Should shut down domains on system shutdown
https://bugs.launchpad.net/bugs/350936
You received this bug notification because you are a member of Ubuntu
The proposals in this report (mine, John Morrissey's) all have a pre-
stop shutdown of virtual machines in their Upstart conf-file.
When you update libvirt-bin, dpkg will stop libvirt-bin before
upgrading. As a result — if you have implemented the pre-stop shutdown —
your virtual machines will
While there's many solutions now to shutdown VM's, here's my 2 cents. Instead
of a libvirt-bin.conf script, I made a separate script
(/usr/local/sbin/shutdown-libvirt-hosts.sh). This script waits 120 seconds for
all VM's to shut down. Then I'm running this script from two places; in
libvirt-bin gets shutdown by Upstart, so when you try to shutdown from
an init script, chances are that libvirt has shutdown already. So if you
want to do this, you need to change /etc/init/libvirt-bin.conf as well,
and have it wait for the VM's to shut down.
--
Should shut down domains on
I'm still not sure, but doesn't the /etc/init.d/sendsigs script,
combined with the Ubuntu 10.04 /etc/init/rc.conf, make up for a giant
race condition? Where a shell script tries to find out which processes
it should not kill? This is, at least, what I'm making of it, when
running libvirt on a
The live-CD has an /etc/hostname set to ubuntu, so what do you want me
to check? Apart from that, the /sbin/dhclient-script file is the same as
above, so the logic to change the hostname does not work and is not
conforming to the dhclient-documentation.
--
Lucid dhclient can't set hostname
Isn't this a duplicate for bug #482313?
--
Make it possible again to let dhcp server set the client hostname
https://bugs.launchpad.net/bugs/523188
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dhcp3 in ubuntu.
--
Ubuntu-server-bugs
We are perfectly able to set hostnames in Karmic; however, we have
/etc/hostname explicitly set to '(none)', while (as far as I see in
other reports), since Karmic, when /etc/hostname is missing, Ubuntu sets
it to localhost, thus making dhclient not set the hostname.
--
Make it possible again to
We have set /etc/hostname explicitly to '(none)'. Naturally, this is an
illegal hostname, but since we use dhcp for our hostnames, the hostname
is changed once the network is up.
--
dhclient-script ignores option host-name from DHCP-server
https://bugs.launchpad.net/bugs/482313
You received this
In Lucid, this is not fixed but it is in fact worse, see bug #537978
--
Make it possible again to let dhcp server set the client hostname
https://bugs.launchpad.net/bugs/523188
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dhcp3 in
Public bug reported:
Until recently (up to and including Karmic), there was a set_hostname()
function in /sbin/dhclient-script, that said:
set_hostname() {
local current_hostname=$(hostname)
if [ -z $current_hostname -o $current_hostname = (none) ]; then
hostname $new_host_name
Public bug reported:
Binary package hint: bind9
apt-get install bind9
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
bind9-doc resolvconf
The following NEW packages will be installed:
bind9
0 upgraded, 1 newly installed, 0
25 matches
Mail list logo
