September 2016 - Users - oVirt List Archives

HE vm stuck in migration state
by Davide Ferrari 26 Sep '16

26 Sep '16

It's running on my vm01 host and when I tried to manually migrate it on another host (vm03) which had a "ghost" VM count (it's a fresh cluster install with just the HE running in it), the migration started, the VMs count in vm03 went to 0 but then the HE machine got stuck in migration. Actually it's still perfectly running on vm01, it seems that it's just a database state. Is there a way to force a refresh? -- Davide Ferrari Senior Systems Engineer

2 4

Replace one engine host
by Davide Ferrari 26 Sep '16

26 Sep '16

Hello Still playing a bit with oVirt, my cluster is ovirt+gluster with a replica 3 glusterfs for the engine (on vm01, vm02 and vm03) and 4 hosts for the data glusterfs and running virtual machines (vm01, vm02, vm03 and vm04). Now, by mistake, I deployed hosted-engine on vm04 but I don't want to have the engine on a machine without local data + it's not working correctly (weight 0 and marked as in maintenance). Now, I've already tried to reinstall it from the the GUI marking the "Undeploy" check, reinstall vm03 marking the "deploy" check but nothing seems to work. Here it is the hosted-engine --vm-status output from vm04. What can I do to deploy correctly the hosted engine on vm03? --== Host 1 status ==-- Status up-to-date : True Hostname : vm01.mydomain.tld Host ID : 1 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : fee2f7d8 Host timestamp : 48911 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=48911 (Sat Sep 17 07:57:02 2016) host-id=1 score=3400 maintenance=False state=EngineDown stopped=False --== Host 3 status ==-- Status up-to-date : True Hostname : vm02.mydomain.tld Host ID : 3 Engine status : {"health": "good", "vm": "up", "detail": "up"} Score : 3400 stopped : False Local maintenance : False crc32 : 9138d24e Host timestamp : 48907 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=48907 (Sat Sep 17 07:57:00 2016) host-id=3 score=3400 maintenance=False state=EngineUp stopped=False --== Host 4 status ==-- Status up-to-date : False Hostname : vm04.mydomain.tld Host ID : 4 Engine status : unknown stale-data Score : 0 stopped : False Local maintenance : True crc32 : 221d262e Host timestamp : 17958 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=17958 (Fri Sep 16 23:19:32 2016) host-id=4 score=0 maintenance=True state=LocalMaintenance stopped=False -- Davide Ferrari Senior Systems Engineer

2 7

VMs get paused when FC port in any host get online
by Federico Alberto Sayd 26 Sep '16

26 Sep '16

Hello: Since I upgraded to 4.0 I have troubles with the storage of my oVirt setup. I have 2 IBM 3512 arrays connected to 8 ovirt hosts through FC. When a host is rebooted or when a new port get online in the FC switchs although the port isn't connected to storage or oVirt hosts; oVirt reports I/O problems and pause some vm's. I have to manually resume the vm's. It seem that any change (even non disruptive changes) to FC switchs and HBAs causes that ovirt detects I/O problems. How I can debug this issue. How can I know if It is related to vdsm/ovirt, mulitpathd..? Thanks in advance Federico

2 2

Disk profile
by Budur Nagaraju 26 Sep '16

26 Sep '16

HI I have created a 2TB if iSCSI lun , when I migrate a vm which is created in a nfs storage to iSCSI storage am not able to find the iSCSI Disk profile any configs do I need to do ? Thanks, Nagaraju

2 5

[ANN] oVirt 4.0.4 Final Release is now available
by Sandro Bonazzola 26 Sep '16

26 Sep '16

The oVirt Project is pleased to announce the availability of oVirt 4.0.4, as of September 26th, 2016. This release is available now for: * Fedora 23 (tech preview) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 (tech preview) * oVirt Next Generation Node 4.0 This update is the fourth in a series of stabilization updates to the 4.0 series. 4.0.4 brings 11 enhancements and 139 bugfixes, including 58 high or urgent severity fixes, on top of oVirt 4.0 series See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is available. [4] * A new oVirt Next Generation Node will be available soon [4]. * A new oVirt Engine Appliance is available for Red Hat Enterprise Linux and CentOS Linux (or similar) * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.4 release highlights: http://www.ovirt.org/release/4.0.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.4/ [4] http://resources.ovirt.org/pub/ovirt-4.0/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

