[Users] persisting selinux nightmare
by David Smith
I'm using the ovirt iso image and can't seem to get selinux to persist off
no matter what i do.
With selinux enforcing, SSHD isnt working, can't install or use the hosts.
With it disabled, all seems to work, but after reboot, boom its enforcing
again.
I even edited /etc/selinux/config and changed it to permissive, then used
"persist config" to persist the file. I reboot, I see the file is still
changed, but selinux is back into enforcing mode (getenforce)
what gives?
I'm using this iso image, is this the latest one? It seems really hard to
navigate the various old links in docs and such to find the most up to date
isos.
ovirt-node-iso-3.0.3-1.1.vdsm.fc19.iso
10 years, 9 months
[Users] vmware image conversion
by Maurice James
------=_NextPart_000_002A_01CF24AE.AF6B7BC0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
I submitted an RFE to have vmware image conversion added to 3.5. I think
that is a key feature that is lacking. Im just trying to get some eyes on it
here.
https://bugzilla.redhat.com/show_bug.cgi?id=1062910
------=_NextPart_000_002A_01CF24AE.AF6B7BC0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US =
link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p =
class=3DMsoNormal>I submitted an RFE to have vmware image conversion =
added to 3.5. I think that is a key feature that is lacking. Im just =
trying to get some eyes on it here.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>https://bugzilla.redhat.com/show_bug.cgi?id=3D1062910<o=
:p></o:p></p></div></body></html>
------=_NextPart_000_002A_01CF24AE.AF6B7BC0--
10 years, 9 months
[Users] repo status
by Jimmy Dorff
This is a cryptographically signed message in MIME format.
--------------ms040407080806040202020907
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
What is going on with the EL repos. I'm getting this message:
http://resources.ovirt.org/releases/3.3.3/rpm/Fedora/6.5/repodata/repomd.=
xml:=20
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not=20
Found"
Trying other mirror.
http://ovirt.org/releases/stable/rpm/Fedora/6.5/repodata/repomd.xml:=20
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not=20
Found"
Trying other mirror.
This is on a fresh install with only EPEL and=20
http://resources.ovirt.org/releases/ovirt-release-el.noarch.rpm
Thanks,
Jimmy
--------------ms040407080806040202020907
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKYDCC
BOowggPSoAMCAQICECeaPwnGr8aRr9rqNxvvpm8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwMjExMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjBkMQswCQYDVQQGEwJVUzES
MBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEuMCwGA1UEAxMlSW5Db21t
b24gU3RhbmRhcmQgQXNzdXJhbmNlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBANPgFQJ7+XaC6f6RlvPwHiFotQ1hML4Jl2bdHSOn+x+GeDrml2rHwaR/iU2z
nlmzOAsfOSJrAigSvymW0TX0lSpsBpgcGWRcpn5FbiBrkbh0DzxTyIMZaxGjxyyFBR6H1Mug
CAUGLmaJPXing5NUt9gX6tPufWbUNN6Jyhn9N8rQg95RaNha9XTr3YICWvogzqrPQCvTyJ6F
6YEzm9bxT5FF2Y0zKRxdB5qF6f/JErJMDEIq7TD019yZtc8LgOp53qcjYp+16Zai1rIaRdDY
Ex2SefSEgT22FY/ubywaxuxdrJOPC0dNOjsJ1d4GIjoRlZBvTnsfci4nkTM+iFfCvwkCAwEA
AaOCAUswggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBTo
172Wqt3QCO+hM55eWZg8ErebkTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB
ADARBgNVHSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2Vy
dHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5j
cmwwdAYIKwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5j
b20vVVROQWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51
c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAO7bbgOJ86aKIBwfCE5Sbu/IHS14zJ
GyRDoMmxheaf5OAq0UTe8qBwrYgYKEiWExJHSfnKOaNX181ThU239y8f2atTemkHTshCv+Ls
Xjt79D6ypEmWkRZ7+U9qXkJyMdHTQ6E5BYk+y7XR6T4RxoR1zjW/9S3ooqv1pAFOcBwmZasW
w70y5ikQL2tqskjWcAYG9SjoVH7MEMVprhHpBes7OMFiWtAeGOlcTVP49Srh3ZI1hPoljx/H
I1ka+KIlpVZi4t44rNTfM1diATgqUSo7TLlHsHHpySHBYY7SY626SSsiAKw2NRBIDl7B7B2x
22JekwPq5VBI71GrIYr7YMXCMIIFbjCCBFagAwIBAgIRAJii4SGmG4xeMs7zeGP14o4wDQYJ
KoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUludGVybmV0MjERMA8GA1UE
CxMISW5Db21tb24xLjAsBgNVBAMTJUluQ29tbW9uIFN0YW5kYXJkIEFzc3VyYW5jZSBDbGll
bnQgQ0EwHhcNMTMxMDMxMDAwMDAwWhcNMTgxMDMxMjM1OTU5WjCBnDEOMAwGA1UEERMFMjc3
MDExJTAjBgNVBAoTHER1a2UgVW5pdmVyc2l0eSAtIEVuY3J5cHRpb24xCzAJBgNVBAgTAk5D
MQ8wDQYDVQQHEwZEdXJoYW0xCzAJBgNVBAYTAlVTMRQwEgYDVQQDEwtKaW1teSBEb3JmZjEi
MCAGCSqGSIb3DQEJARYTamRvcmZmQHBoeS5kdWtlLmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALHXuvlDP6Pjn3MAVN2+FB2Yu+Bjl8VzAxBmqrrflkFWvpOv/xpI0/QI
A1NhPOER1zKev2GK35R44eM4P7jyz3rbvM2SBH4OVpk6l5aTJnM5shneFyxMr9TmlHi6gMeA
MuCwGZvTeP+nfUgf0Gdrf3dPMlwxMeoPDjb0nApn8f5ZtuNRB46yuHwsXmSi6MNrufOgclkm
AtjirEydxysjl/Ck1AOzI6dUyFFmGR63lddOWIPFR+K1Seh7t1auVx4Z8VuW2wCSzurcBOJV
j0RnsduOxIzHZgQcoy5QaNi6h0/61fUvKB4S1K8mGY18rdtTz5DWCgf0lq276E2Wy6JidkMC
AwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFOjXvZaq3dAI76Eznl5ZmDwSt5uRMB0GA1UdDgQW
BBT3kO8ynA7nwzcRrZ/97bI0/CQ9iDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwagYDVR0gBGMwYTBfBg0rBgEEAa4jAQQD
AwABME4wTAYIKwYBBQUHAgEWQGh0dHBzOi8vd3d3LmluY29tbW9uLm9yZy9jZXJ0L3JlcG9z
aXRvcnkvY3BzX3N0YW5kYXJkX2NsaWVudC5wZGYwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDov
L2NybC5pbmNvbW1vbi5vcmcvSW5Db21tb25TdGFuZGFyZEFzc3VyYW5jZUNsaWVudENBLmNy
bDCBgAYIKwYBBQUHAQEEdDByMEoGCCsGAQUFBzAChj5odHRwOi8vY2VydC5pbmNvbW1vbi5v
cmcvSW5Db21tb25TdGFuZGFyZEFzc3VyYW5jZUNsaWVudENBLmNydDAkBggrBgEFBQcwAYYY
aHR0cDovL29jc3AuaW5jb21tb24ub3JnMB4GA1UdEQQXMBWBE2pkb3JmZkBwaHkuZHVrZS5l
ZHUwDQYJKoZIhvcNAQEFBQADggEBAISQv2tq3fwqcnd7y7gjlPcxAvJgiXrgKoeED2KFYrbB
fg8JeBEi1fqRZnk38LDobfgFFbCaBmVZ37sSW0XPxeQIwQdbY5FpcjMpb2dG1SIPEzV5nuos
Bsh+SAGDia86e4SxMpagT39aKcc/5TfR9iBquKEgvriUNJW8VAJzOd9/VmMzsjBz0mEGpEYJ
6cV+7D2uITp4nbpU34YOVENvLUlV44Lyw52DJ6ZeKP+hmNrJx1sz93LD841B9Q494/wC6H4Q
G/OjWB7TEA1EqVNvr9/WiXt5WJDLCT+WSuFwIfq1sY5252u8PCOB8kdBMEvWT23YJ9UdoZPK
K9bYrCXTEn4xggOHMIIDgwIBATB5MGQxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJbnRlcm5l
dDIxETAPBgNVBAsTCEluQ29tbW9uMS4wLAYDVQQDEyVJbkNvbW1vbiBTdGFuZGFyZCBBc3N1
cmFuY2UgQ2xpZW50IENBAhEAmKLhIaYbjF4yzvN4Y/XijjAJBgUrDgMCGgUAoIIB4zAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAyMjAxNjQ2NDdaMCMG
CSqGSIb3DQEJBDEWBBRQiWJQB15Bxa6dpprwqwm97lUj+zBsBgkqhkiG9w0BCQ8xXzBdMAsG
CWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGIBgkrBgEEAYI3EAQxezB5
MGQxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJbnRlcm5ldDIxETAPBgNVBAsTCEluQ29tbW9u
MS4wLAYDVQQDEyVJbkNvbW1vbiBTdGFuZGFyZCBBc3N1cmFuY2UgQ2xpZW50IENBAhEAmKLh
IaYbjF4yzvN4Y/XijjCBigYLKoZIhvcNAQkQAgsxe6B5MGQxCzAJBgNVBAYTAlVTMRIwEAYD
VQQKEwlJbnRlcm5ldDIxETAPBgNVBAsTCEluQ29tbW9uMS4wLAYDVQQDEyVJbkNvbW1vbiBT
dGFuZGFyZCBBc3N1cmFuY2UgQ2xpZW50IENBAhEAmKLhIaYbjF4yzvN4Y/XijjANBgkqhkiG
9w0BAQEFAASCAQAncsXDEFR7PMBKfjHD98bbC4ksH9dczp7J7yQxxJSnHF4fc/dN47jVDg7Y
Zu+24j/l1O5u0L55wYAvqr1pgtrsdzcuGJri12FM0+OXFbm9RqCKf9gtMvAlaX/UYAti/0N2
M7cWp1Faw17MqBLpCZB5c7HxwgSVsHbU/kt8DdzkDdukEvglcBAOuQhleJIvYvfrSHWJLIlZ
PreRj6dFvTPcfl8TiX0mziUlkv5gkyM03jLPClYr7C/CGjN5b5+Ej0qhf7HU3tI+qa2GbOYb
AoJuLWjavNNa4V0TA4+Mu6yso1bIb/dDQJxJSgY4LEv3Pl8ZBUqndSiTbXk312K8UYGlAAAA
AAAA
--------------ms040407080806040202020907--
10 years, 9 months
Re: [Users] about live snapshot and qemu-kvm
by Karli Sjöberg
On Mon, 2014-02-17 at 09:59 -0500, Douglas Schilling Landgraf wrote:
> On 02/17/2014 02:00 AM, Karli Sjöberg wrote:
> > On Thu, 2014-02-13 at 14:42 -0500, Douglas Schilling Landgraf wrote:
> >> On 01/01/2014 06:24 AM, Gianluca Cecchi wrote:
> >>> On Wed, Jan 1, 2014 at 4:38 AM, R P Herrold wrote:
> >>>
> >>>>
> >>>> Out of curiousity, _what_ build environment 'flags' do you
> >>>> all, participating in this thread, refer to? -- the thread
> >>>> does not enumerate them explicitly, and one cannot expect to
> >>>> hit by 'indirect fire', a target not exposed
> >>>>
> >>>> With best regards, this New Year's eve
> >>>
> >>> I'm far from being a programmer, but as I went to compare build
> >>> environments, between
> >>> qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.src.rpm
> >>> and
> >>> qemu-kvm-0.12.1.2-2.415.el6_5.3.src.rpm
> >>> in related spec file I see
> >>> [g.cecchi@tekkaman SPECS]$ diff qemu-kvm.spec.upstream qemu-kvm.spec.rhev
> >>> 3c3
> >>> < %define rhev 0
> >>> ---
> >>>> %define rhev 1
> >>> 12928a12929
> >>>>>>>>>>> rhel-6.5
> >>>
> >>> and apart other probably not trivial implications, such as guest agent
> >>> part, I see that the "configure" command takes one extra argument in
> >>> base RH EL 6.5, that is
> >>>
> >>> --disable-rhev-features
> >>>
> >>> The only patch file containing this keyword is
> >>>
> >>> kvm-Block-streaming-disable-for-RHEL.patch
> >>>
> >>> and inside it there are these lines that impacts configure options and
> >>> related built qemu-kvm:
> >>>
> >>> --- a/configure
> >>> +++ b/configure
> >>> @@ -286,6 +286,7 @@ spice=""
> >>> smartcard=""
> >>> smartcard_nss=""
> >>> live_snapshots="yes"
> >>> +block_stream="yes"
> >>> usb_redir=""
> >>>
> >>> # OS specific
> >>> @@ -686,10 +687,22 @@ for opt do
> >>> ;;
> >>> --enable-live-snapshots) live_snapshots="yes"
> >>> ;;
> >>> + --disable-block-stream) block_stream="no"
> >>> + ;;
> >>> + --enable-block-stream) block_stream="yes"
> >>> + ;;
> >>> --disable-usb-redir) usb_redir="no"
> >>> ;;
> >>> --enable-usb-redir) usb_redir="yes"
> >>> ;;
> >>> + --disable-rhev-features)
> >>> + live_snapshots="no";
> >>> + block_stream="no";
> >>> + ;;
> >>> + --enable-rhev-features)
> >>> + live_snapshots="yes";
> >>> + block_stream="yes";
> >>> + ;;
> >>> *) echo "ERROR: unknown option $opt"; show_help="yes"
> >>> ;;
> >>> esac
> >>> @@ -863,8 +876,12 @@ echo " --disable-smartcard-nss disable
> >>> smartcard nss support"
> >>> echo " --enable-smartcard-nss enable smartcard nss support"
> >>> echo " --disable-live-snapshots disable live block device snapshot support"
> >>> echo " --enable-live-snapshots enable live block device snapshot support"
> >>> +echo " --disable-block-stream disable block streaming support"
> >>> +echo " --enable-block-stream enable block streaming support"
> >>> echo " --disable-usb-redir disable usb network redirection support"
> >>> echo " --enable-usb-redir enable usb network redirection support"
> >>> +echo " --disable-rhev-features disable RHEV-only features"
> >>> +echo " --enable-rhev-features enable RHEV-only features"
> >>> echo ""
> >>> echo "NOTE: The object files are built at the place where configure
> >>> is launched"
> >>> exit 1
> >>> @@ -2271,6 +2288,7 @@ echo "Trace backend $trace_backend"
> >>> echo "spice support $spice"
> >>> echo "nss used $smartcard_nss"
> >>> echo "Live snapshots $live_snapshots"
> >>> +echo "Block streaming $block_stream"
> >>> echo "xfsctl support $xfs"
> >>> echo "usb net redir $usb_redir"
> >>>
> >>> @@ -2526,6 +2544,10 @@ if test "$live_snapshots" = "yes" ; then
> >>> echo "CONFIG_LIVE_SNAPSHOTS=y" >> $config_host_mak
> >>> fi
> >>>
> >>> +if test "$block_stream" = "yes" ; then
> >>> + echo "CONFIG_BLOCK_STREAM=y" >> $config_host_mak
> >>> +fi
> >>> +
> >>> if test "$usb_redir" = "yes" ; then
> >>> echo "CONFIG_USB_REDIR=y" >> $config_host_mak
> >>> fi
> >>>
> >>> I don't think the rhev argument has instead implications in upstream
> >>> source qemu-kvm-0.12.1.2.tar.gz
> >>> So I think that if you want to dig more and if you have more
> >>> competences, you have to see the full spec file and the full patch
> >>> above.
> >>>
> >>> Files downloaded here:
> >>>
> >>> upstream
> >>> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/qemu-kv...
> >>>
> >>> rhev
> >>> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/qemu-...
> >>>
> >>
> >> Just for the record, we have setup a jenkins job to rebuild qemu-kvm for
> >> el6 until we get it officially from centos:
> >> http://jenkins.ovirt.org/view/Packaging/job/qemu-kvm-rhev_create_rpms_el6/
> >>
> >> --
> >> Cheers
> >> Douglas
> >> _______________________________________________
> >> Users mailing list
> >> Users(a)ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/users
> >
> > I think this calls for an oldschool question/statement;
> >
> > Who da man? ... You da man! :)
> >
> > Live snapshot now just works. Haven´t verified quiesce yet though, but
> > looks good as far as the events in webadmin is concerned. Next to test
> > is live disk migration.
> >
> >
> Thanks a lot for the feedback :)
>
> --
> Cheers
> Douglas
Hey,
have gone through the logs to verify quiescence and the only thing
actually mentioning it comes from vdsm.log:
Thread-127371::DEBUG::2014-02-19
14:54:15,612::BindingXMLRPC::977::vds::(wrapper) return vmSnapshot with
{'status': {'message': 'Done', 'code': 0}, 'quiesce': False}
What is it saying really? That quiescing failed, or that it was
deliberately taken without it, or what?
Nothing in qemu-ga.log either, even if changed to "--verbose". Like it
never got any calls to quiesce in the first place. The guest does have
the device[1] attached at least. The guest is CentOS-6.4 or 5, if that
matters.
[1]: /dev/virtio-ports/org.qemu.guest_agent.0
--
Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences Box 7079 (Visiting Address
Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg(a)slu.se
10 years, 9 months
[Users] Host Non-Operational from sanlock and VM fails to migrate
by Trey Dockendorf
I have a 2 node oVirt 3.3.2 cluster setup and am evaluating the setup
for production use on our HPC system for managing our VM
infrastructure. Currently I'm trying to utilize our DDR InfiniBand
fabric for the storage domains in oVirt using NFS over RDMA. I've
noticed some unstable behavior and it seems in every case to begin
with sanlock.
The ovirt web admin interface shows the following message as first
sign of trouble on 2014-Feb-03 07:45.
"Invalid status on Data Center Default. Setting Data Center status to
Non Responsive (On host vm01.brazos.tamu.edu, Error: Network error
during communication with the Host.).".
The single VM I had running is stuck in the "Migrating From" state.
virsh shows the VM paused on the crashed host and the one it attempted
to migrate to.
Right now I have a few concerns.
1) The cause of the sanlock (or other instability) and if it's related
to a bug or an issue using NFSoRDMA.
2) Why the VM failed to migrate if the second host had no issues. If
the first host is down should the VM be considered offline and booted
on the second host after first is fenced?
Attached are logs from the failed host (vm01) and the healthy host
(vm02) as well as engine. The failed host's /var/log/message is also
attached (vm01_message.log).
Thanks
- Trey
10 years, 9 months
[Users] oVirt 3.4 pre-release and GlusterFS support (F19)
by Brad House
I've been testing the 3.4 prerelease on Fedora 19. When I create a GlusterFS
(not POSIXFS) storage group and create a VM with a disk image on the storage
group, I see a POSIX mount created on the host. Upon further investigation,
when evaluating the executed qemu command line, it doesn't appear qemu is
being told to use libgfapi but rather that previously observed POSIX mount.
One other note, I'm specifically testing the hosted engine, and haven't
tested using the non-hosted variant.
The question is .... is this expected behavior, and if so, is it because
of the hosted engine? Or is this some form of regression from the
advertised feature list of oVirt 3.3? Anything I should try or look at?
I'm obviously concerned about the FUSE overhead with Gluster and would
like to avoid that if possible.
Thanks!
-Brad
10 years, 9 months
[Users] Why choose glusterfs over iscsi for oVirt storage?
by Justin Clacherty
--_000_C79B906B4ECB8E46A3281AC932C805502F49039Aexchangeredfish_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
I'm just setting up some storage for use with oVirt and am wondering why I =
might choose glusterfs rather than just exporting a raid array as iscsi. T=
he oVirt team seem to be pushing gluster (though that could just be because=
it's a Red Hat product). Can anyone answer this one?
What I have come up with is as follows.
For:
- easy to expand
- redundancy across storage devices/easy replication
- high availablility
- performance
- it's kind of cool :)
- maintenance?
Against (these are guesses):
- performance? (multiple layers of filesystems everywhere - fs in =
vm + image on gluster + gluster + block filesystem)
- complexity
- maintenance?
Any help here is appreciated. Also, does the underlying block level filesy=
stem matter here? VMs running under ovirt would be typical business applic=
ations - file serving (samba4), email, databases, web servers, etc.
Cheers,
Justin.
--_000_C79B906B4ECB8E46A3281AC932C805502F49039Aexchangeredfish_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:913467833;
mso-list-type:hybrid;
mso-list-template-ids:-1938410588 947050786 201916419 201916421 201916417 =
201916419 201916421 201916417 201916419 201916421;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-AU link=3D"#0563C1=
" vlink=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal>Hi,<o:p>=
</o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I&=
#8217;m just setting up some storage for use with oVirt and am wondering wh=
y I might choose glusterfs rather than just exporting a raid array as iscsi=
. The oVirt team seem to be pushing gluster (though that could just b=
e because it’s a Red Hat product). Can anyone answer this one?<=
o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorma=
l>What I have come up with is as follows.<o:p></o:p></p><p class=3DMsoNorma=
l><o:p> </o:p></p><p class=3DMsoNormal>For:<o:p></o:p></p><p class=3DM=
soListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if=
!supportLists]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt =
"Times New Roman"'> <=
/span></span><![endif]>easy to expand<o:p></o:p></p><p class=3DMsoListParag=
raph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLi=
sts]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'> </span></spa=
n><![endif]>redundancy across storage devices/easy replication<o:p></o:p></=
p><p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 leve=
l1 lfo1'><![if !supportLists]><span style=3D'mso-list:Ignore'>-<span style=
=3D'font:7.0pt "Times New Roman"'>  =
; </span></span><![endif]>high availablility<o:p></o:p></p><p c=
lass=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo=
1'><![if !supportLists]><span style=3D'mso-list:Ignore'>-<span style=3D'fon=
t:7.0pt "Times New Roman"'> =
</span></span><![endif]>performance<o:p></o:p></p><p class=3DMsoList=
Paragraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supp=
ortLists]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times=
New Roman"'> </span>=
</span><![endif]>it’s kind of cool <span style=3D'font-family:Wingdin=
gs'>J</span><o:p></o:p></p><p class=3DMsoListParagraph style=3D'text-indent=
:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'mso-l=
ist:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>  =
; </span></span><![endif]>maintenance?<=
o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorma=
l>Against (these are guesses):<o:p></o:p></p><p class=3DMsoListParagraph st=
yle=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><s=
pan style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'=
> </span></span><![en=
dif]>performance? (multiple layers of filesystems everywhere – fs in =
vm + image on gluster + gluster + block filesystem)<o:p></o:p></p><p class=
=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><=
![if !supportLists]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.=
0pt "Times New Roman"'> &nbs=
p; </span></span><![endif]>complexity<o:p></o:p></p><p class=3DMsoListParag=
raph style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLi=
sts]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'> </span></spa=
n><![endif]>maintenance?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:=
p></p><p class=3DMsoNormal>Any help here is appreciated. Also, does t=
he underlying block level filesystem matter here? VMs running under o=
virt would be typical business applications – file serving (samba4), =
email, databases, web servers, etc.<o:p></o:p></p><p class=3DMsoNormal><o:p=
> </o:p></p><p class=3DMsoNormal>Cheers,<o:p></o:p></p><p class=3DMsoN=
ormal>Justin.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p cl=
ass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p>=
</p></div></body></html>=
--_000_C79B906B4ECB8E46A3281AC932C805502F49039Aexchangeredfish_--
10 years, 9 months
[Users] API read-only access / roles
by Sander Grendelman
I'm working on (Zabbix) monitoring through the RESTful API.
Which role should I assign to the monitoring user?
The user only needs read access to the data but it looks like
I nead to assign at least an "Admin" role to the user to be
able to read data through the API.
For this I've created a "AdminLoginOnly" role that only has
System->Configure System->Login Permissions access.
Is this the way to go for this king of configuration? Or is there
a way to further minimize the permissions of this user?
Another issue is that a "Login" event is generated every time
the user connects through the API. This makes the "Events"
pane less useful / readable. Is there a way to disable this for
some users/roles?
10 years, 9 months
[Users] [QE] oVirt 3.4.0 RC status
by Sandro Bonazzola
Hi,
oVirt 3.4.0 beta3 has been released and is actually on QA.
We're going to start building oVirt 3.4.0 RC this Monday 2014-02-24 09:00 UTC from 3.4 branches.
repository composition will follow as soon as all packages will be built.
This build will be used for a third Test Day scheduled for Wed 2014-02-27.
The bug tracker [1] shows the following bugs blocking the release:
Whiteboard Bug ID Status Summary
infra 1055881 POST REST API: Search for an user in active directory by upn doesn't return any results ...
infra 1059258 POST REST API: Create user user@domain actually creates user only
infra 1060528 POST Error response to DELETE request of 'Everyone' group doesn't contains 'detail' field
infra 1064829 POST Regression: Add data center permission to user causes to internal error
integration 1058018 POST upgrade from 3.3 overwrites exports with acl None
network 1066953 POST Cannot edit network is "setup networks" dialog
network 1066956 POST Cannot create a bond in 'Setup networks' dialog
storage 1057761 NEW Can't discover iSCSI target
storage 1066466 POST Disk name doesn't get assigned automatically after a CREATE command.
ux 1066489 POST Event list not updating when events happen.
ux 1066827 NEW [webadmin] incorrect behavior of manual refresh in Host Main Tab
virt 1062615 POST utc_diff not updated according to a change in VM settings
Maintainers / Assignee:
- Please provide ETA on blockers bugs
- Please fix them ASAP
There are still 347 bugs [2] targeted to 3.4.0.
Excluding node and documentation bugs we still have 222 bugs [3] targeted to 3.4.0.
Please review them as soon as possible.
Maintainers / Assignee:
- Please remember to rebuild your packages before 2014-02-24 09:00 UTC if you want them to be included in 3.4.0 RC.
- Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed.
- Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
- Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-02-27
Be prepared for upcoming oVirt 3.4.0 Test Day on 2014-02-27!
Thanks to all people already testing 3.4.0 beta 3!
[1] https://bugzilla.redhat.com/1024889
[2] http://red.ht/1eIRZXM
[3] http://red.ht/1auBU3r
[4] http://www.ovirt.org/OVirt_3.4.0_release_notes
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 9 months
