[11:15] <mihajlov> xnox, as a followup to the discussion you had with macjl, guest migration between different KVM versions needs more consideration than the security driver used
[11:17] <mihajlov> e.g. the target hypervisor must understand and support the machine type as defined on the source hypervisor
[11:19] <mihajlov> a guest defined on KVM for IBM z will by default have a machine type of s390-ccw-kvmibm-1.1.1
[11:20] <mihajlov> which won't be accepted by an upstream QEMU
[11:22] <mihajlov> one could define the guest with machine type of s390-ccw-virtio-2.4 on the KVM for IBM z hypervisor which would allow the migration to an upstream hypervisor (like Ubuntu)
[11:23] <xnox> mihajlov, right.
[11:24] <xnox> mihajlov, forgot that part. When I saw this different machine type, i was slightly surprised and confused why a new one got defined.
[11:24] <xnox> mihajlov, I can certainly take that machine type as a patch to Debian & Ubuntu qemu, if we do in fact support / are compatible two way between 2.5 and e.g. s390-ccw-kvmibm-1.1.1
[11:25] <mihajlov> regarding the selinux <-> apparmor conversion I have doubts whether an automatic conversion can be vouched to be safe
[11:25] <xnox> true
[11:26] <mihajlov> as a potential way out, it is possible to send a modified domain XML over to the target machine using the --xml option on the migrate command
[11:26] <xnox> mihajlov, i wonder if we can, and/or should enable selinux in qemu on ubuntu. we have selinux anabled in a bunch of things
[11:26] <mihajlov> where you could omit the security driver
[11:26] <xnox> (and e.g. smack too)
[11:26] <xnox> mihajlov, would z/kvm accept --to-ubuntu flag? =)
[11:27]  * xnox is biased and wants everything on ubuntu ;-)
[11:28] <mihajlov> xnox, wrt to selinux on Ubuntu I am not a security expert but I thought you'll have to chose one method for your system?
[11:29] <xnox> apparmor is default and integrated throughout.
[11:29] <xnox> however other systems are available too, for those that want to use them.
[11:29] <xnox> e.g. we had selinux enabled in upstart as pid 1, because there are selinux usecases that people resonably use.
[11:29] <mihajlov> xnox, regarding the flag: to have one would be less of a problem (of course it would be one upstream) then the semantic associated with it
[11:30] <xnox> --insecure or some such =)
[11:30] <mihajlov> there's no way to "downgrade" a running virtual machine without impacting the guest
[11:30] <xnox> i dunno if libvirtd can do multiple security models simultaniously.
[11:30] <xnox> ouch.
[11:35] <mihajlov> would be a matter of testing I think