ovirt python sdk and starting stateless vm
by Jiří Sléžka 26 Sep '16

26 Sep '16

This is a cryptographically signed message in MIME format. --------------ms080203040501010709060600 Content-Type: multipart/mixed; boundary="------------BD443E7FE790D8BDEA51E828" This is a multi-part message in MIME format. --------------BD443E7FE790D8BDEA51E828 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I am testing some from scratch deployment so I created a stateless vm=20 and wrote small python script to shutdown and start the vm again (to=20 revert vm state to starting point). http://pastebin.com/b5yTFEkN problem is that after stopping the vm there is a running operation of=20 snapshot removal and when script try to start the vm it fails with Failed to Start VM: status: 409 reason: Conflict detail: Cannot run VM. Related operation is currently in progress.=20 Please try again later. Is there a cleaner way than checking status and looping or waiting some=20 time to end of this operation? (desclaimer: I am new to python so please = don't hit me :-) Cheers, Jiri --------------BD443E7FE790D8BDEA51E828 Content-Type: text/x-vcard; charset=utf-8; name="jiri_slezka.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="jiri_slezka.vcf" begin:vcard fn;quoted-printable:Ing. Ji=3DC5=3D99=3DC3=3DAD Sl=3DC3=3DA9=3DC5=3DBEka n;quoted-printable;quoted-printable:Sl=3DC3=3DA9=3DC5=3DBEka;Ji=3DC5=3D99= =3DC3=3DAD org;quoted-printable;quoted-printable:Slezsk=3DC3=3DA1 univerzita v Opav=3D= C4=3D9B;Centrum informa=3DC4=3D8Dn=3DC3=3DADch technologi=3DC3=3DAD adr;quoted-printable;quoted-printable:Na Rybn=3DC3=3DAD=3DC4=3D8Dku 1;;CI= T, Slezsk=3DC3=3DA1 univerzita v Opav=3DC4=3D9B;Opava;;74601;Czech Republ= ic email;internet:jiri.slezka@slu.cz title;quoted-printable:Spr=3DC3=3DA1vce s=3DC3=3DADt=3DC4=3D9B a aplikac=3D= C3=3DAD tel;work:+420 553 684 696 x-mozilla-html:FALSE url:http://www.slu.cz version:2.1 end:vcard --------------BD443E7FE790D8BDEA51E828-- --------------ms080203040501010709060600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CWcwggScMIIDhKADAgECAhEAuOSLPwlcx/l5IqBlguM0fDANBgkqhkiG9w0BAQUFADA7MQsw CQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwg Q0EwHhcNMTQxMTEwMDAwMDAwWhcNMTYxMTA5MjM1OTU5WjBlMQswCQYDVQQGEwJDWjElMCMG A1UECgwcU2xlenNrw6EgdW5pdmVyeml0YSB2IE9wYXbEmzEYMBYGA1UEAwwPSmnFmcOtIFNs w6nFvmthMRUwEwYJKoZIhvcNAQkCFgZzbGV6a2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDNcPHUXg4ZfD3shn/1zeMf8tyn/ZplDk1756hc+PVHYNO2VRP2p1HKRdtcfj1i 2V87na0EfMmfxM77dJJklSnAsCXrs0by2eHzdCz746vErs5VkSnZ1nhOWH7FViKadiyxmAv+ zXL+jkzb678GHsT2jPWdHjfhgQXAzd0hE5AqkQ3sRGRspsfruRmfgStEoE2+Ubq4jC69pBYW i80zdAUOc+9Kl5Zfolfo/TpFViXIo4i1FMgDRNYZAhBKpHz70zN/7VUqTl/7x9z3a6ytNC8J TbbMdj8SdWhRV0oyOOhYlFHL+1ZS0KtQ0iz5yWs9dCkq77LrTXCXaWSGBRlQ8H/5AgMBAAGj ggFvMIIBazAfBgNVHSMEGDAWgBRjTUNaGUg/xEbBArq/7g7lgrdmpjAdBgNVHQ4EFgQUNHjX Vei/P0DdklwoP8A3Tkq0XTYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wPwYD VR0fBDgwNjA0oDKgMIYuaHR0cDovL2NybC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25h bENBLmNybDByBggrBgEFBQcBAQRmMGQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcnQudGNzLnRl cmVuYS5vcmcvVEVSRU5BUGVyc29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3Nw LnRjcy50ZXJlbmEub3JnMB0GA1UdEQQWMBSBEmppcmkuc2xlemthQHNsdS5jejANBgkqhkiG 9w0BAQUFAAOCAQEAJy6bixJ53paigwWwnXfipRly2TTkICwf4PtXw9hOBoYC17PbPpAoGBtT Dvz6pQW4woSJ4JbkkD9JKGPlZXt0fQgZKgbfQ7sRFQ54goOhvJYm+CFJUPiSXrZ/i1CUzI40 U3kXYbWOq99yKid5aUEaIub9E6cJY6fybt7ireTV2IKVNIm/AXWjjf6jxGVavQ1QzTxmRvfE sXpQis5jgCeJjRHhZ4BhwRChkIThLYfWTSYId9rbtuj3yjLjtJipDhHJEuIckgV8sCDbjbyt xo0WNLQmfL0KUVxvpfMfdZ3McGKwn7nQiqBcpsGI3+9pfmHkMzy4+rDGZCHkeyNNxEUpLDCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMDkwNTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEP MA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpD m/5bsbC/tFfcdYBBS2Qa9ttPb4/QJUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5Y M38i+/j/7Oa+264KZSUih9pvhItG6ECGKD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyh bp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51WJFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZ UcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSbA/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V 0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRu fTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYDVR0PAQH/BAQDAgEGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTBYBgNVHR8EUTBPME2g S6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRo ZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYBBQUHMAKGLGh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzAB hhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lTLxPc XDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxs H0+pAMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/ HaWWWr3QyxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXc J4bkOjtSWherqQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYIDGjCCAxYCAQEwUDA7MQswCQYD VQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EC EQC45Is/CVzH+XkioGWC4zR8MA0GCWCGSAFlAwQCAQUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MjYwOTQxMDdaMC8GCSqGSIb3DQEJBDEi BCDH/drjngVIAg47jQmKQ6eeUHZTmgUV/Ct+IfeGqLeJETBfBgkrBgEEAYI3EAQxUjBQMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQQIRALjkiz8JXMf5eSKgZYLjNHwwYQYLKoZIhvcNAQkQAgsxUqBQMDsxCzAJBgNVBAYT Ak5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIRALjk iz8JXMf5eSKgZYLjNHwwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCdvM7d+CewgNhrUt/vPTO7Wxro 7BSw3XI0AOdcdi12cRgG8aJm3Ccdg5EQxbGbU0GEAJXVeqzAWH0gBjOkb89vdF9h4l8Dyjc3 osNhFIf2CJdE6wPfEF1FeMZJjUS3y7yZglk/z1YxdbTfRTtoM6qI6Q4a7lNu6PNUZiA1iZ81 wgXaY05AWZ9vIk/fPCmVksNuHEXwzcsCdr48ptSJEMQd8RrLt6JTUVgk2ShOIUyGA0plIcgh M5/3eQYJXJP14T6VMhrudVj+hpgeSiwfCh0OLy9QutZwh2UMu23UCxIW8CMGjICTChjlmIL+ dpqISTDL/j8DlSmuxwEwL13tltTuAAAAAAAA --------------ms080203040501010709060600--

