Cold migration fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
opennebula (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: opennebula
Cold migration fails because we're connecting to qemu:///system, so the saved state is owned by root, so we can't copy it to the remote host. We can't switch to qemu:///session, because adding VM's to a bridged network is a privileged operation.
Soren Hansen (soren) wrote : | #1 |
Soren Hansen (soren) wrote : | #2 |
hmm... The SUID binary would of course have to go in the -node package, which is a bit of a shame.
description: | updated |
Soren Hansen (soren) wrote : | #3 |
In summary, the challenge is that libvirtd runs as root, so saves the memory state as root, mode 600. We need to copy that to another host somehow while running as oneadmin.
Javi Fontan (jfontan) wrote : | #4 |
Does this thread bring any light to the problem? https:/
Anyway, we are about to reengineer the drivers so it is a good time to take care of that problems. We will take a look to this ticket.
Soren Hansen (soren) wrote : | #5 |
To be perfectly honest, I consider this a bug in libvirt, but if you can come up with a decent workaround in OpenNebula, that would be lovely.
Florian Kruse (florian-kruse) wrote : | #6 |
One year later, this bug still affects me in Karmic Server. Is there any workaround yet?
Ruben S, Montero (rubensm-dacya) wrote : Re: [Bug 322779] Re: Cold migration fails | #7 |
Hi
This should be working for OpenNebula 1.4. Check issue 131[1] in the
development portal, you can safely apply the associated changes to
OpenNebula 1.2. If you are using 1.4, please send us the log files...
[1] http://
Cheers
Ruben
On Fri, Mar 26, 2010 at 7:26 AM, Florian Kruse
<email address hidden> wrote:
> One year later, this bug still affects me in Karmic Server. Is there any
> workaround yet?
>
> --
> Cold migration fails
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “opennebula” package in Ubuntu: New
>
> Bug description:
> Binary package hint: opennebula
>
> Cold migration fails because we're connecting to qemu:///system, so the saved state is owned by root, so we can't copy it to the remote host. We can't switch to qemu:///session, because adding VM's to a bridged network is a privileged operation.
>
> To unsubscribe from this bug, go to:
> https:/
>
--
Dr. Ruben Santiago Montero
Associate Professor (Profesor Titular), Complutense University of Madrid
URL: http://
Weblog: http://
Florian Kruse (florian-kruse) wrote : | #8 |
Reading issue 131 it seems to me you suggest using qemu:///session instead of qemu:///system. However, this is no option for me as I use bridged networking. qemu:///session fails on that:
$ virsh -c qemu:///session create deployment.0
Connecting to uri: qemu:///session
error: Failed to create domain from deployment.0
error: internal error Failed to add tap interface 'vnet%d' to bridge 'br0' : Operation not permitted
Ruben S, Montero (rubensm-dacya) wrote : | #9 |
Hi,
Well actually is the opposite: the patch defaults the driver to use
qemu:///system. It also does a touch to the checkpoint file before
saving the image so it belongs to oneadmin and not to root.
You can check the commit
Cheers
Ruben
On Fri, Mar 26, 2010 at 10:06 AM, Florian Kruse
<email address hidden> wrote:
> Reading issue 131 it seems to me you suggest using qemu:///session
> instead of qemu:///system. However, this is no option for me as I use
> bridged networking. qemu:///session fails on that:
>
> $ virsh -c qemu:///session create deployment.0
> Connecting to uri: qemu:///session
> error: Failed to create domain from deployment.0
> error: internal error Failed to add tap interface 'vnet%d' to bridge 'br0' : Operation not permitted
>
> --
> Cold migration fails
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “opennebula” package in Ubuntu: New
>
> Bug description:
> Binary package hint: opennebula
>
> Cold migration fails because we're connecting to qemu:///system, so the saved state is owned by root, so we can't copy it to the remote host. We can't switch to qemu:///session, because adding VM's to a bridged network is a privileged operation.
>
> To unsubscribe from this bug, go to:
> https:/
>
--
Dr. Ruben Santiago Montero
Associate Professor (Profesor Titular), Complutense University of Madrid
URL: http://
Weblog: http://
Florian Kruse (florian-kruse) wrote : | #10 |
Hi,
On 26.03.2010, at 10:56, Ruben S, Montero wrote:
> Well actually is the opposite: the patch defaults the driver to use
> qemu:///system. It also does a touch to the checkpoint file before
> saving the image so it belongs to oneadmin and not to root.
Okay, I just assumed the possibility to change the driver was a suggestion to use qemu:///session (in the bug description it is mentioned as well).
I just missed the touch command. It works like a charm.
> You can check the commit
>
> http://
Unfortunately the changeset cannot be easily integrated into OpenNebula 1.2 since one_vmm_kvm.rb seems to be completely rewritten in OpenNebula 1.4. However, I made a small, quick and very dirty workaround for the current OpenNebula implementation of Karmic. Below you can see the patch that needs to be applied to /usr/lib/
Yet there is still another problem. AppArmor prevents libvirt to write checkpoints outside of oneadmin's home. Is there an open bug ticket for that or should I file a new one? There was a similar bug report in an earlier Ubuntu release but the fix only gave libvirt the ability to write inside the user's home and not in /var/lib/one/...
$ diff -u /usr/lib/
--- /usr/lib/
+++ /usr/lib/
@@ -112,6 +112,7 @@
end
def action_save(args)
+ touch_checkpoin
end
@@ -179,6 +180,18 @@
res
end
+
+ def touch_checkpoin
+ res=Open3.popen3(
+ "ssh -n #{host} touch #{file} ;"+
+ " echo ExitCode: $? 1>&2")
+ res[0].close
+
+ stdout=res[1].read
+ stderr=res[2].read
+
+ write_response(
+ end
def write_response(
Florian Kruse (florian-kruse) wrote : | #11 |
Ruben S, Montero (rubensm-dacya) wrote : | #12 |
Hi Florian
To address the Apparmor issue in Ubuntu 9.10, just add the
$ONE_LOCATION/var directory to
/etc/apparmor.
For example if ONE_LOCATION = /srv/cloud/one then your libvirt-qemu
apparmor file should be:
...
#include <abstractions/
owner @{HOME}/ r,
owner @{HOME}/** rw,
/srv/cloud/
The you have to restart the daemon. This should be done in all the
worker nodes of the cluster
Cheers
PS: You are right the text of the issues is totally misleading
On Fri, Mar 26, 2010 at 8:56 PM, Florian Kruse
<email address hidden> wrote:
> Hi,
>
> On 26.03.2010, at 10:56, Ruben S, Montero wrote:
>> Well actually is the opposite: the patch defaults the driver to use
>> qemu:///system. It also does a touch to the checkpoint file before
>> saving the image so it belongs to oneadmin and not to root.
>
> Okay, I just assumed the possibility to change the driver was a
> suggestion to use qemu:///session (in the bug description it is
> mentioned as well).
>
> I just missed the touch command. It works like a charm.
>
>> You can check the commit
>>
>> http://
>
> Unfortunately the changeset cannot be easily integrated into OpenNebula
> 1.2 since one_vmm_kvm.rb seems to be completely rewritten in OpenNebula
> 1.4. However, I made a small, quick and very dirty workaround for the
> current OpenNebula implementation of Karmic. Below you can see the patch
> that needs to be applied to /usr/lib/
>
> Yet there is still another problem. AppArmor prevents libvirt to write
> checkpoints outside of oneadmin's home. Is there an open bug ticket for
> that or should I file a new one? There was a similar bug report in an
> earlier Ubuntu release but the fix only gave libvirt the ability to
> write inside the user's home and not in /var/lib/one/...
>
> $ diff -u /usr/lib/
> --- /usr/lib/
> +++ /usr/lib/
> @@ -112,6 +112,7 @@
> end
>
> def action_save(args)
> + touch_checkpoin
> std_action("SAVE", "save #{args[3]} #{args[4]}", args)
> end
>
> @@ -179,6 +180,18 @@
> res[0].close
> res
> end
> +
> + def touch_checkpoin
> + res=Open3.popen3(
> + "ssh -n #{host} touch #{file} ;"+
> + " echo ExitCode: $? 1>&2")
> + res[0].close
> +
> + stdout=res[1].read
> + stderr=res[2].read
> +
> + write_response(
> + end
>
> def write_response(
> exit_code=
>
> --
> Cold migration fails
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “opennebula” package in Ubuntu: New
>
> Bug description:
> Binary package hint: opennebula
>
> Cold migration fails because we're conn...
Florian Kruse (florian-kruse) wrote : | #13 |
Hi!
On 26.03.2010, at 23:45, Ruben S, Montero wrote:
> To address the Apparmor issue in Ubuntu 9.10, just add the
> $ONE_LOCATION/var directory to
> /etc/apparmor.
That's what I found out as well. However, since it took me some time to find out and I think newly installed packages should work out of the box, I consider this missing line a bug. Apparently there is no open bug report for that. I'll file one.
Greetings,
Florian
Launchpad Janitor (janitor) wrote : | #14 |
This bug was fixed in the package opennebula - 2.0.1-5
---------------
opennebula (2.0.1-5) unstable; urgency=low
* d/patches/
LDFLAGS setting in OpenNebula build process. Will be included in next
upstream release.
* d/rules: Use dpkg-buildflags to get LDFLAGS.
Set DEB_LDFLAGS_
no-add-needed linker changes.
* d/patches/
-D_
* d/rules: Remove d/opennebula-
* d/opennebula-
but with xen-utils was failing as group `libvirt' does not exist.
Thanks to Łukasz Oleś for report and patch.
opennebula (2.0.1-4) unstable; urgency=low
* d/opennebula{
We cannot rely on adduser being present at package purge time.
General cleanup of maintainer scripts.
* d/opennebula-
(keep uid/gid permanently) but disable it.
opennebula (2.0.1-3) unstable; urgency=low
* d/control: move Depends on openssh-client from opennebula to
opennebula-
* Using dpkg-statoverride instead of chown for postinst.
opennebula (2.0.1-2) unstable; urgency=low
* d/rules: Fix FTBFS (Closes: #605042) by using dh_listpackages to detect if
arch all packages (ie. opennebula-node) debhelper commands will act on.
opennebula (2.0.1-1) unstable; urgency=low
* New upstream release.
* d/rules: Use share/etc/
* Refresh all patches.
* d/{control, rules}: Allow users of cloud group to launch xm & xmtop
from xen-utils-common (Closes: #604567):
- Depends on libvirt-bin | xen-utils-4.0
- Bump dependencies on sudo to (>= 1.7.2p1) for /etc/sudoers.d feature.
- Install /etc/sudoers.
* d/opennebula.
* d/control: Set Maintainer as Debian OpenNebula Maintainers
and myself as Uploaders.
opennebula (2.0-1) experimental; urgency=low
* First upload to Debian (Closes: #500716):
- Drop d/patches/
- Drop d/*.examples: Already handled by upstream install.sh
* New upstream release (2.0).
* d/control: Add Recommends: lvm2, sudo, wget, genisoimage.
- d/patches/
* d/rules, d/opennebula-
oneadmin user, libvirt (Debian) and libvirtd (Ubuntu).
* d/opennebula.
proper permissions.
* d/control: Suggests libamazonec2-ruby for Amazon EC2 access.
opennebula (2.0~rc1-1) UNRELEASED; urgency=low
* New upstream release (2.0 RC1).
* Add d/opennebula.README and d/opennebula-
startup how-to.
* d/rules: Fix perms for non-executables files.
* d/opennebula.init: Handle creation of /var/lock.
* d/patches/
* d/contr...
Changed in opennebula (Ubuntu): | |
status: | New → Fix Released |
A possible solution would be a SUID binary that given a VID, would chown /usr/lib/ one/<VID> /checkpoint to oneadmin.