From kripper at imatronix.cl Tue Jul 7 04:22:22 2015 Content-Type: multipart/mixed; boundary="===============4606044719476433279==" MIME-Version: 1.0 From: Christopher Pereira To: devel at ovirt.org Subject: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 05:22:20 -0300 Message-ID: <559B8C3C.5000105@imatronix.cl> --===============4606044719476433279== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------040500060504070207030504 Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed Content-Transfer-Encoding: 7bit Hi, After upgrading from alpha-1 to alpha-2 and restarting services, a VM = won't start because of the following qemu error: Domain id=3D5 is tainted: hook-script 2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0 qemu: warning: error while loading state section id 2 2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed: Invalid argument The reason is that Engine was starting the VM with the -incoming flag = (for "incoming migrations"). 1) Why did engine enable the -incoming flag? VM was configured with "Allow manual migration only". Maybe this ocurred because I set the host in maintenance mode before = upgrading. 2) How can I clean the -incoming flag in oVirt? 3) Note that the "domain is tainted" error was also freezing the monitor = socket between libvirt and vdsm, requiring a libvirtd + vdsmd restart. --------------040500060504070207030504 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Hi,

After upgrading from alpha-1 to alpha-2 and restarting services, a VM won't start because of the following qemu error:
Domain id=3D5 is tainted: hook-script
2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0
qemu: warning: error while loading state section id 2
2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed: Invalid argument
The reason is that Engine was starting the VM with the -incoming flag (for "incoming migrations").

1) Why did engine enable the -incoming flag?
VM was configured with "Allow manual migration only".
Maybe this ocurred because I set the host in maintenance mode before upgrading.

2) How can I clean the -incoming flag in oVirt?

3) Note that the "domain is tainted" error was also freezing the monitor socket between libvirt and vdsm, requiring a libvirtd + vdsmd restart.

