Hello Antonio (@arcimboldo)

The fix only makes sense for newer QEMUs (>= Xenial, like the one from
Mitaka Ubuntu Cloud Archive).

OBS:

The "migration check" is done in VHOST initialization functions when the
devices are virtually attached to the virtual machine. If you are using
kernel 3.13 and have apparmor enabled, then all the running instances
have the "migration blocker" ON - because of this buggy migration check
- and won't be able to live migration.

Unfortunately there is a "in-memory" linked list telling qemu that is
has a blocker (with the reason). This blocker was added during instance
startup and will be checked/used only when instance is live-migrated.

Check this: http://pastebin.ubuntu.com/23517175/

If you started the instance in a host not running apparmor (or not
having libvirt profile loaded, for example) it won't block the creation
of /tmp/memfd-XXX files during instance initialization. That won't
trigger the "blocker flag" inside the running program and, if/when
needed, the live migration will be able to occur.

This means that, after installing the new package, if you're using
apparmor, yes, you would have to RESTART running instances that were
affected by this bug in order to live migrating them. Sorry for the bad
news!  Even if you remove the apparmor rules, the migration blocker is
already set.

Hacking your process virtual memory would jeopardize the contents of the
virtual memory (could be catastrophic specially for a virtual machine).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1626972

Title:
  QEMU memfd_create fallback mechanism change for security drivers

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1626972/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to