2 4

Re: [ovirt-users] R: moVirt 1.6 released!
by Karli Sjöberg 26 Sep '16

26 Sep '16

--_000_dd35ba2bdf8b4fa782941fb1c58ca538exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjMgc2VwIDIwMTYgMTA6MDggZW0gc2tyZXYgTlVOSU4gUm9iZXJ0byA8Um9iZXJ0by5O dW5pbkBjb21pZmFyLml0PjoNCj4NCj4gPiA+DQo+ID4gPiA+QWxzbyB0ZXN0ZWQgdGhhdCBhU1BJ Q0Ugd29ya3MsIHdoaWNoIGlzID5hd2Vzb21lISBLZWVwIHVwIHRoZSBncmVhdA0KPiA+ID4gd29y ayENCj4gPiA+DQo+ID4gPiBJbnRlcmVzdGluZzogZGlkIHlvdSBoYXZlIHVzZWQgYVNwaWNlIHRv IGFjdCBhcyBhIGNvbnNvbGUgdmlld2VyID8NCj4gPiA+IENvdWxkIHlvdSBzaGFyZSBiYXNpY3Mg Pw0KPiA+DQo+ID4gVmVyeSBiYXNpYzopIEp1c3QgaW5zdGFsbCBhU1BJQ0UgZnJvbSAkYXBwX3N0 b3JlIGFuZCB0aGVuLCBpbiBtb1ZpcnQsIGNsaWNrIHRoZQ0KPiA+ICJ0aHJlZSBkb3RzIiBpbiB0 aGUgdG9wIHJpZ2h0IGNvcm5lciBhbmQgY2hvb3NlICJDb25zb2xlIi4gSSBoYWQgdG8gYWNjZXB0 IG91cg0KPiA+IGNlcnRpZmljYXRlIGFuZCBmb3Igc29tZSByZWFzb24gdGhlIGZpcnN0IHRpbWUg SSB0cmllZCBpdCwgaXQgZGlkbsK0dCB3b3JrLCBidXQgSSB0cmllZA0KPiA+IGFnYWluIGFuZCBC T09NITopDQo+ID4NCj4gPiAvSw0KPg0KPiBUZXN0ZWQgaXQsIGJ1dCBJIHdhc24ndCBhYmxlIHRv IGhhdmUgdGhlIGNvbnNvbGUgdW50aWwgYlZOQyBmcmVlIGluc3RhbGxhdGlvbg0KPiBNZXNzYWdl IHdhczogY2hlY2sgaWYgeW91IGhhdmUgYVNwaWNlIG9yIGJWTkMgaW5zdGFsbGVkLg0KPiBMb29r cyBzdHJhbmdlLCBjb25zaWRlcmluZyB0aGF0IHNldHVwIGlzbid0IGEgbmlnaHRtYXJlIQ0KDQpX ZWxsLCB0aGF0IGRlcGVuZHMgb24gdGhlIGNvbnNvbGUgc2V0dGluZ3Mgb24gdGhlIFZNLiBEbyB5 b3UgaGF2ZSBhIFZNIHdpdGggU1BJQ0UgY29uc29sZSBjb25maWd1cmVkPw0KDQovSw0KDQo+DQo+ IFRoYW5rcw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBR dWVzdG8gbWVzc2FnZ2lvIGUnIGluZGlyaXp6YXRvIGVzY2x1c2l2YW1lbnRlIGFsIGRlc3RpbmF0 YXJpbyBpbmRpY2F0byBlIHBvdHJlYmJlIGNvbnRlbmVyZSBpbmZvcm1hemlvbmkgY29uZmlkZW56 aWFsaSwgcmlzZXJ2YXRlIG8gcHJvcHJpZXRhcmllLiBRdWFsb3JhIGxhIHByZXNlbnRlIHZlbmlz c2UgcmljZXZ1dGEgcGVyIGVycm9yZSwgc2kgcHJlZ2EgZGkgc2VnbmFsYXJsbyBpbW1lZGlhdGFt ZW50ZSBhbCBtaXR0ZW50ZSwgY2FuY2VsbGFuZG8gbCdvcmlnaW5hbGUgZSBvZ25pIHN1YSBjb3Bp YSBlIGRpc3RydWdnZW5kbyBldmVudHVhbGkgY29waWUgY2FydGFjZWUuIE9nbmkgYWx0cm8gdXNv IGUnIHN0cmV0dGFtZW50ZSBwcm9pYml0byBlIHBvdHJlYmJlIGVzc2VyZSBmb250ZSBkaSB2aW9s YXppb25lIGRpIGxlZ2dlLg0KPg0KPiBUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudCBvbmx5IGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0 IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0aW5n IHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyBhbmQgZGVzdHJveWluZyBhbnkgaGFyZCBjb3Bp ZXMuIEFueSBvdGhlciB1c2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLg0K --_000_dd35ba2bdf8b4fa782941fb1c58ca538exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <5E0E8E124B4D9A4A9614DA9D4CB7A11E(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyMyBzZXAgMjAxNiAxMDowOCBlbSBza3JldiBOVU5JTiBSb2JlcnRvICZsdDtS b2JlcnRvLk51bmluQGNvbWlmYXIuaXQmZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDtBbHNvIHRlc3RlZCB0aGF0IGFTUElDRSB3b3Jrcywg d2hpY2ggaXMgJmd0O2F3ZXNvbWUhIEtlZXAgdXAgdGhlIGdyZWF0PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgd29yayE8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEludGVyZXN0 aW5nOiBkaWQgeW91IGhhdmUgdXNlZCBhU3BpY2UgdG8gYWN0IGFzIGEgY29uc29sZSB2aWV3ZXIg Pzxicj4NCiZndDsgJmd0OyAmZ3Q7IENvdWxkIHlvdSBzaGFyZSBiYXNpY3MgPzxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBWZXJ5IGJhc2ljOikgSnVzdCBpbnN0YWxsIGFTUElDRSBmcm9t ICRhcHBfc3RvcmUgYW5kIHRoZW4sIGluIG1vVmlydCwgY2xpY2sgdGhlPGJyPg0KJmd0OyAmZ3Q7 ICZxdW90O3RocmVlIGRvdHMmcXVvdDsgaW4gdGhlIHRvcCByaWdodCBjb3JuZXIgYW5kIGNob29z ZSAmcXVvdDtDb25zb2xlJnF1b3Q7LiBJIGhhZCB0byBhY2NlcHQgb3VyPGJyPg0KJmd0OyAmZ3Q7 IGNlcnRpZmljYXRlIGFuZCBmb3Igc29tZSByZWFzb24gdGhlIGZpcnN0IHRpbWUgSSB0cmllZCBp dCwgaXQgZGlkbsK0dCB3b3JrLCBidXQgSSB0cmllZDxicj4NCiZndDsgJmd0OyBhZ2FpbiBhbmQg Qk9PTSE6KTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAvSzxicj4NCiZndDs8YnI+DQom Z3Q7IFRlc3RlZCBpdCwgYnV0IEkgd2Fzbid0IGFibGUgdG8gaGF2ZSB0aGUgY29uc29sZSB1bnRp bCBiVk5DIGZyZWUgaW5zdGFsbGF0aW9uPGJyPg0KJmd0OyBNZXNzYWdlIHdhczogY2hlY2sgaWYg eW91IGhhdmUgYVNwaWNlIG9yIGJWTkMgaW5zdGFsbGVkLjxicj4NCiZndDsgTG9va3Mgc3RyYW5n ZSwgY29uc2lkZXJpbmcgdGhhdCBzZXR1cCBpc24ndCBhIG5pZ2h0bWFyZSE8L3A+DQo8cCBkaXI9 Imx0ciI+V2VsbCwgdGhhdCBkZXBlbmRzIG9uIHRoZSBjb25zb2xlIHNldHRpbmdzIG9uIHRoZSBW TS4gRG8geW91IGhhdmUgYSBWTSB3aXRoIFNQSUNFIGNvbnNvbGUgY29uZmlndXJlZD88L3A+DQo8 cCBkaXI9Imx0ciI+L0s8L3A+DQo8cCBkaXI9Imx0ciI+Jmd0Ozxicj4NCiZndDsgVGhhbmtzPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0Ozxicj4NCiZndDsgUXVlc3RvIG1lc3NhZ2dpbyBlJyBpbmRpcml6emF0byBl c2NsdXNpdmFtZW50ZSBhbCBkZXN0aW5hdGFyaW8gaW5kaWNhdG8gZSBwb3RyZWJiZSBjb250ZW5l cmUgaW5mb3JtYXppb25pIGNvbmZpZGVuemlhbGksIHJpc2VydmF0ZSBvIHByb3ByaWV0YXJpZS4g UXVhbG9yYSBsYSBwcmVzZW50ZSB2ZW5pc3NlIHJpY2V2dXRhIHBlciBlcnJvcmUsIHNpIHByZWdh IGRpIHNlZ25hbGFybG8gaW1tZWRpYXRhbWVudGUgYWwgbWl0dGVudGUsIGNhbmNlbGxhbmRvDQog bCdvcmlnaW5hbGUgZSBvZ25pIHN1YSBjb3BpYSBlIGRpc3RydWdnZW5kbyBldmVudHVhbGkgY29w aWUgY2FydGFjZWUuIE9nbmkgYWx0cm8gdXNvIGUnIHN0cmV0dGFtZW50ZSBwcm9pYml0byBlIHBv dHJlYmJlIGVzc2VyZSBmb250ZSBkaSB2aW9sYXppb25lIGRpIGxlZ2dlLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJp dmF0ZSBpbmZvcm1hdGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRpbmcgdGhlIG9yaWdpbmFsIGFu ZCBhbGwgY29waWVzIGFuZCBkZXN0cm95aW5nIGFueSBoYXJkDQogY29waWVzLiBBbnkgb3RoZXIg dXNlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48YnI+DQo8L3A+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_dd35ba2bdf8b4fa782941fb1c58ca538exch24sluse_--

3 2

RHSA-2016-1756 - live migration issues
by Markus Stockhausen 25 Sep '16

25 Sep '16

This is a multi-part message in MIME format. ------=_NextPartTM-000-3c712ef9-afaa-4966-adab-6f4efcca2a0d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there.=0A= =0A= several Redhat BZs are currently targeting a live migration error with curr= ent =0A= qemu 2.3/2.6 versions. From my understanding BZ1359731 trie to fix a queue= =0A= overflow issue. With the patch in place qemu might abort randomly during=0A= live migration. BZ1372763 provides info about additional patches to fix the= =0A= fix.=0A= =0A= Can someone with deeper knowledge explain how seriously OVirt 4.0.4 with = =0A= qemu 2.3.0-31_2.21 is affected. Form my understanding it has the initial=0A= (errorneous) but not the final fix. Also it does not get clear from the BZs= how =0A= often or how randomly the crash occurs.=0A= =0A= Thanks in advance.=0A= =0A= Markus=0A= ------=_NextPartTM-000-3c712ef9-afaa-4966-adab-6f4efcca2a0d Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-3c712ef9-afaa-4966-adab-6f4efcca2a0d--

1 0

Re: [ovirt-users] Assigned ipv6 vm addreses
by Yevgeny Zaspitsky 25 Sep '16

25 Sep '16

Adding users list back (my fault ;-) ) On Sun, Sep 25, 2016 at 4:20 PM, Allen Warren <dallenwarren(a)gmail.com> wrote: > Thanks for the reply. I figured it out yesterday. I just edited the VM > Custom Mac Address and it works like a champ now... > I will setup that range and it should be good to go.. I am running oVirt > 4.0.. oVirt is a nice product, beats the heck out of Xen Server.. > > On Sun, Sep 25, 2016 at 6:57 AM, Yevgeny Zaspitsky <yzaspits(a)redhat.com> > wrote: > >> oVirt does not produce IP addresses, but it allocates MAC addresses to >> vNics on VMs it creates. >> A MAC address serves as the base for an IPv6 address allocation (either >> by IPv6 router advertisement for global addresses or by an operation system >> for local addresses). >> >> BTW, 2 vNics with the same MAC address in the same LAN, would cause layer >> 2 (Ethernet) malfunctioning too. >> >> In order to make the 2 oVirt's produce different MAC addresses you need >> to adjust the definition of the MAC-pool ranges to be non-overlapping each >> to another. >> You could find MAC-pool definitions under a DC definitions in v4.0 and >> under a cluster in v4.1. >> >> Regards, >> Yevgeny >> >> On Sat, Sep 24, 2016 at 5:44 PM, Allen Warren <dallenwarren(a)gmail.com> >> wrote: >> >>> I have two oVirt servers running as local servers on the same network. >>> How do I prevent the servers from creating the same ipv6 address for two >>> different vm's. If I start a vm on the first server and then start one on >>> the second server the ipv6 addresses are the same.. >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> >

1 0

How to add the clean-traffic network-filter to a guest
by Troels Arvin 25 Sep '16

25 Sep '16

I would like to minimize the risk of virtual servers harming each other. As part of this, I would like to prevent them from changing their IP address to something different from what they are expected to have. In other words, I would like to prevent IP address spoofing in the guests. And I want to be able to do this without having to assign a different VLAN to each guest. Setup: RHEV 3.6 with RH7-based RHEV-H hypervisor hosts. Using virsh -r dumpxml <guest name> on a host, I can see that the guests have the "vdsm-no-mac-spoofing" network filter active for the virtual network interface. But what if I want the "clean-traffic" filter to be active for the guests, as well (or instead): Is there a way to accomplish that in the RHEV-M/oVirt management interface? If so: Where's the option(s) to be found in the management interface? Can it be done globally, i.e. as a default when guests are started? -- Regards, Troels Arvin

3 3