--------------040500060504070207030504-- --===============4606044719476433279== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNDA1MDAwNjA1MDQwNzAyMDcwMzA1MDQKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PXV0Zi04OyBmb3JtYXQ9Zmxvd2VkCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQK CkhpLAoKQWZ0ZXIgdXBncmFkaW5nIGZyb20gYWxwaGEtMSB0byBhbHBoYS0yIGFuZCByZXN0YXJ0 aW5nIHNlcnZpY2VzLCBhIFZNIAp3b24ndCBzdGFydCBiZWNhdXNlIG9mIHRoZSBmb2xsb3dpbmcg cWVtdSBlcnJvcjoKCiAgICBEb21haW4gaWQ9NSBpcyB0YWludGVkOiBob29rLXNjcmlwdAogICAg MjAxNS0wNy0wN1QwNzozOToyNy4yMTU1NzlaIHFlbXUta3ZtOiBVbmtub3duIG1pZ3JhdGlvbiBm bGFnczogMAogICAgcWVtdTogd2FybmluZzogZXJyb3Igd2hpbGUgbG9hZGluZyBzdGF0ZSBzZWN0 aW9uIGlkIDIKICAgIDIwMTUtMDctMDdUMDc6Mzk6MjcuMjE1NjgxWiBxZW11LWt2bTogbG9hZCBv ZiBtaWdyYXRpb24gZmFpbGVkOgogICAgSW52YWxpZCBhcmd1bWVudAoKVGhlIHJlYXNvbiBpcyB0 aGF0IEVuZ2luZSB3YXMgc3RhcnRpbmcgdGhlIFZNIHdpdGggdGhlIC1pbmNvbWluZyBmbGFnIAoo Zm9yICJpbmNvbWluZyBtaWdyYXRpb25zIikuCgoxKSBXaHkgZGlkIGVuZ2luZSBlbmFibGUgdGhl IC1pbmNvbWluZyBmbGFnPwpWTSB3YXMgY29uZmlndXJlZCB3aXRoICJBbGxvdyBtYW51YWwgbWln cmF0aW9uIG9ubHkiLgpNYXliZSB0aGlzIG9jdXJyZWQgYmVjYXVzZSBJIHNldCB0aGUgaG9zdCBp biBtYWludGVuYW5jZSBtb2RlIGJlZm9yZSAKdXBncmFkaW5nLgoKMikgSG93IGNhbiBJIGNsZWFu IHRoZSAtaW5jb21pbmcgZmxhZyBpbiBvVmlydD8KCjMpIE5vdGUgdGhhdCB0aGUgImRvbWFpbiBp cyB0YWludGVkIiBlcnJvciB3YXMgYWxzbyBmcmVlemluZyB0aGUgbW9uaXRvciAKc29ja2V0IGJl dHdlZW4gbGlidmlydCBhbmQgdmRzbSwgcmVxdWlyaW5nIGEgbGlidmlydGQgKyB2ZHNtZCByZXN0 YXJ0LgoKCi0tLS0tLS0tLS0tLS0tMDQwNTAwMDYwNTA0MDcwMjA3MDMwNTA0CkNvbnRlbnQtVHlw ZTogdGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdi aXQKCjxodG1sPgogIDxoZWFkPgoKICAgIDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8L2hlYWQ+CiAgPGJvZHkgYmdj b2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCI+CiAgICBIaSw8YnI+CiAgICA8YnI+CiAgICBB ZnRlciB1cGdyYWRpbmcgZnJvbSBhbHBoYS0xIHRvIGFscGhhLTIgYW5kIHJlc3RhcnRpbmcgc2Vy dmljZXMsIGEKICAgIFZNIHdvbid0IHN0YXJ0IGJlY2F1c2Ugb2YgdGhlIGZvbGxvd2luZyBxZW11 IGVycm9yOjxicj4KICAgIDxibG9ja3F1b3RlPkRvbWFpbiBpZD01IGlzIHRhaW50ZWQ6IGhvb2st c2NyaXB0PGJyPgogICAgICAyMDE1LTA3LTA3VDA3OjM5OjI3LjIxNTU3OVogcWVtdS1rdm06IFVu a25vd24gbWlncmF0aW9uIGZsYWdzOiAwPGJyPgogICAgICBxZW11OiB3YXJuaW5nOiBlcnJvciB3 aGlsZSBsb2FkaW5nIHN0YXRlIHNlY3Rpb24gaWQgMjxicj4KICAgICAgMjAxNS0wNy0wN1QwNzoz OToyNy4yMTU2ODFaIHFlbXUta3ZtOiBsb2FkIG9mIG1pZ3JhdGlvbiBmYWlsZWQ6CiAgICAgIElu dmFsaWQgYXJndW1lbnQ8YnI+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICBUaGUgcmVhc29uIGlzIHRo YXQgRW5naW5lIHdhcyBzdGFydGluZyB0aGUgVk0gd2l0aCB0aGUgLWluY29taW5nCiAgICBmbGFn IChmb3IgImluY29taW5nIG1pZ3JhdGlvbnMiKS48YnI+CiAgICA8YnI+CiAgICAxKSBXaHkgZGlk IGVuZ2luZSBlbmFibGUgdGhlIC1pbmNvbWluZyBmbGFnPzxicj4KICAgIFZNIHdhcyBjb25maWd1 cmVkIHdpdGggIkFsbG93IG1hbnVhbCBtaWdyYXRpb24gb25seSIuPGJyPgogICAgTWF5YmUgdGhp cyBvY3VycmVkIGJlY2F1c2UgSSBzZXQgdGhlIGhvc3QgaW4gbWFpbnRlbmFuY2UgbW9kZSBiZWZv cmUKICAgIHVwZ3JhZGluZy48YnI+CiAgICA8YnI+CiAgICAyKSBIb3cgY2FuIEkgY2xlYW4gdGhl IC1pbmNvbWluZyBmbGFnIGluIG9WaXJ0Pzxicj4KICAgIDxicj4KICAgIDMpIE5vdGUgdGhhdCB0 aGUgImRvbWFpbiBpcyB0YWludGVkIiBlcnJvciB3YXMgYWxzbyBmcmVlemluZyB0aGUKICAgIG1v bml0b3Igc29ja2V0IGJldHdlZW4gbGlidmlydCBhbmQgdmRzbSwgcmVxdWlyaW5nIGEgbGlidmly dGQgKwogICAgdmRzbWQgcmVzdGFydC48YnI+CiAgICA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+Cgot LS0tLS0tLS0tLS0tLTA0MDUwMDA2MDUwNDA3MDIwNzAzMDUwNC0tCg== --===============4606044719476433279==-- From fromani at redhat.com Tue Jul 7 05:04:36 2015 Content-Type: multipart/mixed; boundary="===============0785531371700802873==" MIME-Version: 1.0 From: Francesco Romani To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 05:04:24 -0400 Message-ID: <1645215389.24286740.1436259864448.JavaMail.zimbra@redhat.com> In-Reply-To: 559B8C3C.5000105@imatronix.cl --===============0785531371700802873== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Christopher Pereira" > To: devel(a)ovirt.org > Sent: Tuesday, July 7, 2015 10:22:20 AM > Subject: [ovirt-devel] VM won't start because of -incoming flag after upg= rading to alpha-2 > = > Hi, > = > After upgrading from alpha-1 to alpha-2 and restarting services, a VM won= 't > start because of the following qemu error: Hi, > Domain id=3D5 is tainted: hook-script > 2015-07-07T07:39:27.215579Z qemu-kvm: Unknown migration flags: 0 > qemu: warning: error while loading state section id 2 > 2015-07-07T07:39:27.215681Z qemu-kvm: load of migration failed: Invalid > argument > The reason is that Engine was starting the VM with the -incoming flag (for > "incoming migrations"). > = > 1) Why did engine enable the -incoming flag? It should not, it should be added by VDSM only when it creates a migration = destination VM/ > VM was configured with "Allow manual migration only". > Maybe this ocurred because I set the host in maintenance mode before > upgrading. > = > 2) How can I clean the -incoming flag in oVirt? Short answer: you cannot, but because it should not be added randomly > 3) Note that the "domain is tainted" error was also freezing the monitor > socket between libvirt and vdsm, requiring a libvirtd + vdsmd restart. Could be QEMU issue. BTW, can you please share the VDSM log which includes the misbehaviour? Thanks, -- = Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani --===============0785531371700802873==-- From kripper at imatronix.cl Tue Jul 7 05:50:09 2015 Content-Type: multipart/mixed; boundary="===============7062688846796614097==" MIME-Version: 1.0 From: Christopher Pereira To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 06:50:08 -0300 Message-ID: <559BA0D0.7090100@imatronix.cl> In-Reply-To: 1645215389.24286740.1436259864448.JavaMail.zimbra@redhat.com --===============7062688846796614097== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07-07-2015 6:04, Francesco Romani wrote: > It should not, it should be added by VDSM only when it creates a = > migration destination VM/ Well, something is triggered it. I will send you the logs right now. --===============7062688846796614097==-- From dfediuck at redhat.com Tue Jul 7 05:59:27 2015 Content-Type: multipart/mixed; boundary="===============6724353372960187709==" MIME-Version: 1.0 From: Doron Fediuck To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 12:59:26 +0300 Message-ID: <559BA2FE.6070100@redhat.com> In-Reply-To: 559BA0D0.7090100@imatronix.cl --===============6724353372960187709== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/07/15 12:50, Christopher Pereira wrote: > = > On 07-07-2015 6:04, Francesco Romani wrote: >> It should not, it should be added by VDSM only when it creates a >> migration destination VM/ > Well, something is triggered it. > I will send you the logs right now. > = According to libvirt docs, this is an internal flag, which is not exposed to the user- http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-incoming Can you please provide the libvirt log? --===============6724353372960187709==-- From kripper at imatronix.cl Tue Jul 7 06:07:23 2015 Content-Type: multipart/mixed; boundary="===============1850025923034660800==" MIME-Version: 1.0 From: Christopher Pereira To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 07:07:20 -0300 Message-ID: <559BA4D8.8020201@imatronix.cl> In-Reply-To: 559BA2FE.6070100@redhat.com --===============1850025923034660800== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07-07-2015 6:59, Doron Fediuck wrote: > On 07/07/15 12:50, Christopher Pereira wrote: >> >> Well, something is triggered it. >> I will send you the logs right now. >> > > According to libvirt docs, this is an internal flag, which is not > exposed to the user- > http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-incoming > > Can you please provide the libvirt log? > This are the libvirt/qemu logs. BTW, I executed a "virsh dumpxml" command before shutting down the = services and there is no "-incoming" flag in the dump. [...] ((null):28066): Spice-Warning **: reds.c:2824:reds_handle_ssl_accept: = SSL_accept failed, error=3D5 ((null):28066): Spice-Warning **: reds.c:2824:reds_handle_ssl_accept: = SSL_accept failed, error=3D5 ((null):28066): Spice-Warning **: reds.c:2824:reds_handle_ssl_accept: = SSL_accept failed, error=3D5 2015-07-07 05:09:56.817+0000: shutting down qemu: terminating on signal 15 from pid 2084 --- Starting via Engine --- 2015-07-07 05:31:32.792+0000: starting up LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin = QEMU_AUDIO_DRV=3Dnone /usr/libexec/qemu-kvm -name test-vm -S -machine = rhel6.5.0,accel=3Dkvm,usb=3Doff -cpu Nehalem -m 4096 -realtime mlock=3Doff = -smp 1,maxcpus=3D16,sockets=3D16,cores=3D1,threads=3D1 -uuid = 8c9437e4-5514-4c85-a52b-da33d9ab6061 -smbios = type=3D1,manufacturer=3DoVirt,product=3DoVirt = Node,version=3D7-1.1503.el7.centos.2.8,serial=3D32393735-3733-5355-4532-303= 957525946,uuid=3D8c9437e4-5514-4c85-a52b-da33d9ab6061 = -no-user-config -nodefaults -chardev = socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/test-vm.monitor,server= ,nowait = -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc = base=3D2015-07-07T02:31:32,driftfix=3Dslew -global = kvm-pit.lost_tick_policy=3Ddiscard -no-hpet -no-shutdown -boot strict=3Don = -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -device = virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x4 -device = virtio-serial-pci,id=3Dvirtio-serial0,max_ports=3D16,bus=3Dpci.0,addr=3D0x5 = -drive if=3Dnone,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw,serial=3D -= device = ide-cd,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive = file=3D/rhev/data-center/1963d7ab-a65b-4a70-8749-f45aceba2393/ebd94ac1-84df= -47da-be87-ca49f7bffdcf/images/7fba2829-772b-43e0-9d47-0b164b2ac975/7b2102e= 5-5f97-4185-9c71-618187c6dee9,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Dqc= ow2,serial=3D7fba2829-772b-43e0-9d47-0b164b2ac975,cache=3Dnone,werror=3Dsto= p,rerror=3Dstop,aio=3Dthreads = -device = virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x6,drive=3Ddrive-virtio-disk0= ,id=3Dvirtio-disk0,bootindex=3D1 = -netdev tap,fd=3D29,id=3Dhostnet0,vhost=3Don,vhostfd=3D30 -device = virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0,mac=3D00:1a:4a:16:01:54,bus=3Dpc= i.0,addr=3D0x3 = -chardev = socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/8c9437e4-551= 4-4c85-a52b-da33d9ab6061.com.redhat.rhevm.vdsm,server,nowait = -device = virtserialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dch= annel0,name=3Dcom.redhat.rhevm.vdsm = -chardev = socket,id=3Dcharchannel1,path=3D/var/lib/libvirt/qemu/channels/8c9437e4-551= 4-4c85-a52b-da33d9ab6061.org.qemu.guest_agent.0,server,nowait = -device = virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel1,id=3Dch= annel1,name=3Dorg.qemu.guest_agent.0 = -chardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -device = virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id=3Dch= annel2,name=3Dcom.redhat.spice.0 = -spice = port=3D5900,tls-port=3D5901,addr=3D0,disable-ticketing,x509-dir=3D/etc/pki/= vdsm/libvirt-spice,seamless-migration=3Don = -vnc 0:2 -device = qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,vgamem_mb=3D16= ,bus=3Dpci.0,addr=3D0x2 = -incoming fd:26 -device = virtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,addr=3D0x7 -msg timestamp=3Don Domain id=3D9 is tainted: hook-script 2015-07-07T05:31:39.798212Z qemu-kvm: Unknown migration flags: 0 qemu: warning: error while loading state section id 2 2015-07-07T05:31:39.798293Z qemu-kvm: load of migration failed: Invalid = argument 2015-07-07 05:47:55.386+0000: shutting down [...] --- Starting via virsh define + start (from a dump) --- 2015-07-07 07:51:53.266+0000: starting up LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin = QEMU_AUDIO_DRV=3Dnone /usr/libexec/qemu-kvm -name test-vm -S -machine = rhel6.5.0,accel=3Dkvm,usb=3Doff -cpu Nehalem -m 4096 -realtime mlock=3Doff = -smp 1,maxcpus=3D16,sockets=3D16,cores=3D1,threads=3D1 -uuid = 8c9437e4-5514-4c85-a52b-da33d9ab6061 -smbios = type=3D1,manufacturer=3DoVirt,product=3DoVirt = Node,version=3D7-1.1503.el7.centos.2.8,serial=3D32393735-3733-5355-4532-303= 957525946,uuid=3D8c9437e4-5514-4c85-a52b-da33d9ab6061 = -no-user-config -nodefaults -chardev = socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/test-vm.monitor,server= ,nowait = -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc = base=3D2015-07-07T04:51:53,driftfix=3Dslew -global = kvm-pit.lost_tick_policy=3Ddiscard -no-hpet -no-shutdown -boot strict=3Don = -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -device = virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x4 -device = virtio-serial-pci,id=3Dvirtio-serial0,max_ports=3D16,bus=3Dpci.0,addr=3D0x5 = -drive if=3Dnone,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw,serial=3D -= device = ide-cd,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive = file=3D/rhev/data-center/1963d7ab-a65b-4a70-8749-f45aceba2393/ebd94ac1-84df= -47da-be87-ca49f7bffdcf/images/7fba2829-772b-43e0-9d47-0b164b2ac975/7b2102e= 5-5f97-4185-9c71-618187c6dee9,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Dqc= ow2,serial=3D7fba2829-772b-43e0-9d47-0b164b2ac975,cache=3Dnone,werror=3Dsto= p,rerror=3Dstop,aio=3Dthreads = -device = virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x6,drive=3Ddrive-virtio-disk0= ,id=3Dvirtio-disk0,bootindex=3D1 = -netdev tap,fd=3D29,id=3Dhostnet0,vhost=3Don,vhostfd=3D30 -device = virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0,mac=3D00:1a:4a:16:01:54,bus=3Dpc= i.0,addr=3D0x3 = -chardev = socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/8c9437e4-551= 4-4c85-a52b-da33d9ab6061.com.redhat.rhevm.vdsm,server,nowait = -device = virtserialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dch= annel0,name=3Dcom.redhat.rhevm.vdsm = -chardev = socket,id=3Dcharchannel1,path=3D/var/lib/libvirt/qemu/channels/8c9437e4-551= 4-4c85-a52b-da33d9ab6061.org.qemu.guest_agent.0,server,nowait = -device = virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel1,id=3Dch= annel1,name=3Dorg.qemu.guest_agent.0 = -chardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -device = virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id=3Dch= annel2,name=3Dcom.redhat.spice.0 = -spice = port=3D5901,tls-port=3D5902,addr=3D0,disable-ticketing,x509-dir=3D/etc/pki/= vdsm/libvirt-spice,seamless-migration=3Don = -vnc 0:3 -device = qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,vgamem_mb=3D16= ,bus=3Dpci.0,addr=3D0x2 = -device virtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,addr=3D0x7 -msg timest= amp=3Don --===============1850025923034660800==-- From fromani at redhat.com Tue Jul 7 07:16:24 2015 Content-Type: multipart/mixed; boundary="===============9081250854585646235==" MIME-Version: 1.0 From: Francesco Romani To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 07:16:17 -0400 Message-ID: <1700802160.24328244.1436267777612.JavaMail.zimbra@redhat.com> In-Reply-To: 559BA4D8.8020201@imatronix.cl --===============9081250854585646235== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Christopher Pereira" > To: "Doron Fediuck" , "Francesco Romani" > Cc: devel(a)ovirt.org, "Roy Golan" > Sent: Tuesday, July 7, 2015 12:07:20 PM > Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after= upgrading to alpha-2 > = > = > On 07-07-2015 6:59, Doron Fediuck wrote: > > On 07/07/15 12:50, Christopher Pereira wrote: > >> > >> Well, something is triggered it. > >> I will send you the logs right now. > >> > > > > According to libvirt docs, this is an internal flag, which is not > > exposed to the user- > > http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-incoming > > > > Can you please provide the libvirt log? > > > 2015-07-07 05:31:32.792+0000: starting up > LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin > QEMU_AUDIO_DRV=3Dnone /usr/libexec/qemu-kvm -name test-vm -S -machine > rhel6.5.0,accel=3Dkvm,usb=3Doff -cpu Nehalem -m 4096 -realtime mlock=3Doff > -smp 1,maxcpus=3D16,sockets=3D16,cores=3D1,threads=3D1 -uuid > 8c9437e4-5514-4c85-a52b-da33d9ab6061 -smbios > type=3D1,manufacturer=3DoVirt,product=3DoVirt > Node,version=3D7-1.1503.el7.centos.2.8,serial=3D32393735-3733-5355-4532-3= 03957525946,uuid=3D8c9437e4-5514-4c85-a52b-da33d9ab6061 > -no-user-config -nodefaults -chardev > socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/test-vm.monitor,serv= er,nowait > -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc > base=3D2015-07-07T02:31:32,driftfix=3Dslew -global > kvm-pit.lost_tick_policy=3Ddiscard -no-hpet -no-shutdown -boot strict=3Don > -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -device > virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x4 -device > virtio-serial-pci,id=3Dvirtio-serial0,max_ports=3D16,bus=3Dpci.0,addr=3D0= x5 > -drive if=3Dnone,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw,serial=3D= -device > ide-cd,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive > file=3D/rhev/data-center/1963d7ab-a65b-4a70-8749-f45aceba2393/ebd94ac1-84= df-47da-be87-ca49f7bffdcf/images/7fba2829-772b-43e0-9d47-0b164b2ac975/7b210= 2e5-5f97-4185-9c71-618187c6dee9,if=3Dnone,id=3Ddrive-virtio-disk0,format=3D= qcow2,serial=3D7fba2829-772b-43e0-9d47-0b164b2ac975,cache=3Dnone,werror=3Ds= top,rerror=3Dstop,aio=3Dthreads > -device > virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x6,drive=3Ddrive-virtio-dis= k0,id=3Dvirtio-disk0,bootindex=3D1 > -netdev tap,fd=3D29,id=3Dhostnet0,vhost=3Don,vhostfd=3D30 -device > virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0,mac=3D00:1a:4a:16:01:54,bus=3D= pci.0,addr=3D0x3 > -chardev > socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/8c9437e4-5= 514-4c85-a52b-da33d9ab6061.com.redhat.rhevm.vdsm,server,nowait > -device > virtserialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3D= channel0,name=3Dcom.redhat.rhevm.vdsm > -chardev > socket,id=3Dcharchannel1,path=3D/var/lib/libvirt/qemu/channels/8c9437e4-5= 514-4c85-a52b-da33d9ab6061.org.qemu.guest_agent.0,server,nowait > -device > virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel1,id=3D= channel1,name=3Dorg.qemu.guest_agent.0 > -chardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -device > virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id=3D= channel2,name=3Dcom.redhat.spice.0 > -spice > port=3D5900,tls-port=3D5901,addr=3D0,disable-ticketing,x509-dir=3D/etc/pk= i/vdsm/libvirt-spice,seamless-migration=3Don > -vnc 0:2 -device > qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,vgamem_mb=3D= 16,bus=3Dpci.0,addr=3D0x2 > -incoming fd:26 This means the VM is "migrating from file", aka resuming after a suspension. Any chance the VM was suspended while running some QEMU version and resumed= using a different QEMU version? > --- Starting via virsh define + start (from a dump) --- [snip] OK, so new boot and no resume, this explains why it starts OK. Bests, -- = Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani --===============9081250854585646235==-- From kripper at imatronix.cl Tue Jul 7 07:32:44 2015 Content-Type: multipart/mixed; boundary="===============7707156669386620062==" MIME-Version: 1.0 From: Christopher Pereira To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 08:32:40 -0300 Message-ID: <559BB8D8.7060704@imatronix.cl> In-Reply-To: 1700802160.24328244.1436267777612.JavaMail.zimbra@redhat.com --===============7707156669386620062== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07-07-2015 8:16, Francesco Romani wrote: > This means the VM is "migrating from file", aka resuming after a suspensi= on. > Any chance the VM was suspended while running some QEMU version and resum= ed using a different QEMU version? Yes, the VM was suspended before updating and restarting services. It probably failed the first time I tried to resume and by some reason, = the memory snapshot is not available any more. --===============7707156669386620062==-- From fromani at redhat.com Tue Jul 7 07:37:09 2015 Content-Type: multipart/mixed; boundary="===============2318291407923170589==" MIME-Version: 1.0 From: Francesco Romani To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 07:36:36 -0400 Message-ID: <1028198893.24334570.1436268996927.JavaMail.zimbra@redhat.com> In-Reply-To: 559BB8D8.7060704@imatronix.cl --===============2318291407923170589== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Christopher Pereira" > To: "Francesco Romani" > Cc: "Doron Fediuck" , devel(a)ovirt.org, "Roy Gola= n" > Sent: Tuesday, July 7, 2015 1:32:40 PM > Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after= upgrading to alpha-2 > = > = > On 07-07-2015 8:16, Francesco Romani wrote: > > This means the VM is "migrating from file", aka resuming after a > > suspension. > > Any chance the VM was suspended while running some QEMU version and res= umed > > using a different QEMU version? > = > Yes, the VM was suspended before updating and restarting services. > It probably failed the first time I tried to resume and by some reason, > the memory snapshot is not available any more. OK, then the scenarios are the following: If you suspended on qemu-kvm-ev version X and resumed on qemu-kvm-ev versio= n Y (Y > X), then it should be supported, so please file a bug against qemu-kvm-ev Same goes for plain qemu. but if you suspended on qemu and resumed on qemu-kvm-ev, or vice versa, the= n I'm not sure this flow is supported (AFAIR, it isn't). -- = Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani --===============2318291407923170589==-- From kripper at imatronix.cl Tue Jul 7 09:47:04 2015 Content-Type: multipart/mixed; boundary="===============2841979663900770669==" MIME-Version: 1.0 From: Christopher Pereira To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Tue, 07 Jul 2015 10:47:05 -0300 Message-ID: <559BD859.5070409@imatronix.cl> In-Reply-To: 1028198893.24334570.1436268996927.JavaMail.zimbra@redhat.com --===============2841979663900770669== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07-07-2015 8:36, Francesco Romani wrote: > ----- Original Message ----- >> From: "Christopher Pereira" >> To: "Francesco Romani" >> Cc: "Doron Fediuck" , devel(a)ovirt.org, "Roy Gol= an" >> Sent: Tuesday, July 7, 2015 1:32:40 PM >> Subject: Re: [ovirt-devel] VM won't start because of -incoming flag afte= r upgrading to alpha-2 >> >> >> On 07-07-2015 8:16, Francesco Romani wrote: >>> This means the VM is "migrating from file", aka resuming after a >>> suspension. >>> Any chance the VM was suspended while running some QEMU version and res= umed >>> using a different QEMU version? >> Yes, the VM was suspended before updating and restarting services. >> It probably failed the first time I tried to resume and by some reason, >> the memory snapshot is not available any more. > OK, then the scenarios are the following: > > If you suspended on qemu-kvm-ev version X and resumed on qemu-kvm-ev vers= ion Y (Y > X), > then it should be supported, so please file a bug against qemu-kvm-ev > > Same goes for plain qemu. > > but if you suspended on qemu and resumed on qemu-kvm-ev, or vice versa, t= hen I'm not sure > this flow is supported (AFAIR, it isn't). > 'qemu-kvm-ev-2.1.2-23.el7_1.3.1.x86_64' was being used for both = suspending and resuming. BZ created here: https://bugzilla.redhat.com/show_bug.cgi?id=3D1240649 --===============2841979663900770669==-- From s.kieske at mittwald.de Wed Jul 8 03:08:51 2015 Content-Type: multipart/mixed; boundary="===============6880938739005289315==" MIME-Version: 1.0 From: Sven Kieske To: devel at ovirt.org Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2 Date: Wed, 08 Jul 2015 09:08:47 +0200 Message-ID: <559CCC7F.2090704@mittwald.de> In-Reply-To: 1028198893.24334570.1436268996927.JavaMail.zimbra@redhat.com --===============6880938739005289315== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/15 13:36, Francesco Romani wrote: > but if you suspended on qemu and resumed on qemu-kvm-ev, or vice > versa, then I'm not sure this flow is supported (AFAIR, it isn't). I wonder why that should not be supported, afaik the only difference between qemu-kvm and qemu-kvm-ev is the enabled flag to allow live migrations. I can't see why this would introduce a flag of "-incoming" on the qemu command line. is there a technical reason why this is not supported? or is this just a "you moved from binary name a to b, so it's not supported" case, no matter the almost 100% exact same content within those binarys? - -- = Mit freundlichen Gr=C3=BC=C3=9Fen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=C3=B6nigsberger Stra=C3=9Fe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVnMx/AAoJEMby9TMDAbQRxV8P/0Zy/nrMG6acKGX34IcMaveL 4l7SqJktjk/i/F520B7D08Ub6iZKsTMP4IrK2ZGV/uF11OfE8ERG3xxKxdAvymES RV+NoBJWWuZHX/6twF8caUqLopnun6q76gHgGQg0ynnECOxlgbnpKE1uLuHF2QZM sS2FlLGC8Zm7ycs+I+/M3ANrV8zXykud1OCl4Oj8Z3wn0lSa8+p4rXrfARs0yamO 4PKwvMJU9jYwf/ZhGO0z2+Qy9ZXofSt/G8OLljGnQlmwzUQvc/oNiENTmh3q+BwB 6/8GSALaAhnHL11VPqB26Os/0+HNp1DgH2mVoFGUa4NhxhVozyWu2Efh73p0Of0I 4lZyxsoUaCdAJg2omC7RCB8DKFZwKFmBfRUGrLtivUmAfpm7oaGV+t+YJaYO+/Fx oabApAHDTJeNA3Zq/QshnwfWg2jpbLBXIO8plJ2Ygwyi7jzgxK+WmUhuEAcm8Ab5 l6kp3ctnnhJW/VErhHnzVDtNHSEUT5c16JcwQniob4haRdtK9ANTqnUbwhjq+K7Q yqbSBiHvZ6LBkXBN1yFekEzFuzQFF954DQP4k/l5BAiJ3o9F/Abk5HZtzf3AeTG4 cL6fXOfrgZAv6iaKogNsETDj9guaqVzrr6FqG0hnGanVNxnwVz2ew4cecxcTF5j/ 777ezRh/zBRpV5Jufsrb =3Duccx -----END PGP SIGNATURE----- --===============6880938739005289315==-- From michal.skrivanek at redhat.com Wed Jul 8 03:22:47 2015 Content-Type: multipart/mixed; boundary="===============7660271579137448759==" MIME-Version: 1.0 From: Michal Skrivanek To: devel at ovirt.org Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2 Date: Wed, 08 Jul 2015 09:22:43 +0200 Message-ID: In-Reply-To: 559CCC7F.2090704@mittwald.de --===============7660271579137448759== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Jul 8, 2015, at 09:08 , Sven Kieske wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > = > On 07/07/15 13:36, Francesco Romani wrote: >> but if you suspended on qemu and resumed on qemu-kvm-ev, or vice >> versa, then I'm not sure this flow is supported (AFAIR, it isn't). > = > I wonder why that should not be supported, afaik the only > difference between qemu-kvm and qemu-kvm-ev is the enabled > flag to allow live migrations. > = > I can't see why this would introduce a flag of "-incoming" > on the qemu command line. I don't think any wrong version would introduce such a thing. -incoming is used internally on all VMs incoming migrations, that includes = a resume from suspended state - which is the case here. = It's just that resume is failing as the stored state file is probably corru= pted = > = > is there a technical reason why this is not supported? > or is this just a "you moved from binary name a to b, so it's not > supported" case, no matter the almost 100% exact same content > within those binarys? When on the same version - mostly as you say, yes. But starting with RHEL 7 you may have noticed different major version of QE= MU in base RHEL/CentOS and what we deliver as part of qemu-kvm-ev. It's mor= e close to latest Fedora versions, yet it's significantly different > = > - -- = > Mit freundlichen Gr=C3=BC=C3=9Fen / Regards > = > Sven Kieske > = > Systemadministrator > Mittwald CM Service GmbH & Co. KG > K=C3=B6nigsberger Stra=C3=9Fe 6 > 32339 Espelkamp > T: +495772 293100 > F: +495772 293333 > https://www.mittwald.de > Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus > en > Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad > Oeynhausen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > = > iQIcBAEBAgAGBQJVnMx/AAoJEMby9TMDAbQRxV8P/0Zy/nrMG6acKGX34IcMaveL > 4l7SqJktjk/i/F520B7D08Ub6iZKsTMP4IrK2ZGV/uF11OfE8ERG3xxKxdAvymES > RV+NoBJWWuZHX/6twF8caUqLopnun6q76gHgGQg0ynnECOxlgbnpKE1uLuHF2QZM > sS2FlLGC8Zm7ycs+I+/M3ANrV8zXykud1OCl4Oj8Z3wn0lSa8+p4rXrfARs0yamO > 4PKwvMJU9jYwf/ZhGO0z2+Qy9ZXofSt/G8OLljGnQlmwzUQvc/oNiENTmh3q+BwB > 6/8GSALaAhnHL11VPqB26Os/0+HNp1DgH2mVoFGUa4NhxhVozyWu2Efh73p0Of0I > 4lZyxsoUaCdAJg2omC7RCB8DKFZwKFmBfRUGrLtivUmAfpm7oaGV+t+YJaYO+/Fx > oabApAHDTJeNA3Zq/QshnwfWg2jpbLBXIO8plJ2Ygwyi7jzgxK+WmUhuEAcm8Ab5 > l6kp3ctnnhJW/VErhHnzVDtNHSEUT5c16JcwQniob4haRdtK9ANTqnUbwhjq+K7Q > yqbSBiHvZ6LBkXBN1yFekEzFuzQFF954DQP4k/l5BAiJ3o9F/Abk5HZtzf3AeTG4 > cL6fXOfrgZAv6iaKogNsETDj9guaqVzrr6FqG0hnGanVNxnwVz2ew4cecxcTF5j/ > 777ezRh/zBRpV5Jufsrb > =3Duccx > -----END PGP SIGNATURE----- > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > = > = --===============7660271579137448759==-- From michal.skrivanek at redhat.com Wed Jul 8 03:26:03 2015 Content-Type: multipart/mixed; boundary="===============4797079262930788646==" MIME-Version: 1.0 From: Michal Skrivanek To: devel at ovirt.org Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2 Date: Wed, 08 Jul 2015 09:25:59 +0200 Message-ID: <9A9FB909-C22D-4180-B12B-AFAFEBD9490F@redhat.com> In-Reply-To: B49F2F8F-D296-44E6-AC04-B1E0D96225C9@redhat.com --===============4797079262930788646== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Jul 8, 2015, at 09:22 , Michal Skrivanek = wrote: > = > On Jul 8, 2015, at 09:08 , Sven Kieske wrote: > = >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> = >> On 07/07/15 13:36, Francesco Romani wrote: >>> but if you suspended on qemu and resumed on qemu-kvm-ev, or vice >>> versa, then I'm not sure this flow is supported (AFAIR, it isn't). >> = >> I wonder why that should not be supported, afaik the only >> difference between qemu-kvm and qemu-kvm-ev is the enabled >> flag to allow live migrations. >> = >> I can't see why this would introduce a flag of "-incoming" >> on the qemu command line. > = > I don't think any wrong version would introduce such a thing. > -incoming is used internally on all VMs incoming migrations, that include= s a resume from suspended state - which is the case here. = > It's just that resume is failing as the stored state file is probably cor= rupted = well, or a plain backend bug, that's always possible:) > = >> = >> is there a technical reason why this is not supported? >> or is this just a "you moved from binary name a to b, so it's not >> supported" case, no matter the almost 100% exact same content >> within those binarys? > = > When on the same version - mostly as you say, yes. > But starting with RHEL 7 you may have noticed different major version of = QEMU in base RHEL/CentOS and what we deliver as part of qemu-kvm-ev. It's m= ore close to latest Fedora versions, yet it's significantly different > = >> = >> - -- = >> Mit freundlichen Gr=C3=BC=C3=9Fen / Regards >> = >> Sven Kieske >> = >> Systemadministrator >> Mittwald CM Service GmbH & Co. KG >> K=C3=B6nigsberger Stra=C3=9Fe 6 >> 32339 Espelkamp >> T: +495772 293100 >> F: +495772 293333 >> https://www.mittwald.de >> Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer >> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus >> en >> Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad >> Oeynhausen >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (GNU/Linux) >> = >> iQIcBAEBAgAGBQJVnMx/AAoJEMby9TMDAbQRxV8P/0Zy/nrMG6acKGX34IcMaveL >> 4l7SqJktjk/i/F520B7D08Ub6iZKsTMP4IrK2ZGV/uF11OfE8ERG3xxKxdAvymES >> RV+NoBJWWuZHX/6twF8caUqLopnun6q76gHgGQg0ynnECOxlgbnpKE1uLuHF2QZM >> sS2FlLGC8Zm7ycs+I+/M3ANrV8zXykud1OCl4Oj8Z3wn0lSa8+p4rXrfARs0yamO >> 4PKwvMJU9jYwf/ZhGO0z2+Qy9ZXofSt/G8OLljGnQlmwzUQvc/oNiENTmh3q+BwB >> 6/8GSALaAhnHL11VPqB26Os/0+HNp1DgH2mVoFGUa4NhxhVozyWu2Efh73p0Of0I >> 4lZyxsoUaCdAJg2omC7RCB8DKFZwKFmBfRUGrLtivUmAfpm7oaGV+t+YJaYO+/Fx >> oabApAHDTJeNA3Zq/QshnwfWg2jpbLBXIO8plJ2Ygwyi7jzgxK+WmUhuEAcm8Ab5 >> l6kp3ctnnhJW/VErhHnzVDtNHSEUT5c16JcwQniob4haRdtK9ANTqnUbwhjq+K7Q >> yqbSBiHvZ6LBkXBN1yFekEzFuzQFF954DQP4k/l5BAiJ3o9F/Abk5HZtzf3AeTG4 >> cL6fXOfrgZAv6iaKogNsETDj9guaqVzrr6FqG0hnGanVNxnwVz2ew4cecxcTF5j/ >> 777ezRh/zBRpV5Jufsrb >> =3Duccx >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> = >> = > = --===============4797079262930788646==-- From fromani at redhat.com Wed Jul 8 03:26:33 2015 Content-Type: multipart/mixed; boundary="===============8799587341307964635==" MIME-Version: 1.0 From: Francesco Romani To: devel at ovirt.org Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2 Date: Wed, 08 Jul 2015 03:26:24 -0400 Message-ID: <1027695025.24746192.1436340384342.JavaMail.zimbra@redhat.com> In-Reply-To: 559CCC7F.2090704@mittwald.de --===============8799587341307964635== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Sven Kieske" > To: devel(a)ovirt.org > Sent: Wednesday, July 8, 2015 9:08:47 AM > Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -in= coming flag after upgrading to alpha-2 > = > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > = > On 07/07/15 13:36, Francesco Romani wrote: > > but if you suspended on qemu and resumed on qemu-kvm-ev, or vice > > versa, then I'm not sure this flow is supported (AFAIR, it isn't). > = > I wonder why that should not be supported, afaik the only > difference between qemu-kvm and qemu-kvm-ev is the enabled > flag to allow live migrations. > = > I can't see why this would introduce a flag of "-incoming" > on the qemu command line. The flag -incoming is for supporting incoming migrations, either from file (aka resume from suspension) or from another qemu on another host. So it should'nt be affected by the qemu VS qemu-kvm-ev split. What I meant is that... > is there a technical reason why this is not supported? > or is this just a "you moved from binary name a to b, so it's not > supported" case, no matter the almost 100% exact same content > within those binarys? ... AFAIR, in the patchset which is part of qemu-kvm-ev, a lot of devices are disabled for security/safety/auditing reasons, and new, stable machines are added (rhel*). When QEMU migrates, again to another qemu or to file, among other things it needs to freeze and serialize device state. The format of this device state can change across versions, even though it usually changes in forward compatible way. So, the problem *could* be that the resuming QEMU doesn't know how to handle some device, or cannot understand the stored format. This is the reason why *I believe* this flow is not supported. But of course the last word is on the QEMU(-kvm[-ev]) devs. -- = Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani --===============8799587341307964635==-- From kripper at imatronix.cl Wed Jul 8 04:15:14 2015 Content-Type: multipart/mixed; boundary="===============3590645473051735060==" MIME-Version: 1.0 From: Christopher Pereira To: devel at ovirt.org Subject: Re: [ovirt-devel] [!!Mass Mail]Re: VM won't start because of -incoming flag after upgrading to alpha-2 Date: Wed, 08 Jul 2015 05:15:14 -0300 Message-ID: <559CDC12.2040201@imatronix.cl> In-Reply-To: 1027695025.24746192.1436340384342.JavaMail.zimbra@redhat.com --===============3590645473051735060== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------060800000400050202020906 Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed Content-Transfer-Encoding: 7bit On 08-07-2015 4:26, Francesco Romani wrote: > ... AFAIR, in the patchset which is part of qemu-kvm-ev, a lot > of devices are disabled for security/safety/auditing reasons, > and new, stable machines are added (rhel*). > > When QEMU migrates, again to another qemu or to file, among other > things it needs to freeze and serialize device state. > The format of this device state can change across versions, even though > it usually changes in forward compatible way. > > So, the problem *could* be that the resuming QEMU doesn't know how > to handle some device, or cannot understand the stored format. > > This is the reason why *I believe* this flow is not supported. > But of course the last word is on the QEMU(-kvm[-ev]) devs. > > Any chance that other upgrades [1] (ie. device-mapper) could invalidate = the state file? Now, how can I tell Engine or VDSM to discard the state file (to not try = reading the invalid state file during next startup) and recover this VM? [1] : This is the list of updated packages: Jul 07 00:11:31 Installed: ruby-libs-2.0.0.598-25.el7_1.x86_64 Jul 07 00:11:31 Updated: file-libs-5.11-22.el7.x86_64 Jul 07 00:11:31 Updated: file-5.11-22.el7.x86_64 Jul 07 00:11:31 Updated: 1:libguestfs-1.28.1-1.28.el7.x86_64 Jul 07 00:11:32 Updated: 1:libguestfs-tools-c-1.28.1-1.28.el7.x86_64 Jul 07 00:11:32 Installed: libyaml-0.1.4-11.el7_0.x86_64 Jul 07 00:11:32 Installed: rubygem-psych-2.0.0-25.el7_1.x86_64 Jul 07 00:11:32 Installed: rubygem-io-console-0.4.2-25.el7_1.x86_64 Jul 07 00:11:32 Installed: ruby-irb-2.0.0.598-25.el7_1.noarch Jul 07 00:11:32 Installed: ruby-2.0.0.598-25.el7_1.x86_64 Jul 07 00:11:32 Installed: rubygem-bigdecimal-1.2.0-25.el7_1.x86_64 Jul 07 00:11:32 Installed: rubygem-json-1.7.7-25.el7_1.x86_64 Jul 07 00:11:32 Installed: rubygems-2.0.14-25.el7_1.noarch Jul 07 00:11:32 Installed: rubygem-rdoc-4.0.0-25.el7_1.noarch Jul 07 00:11:32 Installed: unzip-6.0-15.el7.x86_64 Jul 07 00:11:32 Installed: perl-XML-Parser-2.41-10.el7.x86_64 Jul 07 00:11:32 Installed: perl-XML-XPath-1.13-22.el7.noarch Jul 07 00:11:32 Installed: 1:perl-Sys-Guestfs-1.28.1-1.28.el7.x86_64 Jul 07 00:11:33 Installed: 1:virt-v2v-1.28.1-1.28.el7.x86_64 Jul 07 00:11:33 Installed: 1:ruby-libguestfs-1.28.1-1.28.el7.x86_64 Jul 07 00:11:33 Installed: libguestfs-winsupport-7.1-4.el7.x86_64 Jul 07 00:11:33 Updated: python-magic-5.11-22.el7.noarch Jul 07 02:14:57 Updated: 1:openssl-libs-1.0.1e-42.el7.9.x86_64 Jul 07 02:14:58 Updated: glusterfs-libs-3.7.2-3.el7.x86_64 Jul 07 02:14:58 Updated: glusterfs-3.7.2-3.el7.x86_64 Jul 07 02:14:58 Updated: systemd-libs-208-20.el7_1.5.x86_64 Jul 07 02:15:00 Updated: systemd-208-20.el7_1.5.x86_64 Jul 07 02:15:00 Updated: trousers-0.3.11.2-4.el7_1.x86_64 Jul 07 02:15:00 Updated: dracut-033-241.el7_1.3.x86_64 Jul 07 02:15:00 Updated: glusterfs-client-xlators-3.7.2-3.el7.x86_64 Jul 07 02:15:00 Updated: nss-util-3.19.1-1.el7_1.x86_64 Jul 07 02:15:00 Updated: glusterfs-fuse-3.7.2-3.el7.x86_64 Jul 07 02:15:00 Updated: glusterfs-api-3.7.2-3.el7.x86_64 Jul 07 02:15:00 Updated: gnutls-3.3.8-12.el7_1.1.x86_64 Jul 07 02:15:00 Updated: 7:device-mapper-libs-1.02.93-3.el7_1.1.x86_64 Jul 07 02:15:00 Updated: 7:device-mapper-1.02.93-3.el7_1.1.x86_64 Jul 07 02:15:00 Updated: 7:device-mapper-event-libs-1.02.93-3.el7_1.1.x86_64 Jul 07 02:15:00 Updated: glusterfs-cli-3.7.2-3.el7.x86_64 Jul 07 02:15:01 Updated: 7:device-mapper-event-1.02.93-3.el7_1.1.x86_64 Jul 07 02:15:01 Updated: 7:lvm2-libs-2.02.115-3.el7_1.1.x86_64 Jul 07 02:15:01 Updated: 7:lvm2-2.02.115-3.el7_1.1.x86_64 Jul 07 02:15:01 Updated: gnutls-dane-3.3.8-12.el7_1.1.x86_64 Jul 07 02:15:01 Updated: gnutls-utils-3.3.8-12.el7_1.1.x86_64 Jul 07 02:15:01 Updated: nss-3.19.1-3.el7_1.x86_64 Jul 07 02:15:01 Updated: nss-sysinit-3.19.1-3.el7_1.x86_64 Jul 07 02:15:07 Installed: kernel-3.10.0-229.7.2.el7.x86_64 Jul 07 02:15:07 Updated: iputils-20121221-6.el7_1.1.x86_64 Jul 07 02:15:07 Updated: ntpdate-4.2.6p5-19.el7.centos.1.x86_64 Jul 07 02:15:07 Updated: ntp-4.2.6p5-19.el7.centos.1.x86_64 Jul 07 02:15:09 Updated: python-libs-2.7.5-18.el7_1.1.x86_64 Jul 07 02:15:09 Updated: python-2.7.5-18.el7_1.1.x86_64 Jul 07 02:15:09 Updated: fence-agents-common-4.0.11-13.el7_1.x86_64 Jul 07 02:15:09 Updated: = otopi-1.4.0-0.0.master.20150625083848.gite93fa23.el7.noarch Jul 07 02:15:16 Updated: glusterfs-server-3.7.2-3.el7.x86_64 Jul 07 02:15:16 Updated: vdsm-infra-4.17.0-1054.git562e711.el7.noarch Jul 07 02:15:16 Updated: vdsm-python-4.17.0-1054.git562e711.el7.noarch Jul 07 02:15:16 Updated: vdsm-xmlrpc-4.17.0-1054.git562e711.el7.noarch Jul 07 02:15:16 Updated: vdsm-cli-4.17.0-1054.git562e711.el7.noarch Jul 07 02:15:18 Updated: glusterfs-geo-replication-3.7.2-3.el7.x86_64 Jul 07 02:15:19 Updated: = ovirt-host-deploy-1.4.0-0.0.master.20150617062825.git06a8f80.el7.noarch Jul 07 02:15:19 Updated: fence-agents-ipdu-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-eps-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-apc-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-ilo-ssh-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-bladecenter-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-cisco-ucs-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-ilo2-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-apc-snmp-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-vmware-soap-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-scsi-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-eaton-snmp-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-wti-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-ibmblade-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Installed: fence-agents-compute-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-intelmodular-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-hpblade-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-ipmilan-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-rhevm-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-ifmib-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-ilo-mp-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-drac5-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-brocade-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-rsb-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-kdump-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-cisco-mds-4.0.11-13.el7_1.x86_64 Jul 07 02:15:19 Updated: fence-agents-all-4.0.11-13.el7_1.x86_64 Jul 07 02:15:46 Installed: = ovirt-vmconsole-1.0.0-0.0.master.20150616120945.gitc1fb2bd.el7.noarch Jul 07 02:15:46 Updated: sos-3.2-15.el7.centos.5.noarch Jul 07 02:15:46 Updated: = ovirt-engine-sdk-python-3.6.0.0-0.15.20150625.gitfc90daf.el7.centos.noarch Jul 07 02:15:46 Updated: mom-0.4.5-2.el7.noarch Jul 07 02:15:46 Updated: vdsm-yajsonrpc-4.17.0-1054.git562e711.el7.noarch Jul 07 02:15:46 Updated: vdsm-jsonrpc-4.17.0-1054.git562e711.el7.noarch Jul 07 02:15:47 Updated: 1:openssl-1.0.1e-42.el7.9.x86_64 Jul 07 02:15:47 Updated: kernel-tools-libs-3.10.0-229.7.2.el7.x86_64 Jul 07 02:15:47 Updated: selinux-policy-3.13.1-23.el7_1.8.noarch Jul 07 02:16:01 Updated: selinux-policy-targeted-3.13.1-23.el7_1.8.noarch Jul 07 02:16:01 Updated: vdsm-4.17.0-1054.git562e711.el7.noarch Jul 07 02:16:01 Updated: vdsm-gluster-4.17.0-1054.git562e711.el7.noarch Jul 07 02:16:01 Updated: = ovirt-hosted-engine-ha-1.3.0-0.0.master.20150615153650.20150615153645.git5f= 8c290.el7.noarch Jul 07 02:16:02 Updated: tzdata-java-2015e-1.el7.noarch Jul 07 02:16:06 Updated: = 1:java-1.7.0-openjdk-headless-1.7.0.79-2.5.5.2.el7_1.x86_64 Jul 07 02:16:06 Updated: 1:java-1.7.0-openjdk-1.7.0.79-2.5.5.2.el7_1.x86_64 Jul 07 02:16:07 Updated: = ovirt-hosted-engine-setup-1.3.0-0.0.master.20150623153111.git68138d4.el7.no= arch Jul 07 02:16:07 Updated: kernel-tools-3.10.0-229.7.2.el7.x86_64 Jul 07 02:16:07 Updated: systemd-sysv-208-20.el7_1.5.x86_64 Jul 07 02:16:07 Updated: dracut-network-033-241.el7_1.3.x86_64 Jul 07 02:16:07 Updated: nss-tools-3.19.1-3.el7_1.x86_64 Jul 07 02:16:07 Updated: dracut-config-rescue-033-241.el7_1.3.x86_64 Jul 07 02:16:07 Updated: libgudev1-208-20.el7_1.5.x86_64 Jul 07 02:16:07 Updated: mdadm-3.3.2-2.el7_1.1.x86_64 Jul 07 02:16:07 Updated: glusterfs-rdma-3.7.2-3.el7.x86_64 Jul 07 02:16:08 Updated: tzdata-2015e-1.el7.noarch Jul 07 04:23:21 Installed: libvirt-daemon-driver-lxc-1.2.8-16.el7_1.3.x86_64 Jul 07 06:06:50 Installed: strace-4.8-7.el7.x86_64 Jul 07 07:44:59 Installed: iotop-0.6-2.el7.noarch --------------060800000400050202020906 Content-Type: text/html; charset=3Dwindows-1252 Content-Transfer-Encoding: 7bit
On 08-07-2015 4:26, Francesco Romani wrote:
... AFAIR, in the patchset which is part of qemu-kvm-e=
v, a lot
of devices are disabled for security/safety/auditing reasons,
and new, stable machines are added (rhel*).

When QEMU migrates, again to another qemu or to file, among other
things it needs to freeze and serialize device state.
The format of this device state can change across versions, even though
it usually changes in forward compatible way.

So, the problem *could* be that the resuming QEMU doesn't know how
to handle some device, or cannot understand the stored format.

This is the reason why *I believe* this flow is not supported.
But of course the last word is on the QEMU(-kvm[-ev]) devs.
Any chance that other upgrades [1] (ie. device-mapper) could invalidate the state file?

Now, how can I tell Engine or VDSM to discard the state file (to not try reading the invalid state file during next startup) and recover this VM?

[1] : This is the list of updated packages:

Jul 07 00:11:31 Installed: ruby-libs-2.0.0.598-25.el7_1.x86_64
Jul 07 00:11:31 Updated: file-libs-5.11-22.el7.x86_64
Jul 07 00:11:31 Updated: file-5.11-22.el7.x86_64
Jul 07 00:11:31 Updated: 1:libguestfs-1.28.1-1.28.el7.x86_64
Jul 07 00:11:32 Updated: 1:libguestfs-tools-c-1.28.1-1.28.el7.x86_64
Jul 07 00:11:32 Installed: libyaml-0.1.4-11.el7_0.x86_64
Jul 07 00:11:32 Installed: rubygem-psych-2.0.0-25.el7_1.x86_64
Jul 07 00:11:32 Installed: rubygem-io-console-0.4.2-25.el7_1.x86_64
Jul 07 00:11:32 Installed: ruby-irb-2.0.0.598-25.el7_1.noarch
Jul 07 00:11:32 Installed: ruby-2.0.0.598-25.el7_1.x86_64
Jul 07 00:11:32 Installed: rubygem-bigdecimal-1.2.0-25.el7_1.x86_64
Jul 07 00:11:32 Installed: rubygem-json-1.7.7-25.el7_1.x86_64
Jul 07 00:11:32 Installed: rubygems-2.0.14-25.el7_1.noarch
Jul 07 00:11:32 Installed: rubygem-rdoc-4.0.0-25.el7_1.noarch
Jul 07 00:11:32 Installed: unzip-6.0-15.el7.x86_64
Jul 07 00:11:32 Installed: perl-XML-Parser-2.41-10.el7.x86_64
Jul 07 00:11:32 Installed: perl-XML-XPath-1.13-22.el7.noarch
Jul 07 00:11:32 Installed: 1:perl-Sys-Guestfs-1.28.1-1.28.el7.x86_64
Jul 07 00:11:33 Installed: 1:virt-v2v-1.28.1-1.28.el7.x86_64
Jul 07 00:11:33 Installed: 1:ruby-libguestfs-1.28.1-1.28.el7.x86_64
Jul 07 00:11:33 Installed: libguestfs-winsupport-7.1-4.el7.x86_64
Jul 07 00:11:33 Updated: python-magic-5.11-22.el7.noarch
Jul 07 02:14:57 Updated: 1:openssl-libs-1.0.1e-42.el7.9.x86_64
Jul 07 02:14:58 Updated: glusterfs-libs-3.7.2-3.el7.x86_64
Jul 07 02:14:58 Updated: glusterfs-3.7.2-3.el7.x86_64
Jul 07 02:14:58 Updated: systemd-libs-208-20.el7_1.5.x86_64
Jul 07 02:15:00 Updated: systemd-208-20.el7_1.5.x86_64
Jul 07 02:15:00 Updated: trousers-0.3.11.2-4.el7_1.x86_64
Jul 07 02:15:00 Updated: dracut-033-241.el7_1.3.x86_64
Jul 07 02:15:00 Updated: glusterfs-client-xlators-3.7.2-3.el7.x86_64
Jul 07 02:15:00 Updated: nss-util-3.19.1-1.el7_1.x86_64
Jul 07 02:15:00 Updated: glusterfs-fuse-3.7.2-3.el7.x86_64
Jul 07 02:15:00 Updated: glusterfs-api-3.7.2-3.el7.x86_64
Jul 07 02:15:00 Updated: gnutls-3.3.8-12.el7_1.1.x86_64
Jul 07 02:15:00 Updated: 7:device-mapper-libs-1.02.93-3.el7_1.1.x86_64
Jul 07 02:15:00 Updated: 7:device-mapper-1.02.93-3.el7_1.1.x86_64
Jul 07 02:15:00 Updated: 7:device-mapper-event-libs-1.02.93-3.el7_1.1.x86_64
Jul 07 02:15:00 Updated: glusterfs-cli-3.7.2-3.el7.x86_64
Jul 07 02:15:01 Updated: 7:device-mapper-event-1.02.93-3.el7_1.1.x86_64
Jul 07 02:15:01 Updated: 7:lvm2-libs-2.02.115-3.el7_1.1.x86_64
Jul 07 02:15:01 Updated: 7:lvm2-2.02.115-3.el7_1.1.x86_64
Jul 07 02:15:01 Updated: gnutls-dane-3.3.8-12.el7_1.1.x86_64
Jul 07 02:15:01 Updated: gnutls-utils-3.3.8-12.el7_1.1.x86_64
Jul 07 02:15:01 Updated: nss-3.19.1-3.el7_1.x86_64
Jul 07 02:15:01 Updated: nss-sysinit-3.19.1-3.el7_1.x86_64
Jul 07 02:15:07 Installed: kernel-3.10.0-229.7.2.el7.x86_64
Jul 07 02:15:07 Updated: iputils-20121221-6.el7_1.1.x86_64
Jul 07 02:15:07 Updated: ntpdate-4.2.6p5-19.el7.centos.1.x86_64
Jul 07 02:15:07 Updated: ntp-4.2.6p5-19.el7.centos.1.x86_64
Jul 07 02:15:09 Updated: python-libs-2.7.5-18.el7_1.1.x86_64
Jul 07 02:15:09 Updated: python-2.7.5-18.el7_1.1.x86_64
Jul 07 02:15:09 Updated: fence-agents-common-4.0.11-13.el7_1.x86_64
Jul 07 02:15:09 Updated: otopi-1.4.0-0.0.master.20150625083848.gite93fa23.el7.noarch
Jul 07 02:15:16 Updated: glusterfs-server-3.7.2-3.el7.x86_64
Jul 07 02:15:16 Updated: vdsm-infra-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:15:16 Updated: vdsm-python-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:15:16 Updated: vdsm-xmlrpc-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:15:16 Updated: vdsm-cli-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:15:18 Updated: glusterfs-geo-replication-3.7.2-3.el7.x86_64
Jul 07 02:15:19 Updated: ovirt-host-deploy-1.4.0-0.0.master.20150617062825.git06a8f80.el7.noarch=
Jul 07 02:15:19 Updated: fence-agents-ipdu-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-eps-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-apc-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-ilo-ssh-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-bladecenter-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-cisco-ucs-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-ilo2-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-apc-snmp-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-vmware-soap-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-scsi-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-eaton-snmp-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-wti-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-ibmblade-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Installed: fence-agents-compute-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-intelmodular-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-hpblade-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-ipmilan-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-rhevm-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-ifmib-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-ilo-mp-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-drac5-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-brocade-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-rsb-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-kdump-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-cisco-mds-4.0.11-13.el7_1.x86_64
Jul 07 02:15:19 Updated: fence-agents-all-4.0.11-13.el7_1.x86_64
Jul 07 02:15:46 Installed: ovirt-vmconsole-1.0.0-0.0.master.20150616120945.gitc1fb2bd.el7.noarch Jul 07 02:15:46 Updated: sos-3.2-15.el7.centos.5.noarch
Jul 07 02:15:46 Updated: ovirt-engine-sdk-python-3.6.0.0-0.15.20150625.gitfc90daf.el7.centos.noarch<= br> Jul 07 02:15:46 Updated: mom-0.4.5-2.el7.noarch
Jul 07 02:15:46 Updated: vdsm-yajsonrpc-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:15:46 Updated: vdsm-jsonrpc-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:15:47 Updated: 1:openssl-1.0.1e-42.el7.9.x86_64
Jul 07 02:15:47 Updated: kernel-tools-libs-3.10.0-229.7.2.el7.x86_64
Jul 07 02:15:47 Updated: selinux-policy-3.13.1-23.el7_1.8.noarch
Jul 07 02:16:01 Updated: selinux-policy-targeted-3.13.1-23.el7_1.8.noarch
Jul 07 02:16:01 Updated: vdsm-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:16:01 Updated: vdsm-gluster-4.17.0-1054.git562e711.el7.noarch
Jul 07 02:16:01 Updated: ovirt-hosted-engine-ha-1.3.0-0.0.master.20150615153650.20150615153645.git5f= 8c290.el7.noarch
Jul 07 02:16:02 Updated: tzdata-java-2015e-1.el7.noarch
Jul 07 02:16:06 Updated: 1:java-1.7.0-openjdk-headless-1.7.0.79-2.5.5.2.el7_1.x86_64
Jul 07 02:16:06 Updated: 1:java-1.7.0-openjdk-1.7.0.79-2.5.5.2.el7_1.x86_64
Jul 07 02:16:07 Updated: ovirt-hosted-engine-setup-1.3.0-0.0.master.20150623153111.git68138d4.el7.no= arch
Jul 07 02:16:07 Updated: kernel-tools-3.10.0-229.7.2.el7.x86_64
Jul 07 02:16:07 Updated: systemd-sysv-208-20.el7_1.5.x86_64
Jul 07 02:16:07 Updated: dracut-network-033-241.el7_1.3.x86_64
Jul 07 02:16:07 Updated: nss-tools-3.19.1-3.el7_1.x86_64
Jul 07 02:16:07 Updated: dracut-config-rescue-033-241.el7_1.3.x86_64
Jul 07 02:16:07 Updated: libgudev1-208-20.el7_1.5.x86_64
Jul 07 02:16:07 Updated: mdadm-3.3.2-2.el7_1.1.x86_64
Jul 07 02:16:07 Updated: glusterfs-rdma-3.7.2-3.el7.x86_64
Jul 07 02:16:08 Updated: tzdata-2015e-1.el7.noarch
Jul 07 04:23:21 Installed: libvirt-daemon-driver-lxc-1.2.8-16.el7_1.3.x86_64
Jul 07 06:06:50 Installed: strace-4.8-7.el7.x86_64
Jul 07 07:44:59 Installed: iotop-0.6-2.el7.noarch

--------------060800000400050202020906-- --===============3590645473051735060== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNjA4MDAwMDA0MDAwNTAyMDIwMjA5MDYKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PXdpbmRvd3MtMTI1MjsgZm9ybWF0PWZsb3dlZApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiA3Yml0CgoKT24gMDgtMDctMjAxNSA0OjI2LCBGcmFuY2VzY28gUm9tYW5pIHdyb3RlOgo+IC4u LiBBRkFJUiwgaW4gdGhlIHBhdGNoc2V0IHdoaWNoIGlzIHBhcnQgb2YgcWVtdS1rdm0tZXYsIGEg bG90Cj4gb2YgZGV2aWNlcyBhcmUgZGlzYWJsZWQgZm9yIHNlY3VyaXR5L3NhZmV0eS9hdWRpdGlu ZyByZWFzb25zLAo+IGFuZCBuZXcsIHN0YWJsZSBtYWNoaW5lcyBhcmUgYWRkZWQgKHJoZWwqKS4K Pgo+IFdoZW4gUUVNVSBtaWdyYXRlcywgYWdhaW4gdG8gYW5vdGhlciBxZW11IG9yIHRvIGZpbGUs IGFtb25nIG90aGVyCj4gdGhpbmdzIGl0IG5lZWRzIHRvIGZyZWV6ZSBhbmQgc2VyaWFsaXplIGRl dmljZSBzdGF0ZS4KPiBUaGUgZm9ybWF0IG9mIHRoaXMgZGV2aWNlIHN0YXRlIGNhbiBjaGFuZ2Ug YWNyb3NzIHZlcnNpb25zLCBldmVuIHRob3VnaAo+IGl0IHVzdWFsbHkgY2hhbmdlcyBpbiBmb3J3 YXJkIGNvbXBhdGlibGUgd2F5Lgo+Cj4gU28sIHRoZSBwcm9ibGVtICpjb3VsZCogYmUgdGhhdCB0 aGUgcmVzdW1pbmcgUUVNVSBkb2Vzbid0IGtub3cgaG93Cj4gdG8gaGFuZGxlIHNvbWUgZGV2aWNl LCBvciBjYW5ub3QgdW5kZXJzdGFuZCB0aGUgc3RvcmVkIGZvcm1hdC4KPgo+IFRoaXMgaXMgdGhl IHJlYXNvbiB3aHkgKkkgYmVsaWV2ZSogdGhpcyBmbG93IGlzIG5vdCBzdXBwb3J0ZWQuCj4gQnV0 IG9mIGNvdXJzZSB0aGUgbGFzdCB3b3JkIGlzIG9uIHRoZSBRRU1VKC1rdm1bLWV2XSkgZGV2cy4K Pgo+CkFueSBjaGFuY2UgdGhhdCBvdGhlciB1cGdyYWRlcyBbMV0gKGllLiBkZXZpY2UtbWFwcGVy KSBjb3VsZCBpbnZhbGlkYXRlIAp0aGUgc3RhdGUgZmlsZT8KCk5vdywgaG93IGNhbiBJIHRlbGwg RW5naW5lIG9yIFZEU00gdG8gZGlzY2FyZCB0aGUgc3RhdGUgZmlsZSAodG8gbm90IHRyeSAKcmVh ZGluZyB0aGUgaW52YWxpZCBzdGF0ZSBmaWxlIGR1cmluZyBuZXh0IHN0YXJ0dXApIGFuZCByZWNv dmVyIHRoaXMgVk0/CgpbMV0gOiBUaGlzIGlzIHRoZSBsaXN0IG9mIHVwZGF0ZWQgcGFja2FnZXM6 CgpKdWwgMDcgMDA6MTE6MzEgSW5zdGFsbGVkOiBydWJ5LWxpYnMtMi4wLjAuNTk4LTI1LmVsN18x Lng4Nl82NApKdWwgMDcgMDA6MTE6MzEgVXBkYXRlZDogZmlsZS1saWJzLTUuMTEtMjIuZWw3Lng4 Nl82NApKdWwgMDcgMDA6MTE6MzEgVXBkYXRlZDogZmlsZS01LjExLTIyLmVsNy54ODZfNjQKSnVs IDA3IDAwOjExOjMxIFVwZGF0ZWQ6IDE6bGliZ3Vlc3Rmcy0xLjI4LjEtMS4yOC5lbDcueDg2XzY0 Ckp1bCAwNyAwMDoxMTozMiBVcGRhdGVkOiAxOmxpYmd1ZXN0ZnMtdG9vbHMtYy0xLjI4LjEtMS4y OC5lbDcueDg2XzY0Ckp1bCAwNyAwMDoxMTozMiBJbnN0YWxsZWQ6IGxpYnlhbWwtMC4xLjQtMTEu ZWw3XzAueDg2XzY0Ckp1bCAwNyAwMDoxMTozMiBJbnN0YWxsZWQ6IHJ1YnlnZW0tcHN5Y2gtMi4w LjAtMjUuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMDoxMTozMiBJbnN0YWxsZWQ6IHJ1YnlnZW0taW8t Y29uc29sZS0wLjQuMi0yNS5lbDdfMS54ODZfNjQKSnVsIDA3IDAwOjExOjMyIEluc3RhbGxlZDog cnVieS1pcmItMi4wLjAuNTk4LTI1LmVsN18xLm5vYXJjaApKdWwgMDcgMDA6MTE6MzIgSW5zdGFs bGVkOiBydWJ5LTIuMC4wLjU5OC0yNS5lbDdfMS54ODZfNjQKSnVsIDA3IDAwOjExOjMyIEluc3Rh bGxlZDogcnVieWdlbS1iaWdkZWNpbWFsLTEuMi4wLTI1LmVsN18xLng4Nl82NApKdWwgMDcgMDA6 MTE6MzIgSW5zdGFsbGVkOiBydWJ5Z2VtLWpzb24tMS43LjctMjUuZWw3XzEueDg2XzY0Ckp1bCAw NyAwMDoxMTozMiBJbnN0YWxsZWQ6IHJ1YnlnZW1zLTIuMC4xNC0yNS5lbDdfMS5ub2FyY2gKSnVs IDA3IDAwOjExOjMyIEluc3RhbGxlZDogcnVieWdlbS1yZG9jLTQuMC4wLTI1LmVsN18xLm5vYXJj aApKdWwgMDcgMDA6MTE6MzIgSW5zdGFsbGVkOiB1bnppcC02LjAtMTUuZWw3Lng4Nl82NApKdWwg MDcgMDA6MTE6MzIgSW5zdGFsbGVkOiBwZXJsLVhNTC1QYXJzZXItMi40MS0xMC5lbDcueDg2XzY0 Ckp1bCAwNyAwMDoxMTozMiBJbnN0YWxsZWQ6IHBlcmwtWE1MLVhQYXRoLTEuMTMtMjIuZWw3Lm5v YXJjaApKdWwgMDcgMDA6MTE6MzIgSW5zdGFsbGVkOiAxOnBlcmwtU3lzLUd1ZXN0ZnMtMS4yOC4x LTEuMjguZWw3Lng4Nl82NApKdWwgMDcgMDA6MTE6MzMgSW5zdGFsbGVkOiAxOnZpcnQtdjJ2LTEu MjguMS0xLjI4LmVsNy54ODZfNjQKSnVsIDA3IDAwOjExOjMzIEluc3RhbGxlZDogMTpydWJ5LWxp Ymd1ZXN0ZnMtMS4yOC4xLTEuMjguZWw3Lng4Nl82NApKdWwgMDcgMDA6MTE6MzMgSW5zdGFsbGVk OiBsaWJndWVzdGZzLXdpbnN1cHBvcnQtNy4xLTQuZWw3Lng4Nl82NApKdWwgMDcgMDA6MTE6MzMg VXBkYXRlZDogcHl0aG9uLW1hZ2ljLTUuMTEtMjIuZWw3Lm5vYXJjaApKdWwgMDcgMDI6MTQ6NTcg VXBkYXRlZDogMTpvcGVuc3NsLWxpYnMtMS4wLjFlLTQyLmVsNy45Lng4Nl82NApKdWwgMDcgMDI6 MTQ6NTggVXBkYXRlZDogZ2x1c3RlcmZzLWxpYnMtMy43LjItMy5lbDcueDg2XzY0Ckp1bCAwNyAw MjoxNDo1OCBVcGRhdGVkOiBnbHVzdGVyZnMtMy43LjItMy5lbDcueDg2XzY0Ckp1bCAwNyAwMjox NDo1OCBVcGRhdGVkOiBzeXN0ZW1kLWxpYnMtMjA4LTIwLmVsN18xLjUueDg2XzY0Ckp1bCAwNyAw MjoxNTowMCBVcGRhdGVkOiBzeXN0ZW1kLTIwOC0yMC5lbDdfMS41Lng4Nl82NApKdWwgMDcgMDI6 MTU6MDAgVXBkYXRlZDogdHJvdXNlcnMtMC4zLjExLjItNC5lbDdfMS54ODZfNjQKSnVsIDA3IDAy OjE1OjAwIFVwZGF0ZWQ6IGRyYWN1dC0wMzMtMjQxLmVsN18xLjMueDg2XzY0Ckp1bCAwNyAwMjox NTowMCBVcGRhdGVkOiBnbHVzdGVyZnMtY2xpZW50LXhsYXRvcnMtMy43LjItMy5lbDcueDg2XzY0 Ckp1bCAwNyAwMjoxNTowMCBVcGRhdGVkOiBuc3MtdXRpbC0zLjE5LjEtMS5lbDdfMS54ODZfNjQK SnVsIDA3IDAyOjE1OjAwIFVwZGF0ZWQ6IGdsdXN0ZXJmcy1mdXNlLTMuNy4yLTMuZWw3Lng4Nl82 NApKdWwgMDcgMDI6MTU6MDAgVXBkYXRlZDogZ2x1c3RlcmZzLWFwaS0zLjcuMi0zLmVsNy54ODZf NjQKSnVsIDA3IDAyOjE1OjAwIFVwZGF0ZWQ6IGdudXRscy0zLjMuOC0xMi5lbDdfMS4xLng4Nl82 NApKdWwgMDcgMDI6MTU6MDAgVXBkYXRlZDogNzpkZXZpY2UtbWFwcGVyLWxpYnMtMS4wMi45My0z LmVsN18xLjEueDg2XzY0Ckp1bCAwNyAwMjoxNTowMCBVcGRhdGVkOiA3OmRldmljZS1tYXBwZXIt MS4wMi45My0zLmVsN18xLjEueDg2XzY0Ckp1bCAwNyAwMjoxNTowMCBVcGRhdGVkOiA3OmRldmlj ZS1tYXBwZXItZXZlbnQtbGlicy0xLjAyLjkzLTMuZWw3XzEuMS54ODZfNjQKSnVsIDA3IDAyOjE1 OjAwIFVwZGF0ZWQ6IGdsdXN0ZXJmcy1jbGktMy43LjItMy5lbDcueDg2XzY0Ckp1bCAwNyAwMjox NTowMSBVcGRhdGVkOiA3OmRldmljZS1tYXBwZXItZXZlbnQtMS4wMi45My0zLmVsN18xLjEueDg2 XzY0Ckp1bCAwNyAwMjoxNTowMSBVcGRhdGVkOiA3Omx2bTItbGlicy0yLjAyLjExNS0zLmVsN18x LjEueDg2XzY0Ckp1bCAwNyAwMjoxNTowMSBVcGRhdGVkOiA3Omx2bTItMi4wMi4xMTUtMy5lbDdf MS4xLng4Nl82NApKdWwgMDcgMDI6MTU6MDEgVXBkYXRlZDogZ251dGxzLWRhbmUtMy4zLjgtMTIu ZWw3XzEuMS54ODZfNjQKSnVsIDA3IDAyOjE1OjAxIFVwZGF0ZWQ6IGdudXRscy11dGlscy0zLjMu OC0xMi5lbDdfMS4xLng4Nl82NApKdWwgMDcgMDI6MTU6MDEgVXBkYXRlZDogbnNzLTMuMTkuMS0z LmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6MDEgVXBkYXRlZDogbnNzLXN5c2luaXQtMy4xOS4x LTMuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNTowNyBJbnN0YWxsZWQ6IGtlcm5lbC0zLjEwLjAt MjI5LjcuMi5lbDcueDg2XzY0Ckp1bCAwNyAwMjoxNTowNyBVcGRhdGVkOiBpcHV0aWxzLTIwMTIx MjIxLTYuZWw3XzEuMS54ODZfNjQKSnVsIDA3IDAyOjE1OjA3IFVwZGF0ZWQ6IG50cGRhdGUtNC4y LjZwNS0xOS5lbDcuY2VudG9zLjEueDg2XzY0Ckp1bCAwNyAwMjoxNTowNyBVcGRhdGVkOiBudHAt NC4yLjZwNS0xOS5lbDcuY2VudG9zLjEueDg2XzY0Ckp1bCAwNyAwMjoxNTowOSBVcGRhdGVkOiBw eXRob24tbGlicy0yLjcuNS0xOC5lbDdfMS4xLng4Nl82NApKdWwgMDcgMDI6MTU6MDkgVXBkYXRl ZDogcHl0aG9uLTIuNy41LTE4LmVsN18xLjEueDg2XzY0Ckp1bCAwNyAwMjoxNTowOSBVcGRhdGVk OiBmZW5jZS1hZ2VudHMtY29tbW9uLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE1 OjA5IFVwZGF0ZWQ6IApvdG9waS0xLjQuMC0wLjAubWFzdGVyLjIwMTUwNjI1MDgzODQ4LmdpdGU5 M2ZhMjMuZWw3Lm5vYXJjaApKdWwgMDcgMDI6MTU6MTYgVXBkYXRlZDogZ2x1c3RlcmZzLXNlcnZl ci0zLjcuMi0zLmVsNy54ODZfNjQKSnVsIDA3IDAyOjE1OjE2IFVwZGF0ZWQ6IHZkc20taW5mcmEt NC4xNy4wLTEwNTQuZ2l0NTYyZTcxMS5lbDcubm9hcmNoCkp1bCAwNyAwMjoxNToxNiBVcGRhdGVk OiB2ZHNtLXB5dGhvbi00LjE3LjAtMTA1NC5naXQ1NjJlNzExLmVsNy5ub2FyY2gKSnVsIDA3IDAy OjE1OjE2IFVwZGF0ZWQ6IHZkc20teG1scnBjLTQuMTcuMC0xMDU0LmdpdDU2MmU3MTEuZWw3Lm5v YXJjaApKdWwgMDcgMDI6MTU6MTYgVXBkYXRlZDogdmRzbS1jbGktNC4xNy4wLTEwNTQuZ2l0NTYy ZTcxMS5lbDcubm9hcmNoCkp1bCAwNyAwMjoxNToxOCBVcGRhdGVkOiBnbHVzdGVyZnMtZ2VvLXJl cGxpY2F0aW9uLTMuNy4yLTMuZWw3Lng4Nl82NApKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDogCm92 aXJ0LWhvc3QtZGVwbG95LTEuNC4wLTAuMC5tYXN0ZXIuMjAxNTA2MTcwNjI4MjUuZ2l0MDZhOGY4 MC5lbDcubm9hcmNoCkp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtaXBkdS00 LjAuMTEtMTMuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2Vu dHMtZXBzLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZl bmNlLWFnZW50cy1hcGMtNC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6MTkgVXBk YXRlZDogZmVuY2UtYWdlbnRzLWlsby1zc2gtNC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcg MDI6MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdlbnRzLWJsYWRlY2VudGVyLTQuMC4xMS0xMy5lbDdf MS54ODZfNjQKSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy1jaXNjby11Y3Mt NC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdl bnRzLWlsbzItNC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDog ZmVuY2UtYWdlbnRzLWFwYy1zbm1wLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE1 OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy12bXdhcmUtc29hcC00LjAuMTEtMTMuZWw3XzEueDg2 XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtc2NzaS00LjAuMTEtMTMu ZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtZWF0b24t c25tcC00LjAuMTEtMTMuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5j ZS1hZ2VudHMtd3RpLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE1OjE5IFVwZGF0 ZWQ6IGZlbmNlLWFnZW50cy1pYm1ibGFkZS00LjAuMTEtMTMuZWw3XzEueDg2XzY0Ckp1bCAwNyAw MjoxNToxOSBJbnN0YWxsZWQ6IGZlbmNlLWFnZW50cy1jb21wdXRlLTQuMC4xMS0xMy5lbDdfMS54 ODZfNjQKSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy1pbnRlbG1vZHVsYXIt NC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdl bnRzLWhwYmxhZGUtNC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6MTkgVXBkYXRl ZDogZmVuY2UtYWdlbnRzLWlwbWlsYW4tNC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6 MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdlbnRzLXJoZXZtLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQK SnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy1pZm1pYi00LjAuMTEtMTMuZWw3 XzEueDg2XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtaWxvLW1wLTQu MC4xMS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50 cy1kcmFjNS00LjAuMTEtMTMuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBm ZW5jZS1hZ2VudHMtYnJvY2FkZS00LjAuMTEtMTMuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNTox OSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtcnNiLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3 IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy1rZHVtcC00LjAuMTEtMTMuZWw3XzEueDg2 XzY0Ckp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtY2lzY28tbWRzLTQuMC4x MS0xMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy1h bGwtNC4wLjExLTEzLmVsN18xLng4Nl82NApKdWwgMDcgMDI6MTU6NDYgSW5zdGFsbGVkOiAKb3Zp cnQtdm1jb25zb2xlLTEuMC4wLTAuMC5tYXN0ZXIuMjAxNTA2MTYxMjA5NDUuZ2l0YzFmYjJiZC5l bDcubm9hcmNoCkp1bCAwNyAwMjoxNTo0NiBVcGRhdGVkOiBzb3MtMy4yLTE1LmVsNy5jZW50b3Mu NS5ub2FyY2gKSnVsIDA3IDAyOjE1OjQ2IFVwZGF0ZWQ6IApvdmlydC1lbmdpbmUtc2RrLXB5dGhv bi0zLjYuMC4wLTAuMTUuMjAxNTA2MjUuZ2l0ZmM5MGRhZi5lbDcuY2VudG9zLm5vYXJjaApKdWwg MDcgMDI6MTU6NDYgVXBkYXRlZDogbW9tLTAuNC41LTIuZWw3Lm5vYXJjaApKdWwgMDcgMDI6MTU6 NDYgVXBkYXRlZDogdmRzbS15YWpzb25ycGMtNC4xNy4wLTEwNTQuZ2l0NTYyZTcxMS5lbDcubm9h cmNoCkp1bCAwNyAwMjoxNTo0NiBVcGRhdGVkOiB2ZHNtLWpzb25ycGMtNC4xNy4wLTEwNTQuZ2l0 NTYyZTcxMS5lbDcubm9hcmNoCkp1bCAwNyAwMjoxNTo0NyBVcGRhdGVkOiAxOm9wZW5zc2wtMS4w LjFlLTQyLmVsNy45Lng4Nl82NApKdWwgMDcgMDI6MTU6NDcgVXBkYXRlZDoga2VybmVsLXRvb2xz LWxpYnMtMy4xMC4wLTIyOS43LjIuZWw3Lng4Nl82NApKdWwgMDcgMDI6MTU6NDcgVXBkYXRlZDog c2VsaW51eC1wb2xpY3ktMy4xMy4xLTIzLmVsN18xLjgubm9hcmNoCkp1bCAwNyAwMjoxNjowMSBV cGRhdGVkOiBzZWxpbnV4LXBvbGljeS10YXJnZXRlZC0zLjEzLjEtMjMuZWw3XzEuOC5ub2FyY2gK SnVsIDA3IDAyOjE2OjAxIFVwZGF0ZWQ6IHZkc20tNC4xNy4wLTEwNTQuZ2l0NTYyZTcxMS5lbDcu bm9hcmNoCkp1bCAwNyAwMjoxNjowMSBVcGRhdGVkOiB2ZHNtLWdsdXN0ZXItNC4xNy4wLTEwNTQu Z2l0NTYyZTcxMS5lbDcubm9hcmNoCkp1bCAwNyAwMjoxNjowMSBVcGRhdGVkOiAKb3ZpcnQtaG9z dGVkLWVuZ2luZS1oYS0xLjMuMC0wLjAubWFzdGVyLjIwMTUwNjE1MTUzNjUwLjIwMTUwNjE1MTUz NjQ1LmdpdDVmOGMyOTAuZWw3Lm5vYXJjaApKdWwgMDcgMDI6MTY6MDIgVXBkYXRlZDogdHpkYXRh LWphdmEtMjAxNWUtMS5lbDcubm9hcmNoCkp1bCAwNyAwMjoxNjowNiBVcGRhdGVkOiAKMTpqYXZh LTEuNy4wLW9wZW5qZGstaGVhZGxlc3MtMS43LjAuNzktMi41LjUuMi5lbDdfMS54ODZfNjQKSnVs IDA3IDAyOjE2OjA2IFVwZGF0ZWQ6IDE6amF2YS0xLjcuMC1vcGVuamRrLTEuNy4wLjc5LTIuNS41 LjIuZWw3XzEueDg2XzY0Ckp1bCAwNyAwMjoxNjowNyBVcGRhdGVkOiAKb3ZpcnQtaG9zdGVkLWVu Z2luZS1zZXR1cC0xLjMuMC0wLjAubWFzdGVyLjIwMTUwNjIzMTUzMTExLmdpdDY4MTM4ZDQuZWw3 Lm5vYXJjaApKdWwgMDcgMDI6MTY6MDcgVXBkYXRlZDoga2VybmVsLXRvb2xzLTMuMTAuMC0yMjku Ny4yLmVsNy54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6IHN5c3RlbWQtc3lzdi0yMDgt MjAuZWw3XzEuNS54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6IGRyYWN1dC1uZXR3b3Jr LTAzMy0yNDEuZWw3XzEuMy54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6IG5zcy10b29s cy0zLjE5LjEtMy5lbDdfMS54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6IGRyYWN1dC1j b25maWctcmVzY3VlLTAzMy0yNDEuZWw3XzEuMy54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0 ZWQ6IGxpYmd1ZGV2MS0yMDgtMjAuZWw3XzEuNS54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0 ZWQ6IG1kYWRtLTMuMy4yLTIuZWw3XzEuMS54ODZfNjQKSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6 IGdsdXN0ZXJmcy1yZG1hLTMuNy4yLTMuZWw3Lng4Nl82NApKdWwgMDcgMDI6MTY6MDggVXBkYXRl ZDogdHpkYXRhLTIwMTVlLTEuZWw3Lm5vYXJjaApKdWwgMDcgMDQ6MjM6MjEgSW5zdGFsbGVkOiBs aWJ2aXJ0LWRhZW1vbi1kcml2ZXItbHhjLTEuMi44LTE2LmVsN18xLjMueDg2XzY0Ckp1bCAwNyAw NjowNjo1MCBJbnN0YWxsZWQ6IHN0cmFjZS00LjgtNy5lbDcueDg2XzY0Ckp1bCAwNyAwNzo0NDo1 OSBJbnN0YWxsZWQ6IGlvdG9wLTAuNi0yLmVsNy5ub2FyY2gKCgotLS0tLS0tLS0tLS0tLTA2MDgw MDAwMDQwMDA1MDIwMjAyMDkwNgpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD13aW5k b3dzLTEyNTIKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoKPGh0bWw+CiAgPGhlYWQ+ CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIgogICAg ICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIj RkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4KICAgIDxicj4KICAgIDxkaXYgY2xhc3M9Im1vei1zaWdu YXR1cmUiPgogICAgICA8c3R5bGU+Ci5zaWduYXR1cmUsIC5zbWFsbC1zaWduYXR1cmUgewoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tZmFyZWFzdC1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjsKCWNvbG9yOiM3RjdGN0Y7Cn0KCi5zaWduYXR1cmUgewoJZm9udC1z aXplOjEwcHQ7Cn0KCi5zbWFsbC1zaWduYXR1cmUgewoJZm9udC1zaXplOjhwdDsKfTwvc3R5bGU+ PC9kaXY+CiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDA4LTA3LTIwMTUgNDoy NiwgRnJhbmNlc2NvIFJvbWFuaQogICAgICB3cm90ZTo8YnI+CiAgICA8L2Rpdj4KICAgIDxibG9j a3F1b3RlCiAgICAgIGNpdGU9Im1pZDoxMDI3Njk1MDI1LjI0NzQ2MTkyLjE0MzYzNDAzODQzNDIu SmF2YU1haWwuemltYnJhQHJlZGhhdC5jb20iCiAgICAgIHR5cGU9ImNpdGUiPgogICAgICA8cHJl IHdyYXA9IiI+Li4uIEFGQUlSLCBpbiB0aGUgcGF0Y2hzZXQgd2hpY2ggaXMgcGFydCBvZiBxZW11 LWt2bS1ldiwgYSBsb3QKb2YgZGV2aWNlcyBhcmUgZGlzYWJsZWQgZm9yIHNlY3VyaXR5L3NhZmV0 eS9hdWRpdGluZyByZWFzb25zLAphbmQgbmV3LCBzdGFibGUgbWFjaGluZXMgYXJlIGFkZGVkIChy aGVsKikuCgpXaGVuIFFFTVUgbWlncmF0ZXMsIGFnYWluIHRvIGFub3RoZXIgcWVtdSBvciB0byBm aWxlLCBhbW9uZyBvdGhlcgp0aGluZ3MgaXQgbmVlZHMgdG8gZnJlZXplIGFuZCBzZXJpYWxpemUg ZGV2aWNlIHN0YXRlLgpUaGUgZm9ybWF0IG9mIHRoaXMgZGV2aWNlIHN0YXRlIGNhbiBjaGFuZ2Ug YWNyb3NzIHZlcnNpb25zLCBldmVuIHRob3VnaAppdCB1c3VhbGx5IGNoYW5nZXMgaW4gZm9yd2Fy ZCBjb21wYXRpYmxlIHdheS4KClNvLCB0aGUgcHJvYmxlbSAqY291bGQqIGJlIHRoYXQgdGhlIHJl c3VtaW5nIFFFTVUgZG9lc24ndCBrbm93IGhvdwp0byBoYW5kbGUgc29tZSBkZXZpY2UsIG9yIGNh bm5vdCB1bmRlcnN0YW5kIHRoZSBzdG9yZWQgZm9ybWF0LgoKVGhpcyBpcyB0aGUgcmVhc29uIHdo eSAqSSBiZWxpZXZlKiB0aGlzIGZsb3cgaXMgbm90IHN1cHBvcnRlZC4KQnV0IG9mIGNvdXJzZSB0 aGUgbGFzdCB3b3JkIGlzIG9uIHRoZSBRRU1VKC1rdm1bLWV2XSkgZGV2cy4KCgo8L3ByZT4KICAg IDwvYmxvY2txdW90ZT4KICAgIEFueSBjaGFuY2UgdGhhdCBvdGhlciB1cGdyYWRlcyBbMV0gKGll LiBkZXZpY2UtbWFwcGVyKSBjb3VsZAogICAgaW52YWxpZGF0ZSB0aGUgc3RhdGUgZmlsZT88YnI+ CiAgICA8YnI+CiAgICBOb3csIGhvdyBjYW4gSSB0ZWxsIEVuZ2luZSBvciBWRFNNIHRvIGRpc2Nh cmQgdGhlIHN0YXRlIGZpbGUgKHRvIG5vdAogICAgdHJ5IHJlYWRpbmcgdGhlIGludmFsaWQgc3Rh dGUgZmlsZSBkdXJpbmcgbmV4dCBzdGFydHVwKSBhbmQgcmVjb3ZlcgogICAgdGhpcyBWTT88YnI+ CiAgICA8YnI+CiAgICBbMV0gOiBUaGlzIGlzIHRoZSBsaXN0IG9mIHVwZGF0ZWQgcGFja2FnZXM6 PGJyPgogICAgPGJyPgogICAgSnVsIDA3IDAwOjExOjMxIEluc3RhbGxlZDogcnVieS1saWJzLTIu MC4wLjU5OC0yNS5lbDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDA6MTE6MzEgVXBkYXRlZDog ZmlsZS1saWJzLTUuMTEtMjIuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMDoxMTozMSBVcGRh dGVkOiBmaWxlLTUuMTEtMjIuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMDoxMTozMSBVcGRh dGVkOiAxOmxpYmd1ZXN0ZnMtMS4yOC4xLTEuMjguZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAw MDoxMTozMiBVcGRhdGVkOiAxOmxpYmd1ZXN0ZnMtdG9vbHMtYy0xLjI4LjEtMS4yOC5lbDcueDg2 XzY0PGJyPgogICAgSnVsIDA3IDAwOjExOjMyIEluc3RhbGxlZDogbGlieWFtbC0wLjEuNC0xMS5l bDdfMC54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDA6MTE6MzIgSW5zdGFsbGVkOiBydWJ5Z2VtLXBz eWNoLTIuMC4wLTI1LmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMDoxMTozMiBJbnN0YWxs ZWQ6IHJ1YnlnZW0taW8tY29uc29sZS0wLjQuMi0yNS5lbDdfMS54ODZfNjQ8YnI+CiAgICBKdWwg MDcgMDA6MTE6MzIgSW5zdGFsbGVkOiBydWJ5LWlyYi0yLjAuMC41OTgtMjUuZWw3XzEubm9hcmNo PGJyPgogICAgSnVsIDA3IDAwOjExOjMyIEluc3RhbGxlZDogcnVieS0yLjAuMC41OTgtMjUuZWw3 XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAwOjExOjMyIEluc3RhbGxlZDogcnVieWdlbS1iaWdk ZWNpbWFsLTEuMi4wLTI1LmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMDoxMTozMiBJbnN0 YWxsZWQ6IHJ1YnlnZW0tanNvbi0xLjcuNy0yNS5lbDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcg MDA6MTE6MzIgSW5zdGFsbGVkOiBydWJ5Z2Vtcy0yLjAuMTQtMjUuZWw3XzEubm9hcmNoPGJyPgog ICAgSnVsIDA3IDAwOjExOjMyIEluc3RhbGxlZDogcnVieWdlbS1yZG9jLTQuMC4wLTI1LmVsN18x Lm5vYXJjaDxicj4KICAgIEp1bCAwNyAwMDoxMTozMiBJbnN0YWxsZWQ6IHVuemlwLTYuMC0xNS5l bDcueDg2XzY0PGJyPgogICAgSnVsIDA3IDAwOjExOjMyIEluc3RhbGxlZDogcGVybC1YTUwtUGFy c2VyLTIuNDEtMTAuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMDoxMTozMiBJbnN0YWxsZWQ6 IHBlcmwtWE1MLVhQYXRoLTEuMTMtMjIuZWw3Lm5vYXJjaDxicj4KICAgIEp1bCAwNyAwMDoxMToz MiBJbnN0YWxsZWQ6IDE6cGVybC1TeXMtR3Vlc3Rmcy0xLjI4LjEtMS4yOC5lbDcueDg2XzY0PGJy PgogICAgSnVsIDA3IDAwOjExOjMzIEluc3RhbGxlZDogMTp2aXJ0LXYydi0xLjI4LjEtMS4yOC5l bDcueDg2XzY0PGJyPgogICAgSnVsIDA3IDAwOjExOjMzIEluc3RhbGxlZDogMTpydWJ5LWxpYmd1 ZXN0ZnMtMS4yOC4xLTEuMjguZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMDoxMTozMyBJbnN0 YWxsZWQ6IGxpYmd1ZXN0ZnMtd2luc3VwcG9ydC03LjEtNC5lbDcueDg2XzY0PGJyPgogICAgSnVs IDA3IDAwOjExOjMzIFVwZGF0ZWQ6IHB5dGhvbi1tYWdpYy01LjExLTIyLmVsNy5ub2FyY2g8YnI+ CiAgICBKdWwgMDcgMDI6MTQ6NTcgVXBkYXRlZDogMTpvcGVuc3NsLWxpYnMtMS4wLjFlLTQyLmVs Ny45Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNDo1OCBVcGRhdGVkOiBnbHVzdGVyZnMtbGli cy0zLjcuMi0zLmVsNy54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTQ6NTggVXBkYXRlZDogZ2x1 c3RlcmZzLTMuNy4yLTMuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNDo1OCBVcGRhdGVk OiBzeXN0ZW1kLWxpYnMtMjA4LTIwLmVsN18xLjUueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1 OjAwIFVwZGF0ZWQ6IHN5c3RlbWQtMjA4LTIwLmVsN18xLjUueDg2XzY0PGJyPgogICAgSnVsIDA3 IDAyOjE1OjAwIFVwZGF0ZWQ6IHRyb3VzZXJzLTAuMy4xMS4yLTQuZWw3XzEueDg2XzY0PGJyPgog ICAgSnVsIDA3IDAyOjE1OjAwIFVwZGF0ZWQ6IGRyYWN1dC0wMzMtMjQxLmVsN18xLjMueDg2XzY0 PGJyPgogICAgSnVsIDA3IDAyOjE1OjAwIFVwZGF0ZWQ6IGdsdXN0ZXJmcy1jbGllbnQteGxhdG9y cy0zLjcuMi0zLmVsNy54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MDAgVXBkYXRlZDogbnNz LXV0aWwtMy4xOS4xLTEuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjAwIFVwZGF0 ZWQ6IGdsdXN0ZXJmcy1mdXNlLTMuNy4yLTMuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjox NTowMCBVcGRhdGVkOiBnbHVzdGVyZnMtYXBpLTMuNy4yLTMuZWw3Lng4Nl82NDxicj4KICAgIEp1 bCAwNyAwMjoxNTowMCBVcGRhdGVkOiBnbnV0bHMtMy4zLjgtMTIuZWw3XzEuMS54ODZfNjQ8YnI+ CiAgICBKdWwgMDcgMDI6MTU6MDAgVXBkYXRlZDoKICAgIDc6ZGV2aWNlLW1hcHBlci1saWJzLTEu MDIuOTMtMy5lbDdfMS4xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTowMCBVcGRhdGVkOiA3 OmRldmljZS1tYXBwZXItMS4wMi45My0zLmVsN18xLjEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAy OjE1OjAwIFVwZGF0ZWQ6CiAgICA3OmRldmljZS1tYXBwZXItZXZlbnQtbGlicy0xLjAyLjkzLTMu ZWw3XzEuMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MDAgVXBkYXRlZDogZ2x1c3RlcmZz LWNsaS0zLjcuMi0zLmVsNy54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MDEgVXBkYXRlZDoK ICAgIDc6ZGV2aWNlLW1hcHBlci1ldmVudC0xLjAyLjkzLTMuZWw3XzEuMS54ODZfNjQ8YnI+CiAg ICBKdWwgMDcgMDI6MTU6MDEgVXBkYXRlZDogNzpsdm0yLWxpYnMtMi4wMi4xMTUtMy5lbDdfMS4x Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTowMSBVcGRhdGVkOiA3Omx2bTItMi4wMi4xMTUt My5lbDdfMS4xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTowMSBVcGRhdGVkOiBnbnV0bHMt ZGFuZS0zLjMuOC0xMi5lbDdfMS4xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTowMSBVcGRh dGVkOiBnbnV0bHMtdXRpbHMtMy4zLjgtMTIuZWw3XzEuMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcg MDI6MTU6MDEgVXBkYXRlZDogbnNzLTMuMTkuMS0zLmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAw NyAwMjoxNTowMSBVcGRhdGVkOiBuc3Mtc3lzaW5pdC0zLjE5LjEtMy5lbDdfMS54ODZfNjQ8YnI+ CiAgICBKdWwgMDcgMDI6MTU6MDcgSW5zdGFsbGVkOiBrZXJuZWwtMy4xMC4wLTIyOS43LjIuZWw3 Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTowNyBVcGRhdGVkOiBpcHV0aWxzLTIwMTIxMjIx LTYuZWw3XzEuMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MDcgVXBkYXRlZDogbnRwZGF0 ZS00LjIuNnA1LTE5LmVsNy5jZW50b3MuMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MDcg VXBkYXRlZDogbnRwLTQuMi42cDUtMTkuZWw3LmNlbnRvcy4xLng4Nl82NDxicj4KICAgIEp1bCAw NyAwMjoxNTowOSBVcGRhdGVkOiBweXRob24tbGlicy0yLjcuNS0xOC5lbDdfMS4xLng4Nl82NDxi cj4KICAgIEp1bCAwNyAwMjoxNTowOSBVcGRhdGVkOiBweXRob24tMi43LjUtMTguZWw3XzEuMS54 ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MDkgVXBkYXRlZDogZmVuY2UtYWdlbnRzLWNvbW1v bi00LjAuMTEtMTMuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjA5IFVwZGF0ZWQ6 CiAgICBvdG9waS0xLjQuMC0wLjAubWFzdGVyLjIwMTUwNjI1MDgzODQ4LmdpdGU5M2ZhMjMuZWw3 Lm5vYXJjaDxicj4KICAgIEp1bCAwNyAwMjoxNToxNiBVcGRhdGVkOiBnbHVzdGVyZnMtc2VydmVy LTMuNy4yLTMuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNToxNiBVcGRhdGVkOgogICAg dmRzbS1pbmZyYS00LjE3LjAtMTA1NC5naXQ1NjJlNzExLmVsNy5ub2FyY2g8YnI+CiAgICBKdWwg MDcgMDI6MTU6MTYgVXBkYXRlZDoKICAgIHZkc20tcHl0aG9uLTQuMTcuMC0xMDU0LmdpdDU2MmU3 MTEuZWw3Lm5vYXJjaDxicj4KICAgIEp1bCAwNyAwMjoxNToxNiBVcGRhdGVkOgogICAgdmRzbS14 bWxycGMtNC4xNy4wLTEwNTQuZ2l0NTYyZTcxMS5lbDcubm9hcmNoPGJyPgogICAgSnVsIDA3IDAy OjE1OjE2IFVwZGF0ZWQ6IHZkc20tY2xpLTQuMTcuMC0xMDU0LmdpdDU2MmU3MTEuZWw3Lm5vYXJj aDxicj4KICAgIEp1bCAwNyAwMjoxNToxOCBVcGRhdGVkOgogICAgZ2x1c3RlcmZzLWdlby1yZXBs aWNhdGlvbi0zLjcuMi0zLmVsNy54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MTkgVXBkYXRl ZDoKICAgIG92aXJ0LWhvc3QtZGVwbG95LTEuNC4wLTAuMC5tYXN0ZXIuMjAxNTA2MTcwNjI4MjUu Z2l0MDZhOGY4MC5lbDcubm9hcmNoPGJyPgogICAgSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZl bmNlLWFnZW50cy1pcGR1LTQuMC4xMS0xMy5lbDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6 MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdlbnRzLWVwcy00LjAuMTEtMTMuZWw3XzEueDg2XzY0PGJy PgogICAgSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50cy1hcGMtNC4wLjExLTEz LmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2Vu dHMtaWxvLXNzaC00LjAuMTEtMTMuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjE5 IFVwZGF0ZWQ6CiAgICBmZW5jZS1hZ2VudHMtYmxhZGVjZW50ZXItNC4wLjExLTEzLmVsN18xLng4 Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOgogICAgZmVuY2UtYWdlbnRzLWNp c2NvLXVjcy00LjAuMTEtMTMuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjE5IFVw ZGF0ZWQ6IGZlbmNlLWFnZW50cy1pbG8yLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQ8YnI+CiAgICBK dWwgMDcgMDI6MTU6MTkgVXBkYXRlZDoKICAgIGZlbmNlLWFnZW50cy1hcGMtc25tcC00LjAuMTEt MTMuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6CiAgICBmZW5j ZS1hZ2VudHMtdm13YXJlLXNvYXAtNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAw NyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtc2NzaS00LjAuMTEtMTMuZWw3XzEueDg2 XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6CiAgICBmZW5jZS1hZ2VudHMtZWF0 b24tc25tcC00LjAuMTEtMTMuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjE5IFVw ZGF0ZWQ6IGZlbmNlLWFnZW50cy13dGktNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4KICAgIEp1 bCAwNyAwMjoxNToxOSBVcGRhdGVkOgogICAgZmVuY2UtYWdlbnRzLWlibWJsYWRlLTQuMC4xMS0x My5lbDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MTkgSW5zdGFsbGVkOgogICAgZmVu Y2UtYWdlbnRzLWNvbXB1dGUtNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAw MjoxNToxOSBVcGRhdGVkOgogICAgZmVuY2UtYWdlbnRzLWludGVsbW9kdWxhci00LjAuMTEtMTMu ZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE1OjE5IFVwZGF0ZWQ6IGZlbmNlLWFnZW50 cy1ocGJsYWRlLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MTkg VXBkYXRlZDogZmVuY2UtYWdlbnRzLWlwbWlsYW4tNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4K ICAgIEp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtcmhldm0tNC4wLjExLTEz LmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNToxOSBVcGRhdGVkOiBmZW5jZS1hZ2Vu dHMtaWZtaWItNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNToxOSBV cGRhdGVkOiBmZW5jZS1hZ2VudHMtaWxvLW1wLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQ8YnI+CiAg ICBKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdlbnRzLWRyYWM1LTQuMC4xMS0xMy5l bDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdlbnRz LWJyb2NhZGUtNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNToxOSBV cGRhdGVkOiBmZW5jZS1hZ2VudHMtcnNiLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQ8YnI+CiAgICBK dWwgMDcgMDI6MTU6MTkgVXBkYXRlZDogZmVuY2UtYWdlbnRzLWtkdW1wLTQuMC4xMS0xMy5lbDdf MS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTU6MTkgVXBkYXRlZDoKICAgIGZlbmNlLWFnZW50 cy1jaXNjby1tZHMtNC4wLjExLTEzLmVsN18xLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTox OSBVcGRhdGVkOiBmZW5jZS1hZ2VudHMtYWxsLTQuMC4xMS0xMy5lbDdfMS54ODZfNjQ8YnI+CiAg ICBKdWwgMDcgMDI6MTU6NDYgSW5zdGFsbGVkOgogICAgb3ZpcnQtdm1jb25zb2xlLTEuMC4wLTAu MC5tYXN0ZXIuMjAxNTA2MTYxMjA5NDUuZ2l0YzFmYjJiZC5lbDcubm9hcmNoPGJyPgogICAgSnVs IDA3IDAyOjE1OjQ2IFVwZGF0ZWQ6IHNvcy0zLjItMTUuZWw3LmNlbnRvcy41Lm5vYXJjaDxicj4K ICAgIEp1bCAwNyAwMjoxNTo0NiBVcGRhdGVkOgpvdmlydC1lbmdpbmUtc2RrLXB5dGhvbi0zLjYu MC4wLTAuMTUuMjAxNTA2MjUuZ2l0ZmM5MGRhZi5lbDcuY2VudG9zLm5vYXJjaDxicj4KICAgIEp1 bCAwNyAwMjoxNTo0NiBVcGRhdGVkOiBtb20tMC40LjUtMi5lbDcubm9hcmNoPGJyPgogICAgSnVs IDA3IDAyOjE1OjQ2IFVwZGF0ZWQ6CiAgICB2ZHNtLXlhanNvbnJwYy00LjE3LjAtMTA1NC5naXQ1 NjJlNzExLmVsNy5ub2FyY2g8YnI+CiAgICBKdWwgMDcgMDI6MTU6NDYgVXBkYXRlZDoKICAgIHZk c20tanNvbnJwYy00LjE3LjAtMTA1NC5naXQ1NjJlNzExLmVsNy5ub2FyY2g8YnI+CiAgICBKdWwg MDcgMDI6MTU6NDcgVXBkYXRlZDogMTpvcGVuc3NsLTEuMC4xZS00Mi5lbDcuOS54ODZfNjQ8YnI+ CiAgICBKdWwgMDcgMDI6MTU6NDcgVXBkYXRlZDoga2VybmVsLXRvb2xzLWxpYnMtMy4xMC4wLTIy OS43LjIuZWw3Lng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNTo0NyBVcGRhdGVkOiBzZWxpbnV4 LXBvbGljeS0zLjEzLjEtMjMuZWw3XzEuOC5ub2FyY2g8YnI+CiAgICBKdWwgMDcgMDI6MTY6MDEg VXBkYXRlZDoKICAgIHNlbGludXgtcG9saWN5LXRhcmdldGVkLTMuMTMuMS0yMy5lbDdfMS44Lm5v YXJjaDxicj4KICAgIEp1bCAwNyAwMjoxNjowMSBVcGRhdGVkOiB2ZHNtLTQuMTcuMC0xMDU0Lmdp dDU2MmU3MTEuZWw3Lm5vYXJjaDxicj4KICAgIEp1bCAwNyAwMjoxNjowMSBVcGRhdGVkOgogICAg dmRzbS1nbHVzdGVyLTQuMTcuMC0xMDU0LmdpdDU2MmU3MTEuZWw3Lm5vYXJjaDxicj4KICAgIEp1 bCAwNyAwMjoxNjowMSBVcGRhdGVkOgpvdmlydC1ob3N0ZWQtZW5naW5lLWhhLTEuMy4wLTAuMC5t YXN0ZXIuMjAxNTA2MTUxNTM2NTAuMjAxNTA2MTUxNTM2NDUuZ2l0NWY4YzI5MC5lbDcubm9hcmNo PGJyPgogICAgSnVsIDA3IDAyOjE2OjAyIFVwZGF0ZWQ6IHR6ZGF0YS1qYXZhLTIwMTVlLTEuZWw3 Lm5vYXJjaDxicj4KICAgIEp1bCAwNyAwMjoxNjowNiBVcGRhdGVkOgogICAgMTpqYXZhLTEuNy4w LW9wZW5qZGstaGVhZGxlc3MtMS43LjAuNzktMi41LjUuMi5lbDdfMS54ODZfNjQ8YnI+CiAgICBK dWwgMDcgMDI6MTY6MDYgVXBkYXRlZDoKICAgIDE6amF2YS0xLjcuMC1vcGVuamRrLTEuNy4wLjc5 LTIuNS41LjIuZWw3XzEueDg2XzY0PGJyPgogICAgSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6Cm92 aXJ0LWhvc3RlZC1lbmdpbmUtc2V0dXAtMS4zLjAtMC4wLm1hc3Rlci4yMDE1MDYyMzE1MzExMS5n aXQ2ODEzOGQ0LmVsNy5ub2FyY2g8YnI+CiAgICBKdWwgMDcgMDI6MTY6MDcgVXBkYXRlZDoga2Vy bmVsLXRvb2xzLTMuMTAuMC0yMjkuNy4yLmVsNy54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTY6 MDcgVXBkYXRlZDogc3lzdGVtZC1zeXN2LTIwOC0yMC5lbDdfMS41Lng4Nl82NDxicj4KICAgIEp1 bCAwNyAwMjoxNjowNyBVcGRhdGVkOiBkcmFjdXQtbmV0d29yay0wMzMtMjQxLmVsN18xLjMueDg2 XzY0PGJyPgogICAgSnVsIDA3IDAyOjE2OjA3IFVwZGF0ZWQ6IG5zcy10b29scy0zLjE5LjEtMy5l bDdfMS54ODZfNjQ8YnI+CiAgICBKdWwgMDcgMDI6MTY6MDcgVXBkYXRlZDogZHJhY3V0LWNvbmZp Zy1yZXNjdWUtMDMzLTI0MS5lbDdfMS4zLng4Nl82NDxicj4KICAgIEp1bCAwNyAwMjoxNjowNyBV cGRhdGVkOiBsaWJndWRldjEtMjA4LTIwLmVsN18xLjUueDg2XzY0PGJyPgogICAgSnVsIDA3IDAy OjE2OjA3IFVwZGF0ZWQ6IG1kYWRtLTMuMy4yLTIuZWw3XzEuMS54ODZfNjQ8YnI+CiAgICBKdWwg MDcgMDI6MTY6MDcgVXBkYXRlZDogZ2x1c3RlcmZzLXJkbWEtMy43LjItMy5lbDcueDg2XzY0PGJy PgogICAgSnVsIDA3IDAyOjE2OjA4IFVwZGF0ZWQ6IHR6ZGF0YS0yMDE1ZS0xLmVsNy5ub2FyY2g8 YnI+CiAgICBKdWwgMDcgMDQ6MjM6MjEgSW5zdGFsbGVkOgogICAgbGlidmlydC1kYWVtb24tZHJp dmVyLWx4Yy0xLjIuOC0xNi5lbDdfMS4zLng4Nl82NDxicj4KICAgIEp1bCAwNyAwNjowNjo1MCBJ bnN0YWxsZWQ6IHN0cmFjZS00LjgtNy5lbDcueDg2XzY0PGJyPgogICAgSnVsIDA3IDA3OjQ0OjU5 IEluc3RhbGxlZDogaW90b3AtMC42LTIuZWw3Lm5vYXJjaDxicj4KICAgIDxicj4KICA8L2JvZHk+ CjwvaHRtbD4KCi0tLS0tLS0tLS0tLS0tMDYwODAwMDAwNDAwMDUwMjAyMDIwOTA2LS0K --===============3590645473051735060==-- From s.kieske at mittwald.de Wed Jul 8 04:15:40 2015 Content-Type: multipart/mixed; boundary="===============3510586691127838468==" MIME-Version: 1.0 From: Sven Kieske To: devel at ovirt.org Subject: Re: [ovirt-devel] VM won't start because of -incoming flag after upgrading to alpha-2 Date: Wed, 08 Jul 2015 10:15:35 +0200 Message-ID: <559CDC27.905@mittwald.de> In-Reply-To: 1027695025.24746192.1436340384342.JavaMail.zimbra@redhat.com --===============3510586691127838468== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/07/15 09:26, Francesco Romani wrote: > ... AFAIR, in the patchset which is part of qemu-kvm-ev, a lot of = > devices are disabled for security/safety/auditing reasons, and > new, stable machines are added (rhel*). Thanks Franceso and Michal for clearing this up. I really thought that the only technical difference is live migration support, I didn't know that there where further tweaks to qemu-kvm-ev. - -- = Mit freundlichen Gr=C3=BC=C3=9Fen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=C3=B6nigsberger Stra=C3=9Fe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVnNwnAAoJEMby9TMDAbQR7xUQANjTJHwEuLIGyMuaGtl8AnhP cjeOfmbc7858vxZ6PMmLd1xruds+XbOh1d/7h3mpEV8rYkJyRvXHUFvzdnAvsqXP u/Ml6HY7zis+1ucrrAScZGb7javZohY1nnoG6+hqzm85IKc9SMLu5IeKPfZslFAj I6taYvxl9/djZnp1Mbo0E1NyNqpriGHySZSI9+3cntJFU8eZysQmflBjxkQlsaI8 fIpmLDxFSWVxnttMlWhDkP0tVPfsr3IkVTpi1UwGur9P8gp3S1bH7W1FWWUUpwxj K3EOVgMVf+av8syEsfmn9BGXkYqxrwTaVkr0yY4P0nknc+Qqn8AGZGmfLhsH6F6L UjDDDO81wNUaFNBFlhF9j0XdiM7NF6H0vBQmzxGmPJ68sP/4cK7qdD4H3ZCKqmEm iXfX9jkMEI1abOoAOILcNP3IiwygahkOyUFp++CTeu9MkuaGwLQ0758qXdSTicCv m+yjqd2BPUhiz7nZQC55PBcjZqLriPqHjF+Z8Ys02Fevljvi2vf2anAsPBqy7Mbv Lw85au30g6TQbiOWDxvWhusfzt5ksLkTLS8MWFJCXnQS8moK1BLqfup83hfTXR4Q urH661yc/BjR8CQfnNh8pa+RoAVshmyXnY3Rd+5zcCqoupe4UYRRbxTBGVJzILWp vcfLIsnvsu0DsZApjeOK =3DYZ2e -----END PGP SIGNATURE----- --===============3510586691127838468==--