HE vm stuck in migration state
by Davide Ferrari
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
8 years, 2 months
Replace one engine host
by Davide Ferrari
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
8 years, 2 months
VMs get paused when FC port in any host get online
by Federico Alberto Sayd
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
8 years, 2 months
Disk profile
by Budur Nagaraju
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
8 years, 2 months
ovirt python sdk and starting stateless vm
by Jiří Sléžka
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--
8 years, 2 months
Re: [ovirt-users] R: moVirt 1.6 released!
by Karli Sjöberg
--_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_--
8 years, 2 months
RHSA-2016-1756 - live migration issues
by Markus Stockhausen
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--
8 years, 2 months
Re: [ovirt-users] Assigned ipv6 vm addreses
by Yevgeny Zaspitsky
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
>>>
>>>
>>
>
8 years, 2 months
How to add the clean-traffic network-filter to a guest
by Troels Arvin
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
8 years, 2 months
