Devel
Threads by month
- ----- 2025 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- 6472 discussions
This is a message in Mime Format. If you see this, your mail reader does not support this format.
--=_e9d61e8d48e903f0efdbb593e871d8b1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
----- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC=D0=BE=
=D0=B5 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=BE -----=0A=D0=94=D0=B0=D1=82=
=D0=B0: =D0=A7=D1=82=D0=B2 07 =D0=98=D1=8E=D0=BD 2012 11:37:22 +0400=0A=
=D0=9E=D1=82: Itamar Heim =0A=D0=A2=D0=B5=D0=BC=D0=B0: Re: [Engine-devel=
] Ovirt =C2=AD=C2=ADon Fedora17=0A=D0=9A=D0=BE=D0=BC=D1=83: ovirt(a)qip.ru=
=0A=0AOn 06/07/2012 08:55 AM, ovirt(a)qip.ru wrote:=0D=0A=0A> In libvirt t=
here is no such parameter even in=0D=0A=0A> http://kojipkgs.fedoraprojec=
t.org/packages/libvirt/0.9.12/1.fc18/src/libvirt-0.9.12-1.fc18.src.rpm=
=0D=0A=0A>=0D=0A=0A> ignore_readonly_and_shared_disks=0A=0Aplease reply=
to list=0A=0A>=0D=0A=0A>=0D=0A=0A>=0D=0A=0A>=0D=0A=0A> =D0=A7=D1=82=D0=
=B2 07 =D0=98=D1=8E=D0=BD 2012 09:15:53 +0400, Itamar Heim =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:=0D=0A=0A>=0D=0A=0A> On 06/06/2012 11=
:41 PM, Itamar Heim wrote:=0D=0A=0A> > On 06/06/2012 07:07 PM, Oved=
Ourfalli wrote:=0D=0A=0A> >> Hey,=0D=0A=0A> >>=0D=0A=0A> =
>> You should really send such question to engine-devel, as someone=0D=
=0A=0A> might=0D=0A=0A> >> have encountered such an issue, so t=
here might be a solution for=0D=0A=0A> that.=0D=0A=0A> >> Can y=
ou also attach the vdsm.log file (in the host, under the=0D=0A=0A> =
>> directory /var/log/vdsm/vdsm.log).=0D=0A=0A> >=0D=0A=0A> >=
I think i saw something around this recently.=0D=0A=0A> > federico=
?=0D=0A=0A>=0D=0A=0A> found it - https://bugzilla.redhat.com/show_bu=
g.cgi?id=3D828633=0D=0A=0A>=0D=0A=0A> >=0D=0A=0A> >>=0D=0A=0A>=
>> Thank you,=0D=0A=0A> >> Oved=0D=0A=0A> >>=0D=0A=0A> =
>> ----- Original Message -----=0D=0A=0A> >>> From: ovirt(a)qip.=
ru=0D=0A=0A> >>> To: "Oved Ourfalli"=0D=0A=0A> >>> Sent: Wedne=
sday, June 6, 2012 5:55:44 PM=0D=0A=0A> >>> Subject: Re: Re: Ovirt=
on Fedora17=0D=0A=0A> >>>=0D=0A=0A> >>> I use rpms from=0D=0A=
=0A> >>>=0D=0A=0A> >>> http:// jenkins .ovirt.org/job/ovirt_en=
gine_create_ rpms=0D=0A=0A> >>> /lastSuccessfulBuild/artifact/outpu=
t/*zip*/output.zip=0D=0A=0A> >>>=0D=0A=0A> >>> and another pro=
blem that not solved is that VM don't start with=0D=0A=0A> >>> atta=
ched CD=0D=0A=0A> >>>=0D=0A=0A> >>> if only I attach CD to VM=
I got libvirt error ( i use only needed=0D=0A=0A> >>> pachages fro=
m fedora17 repo except ovirt-engine and vdsm )=0D=0A=0A> >>>=0D=0A=
=0A> >>> in webadmin error=0D=0A=0A> >>>=0D=0A=0A> >>> VM=
VM01-Fedora17 is down. Exit message: internal error unsupported=0D=0A=
=0A> >>> configuration: Readonly leases are not supported=0D=0A=0A>=
>>>=0D=0A=0A> >>> in VM01-Fedora17.log=0D=0A=0A> >>>=0D=
=0A=0A> >>> red_worker_main: begin=0D=0A=0A> >>> display_chann=
el_create: create display channel=0D=0A=0A> >>> cursor_channel_crea=
te: create cursor channel=0D=0A=0A> >>> Domain id=3D2 is tainted: c=
ustom- mon itor=0D=0A=0A> >>> qemu: terminat ing on signal 15 from=
pid 606=0D=0A=0A> >>> 2012-06-06 14:39:15.167+0000: shutt ing down=
=0D=0A=0A> >>> 2012-06-06 14:39:37.381+0000: start ing up=0D=0A=0A>=
>>> LC_ALL=3DC PATH=3D/ usr /local/sbin:/ usr /local/bin:/ usr /sb=
in:/ usr=0D=0A=0A> >>> /bin QEMU _AUDIO_ DRV =3Dnone / usr /bin/qem=
u- kvm -S -M pc -0.14 -=0D=0A=0A> >>> cpu kvm 64,+ lahf _lm,+ ssse=
3,- cx 16 -enable- kvm -m 1024 - smp=0D=0A=0A> >>> 1,sockets=3D1,c=
ores=3D1,threads=3D1 -name VM01-Fedora17 - uuid=0D=0A=0A> >>> e0a70=
093-5b11-472f-b452-d1ae815028f4 - smbios=0D=0A=0A> >>> type=3D1,man=
ufacturer=3DRed Hat,product=3D RHEV Hyperv iso r=0D=0A=0A> >>>=0D=
=0A=0A> ,version=3D17-1,serial=3D49434D53-0200-9066-2500-66902500FE5=
3_00:25:90:66:53:fe,=0D=0A=0A>=0D=0A=0A> >>>=0D=0A=0A> >>> uui=
d =3De0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig -=0D=0A=0A> n=
odefaults=0D=0A=0A> >>> - chardev socket,id=3D char mon itor ,path=
=3D/var/lib/ libvirt=0D=0A=0A> >>> /qemu/VM01-Fedora17. mon itor,se=
rver, nowait - mon chardev =3D char=0D=0A=0A> >>> mon itor ,id=3D m=
on itor,mode=3Dcontrol - rtc=0D=0A=0A> base=3D2012-06-06T14:39:37,=
=0D=0A=0A> >>> driftfix =3Dslew -no-shutdown -device piix 3- usb -=
uhci ,id=3D usb=0D=0A=0A> >>> ,bus=3D pc i.0, addr =3D0x1.0x2 -dev=
ice virtio -serial- pc i,id=3D=0D=0A=0A> virtio=0D=0A=0A> >>> -=
serial0,bus=3D pc i.0, addr =3D0x4 -drive file=3D/ rhev=0D=0A=0A> >=
>> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee=0D=0A=
=0A> >>> -7146-4197- aecf -0 dfad=0D=0A=0A> >>>=0D=0A=0A> =
32b54ea/images/11111111-1111-1111-1111-111111111111/Fedora-17-x86_64-=
=0D=0A=0A> >>> netinst . iso ,if=3Dnone,media=3D cdrom ,id=3Ddrive-=
ide 0-1-0, readonly=0D=0A=0A> >>> =3Don,format=3Draw,serial=3D -de=
vice ide -drive,bus=3D ide=0D=0A=0A> >>> .1,unit=3D0,drive=3Ddrive-=
ide 0-1-0,id=3D ide 0-1-0 -drive file=3D/ rhev=0D=0A=0A> >>> /data=
-center/5ac3a99a- afdd=0D=0A=0A> >>> -11e1-8957-000c290cc066/e54855=
77-8f51-4213- acd=0D=0A=0A> >>>=0D=0A=0A> 8-f38e064cf308/images=
/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d=
50,if=3Dnone,id=3Ddrive-=0D=0A=0A>=0D=0A=0A> >>>=0D=0A=0A> >>>=
virtio -disk0,format=3D qcow=0D=0A=0A> >>> 2,serial=3D9865260a-748=
0-4cd2-8352-9f44ee2d6c37,cache=3Dnone, werror=0D=0A=0A> >>> =3Dstop=
, rerror =3Dstop, aio =3Dnative -device virtio - blk - pc i, scsi=0D=0A=
=0A> >>> =3Doff,bus=3D pc i.0, addr =3D0x5,drive=3Ddrive- virtio -d=
isk0,id=3D virtio=0D=0A=0A> >>> -disk0, bootindex =3D1 - netdev tap=
,fd=3D25,id=3D hostnet 0, vhost =3Don,=0D=0A=0A> >>> vhost fd=3D26=
-device virtio -net- pc i, netdev =3D hostnet=0D=0A=0A> >>> 0,id=
=3Dnet0,mac=3D00:1a:4a:10:00:00,bus=3D pc i.0, addr =3D0x3 - chardev=0D=
=0A=0A> >>> socket,id=3D charchannel 0,path=3D/var/lib/ libvirt=0D=
=0A=0A> >>> /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm=
,server,=0D=0A=0A> >>> nowait -device virtserialport,bus=3D virtio=
-serial0.0,nr=3D1,=0D=0A=0A> chardev =3D=0D=0A=0A> >>> charcha=
nnel 0,id=3Dchannel0,name=3Dcom. redhat . rhev m. vdsm -=0D=0A=0A> c=
hardev=0D=0A=0A> >>> pty ,id=3D charconsole 0 -device vi rtc onsole=
, chardev =3D=0D=0A=0A> charconsole=0D=0A=0A> >>> 0,id=3Dconsol=
e0 -device usb -tablet,id=3Dinput0 - vnc 0:0,password -k=0D=0A=0A> =
>>> en-us - vga qxl -global qxl - vga . vram _size=3D67108864 -device=
=0D=0A=0A> >>> virtio -balloon- pc i,id=3Dballoon0,bus=3D pc i.0, a=
ddr =3D0x6=0D=0A=0A> >>> l ibvir: Lock ing error : unsupported conf=
iguration: Readonly=0D=0A=0A> leases=0D=0A=0A> >>> are not supp=
orted=0D=0A=0A> >>> 2012-06-06 14:39:37.412+0000: shutt ing down=0D=
=0A=0A> >>>=0D=0A=0A> >>>=0D=0A=0A> >>> I tried to use th=
is patch on libvirt=0D=0A=0A> >>>=0D=0A=0A> >>> http:// www .m=
ail-archive.com/libvir-list@ redhat .com/ msg 56247.=0D=0A=0A> >>>=
html=0D=0A=0A> >>>=0D=0A=0A> >>> but it didn't help=0D=0A=0A>=
>>=0D=0A=0A> >> _____________________________________________=
__=0D=0A=0A> >> Engine-devel mailing list=0D=0A=0A> >> Engine-=
devel(a)ovirt.org=0D=0A=0A> >> http://lists.ovirt.org/mailman/listinf=
o/engine-devel=0D=0A=0A> >=0D=0A=0A>=0D=0A=0A>=0D=0A=0A>=0D=0A=0A>=
=0D=0A=0A> --=0D=0A=0A>=0A=0A----- =D0=9A=D0=BE=D0=BD=D0=B5=D1=86 =D0=BF=
=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC=D0=BE=D0=B3=D0=BE=
=D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B0 -----=0A=0A--
--=_e9d61e8d48e903f0efdbb593e871d8b1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<br><font color=3D"#666">----- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=
=BB=D0=B0=D0=B5=D0=BC=D0=BE=D0=B5 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=BE -=
----</font><br><b>=D0=94=D0=B0=D1=82=D0=B0:</b> =D0=A7=D1=82=D0=B2 07=
=D0=98=D1=8E=D0=BD 2012 11:37:22 +0400<br><b>=D0=9E=D1=82:</b> Itamar H=
eim <iheim(a)redhat.com><br><b>=D0=A2=D0=B5=D0=BC=D0=B0:</b> Re: [En=
gine-devel] Ovirt =C2=AD=C2=ADon Fedora17<br><b>=D0=9A=D0=BE=D0=BC=D1=83=
:</b> ovirt(a)qip.ru<br><br>On 06/07/2012 08:55 AM, ovirt(a)qip.ru wrote:=0D=
=0A<br>> In libvirt there is no such parameter even in=0D=0A<br>>=
<a style=3D"border-bottom:1px dotted; text-decoration: none" target=3D"=
_blank" href=3D"http://kojipkgs.fedoraproject.org/packages/libvirt/0.9.1=
2/1.fc18/src/libvirt-0.9.12-1.fc18.src.rpm" title=3D"=D0=9E=D1=82=D0=BA=
=D1=80=D1=8B=D1=82=D1=8C =D0=B2=D0=BD=D0=B5=D1=88=D0=BD=D1=8E=D1=8E =D1=
=81=D1=81=D1=8B=D0=BB=D0=BA=D1=83">http://kojipkgs.fedoraproject.org/pac=
kages/libvirt/0.9.12/1.fc18/src/libvirt-0.9.12-1.fc18.src.rpm</a>=0D=0A<=
br>>=0D=0A<br>> ignore_readonly_and_shared_disks=0D=0A<br>=0D=0A<b=
r>please reply to list=0D=0A<br>=0D=0A<br>>=0D=0A<br>>=0D=0A<br>&g=
t;=0D=0A<br>>=0D=0A<br>> =D0=A7=D1=82=D0=B2 07 =D0=98=D1=8E=D0=BD=
2012 09:15:53 +0400, Itamar Heim <iheim(a)redhat.com> =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:=0D=0A<br>>=0D=0A<br>> On 06/06=
/2012 11:41 PM, Itamar Heim wrote:=0D=0A<br>> > On 06/06/2012=
07:07 PM, Oved Ourfalli wrote:=0D=0A<br>> >> Hey,=0D=0A<b=
r>> >>=0D=0A<br>> >> You should really send=
such question to engine-devel, as someone=0D=0A<br>> might=0D=0A=
<br>> >> have encountered such an issue, so there might be=
a solution for=0D=0A<br>> that.=0D=0A<br>> >> Can=
you also attach the vdsm.log file (in the host, under the=0D=0A<br>>=
>> directory /var/log/vdsm/vdsm.log).=0D=0A<br>> >=
;=0D=0A<br>> > I think i saw something around this recently.=
=0D=0A<br>> > federico?=0D=0A<br>>=0D=0A<br>> found=
it - <a style=3D"border-bottom:1px dotted; text-decoration: none" targe=
t=3D"_blank" href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D82863=
3" title=3D"=D0=9E=D1=82=D0=BA=D1=80=D1=8B=D1=82=D1=8C =D0=B2=D0=BD=D0=
=B5=D1=88=D0=BD=D1=8E=D1=8E =D1=81=D1=81=D1=8B=D0=BB=D0=BA=D1=83">https:=
//bugzilla.redhat.com/show_bug.cgi?id=3D828633</a>=0D=0A<br>>=0D=0A<b=
r>> >=0D=0A<br>> >>=0D=0A<br>> >>=
Thank you,=0D=0A<br>> >> Oved=0D=0A<br>> >>=
=0D=0A<br>> >> ----- Original Message -----=0D=0A<br>>=
>>> From: ovirt(a)qip.ru=0D=0A<br>> >>> To=
: "Oved Ourfalli"<ovedo(a)redhat.com>=0D=0A<br>> >>>=
; Sent: Wednesday, June 6, 2012 5:55:44 PM=0D=0A<br>> >>&g=
t; Subject: Re: Re: Ovirt on Fedora17=0D=0A<br>> >>>=0D=
=0A<br>> >>> I use rpms from=0D=0A<br>> >>=
;>=0D=0A<br>> >>> http:// jenkins .ovirt.org/job/ovi=
rt_engine_create_ rpms=0D=0A<br>> >>> /lastSuccessfulBu=
ild/artifact/output/*zip*/output.zip=0D=0A<br>> >>>=0D=
=0A<br>> >>> and another problem that not solved is tha=
t VM don't start with=0D=0A<br>> >>> attached CD=0D=0A<=
br>> >>>=0D=0A<br>> >>> if only I atta=
ch CD to VM I got libvirt error ( i use only needed=0D=0A<br>> &=
gt;>> pachages from fedora17 repo except ovirt-engine and vdsm )=
=0D=0A<br>> >>>=0D=0A<br>> >>> in weba=
dmin error=0D=0A<br>> >>>=0D=0A<br>> >>&g=
t; VM VM01-Fedora17 is down. Exit message: internal error unsupported=0D=
=0A<br>> >>> configuration: Readonly leases are not sup=
ported=0D=0A<br>> >>>=0D=0A<br>> >>> i=
n VM01-Fedora17.log=0D=0A<br>> >>>=0D=0A<br>> &=
gt;>> red_worker_main: begin=0D=0A<br>> >>> displ=
ay_channel_create: create display channel=0D=0A<br>> >>>=
; cursor_channel_create: create cursor channel=0D=0A<br>> >&g=
t;> Domain id=3D2 is tainted: custom- mon itor=0D=0A<br>> >=
;>> qemu: terminat ing on signal 15 from pid 606=0D=0A<br>> =
>>> 2012-06-06 14:39:15.167+0000: shutt ing down=0D=0A<br>&g=
t; >>> 2012-06-06 14:39:37.381+0000: start ing up=0D=0A<br=
>> >>> LC_ALL=3DC PATH=3D/ usr /local/sbin:/ usr /local=
/bin:/ usr /sbin:/ usr=0D=0A<br>> >>> /bin QEMU _AUDIO_=
DRV =3Dnone / usr /bin/qemu- kvm -S -M pc -0.14 -=0D=0A<br>> &g=
t;>> cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 -=
smp=0D=0A<br>> >>> 1,sockets=3D1,cores=3D1,threads=3D1=
-name VM01-Fedora17 - uuid=0D=0A<br>> >>> e0a70093-5b1=
1-472f-b452-d1ae815028f4 - smbios=0D=0A<br>> >>> type=
=3D1,manufacturer=3DRed Hat,product=3D RHEV Hyperv iso r=0D=0A<br>> =
>>>=0D=0A<br>> ,version=3D17-1,serial=3D49434D53-02=
00-9066-2500-66902500FE53_00:25:90:66:53:fe,=0D=0A<br>>=0D=0A<br>>=
>>>=0D=0A<br>> >>> uuid =3De0a70093-5b11=
-472f-b452-d1ae815028f4 -nodefconfig -=0D=0A<br>> nodefaults=0D=
=0A<br>> >>> - chardev socket,id=3D char mon itor ,path=
=3D/var/lib/ libvirt=0D=0A<br>> >>> /qemu/VM01-Fedora17=
. mon itor,server, nowait - mon chardev =3D char=0D=0A<br>> >=
>> mon itor ,id=3D mon itor,mode=3Dcontrol - rtc=0D=0A<br>> =
base=3D2012-06-06T14:39:37,=0D=0A<br>> >>> driftfix=
=3Dslew -no-shutdown -device piix 3- usb - uhci ,id=3D usb=0D=0A<br>>=
; >>> ,bus=3D pc i.0, addr =3D0x1.0x2 -device virtio -seri=
al- pc i,id=3D=0D=0A<br>> virtio=0D=0A<br>> >>>=
-serial0,bus=3D pc i.0, addr =3D0x4 -drive file=3D/ rhev=0D=0A<br>>=
>>> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d=
2221 cee=0D=0A<br>> >>> -7146-4197- aecf -0 dfad=0D=0A<=
br>> >>>=0D=0A<br>> 32b54ea/images/11111111-1111=
-1111-1111-111111111111/Fedora-17-x86_64-=0D=0A<br>> >>>=
; netinst . iso ,if=3Dnone,media=3D cdrom ,id=3Ddrive- ide 0-1-0, readon=
ly=0D=0A<br>> >>> =3Don,format=3Draw,serial=3D -device=
ide -drive,bus=3D ide=0D=0A<br>> >>> .1,unit=3D0,drive=
=3Ddrive- ide 0-1-0,id=3D ide 0-1-0 -drive file=3D/ rhev=0D=0A<br>> =
>>> /data-center/5ac3a99a- afdd=0D=0A<br>> >>=
;> -11e1-8957-000c290cc066/e5485577-8f51-4213- acd=0D=0A<br>> =
>>>=0D=0A<br>> 8-f38e064cf308/images/9865260a-7480-4cd=
2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=3Dnone,id=3D=
drive-=0D=0A<br>>=0D=0A<br>> >>>=0D=0A<br>> =
>>> virtio -disk0,format=3D qcow=0D=0A<br>> >>&g=
t; 2,serial=3D9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=3Dnone, werror=
=0D=0A<br>> >>> =3Dstop, rerror =3Dstop, aio =3Dnative=
-device virtio - blk - pc i, scsi=0D=0A<br>> >>> =3Dof=
f,bus=3D pc i.0, addr =3D0x5,drive=3Ddrive- virtio -disk0,id=3D virtio=
=0D=0A<br>> >>> -disk0, bootindex =3D1 - netdev tap,fd=
=3D25,id=3D hostnet 0, vhost =3Don,=0D=0A<br>> >>> vhos=
t fd=3D26 -device virtio -net- pc i, netdev =3D hostnet=0D=0A<br>> =
>>> 0,id=3Dnet0,mac=3D00:1a:4a:10:00:00,bus=3D pc i.0, addr=
=3D0x3 - chardev=0D=0A<br>> >>> socket,id=3D charchann=
el 0,path=3D/var/lib/ libvirt=0D=0A<br>> >>> /qemu/chan=
nels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server,=0D=0A<br>> =
>>> nowait -device virtserialport,bus=3D virtio -serial0.0,n=
r=3D1,=0D=0A<br>> chardev =3D=0D=0A<br>> >>> cha=
rchannel 0,id=3Dchannel0,name=3Dcom. redhat . rhev m. vdsm -=0D=0A<br>&g=
t; chardev=0D=0A<br>> >>> pty ,id=3D charconsole 0=
-device vi rtc onsole, chardev =3D=0D=0A<br>> charconsole=0D=0A<=
br>> >>> 0,id=3Dconsole0 -device usb -tablet,id=3Dinput=
0 - vnc 0:0,password -k=0D=0A<br>> >>> en-us - vga qxl=
-global qxl - vga . vram _size=3D67108864 -device=0D=0A<br>> &g=
t;>> virtio -balloon- pc i,id=3Dballoon0,bus=3D pc i.0, addr =3D0x=
6=0D=0A<br>> >>> l ibvir: Lock ing error : unsupported=
configuration: Readonly=0D=0A<br>> leases=0D=0A<br>> >=
;>> are not supported=0D=0A<br>> >>> 2012-06-06 1=
4:39:37.412+0000: shutt ing down=0D=0A<br>> >>>=0D=0A<b=
r>> >>>=0D=0A<br>> >>> I tried to use=
this patch on libvirt=0D=0A<br>> >>>=0D=0A<br>> =
>>> http:// www .mail-archive.com/libvir-list@ redhat .com/=
msg 56247.=0D=0A<br>> >>> html=0D=0A<br>> >=
>>=0D=0A<br>> >>> but it didn't help=0D=0A<br>>=
; >>=0D=0A<br>> >> ____________________________=
___________________=0D=0A<br>> >> Engine-devel mailing lis=
t=0D=0A<br>> >> Engine-devel(a)ovirt.org=0D=0A<br>> =
>> <a style=3D"border-bottom:1px dotted; text-decoration: none" t=
arget=3D"_blank" href=3D"http://lists.ovirt.org/mailman/listinfo/engine-=
devel" title=3D"=D0=9E=D1=82=D0=BA=D1=80=D1=8B=D1=82=D1=8C =D0=B2=D0=BD=
=D0=B5=D1=88=D0=BD=D1=8E=D1=8E =D1=81=D1=81=D1=8B=D0=BB=D0=BA=D1=83">htt=
p://lists.ovirt.org/mailman/listinfo/engine-devel</a>=0D=0A<br>> =
>=0D=0A<br>>=0D=0A<br>>=0D=0A<br>>=0D=0A<br>>=0D=0A<br>=
> --=0D=0A<br>>=0D=0A<br>=0D=0A<br>=0D=0A<br><br><font color=3D"#6=
66">----- =D0=9A=D0=BE=D0=BD=D0=B5=D1=86 =D0=BF=D0=B5=D1=80=D0=B5=D1=81=
=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC=D0=BE=D0=B3=D0=BE =D0=BF=D0=B8=D1=81=D1=
=8C=D0=BC=D0=B0 -----</font><br><br>--<br>=0D=0A<br>
--=_e9d61e8d48e903f0efdbb593e871d8b1--
1
0
Hey,
You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).
Thank you,
Oved
----- Original Message -----
> From: ovirt(a)qip.ru
> To: "Oved Ourfalli" <ovedo(a)redhat.com>
> Sent: Wednesday, June 6, 2012 5:55:44 PM
> Subject: Re: Re: Ovirt on Fedora17
>
> I use rpms from
>
> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
>
> and another problem that not solved is that VM don't start with
> attached CD
>
> if only I attach CD to VM I got libvirt error ( i use only needed
> pachages from fedora17 repo except ovirt-engine and vdsm )
>
> in webadmin error
>
> VM VM01-Fedora17 is down. Exit message: internal error unsupported
> configuration: Readonly leases are not supported
>
> in VM01-Fedora17.log
>
> red_worker_main: begin
> display_channel_create: create display channel
> cursor_channel_create: create cursor channel
> Domain id=2 is tainted: custom- mon itor
> qemu: terminat ing on signal 15 from pid 606
> 2012-06-06 14:39:15.167+0000: shutt ing down
> 2012-06-06 14:39:37.381+0000: start ing up
> LC_ALL=C PATH=/ usr /local/sbin:/ usr /local/bin:/ usr /sbin:/ usr
> /bin QEMU _AUDIO_ DRV =none / usr /bin/qemu- kvm -S -M pc -0.14 -
> cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 - smp
> 1,sockets=1,cores=1,threads=1 -name VM01-Fedora17 - uuid
> e0a70093-5b11-472f-b452-d1ae815028f4 - smbios
> type=1,manufacturer=Red Hat,product= RHEV Hyperv iso r
> ,version=17-1,serial=49434D53-0200-9066-2500-66902500FE53_00:25:90:66:53:fe,
> uuid =e0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig - nodefaults
> - chardev socket,id= char mon itor ,path=/var/lib/ libvirt
> /qemu/VM01-Fedora17. mon itor,server, nowait - mon chardev = char
> mon itor ,id= mon itor,mode=control - rtc base=2012-06-06T14:39:37,
> driftfix =slew -no-shutdown -device piix 3- usb - uhci ,id= usb
> ,bus= pc i.0, addr =0x1.0x2 -device virtio -serial- pc i,id= virtio
> -serial0,bus= pc i.0, addr =0x4 -drive file=/ rhev
> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee
> -7146-4197- aecf -0 dfad
> 32b54ea/images/11111111-1111-1111-1111-111111111111/Fedora-17-x86_64-
> netinst . iso ,if=none,media= cdrom ,id=drive- ide 0-1-0, readonly
> =on,format=raw,serial= -device ide -drive,bus= ide
> .1,unit=0,drive=drive- ide 0-1-0,id= ide 0-1-0 -drive file=/ rhev
> /data-center/5ac3a99a- afdd
> -11e1-8957-000c290cc066/e5485577-8f51-4213- acd
> 8-f38e064cf308/images/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=none,id=drive-
> virtio -disk0,format= qcow
> 2,serial=9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=none, werror
> =stop, rerror =stop, aio =native -device virtio - blk - pc i, scsi
> =off,bus= pc i.0, addr =0x5,drive=drive- virtio -disk0,id= virtio
> -disk0, bootindex =1 - netdev tap,fd=25,id= hostnet 0, vhost =on,
> vhost fd=26 -device virtio -net- pc i, netdev = hostnet
> 0,id=net0,mac=00:1a:4a:10:00:00,bus= pc i.0, addr =0x3 - chardev
> socket,id= charchannel 0,path=/var/lib/ libvirt
> /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server,
> nowait -device virtserialport,bus= virtio -serial0.0,nr=1, chardev =
> charchannel 0,id=channel0,name=com. redhat . rhev m. vdsm - chardev
> pty ,id= charconsole 0 -device vi rtc onsole, chardev = charconsole
> 0,id=console0 -device usb -tablet,id=input0 - vnc 0:0,password -k
> en-us - vga qxl -global qxl - vga . vram _size=67108864 -device
> virtio -balloon- pc i,id=balloon0,bus= pc i.0, addr =0x6
> l ibvir: Lock ing error : unsupported configuration: Readonly leases
> are not supported
> 2012-06-06 14:39:37.412+0000: shutt ing down
>
>
> I tried to use this patch on libvirt
>
> http:// www .mail-archive.com/libvir-list@ redhat .com/ msg 56247.
> html
>
> but it didn't help
2
2
06 Jun '12
Almost 4 month after oVirt's first release, we're one step closer to the next version.
The Feature Freeze is scheduled for tomorrow, June 7th, and shortly after that, new "beta" builds should be uploaded into http://ovirt.org:/releases/beta
Currently, http://ovirt.org:/releases/beta/fedora/17 is populated with "alpha" builds of oVirt. Feel free to test them, and share with us your feedback.
Regards,
--
Ofer Schreiber
oVirt Release Manager
1
0
Hi
Can some review and approve this small patch?
http://gerrit.ovirt.org/#/c/4554/
--
Shu Ming<shuming(a)linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory
1
0
--=_d6ac7c2f-41ec-4ce1-8875-286eff93a19f
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
The following meeting has been modified:
Subject: oVirt - quantum integration
Organiser: "Livnat Peer" <lpeer(a)redhat.com>
Location: "Antartica - TLV" <antartica-tlv(a)redhat.com> [MODIFIED]
Resources: "Antartica - TLV" <antartica-tlv(a)redhat.com> [MODIFIED]
Time: Wednesday, 6 June, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem
Invitees: engine-devel(a)ovirt.org; arch(a)ovirt.com; simon(a)redhat.com; gkotton(a)redhat.com; lhornyak(a)redhat.com; kroberts(a)redhat.com; rkukura(a)redhat.com
*~*~*~*~*~*~*~*~*~*
Hi All,
We'll have a discussion on oVirt-Quantum integration.
In the meeting we'll discuss -
http://www.ovirt.org/wiki/Quantum_and_oVirt
Thanks, Livnat
Bridge ID: 972506565679
Dial-in information:
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679
Reservationless-Plus International Dial-In Number: (212) 729-5016
Conference code: 972506565679
Global Access Numbers Local:
Australia, Sydney Dial-In #: 0289852326
Austria, Vienna Dial-In #: 012534978196
Belgium, Brussels Dial-In #: 027920405
China Dial-In #: 4006205013
Denmark, Copenhagen Dial-In #: 32729215
Finland, Helsinki Dial-In #: 0923194436
France, Paris Dial-In #: 0170377140
Germany, Berlin Dial-In #: 030300190579
Ireland, Dublin Dial-In #: 014367793
Italy, Milan Dial-In #: 0236269529
Netherlands, Amsterdam Dial-In #: 0207975872
Norway, Oslo Dial-In #: 21033188
Singapore Dial-In #: 64840858
Spain, Barcelona Dial-In #: 935452328
Sweden, Stockholm Dial-In #: 0850513770
Switzerland, Geneva Dial-In #: 0225927881
United Kingdom Dial-In #: 02078970515
United Kingdom Dial-In #: 08445790676
United Kingdom, LocalCall Dial-In #: 08445790678
United States Dial-In #: 2127295016
Global Access Numbers Tollfree:
Argentina Dial-In #: 8004441016
Australia Dial-In #: 1800337169
Austria Dial-In #: 0800005898
Bahamas Dial-In #: 18002054776
Bahrain Dial-In #: 80004377
Belgium Dial-In #: 080048325
Brazil Dial-In #: 08008921002
Bulgaria Dial-In #: 008001100236
Chile Dial-In #: 800370228
Colombia Dial-In #: 018009134033
Costa Rica Dial-In #: 08000131048
Cyprus Dial-In #: 80095297
Czech Republic Dial-In #: 800700318
Denmark Dial-In #: 80887114
Dominican Republic Dial-In #: 18887512313
Estonia Dial-In #: 8000100232
Finland Dial-In #: 0800117116
France Dial-In #: 0805632867
Germany Dial-In #: 8006647541
Greece Dial-In #: 00800127562
Hong Kong Dial-In #: 800930349
Hungary Dial-In #: 0680016796
Iceland Dial-In #: 8008967
India Dial-In #: 0008006501533
Indonesia Dial-In #: 0018030179162
Ireland Dial-In #: 1800932401
Israel Dial-In #: 1809462557
Italy Dial-In #: 800985897
Jamaica Dial-In #: 18002050328
Japan Dial-In #: 0120934453
Korea (South) Dial-In #: 007986517393
Latvia Dial-In #: 80003339
Lithuania Dial-In #: 880030479
Luxembourg Dial-In #: 80026595
Malaysia Dial-In #: 1800814451
Mexico Dial-In #: 0018664590915
New Zealand Dial-In #: 0800888167
Norway Dial-In #: 80012994
Panama Dial-In #: 008002269184
Philippines Dial-In #: 180011100991
Poland Dial-In #: 008001210187
Portugal Dial-In #: 800814625
Russian Federation Dial-In #: 81080028341012
Saint Kitts and Nevis Dial-In #: 18002059252
Singapore Dial-In #: 8006162235
Slovak Republic Dial-In #: 0800001441
South Africa Dial-In #: 0800981148
Spain Dial-In #: 800300524
Sweden Dial-In #: 200896860
Switzerland Dial-In #: 800650077
Taiwan Dial-In #: 00801127141
Thailand Dial-In #: 001800656966
Trinidad and Tobago Dial-In #: 18002024615
United Arab Emirates Dial-In #: 8000650591
United Kingdom Dial-In #: 08006948057
United States Dial-In #: 8004518679
Uruguay Dial-In #: 00040190315
Venezuela Dial-In #: 08001627182
--=_d6ac7c2f-41ec-4ce1-8875-286eff93a19f
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><h3>The following meeting has been modified:</h3>
<p>
<table border=3D'0'>
<tr><th align=3Dleft>Subject:</th><td>oVirt - quantum integration </td></tr=
>
<tr><th align=3Dleft>Organiser:</th><td>"Livnat Peer" <lpeer(a)redhat.com&=
gt; </td></tr>
</table>
<p>
<table border=3D'0'>
<tr><th align=3Dleft>Location:</th><td>"Antartica - TLV" <antartica-tlv@red=
hat.com> [MODIFIED]</td></tr>
<tr><th align=3Dleft>Resources:</th><td>"Antartica - TLV" <antartica-tlv@re=
dhat.com> [MODIFIED]</td></tr>
<tr><th align=3Dleft>Time:</th><td>Wednesday, 6 June, 2012, 4:00:00 PM - 5:=
00:00 PM GMT +02:00 Jerusalem
</td></tr></table>
<p>
<table border=3D'0'>
<tr><th align=3Dleft>Invitees:</th><td>engine-devel(a)ovirt.org; arch(a)ovirt.c=
om; simon(a)redhat.com; gkotton(a)redhat.com; lhornyak(a)redhat.com; kroberts@red=
hat.com; rkukura(a)redhat.com </td></tr>
</table>
<div>*~*~*~*~*~*~*~*~*~*</div><br><br>Hi All, <br><br>We'll have a discussi=
on on oVirt-Quantum integration. <br>In the meeting we'll discuss - <br>htt=
p://www.ovirt.org/wiki/Quantum_and_oVirt <br><br>Thanks, Livnat <br><br>Bri=
dge ID: 972506565679 <br>Dial-in information: <br>Reservationless-Plus Toll=
Free Dial-In Number (US & Canada): (800) 451-8679 <br>Reservationless-=
Plus International Dial-In Number: (212) 729-5016 <br>Conference code: 9725=
06565679 <br><br>Global Access Numbers Local: <br>Australia, Sydney Dial-In=
#: 0289852326 <br>Austria, Vienna Dial-In #: 012534978196 <br>Belgium, Bru=
ssels Dial-In #: 027920405 <br>China Dial-In #: 4006205013 <br>Denmark, Cop=
enhagen Dial-In #: 32729215 <br>Finland, Helsinki Dial-In #: 0923194436 <br=
>France, Paris Dial-In #: 0170377140 <br>Germany, Berlin Dial-In #: 0303001=
90579 <br>Ireland, Dublin Dial-In #: 014367793 <br>Italy, Milan Dial-In #: =
0236269529 <br>Netherlands, Amsterdam Dial-In #: 0207975872 <br>Norway, Osl=
o Dial-In #: 21033188 <br>Singapore Dial-In #: 64840858 <br>Spain, Barcelon=
a Dial-In #: 935452328 <br>Sweden, Stockholm Dial-In #: 0850513770 <br>Swit=
zerland, Geneva Dial-In #: 0225927881 <br>United Kingdom Dial-In #: 0207897=
0515 <br>United Kingdom Dial-In #: 08445790676 <br>United Kingdom, LocalCal=
l Dial-In #: 08445790678 <br>United States Dial-In #: 2127295016 <br><br><b=
r>Global Access Numbers Tollfree: <br>Argentina Dial-In #: 8004441016 <br>A=
ustralia Dial-In #: 1800337169 <br>Austria Dial-In #: 0800005898 <br>Bahama=
s Dial-In #: 18002054776 <br>Bahrain Dial-In #: 80004377 <br>Belgium Dial-I=
n #: 080048325 <br>Brazil Dial-In #: 08008921002 <br>Bulgaria Dial-In #: 00=
8001100236 <br>Chile Dial-In #: 800370228 <br>Colombia Dial-In #: 018009134=
033 <br>Costa Rica Dial-In #: 08000131048 <br>Cyprus Dial-In #: 80095297 <b=
r>Czech Republic Dial-In #: 800700318 <br>Denmark Dial-In #: 80887114 <br>D=
ominican Republic Dial-In #: 18887512313 <br>Estonia Dial-In #: 8000100232 =
<br>Finland Dial-In #: 0800117116 <br>France Dial-In #: 0805632867 <br>Germ=
any Dial-In #: 8006647541 <br>Greece Dial-In #: 00800127562 <br>Hong Kong D=
ial-In #: 800930349 <br>Hungary Dial-In #: 0680016796 <br>Iceland Dial-In #=
: 8008967 <br>India Dial-In #: 0008006501533 <br>Indonesia Dial-In #: 00180=
30179162 <br>Ireland Dial-In #: 1800932401 <br>Israel Dial-In #: 1809462557=
<br>Italy Dial-In #: 800985897 <br>Jamaica Dial-In #: 18002050328 <br>Japa=
n Dial-In #: 0120934453 <br>Korea (South) Dial-In #: 007986517393 <br>Latvi=
a Dial-In #: 80003339 <br>Lithuania Dial-In #: 880030479 <br>Luxembourg Dia=
l-In #: 80026595 <br>Malaysia Dial-In #: 1800814451 <br>Mexico Dial-In #: 0=
018664590915 <br>New Zealand Dial-In #: 0800888167 <br>Norway Dial-In #: 80=
012994 <br>Panama Dial-In #: 008002269184 <br>Philippines Dial-In #: 180011=
100991 <br>Poland Dial-In #: 008001210187 <br>Portugal Dial-In #: 800814625=
<br>Russian Federation Dial-In #: 81080028341012 <br>Saint Kitts and Nevis=
Dial-In #: 18002059252 <br>Singapore Dial-In #: 8006162235 <br>Slovak Repu=
blic Dial-In #: 0800001441 <br>South Africa Dial-In #: 0800981148 <br>Spain=
Dial-In #: 800300524 <br>Sweden Dial-In #: 200896860 <br>Switzerland Dial-=
In #: 800650077 <br>Taiwan Dial-In #: 00801127141 <br>Thailand Dial-In #: 0=
01800656966 <br>Trinidad and Tobago Dial-In #: 18002024615 <br>United Arab =
Emirates Dial-In #: 8000650591 <br>United Kingdom Dial-In #: 08006948057 <b=
r>United States Dial-In #: 8004518679 <br>Uruguay Dial-In #: 00040190315 <b=
r>Venezuela Dial-In #: 08001627182 </body></html>
--=_d6ac7c2f-41ec-4ce1-8875-286eff93a19f
Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=2SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T020000
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:6ca077c8-6f6d-4826-9cc4-7b54012c05e7
SUMMARY:oVirt - quantum integration
LOCATION:"Antartica - TLV" <antartica-tlv(a)redhat.com>
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
devel(a)ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:arch@ov
irt.com
ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T
RUE:mailto:simon@redhat.com
ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:gkotton@redhat.com
ATTENDEE;CN=Laszlo Hornyak;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T
RUE:mailto:lhornyak@redhat.com
ATTENDEE;CN=Keith Robertson;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE:mailto:kroberts@redhat.com
ATTENDEE;CN=Robert Kukura;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
UE:mailto:rkukura@redhat.com
ATTENDEE;CN=Antartica - TLV;CUTYPE=RESOURCE;ROLE=NON-PARTICIPANT;PARTSTAT=NE
EDS-ACTION;RSVP=TRUE:mailto:antartica-tlv@redhat.com
ORGANIZER;CN=Livnat Peer:mailto:lpeer@redhat.com
DTSTART;TZID="Asia/Jerusalem":20120606T160000
DTEND;TZID="Asia/Jerusalem":20120606T170000
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20120606T123843Z
DTSTAMP:20120606T123843Z
SEQUENCE:1
DESCRIPTION:The following meeting has been modified:\n\nSubject: oVirt - qua
ntum integration \nOrganiser: "Livnat Peer" <lpeer(a)redhat.com> \n\nLocation:
"Antartica - TLV" <antartica-tlv(a)redhat.com> [MODIFIED]\nResources: "Antart
ica - TLV" <antartica-tlv(a)redhat.com> [MODIFIED]\nTime: Wednesday\, 6 June\,
2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem\n \nInvitees: engine-de
vel(a)ovirt.org\; arch(a)ovirt.com\; simon(a)redhat.com\; gkotton(a)redhat.com\; lho
rnyak(a)redhat.com\; kroberts(a)redhat.com\; rkukura(a)redhat.com \n\n\n*~*~*~*~*~
*~*~*~*~*\n\n\nHi All\, \n\nWe'll have a discussion on oVirt-Quantum integra
tion. \nIn the meeting we'll discuss - \nhttp://www.ovirt.org/wiki/Quantum_a
nd_oVirt \n\nThanks\, Livnat \n\nBridge ID: 972506565679 \nDial-in informati
on: \nReservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451
-8679 \nReservationless-Plus International Dial-In Number: (212) 729-5016 \n
Conference code: 972506565679 \n\nGlobal Access Numbers Local: \nAustralia\,
Sydney Dial-In #: 0289852326 \nAustria\, Vienna Dial-In #: 012534978196 \nB
elgium\, Brussels Dial-In #: 027920405 \nChina Dial-In #: 4006205013 \nDenma
rk\, Copenhagen Dial-In #: 32729215 \nFinland\, Helsinki Dial-In #: 09231944
36 \nFrance\, Paris Dial-In #: 0170377140 \nGermany\, Berlin Dial-In #: 0303
00190579 \nIreland\, Dublin Dial-In #: 014367793 \nItaly\, Milan Dial-In #:
0236269529 \nNetherlands\, Amsterdam Dial-In #: 0207975872 \nNorway\, Oslo D
ial-In #: 21033188 \nSingapore Dial-In #: 64840858 \nSpain\, Barcelona Dial-
In #: 935452328 \nSweden\, Stockholm Dial-In #: 0850513770 \nSwitzerland\, G
eneva Dial-In #: 0225927881 \nUnited Kingdom Dial-In #: 02078970515 \nUnited
Kingdom Dial-In #: 08445790676 \nUnited Kingdom\, LocalCall Dial-In #: 0844
5790678 \nUnited States Dial-In #: 2127295016 \n\n\nGlobal Access Numbers To
llfree: \nArgentina Dial-In #: 8004441016 \nAustralia Dial-In #: 1800337169
\nAustria Dial-In #: 0800005898 \nBahamas Dial-In #: 18002054776 \nBahrain D
ial-In #: 80004377 \nBelgium Dial-In #: 080048325 \nBrazil Dial-In #: 080089
21002 \nBulgaria Dial-In #: 008001100236 \nChile Dial-In #: 800370228 \nColo
mbia Dial-In #: 018009134033 \nCosta Rica Dial-In #: 08000131048 \nCyprus Di
al-In #: 80095297 \nCzech Republic Dial-In #: 800700318 \nDenmark Dial-In #:
80887114 \nDominican Republic Dial-In #: 18887512313 \nEstonia Dial-In #: 8
000100232 \nFinland Dial-In #: 0800117116 \nFrance Dial-In #: 0805632867 \nG
ermany Dial-In #: 8006647541 \nGreece Dial-In #: 00800127562 \nHong Kong Dia
l-In #: 800930349 \nHungary Dial-In #: 0680016796 \nIceland Dial-In #: 80089
67 \nIndia Dial-In #: 0008006501533 \nIndonesia Dial-In #: 0018030179162 \nI
reland Dial-In #: 1800932401 \nIsrael Dial-In #: 1809462557 \nItaly Dial-In
#: 800985897 \nJamaica Dial-In #: 18002050328 \nJapan Dial-In #: 0120934453
\nKorea (South) Dial-In #: 007986517393 \nLatvia Dial-In #: 80003339 \nLithu
ania Dial-In #: 880030479 \nLuxembourg Dial-In #: 80026595 \nMalaysia Dial-I
n #: 1800814451 \nMexico Dial-In #: 0018664590915 \nNew Zealand Dial-In #: 0
800888167 \nNorway Dial-In #: 80012994 \nPanama Dial-In #: 008002269184 \nPh
ilippines Dial-In #: 180011100991 \nPoland Dial-In #: 008001210187 \nPortuga
l Dial-In #: 800814625 \nRussian Federation Dial-In #: 81080028341012 \nSain
t Kitts and Nevis Dial-In #: 18002059252 \nSingapore Dial-In #: 8006162235 \
nSlovak Republic Dial-In #: 0800001441 \nSouth Africa Dial-In #: 0800981148
\nSpain Dial-In #: 800300524 \nSweden Dial-In #: 200896860 \nSwitzerland Dia
l-In #: 800650077 \nTaiwan Dial-In #: 00801127141 \nThailand Dial-In #: 0018
00656966 \nTrinidad and Tobago Dial-In #: 18002024615 \nUnited Arab Emirates
Dial-In #: 8000650591 \nUnited Kingdom Dial-In #: 08006948057 \nUnited Stat
es Dial-In #: 8004518679 \nUruguay Dial-In #: 00040190315 \nVenezuela Dial-I
n #: 08001627182
X-ALT-DESC;FMTTYPE=text/html:<html><body><h3>The following meeting has been
modified:</h3>\n\n<p>\n<table border='0'>\n<tr><th align=left>Subject:</th><
td>oVirt - quantum integration </td></tr>\n<tr><th align=left>Organiser:</th
><td>"Livnat Peer" <\;lpeer(a)redhat.com>\; </td></tr>\n</table>\n<p>\n<ta
ble border='0'>\n<tr><th align=left>Location:</th><td>"Antartica - TLV" <ant
artica-tlv(a)redhat.com> [MODIFIED]</td></tr>\n<tr><th align=left>Resources:</
th><td>"Antartica - TLV" <antartica-tlv(a)redhat.com> [MODIFIED]</td></tr>\n<t
r><th align=left>Time:</th><td>Wednesday\, 6 June\, 2012\, 4:00:00 PM - 5:00
:00 PM GMT +02:00 Jerusalem\n </td></tr></table>\n<p>\n<table border='0'>\n<
tr><th align=left>Invitees:</th><td>engine-devel(a)ovirt.org\; arch(a)ovirt.com\
; simon(a)redhat.com\; gkotton(a)redhat.com\; lhornyak(a)redhat.com\; kroberts@red
hat.com\; rkukura(a)redhat.com </td></tr>\n</table>\n<div>*~*~*~*~*~*~*~*~*~*<
/div><br><br>Hi All\, <br><br>We'll have a discussion on oVirt-Quantum integ
ration. <br>In the meeting we'll discuss - <br>http://www.ovirt.org/wiki/Qua
ntum_and_oVirt <br><br>Thanks\, Livnat <br><br>Bridge ID: 972506565679 <br>D
ial-in information: <br>Reservationless-Plus Toll Free Dial-In Number (US &a
mp\; Canada): (800) 451-8679 <br>Reservationless-Plus International Dial-In
Number: (212) 729-5016 <br>Conference code: 972506565679 <br><br>Global Acce
ss Numbers Local: <br>Australia\, Sydney Dial-In #: 0289852326 <br>Austria\,
Vienna Dial-In #: 012534978196 <br>Belgium\, Brussels Dial-In #: 027920405
<br>China Dial-In #: 4006205013 <br>Denmark\, Copenhagen Dial-In #: 32729215
<br>Finland\, Helsinki Dial-In #: 0923194436 <br>France\, Paris Dial-In #:
0170377140 <br>Germany\, Berlin Dial-In #: 030300190579 <br>Ireland\, Dublin
Dial-In #: 014367793 <br>Italy\, Milan Dial-In #: 0236269529 <br>Netherland
s\, Amsterdam Dial-In #: 0207975872 <br>Norway\, Oslo Dial-In #: 21033188 <b
r>Singapore Dial-In #: 64840858 <br>Spain\, Barcelona Dial-In #: 935452328 <
br>Sweden\, Stockholm Dial-In #: 0850513770 <br>Switzerland\, Geneva Dial-In
#: 0225927881 <br>United Kingdom Dial-In #: 02078970515 <br>United Kingdom
Dial-In #: 08445790676 <br>United Kingdom\, LocalCall Dial-In #: 08445790678
<br>United States Dial-In #: 2127295016 <br><br><br>Global Access Numbers T
ollfree: <br>Argentina Dial-In #: 8004441016 <br>Australia Dial-In #: 180033
7169 <br>Austria Dial-In #: 0800005898 <br>Bahamas Dial-In #: 18002054776 <b
r>Bahrain Dial-In #: 80004377 <br>Belgium Dial-In #: 080048325 <br>Brazil Di
al-In #: 08008921002 <br>Bulgaria Dial-In #: 008001100236 <br>Chile Dial-In
#: 800370228 <br>Colombia Dial-In #: 018009134033 <br>Costa Rica Dial-In #:
08000131048 <br>Cyprus Dial-In #: 80095297 <br>Czech Republic Dial-In #: 800
700318 <br>Denmark Dial-In #: 80887114 <br>Dominican Republic Dial-In #: 188
87512313 <br>Estonia Dial-In #: 8000100232 <br>Finland Dial-In #: 0800117116
<br>France Dial-In #: 0805632867 <br>Germany Dial-In #: 8006647541 <br>Gree
ce Dial-In #: 00800127562 <br>Hong Kong Dial-In #: 800930349 <br>Hungary Dia
l-In #: 0680016796 <br>Iceland Dial-In #: 8008967 <br>India Dial-In #: 00080
06501533 <br>Indonesia Dial-In #: 0018030179162 <br>Ireland Dial-In #: 18009
32401 <br>Israel Dial-In #: 1809462557 <br>Italy Dial-In #: 800985897 <br>Ja
maica Dial-In #: 18002050328 <br>Japan Dial-In #: 0120934453 <br>Korea (Sout
h) Dial-In #: 007986517393 <br>Latvia Dial-In #: 80003339 <br>Lithuania Dial
-In #: 880030479 <br>Luxembourg Dial-In #: 80026595 <br>Malaysia Dial-In #:
1800814451 <br>Mexico Dial-In #: 0018664590915 <br>New Zealand Dial-In #: 08
00888167 <br>Norway Dial-In #: 80012994 <br>Panama Dial-In #: 008002269184 <
br>Philippines Dial-In #: 180011100991 <br>Poland Dial-In #: 008001210187 <b
r>Portugal Dial-In #: 800814625 <br>Russian Federation Dial-In #: 8108002834
1012 <br>Saint Kitts and Nevis Dial-In #: 18002059252 <br>Singapore Dial-In
#: 8006162235 <br>Slovak Republic Dial-In #: 0800001441 <br>South Africa Dia
l-In #: 0800981148 <br>Spain Dial-In #: 800300524 <br>Sweden Dial-In #: 2008
96860 <br>Switzerland Dial-In #: 800650077 <br>Taiwan Dial-In #: 00801127141
<br>Thailand Dial-In #: 001800656966 <br>Trinidad and Tobago Dial-In #: 180
02024615 <br>United Arab Emirates Dial-In #: 8000650591 <br>United Kingdom D
ial-In #: 08006948057 <br>United States Dial-In #: 8004518679 <br>Uruguay Di
al-In #: 00040190315 <br>Venezuela Dial-In #: 08001627182 </body></html>
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:-PT5M
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
--=_d6ac7c2f-41ec-4ce1-8875-286eff93a19f--
1
0
Hi All,
A friendly reminder we'll have ovirt-quantum integration session in one
hour.
Thanks, Livnat
1
0
[Engine-devel] engine complained that it couldn't find the ovirtmgmt interface in my FC16 ovirt node
by Shu Ming 05 Jun '12
by Shu Ming 05 Jun '12
05 Jun '12
Hi,
I found the followings logs in my engine and engine set the node to
non-operation state. It is strange that I can see the ovirtmgmt
network interface was there in the ovirt node. Below are the logs and
steps I did in ovirt node. It seems that engine didn't get the right
network interface information from ovirt node. Can any one show me some
steps to debug this problem?
In my engine log:
2012-06-06 00:45:00,185 INFO
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
(QuartzScheduler_Worker-68) [897fad0] START,
SetVdsStatusVDSCommand(vdsId = 848bcff0-ae2a-11e1-bb49-5254001498c4,
status=NonOperational, nonOperationalReason=NETWORK_UNREACHABLE), log
id: 53d27ec8
2012-06-06 00:45:00,188 INFO
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
(QuartzScheduler_Worker-68) [897fad0] FINISH, SetVdsStatusVDSCommand,
log id: 53d27ec8
2012-06-06 00:45:00,190 INFO
[org.ovirt.engine.core.bll.SetNonOperationalVdsCommand]
(QuartzScheduler_Worker-68) [897fad0] Host ovirt-node1 is set to
Non-Operational, it is missing the following networks: ovirtmgmt,
2012-06-06 00:45:00,198 INFO
[org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand]
(QuartzScheduler_Worker-68) [60291e0d] Running command:
HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entities
affected : ID: 848bcff0-ae2a-11e1-bb49-5254001498c4 Type: VDS
However in my ovirt node, the ovirtmgmt interface was there.
[root@ovirt-node1 ~]# brctl show
bridge name bridge id STP enabled interfaces
ovirtmgmt 8000.5cf3fce432a0 no eth0
[root@ovirt-node1 ~]#
[root@ovirt-node1 ~]# ifconfig -a|more
bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond3 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A0
inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:315 errors:0 dropped:0 overruns:0 frame:0
TX packets:143 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30785 (30.0 KiB) TX bytes:38501 (37.5 KiB)
Interrupt:28 Memory:92000000-92012800
eth1 Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A2
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:40 Memory:94000000-94012800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:13156 errors:0 dropped:0 overruns:0 frame:0
TX packets:13156 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3271301 (3.1 MiB) TX bytes:3271301 (3.1 MiB)
ovirtmgmt Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A0
inet addr:9.181.129.110 Bcast:9.181.129.255 Mask:255.255.255.0
inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:182 errors:0 dropped:3 overruns:0 frame:0
TX packets:133 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:16290 (15.9 KiB) TX bytes:36667 (35.8 KiB)
[root@ovirt-node1 ~]#
[root@ovirt-node1 ~]# ifconfig -a|more
bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond3 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
bond4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A0
inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:2036 errors:0 dropped:0 overruns:0 frame:0
TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:184913 (180.5 KiB) TX bytes:65801 (64.2 KiB)
Interrupt:28 Memory:92000000-92012800
eth1 Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A2
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:40 Memory:94000000-94012800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:13186 errors:0 dropped:0 overruns:0 frame:0
TX packets:13186 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3278642 (3.1 MiB) TX bytes:3278642 (3.1 MiB)
ovirtmgmt Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A0
inet addr:9.181.129.110 Bcast:9.181.129.255 Mask:255.255.255.0
inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1562 errors:0 dropped:69 overruns:0 frame:0
TX packets:225 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:116628 (113.8 KiB) TX bytes:62627 (61.1 KiB)
p4p1 Link encap:Ethernet HWaddr 00:00:C9:E5:A1:36
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
p4p2 Link encap:Ethernet HWaddr 00:00:C9:E5:A1:3A
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
usb0 Link encap:Ethernet HWaddr 5E:F3:FC:DC:32:A3
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@ovirt-node1 ~]#
--
Shu Ming<shuming(a)linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory
2
1
Re: [Engine-devel] Change in ovirt-engine[master]: restapi: non admin user api - Filtering user queries (#78308...
by Itamar Heim 04 Jun '12
by Itamar Heim 04 Jun '12
04 Jun '12
please send a status of what works, what not, and gaps to close.
thanks
On 06/04/2012 05:24 PM, asaf(a)redhat.com wrote:
> Asaf Shakarchi has submitted this change and it was merged.
>
> Change subject: restapi: non admin user api - Filtering user queries (#783087)
> ......................................................................
>
>
> restapi: non admin user api - Filtering user queries (#783087)
>
> https://bugzilla.redhat.com/783087
>
> - A global support for filtering content based on user permissions for all
> query executions based on the 'filter' HTTP header.
> Note: The 'filter' attribute header is stateless and must be specified by the client per HTTP request.
>
> - Added a unit test for BackendResourceTest currently for testing the 'filter' HTTP header.
>
> - Abstracted base test class from resource centric base test class
>
> - Changed TestHelper.getMethod to seek for 'isMethod()' if 'getMethod()' wasn't found.
>
> Change-Id: I8e5e23cbb8e883f6005f69be46fa528ac6e7518c
> Signed-off-by: Asaf Shakarchi<asaf(a)redhat.com>
> ---
> M backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendResource.java
> M backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BaseBackendResource.java
> A backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/AbstractBackendBaseTest.java
> M backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/AbstractBackendResourceTest.java
> M backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/BackendApiResourceTest.java
> A backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/BackendResourceTest.java
> M backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/BackendVmResourceTest.java
> 7 files changed, 490 insertions(+), 387 deletions(-)
>
> Approvals:
> Asaf Shakarchi: Verified; Looks good to me, approved
>
>
> --
> To view, visit http://gerrit.ovirt.org/4360
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: merged
> Gerrit-Change-Id: I8e5e23cbb8e883f6005f69be46fa528ac6e7518c
> Gerrit-PatchSet: 9
> Gerrit-Project: ovirt-engine
> Gerrit-Branch: master
> Gerrit-Owner: Asaf Shakarchi<asaf(a)redhat.com>
> Gerrit-Reviewer: Asaf Shakarchi<asaf(a)redhat.com>
> Gerrit-Reviewer: Michael Pasternak<mpastern(a)redhat.com>
> Gerrit-Reviewer: Ori Liel<oliel(a)redhat.com>
> _______________________________________________
> Engine-commits mailing list
> Engine-commits(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-commits
1
0
This is a multi-part message in MIME format.
--------------040303020501050109020008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello,
I'm starting to know the engine code. I chose a little unstandardized
behaviour to follow through the devel process. I have a patch and I'd
like to know if you fell relevant to correct this issue:
- Description: Adding a LOCAL storage [1], webadmin does not validate
path against regex, sendind the invalid path (with final slash) to vdsm
[2] [3]. But, adding a NFS storage, the path is validated before
contacting vdsm [4] avoiding extra vdsm processing and quickly/clearly
informing user about what's wrong.
- Expected result: Same behaviour to NFS and LOCALFS storage path
validation. Validate LOCALFS path in webadmin before send it to vdsm [5].
- Newbie doubt: Wouldn't be better to validate the both local and nfs
path on the backend, achieving all user interfaces/APIs?
[1] -
https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEc…
[2] -
https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEc…
[3] - https://gist.github.com/2762656
[4] -
https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEc…
[5] -
https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEc…
I look forward to hearing your comments.
Best Regards,
--
Pahim
--------------040303020501050109020008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
I'm starting to know the engine code. I chose a little
unstandardized behaviour to follow through the devel process. I have
a patch and I'd like to know if you fell relevant to correct this
issue:<br>
<br>
- Description: Adding a LOCAL storage [1], webadmin does not
validate path against regex, sendind the invalid path (with final
slash) to vdsm [2] [3]. But, adding a NFS storage, the path is
validated before contacting vdsm [4] avoiding extra vdsm processing
and quickly/clearly informing user about what's wrong.<br>
<br>
- Expected result: Same behaviour to NFS and LOCALFS storage path
validation. Validate LOCALFS path in webadmin before send it to vdsm
[5].<br>
<br>
- Newbie doubt: Wouldn't be better to validate the both local and
nfs path on the backend, achieving all user interfaces/APIs?<br>
<br>
[1] -
<a class="moz-txt-link-freetext" href="https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEc…">https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEc…</a><br>
[2] -
<a class="moz-txt-link-freetext" href="https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEc…">https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEc…</a><br>
[3] - <a class="moz-txt-link-freetext" href="https://gist.github.com/2762656">https://gist.github.com/2762656</a><br>
[4] -
<a class="moz-txt-link-freetext" href="https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEc…">https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEc…</a><br>
[5] -
<a class="moz-txt-link-freetext" href="https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEc…">https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEc…</a><br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
I look forward to hearing your comments.<br>
<br>
Best Regards,<br>
--<br>
Pahim<br>
</body>
</html>
--------------040303020501050109020008--
4
6
Re: [Engine-devel] Fwd: [vdsm] RFC: Writeup on VDSM-libstoragemgmt integration
by Deepak C Shetty 04 Jun '12
by Deepak C Shetty 04 Jun '12
04 Jun '12
This is a multi-part message in MIME format.
--------------060306070208010807040506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
(for some reason i never recd. Adam's note tho' I am subscribed to all
the 3 lists Cc'ed here, strange !
Replying off from the mail fwd.ed to me from my colleague, pls see my
responses inline below. Thanks. )
>
>
> ---------- Forwarded message ----------
> From: *Adam Litke* <agl(a)us.ibm.com <mailto:agl@us.ibm.com>>
> Date: Thu, May 31, 2012 at 7:31 PM
> Subject: Re: [vdsm] RFC: Writeup on VDSM-libstoragemgmt integration
> To: Deepak C Shetty <deepakcs(a)linux.vnet.ibm.com
> <mailto:deepakcs@linux.vnet.ibm.com>>
> Cc: libstoragemgmt-devel(a)lists.sourceforge.net
> <mailto:libstoragemgmt-devel@lists.sourceforge.net>,
> engine-devel(a)ovirt.org <mailto:engine-devel@ovirt.org>, VDSM Project
> Development <vdsm-devel(a)lists.fedorahosted.org
> <mailto:vdsm-devel@lists.fedorahosted.org>>
>
>
> On Wed, May 30, 2012 at 03:08:46PM +0530, Deepak C Shetty wrote:
> > Hello All,
> >
> > I have a draft write-up on the VDSM-libstoragemgmt integration.
> > I wanted to run this thru' the mailing list(s) to help tune and
> > crystallize it, before putting it on the ovirt wiki.
> > I have run this once thru Ayal and Tony, so have some of their
> > comments incorporated.
> >
> > I still have few doubts/questions, which I have posted below with
> > lines ending with '?'
> >
> > Comments / Suggestions are welcome & appreciated.
> >
> > thanx,
> > deepak
> >
> > [Ccing engine-devel and libstoragemgmt lists as this stuff is
> > relevant to them too]
> >
> >
> --------------------------------------------------------------------------------------------------------------
> >
> > 1) Background:
> >
> > VDSM provides high level API for node virtualization management. It
> > acts in response to the requests sent by oVirt Engine, which uses
> > VDSM to do all node virtualization related tasks, including but not
> > limited to storage management.
> >
> > libstoragemgmt aims to provide vendor agnostic API for managing
> > external storage array. It should help system administrators
> > utilizing open source solutions have a way to programmatically
> > manage their storage hardware in a vendor neutral way. It also aims
> > to facilitate management automation, ease of use and take advantage
> > of storage vendor supported features which improve storage
> > performance and space utilization.
> >
> > Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/
> >
> > libstoragemgmt (LSM) today supports C and python plugins for talking
> > to external storage array using SMI-S as well as native interfaces
> > (eg: netapp plugin )
> > Plan is to grow the SMI-S interface as needed over time and add more
> > vendor specific plugins for exploiting features not possible via
> > SMI-S or have better alternatives than using SMI-S.
> > For eg: Many of the copy offload features require to use vendor
> > specific commands, which justifies the need for a vendor specific
> > plugin.
> >
> >
> > 2) Goals:
> >
> > 2a) Ability to plugin external storage array into oVirt/VDSM
> > virtualization stack, in a vendor neutral way.
> >
> > 2b) Ability to list features/capabilities and other statistical
> > info of the array
> >
> > 2c) Ability to utilize the storage array offload capabilities
> > from oVirt/VDSM.
> >
> >
> > 3) Details:
> >
> > LSM will sit as a new repository engine in VDSM.
> > VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192
> >
> > Current plan is to have LSM co-exist with VDSM on the virtualization
> nodes.
> >
> > *Note : 'storage' used below is generic. It can be a file/nfs-export
> > for NAS targets and LUN/logical-drive for SAN targets.
> >
> > VDSM can use LSM and do the following...
> > - Provision storage
> > - Consume storage
> >
> > 3.1) Provisioning Storage using LSM
> >
> > Typically this will be done by a Storage administrator.
> >
> > oVirt/VDSM should provide storage admin the
> > - ability to list the different storage arrays along with their
> > types (NAS/SAN), capabilities, free/used space.
> > - ability to provision storage using any of the array
> > capabilities (eg: thin provisioned lun or new NFS export )
> > - ability to manage the provisioned storage (eg: resize/delete
> storage)
>
> I guess vdsm will need to model a new type of object (perhaps
> StorageTarget) to
> be used for performing the above provisioning operations. Then, to
> consume the
> provisioned storage, we could create a StorageConnectionRef by passing
> in a
> StorageTarget object and some additional parameters. Sound about right?
Sounds right to me, but I am not an expert in VDSM object model,
Saggi/Ayal/Dan can provide
more inputs here. The (proposed) storage array entity in ovirt engine
can use this vdsm object to
communicate and work with the storage array in doing the provisioning work.
Going ahead with the change to new Image Repository, I was envisioning
that LSM when integrated as
a new repo engine will exhibit "Storage Provisioning" as a implicit
feature/capability, only then it
will be picked up by the StorageTarget, else not.
>
> > Once the storage is provisioned by the storage admin, VDSM will have
> > to refresh the host(s) for them to be able to see the newly
> > provisioned storage.
>
> How would this refresh affect currently connected storage and running VMs?
I am not too sure on this... looking for more info from the experts
here. Per ayal, getDeviceInfo
should help refresh, but by 'affect' are you referring to what happens
if post refresh the device
IDs and/or names of the existing storage on the host changes ? What
exactly is the concern here ?
>
> > 3.1.1) Potential flows:
> >
> > Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is
> > needed to make LUN available to list of hosts passed by mgmt
> > Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices)
> > Repeat above for all relevant hosts (depending on list passed
> > earlier, mostly relevant when extending an existing VG)
> > Mgmt -> use LUN in normal flows.
> >
> >
> > 3.1.2) How oVirt Engine will know which LSM to use ?
> >
> > Normally the way this works today is that user can choose the host
> > to use (default today is SPM), however there are a few flows where
> > mgmt will know which host to use:
> > 1. extend storage domain (add LUN to existing VG) - Use SPM and make
> > sure *all* hosts that need access to this SD can see the new LUN
> > 2. attach new LUN to a VM which is pinned to a specific host - use
> this host
> > 3. attach new LUN to a VM which is not pinned - use a host from the
> > cluster the VM belongs to and make sure all nodes in cluster can see
> > the new LUN
>
> You are still going to need to worry about locking the shared storage
> resource.
> Will libstoragemgmt have storage clustering support baked in or will
> we continue
> to rely on SPM? If the latter is true, most/all of these operations
> would still
> need to be done by SPM if I understand correctly.
The above scenarios were noted by me on behalf of Ayal.
I don't think LSM will worry abt storage clustering. We are just using
LSM to 'talk' with the
storage array. I am not sure if we need locking for the above scenarios.
We are just ensuring
that the newly provisioned LUN is visible to the relevant hosts, so not
sure why we might need
locking?
>
> > Flows for which there is no clear candidate (Maybe we can use the
> > SPM host itself which is the default ?)
> > 1. create a new disk without attaching it to any VM
> > 2. create a LUN for a new storage domain
>
> Yes, SPM would seem correct to me.
>
> > 3.2) Consuming storage using LSM
> >
> > Typically this will be done by a virtualization administrator
> >
> > oVirt/VDSM should allow virtualization admin to
> > - Create a new storage domain using the storage on the array.
> > - Be able to specify whether VDSM should use the storage offload
> > capability (default) or override it to use its own internal logic.
>
> If vdsm can make the right decisions, I would prefer that vdsm decides
> when to use
> hardware offload and when to use software algorithms without administrator
> intervention. It's another case where oVirt can provide value-add by
> simplifying the configuration and providing optimal performance.
Per ayal, the thought was that in scenarios we know where the storage
array implementation is
not optimal, we can override and tell VDSM to use its internal logic
than offload.
>
> > 4) VDSM potential changes:
> >
> > 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk
> > ? which bring another question...1 array == 1 storage domain OR 1
> > LUN/nfs-export on the array == 1 storage domain ?
>
> Saggi has mentioned some ideas on this topic so I will encourage him
> to explain
> his thoughts here.
Looking forward to Saggi's thoughts :)
>
> >
> > Pros & Cons of each...
> >
> > 1 array == 1 storage domain
> > - Each new vmdisk (aka volume) will be a new lun/file on the array.
> > - Easier to exploit offload capabilities, as they are available
> > at the LUN/File granularity
> > - Will there be any issues where there will be too many
> > LUNs/Files ... any maxluns limit on linux hosts that we might hit ?
> > -- VDSM has been tested with 1K LUNs and it worked fine - ayal
> > - Storage array limitations on the number of LUNs can be a
> > downside here.
> > - Would it be ok to share the array for hosting another storage
> > domain if need be ?
> > -- Provided the existing domain is not utilising all of the
> > free space
> > -- We can create new LUNs and hand it over to anyone needed ?
> > -- Changes needed in VDSM to work with raw LUNs, today it only
> > has support for consuming LUNs via VG/LV.
> >
> > 1 LUN/nfs-export on the array == 1 storage domain
> > - How to represent a new vmdisk (aka vdsm volume) if its a LUN
> > provisioned using SAN target ?
> > -- Will it be VG/LV as is done today for block domains ?
> > -- If yes, then it will be difficult to exploit offload
> > capabilities, as they are at LUN level, not at LV level.
> > - Each new vmdisk will be a new file on the nfs-export, assuming
> > offload capability is available at the file level, so this should
> > work for NAS targets ?
> > - Can use the storage array for hosting multiple storage domains.
> > -- Provision one more LUN and use it for another storage
> > domain if need be.
> > - VDSM already supports this today, as part of block storage
> > domains for LUNs case.
> >
> > Note that we will allow user to do either one of the two options
> > above, depending on need.
> >
> > 4.2) Storage domain metadata will also include the
> > features/capabilities of the storage array as reported by LSM.
> > - Capabilities (taken via LSM) will be stored in the domain
> > metadata during storage domain create flow.
> > - Need changes in oVirt engine as well ( see 'oVirt Engine
> > potential changes' section below )
>
> Do we want to store the exact hw capabilities or some set of vdsm
> chosen feature
> bits that are set at create time based on the discovered hw
> capabilities? The
> difference would be that vdsm could choose which features to enable at
> create
> time and update those features later if needed.
IIUC, you are saying VDSM will only look for those capabilities, whcih
are of interest to it and
store it? That should be done by way LSM returning its capabilities as
part of it being a Image Repo.
I am referring to how localFSRepo (def capabilities) is shown in the PoC
Saggie posted @
http://gerrit.ovirt.org/#change,192
>
> > 4.3) VDSM to poll LSM for array capabilities on a regular basis ?
> > Per ayal:
> > - If we have a 'storage array' entity in oVirt Engine (see
> > 'oVirt Engine potential changes' section below ) then we can have a
> > 'refresh capabilities' button/verb.
> > - We can periodically query the storage array.
> > - Query LSM before running operations (sounds redundant to me,
> > but if it's cheap enough it could be simplest).
> >
> > Probably need a combination of 1+2 (query at very low frequency
> > - 1/hour or 1/day + refresh button)
>
> This problem can be aleviated by the abstraction I suggested above.
> Then, LSM
> can be queried only when we may want to adjust the policy connected with a
> particular storage target.
Not clear to me, can you explain more ?
LSM might need to be contacted for updating the capabilities, because
storage admins can add/remove
capabilities over a period of time. Many storage arrays provide ability
to enable/disable array
features on demand.
>
> > 5) oVirt Engine potential changes - as described by ayal :
> >
> > - We will either need a new 'storage array' entity in engine to
> > keep credentials, or, in case of storage array as storage domain,
> > just keep this info as part of the domain at engine level.
> > - Have a 'storage array' entity in oVirt Engine to support
> > 'refresh capabilities' as a button/verb.
> > - When user during storage provisioning, selects a LUN exported
> > from a storage array (via LSM), the oVirt Engine would know from
> > then onwards that this LUN is being served via LSM.
> > It would then be able to query the capabilities of the LUN
> > and show it to the virt admin during storage consumption flow.
> >
> > 6) Potential flows:
> > - Create snapshot flow
> > -- VDSM will check the snapshot offload capability in the
> > domain metadata
> > -- If available, and override is not configured, it will use
> > LSM to offload LUN/File snapshot
> > -- If override is configured or capability is not available,
> > it will use its internal logic to create
> > snapshot (qcow2).
> >
> > - Copy/Clone vmdisk flow
> > -- VDSM will check the copy offload capability in the domain
> > metadata
> > -- If available, and override is not configured, it will use
> > LSM to offload LUN/File copy
> > -- If override is configured or capability is not available,
> > it will use its internal logic to create
> > snapshot (eg: dd cmd in case of LUN).
> >
> > 7) LSM potential changes:
> >
> > - list features/capabilities of the array. Eg: copy offload,
> > thin prov. etc.
> > - list containers (aka pools) (present in LSM today)
> > - Ability to list different types of arrays being managed, their
> > capabilities and used/free space
> > - Ability to create/list/delete/resize volumes ( LUN or exports,
> > available in LSM as of today)
> > - Get monitoring info with object (LUN/snapshot/volume) as
> > optional parameter for specific info. eg: container/pool free/used
> > space, raid type etc.
> >
> > Need to make sure above info is listed in a coherent way across
> > arrays (number of LUNs, raid type used? free/total per
> > container/pool, per LUN?. Also need I/O statistics wherever
> > possible.
I forgot to add this in the original mail.. adding it now.
8) Concerns/Issues
- Per Tony of libstoragemgmt
-- Some additional things to consider.
-- Some of the array vendors may not allow multiple points of control at
the same time. e.g. you may not be able to have 2 or more nodes running
libStorageMgmt at the same time talking to the same array. NetApp
limits what things can be done concurrently.
-- LibStorageMgmt currently just provides the bits to control external
storage arrays. The plug-in daemon and the plug-ins themselves execute
unprivileged.
- How does the change from SPM to SDM will affect the above discussions ?
--------------060306070208010807040506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<tt>(for some reason i never recd. Adam's note tho' I am subscribed
to all the 3 lists Cc'ed here, strange !<br>
Replying off from the mail fwd.ed to me from my colleague, pls
see my responses inline below. Thanks. )<br>
<br>
</tt>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Adam Litke</b> <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:agl@us.ibm.com">agl(a)us.ibm.com</a>></span><br>
Date: Thu, May 31, 2012 at 7:31 PM<br>
Subject: Re: [vdsm] RFC: Writeup on VDSM-libstoragemgmt
integration<br>
To: Deepak C Shetty <<a moz-do-not-send="true"
href="mailto:deepakcs@linux.vnet.ibm.com">deepakcs(a)linux.vnet.ibm.com</a>><br>
Cc: <a moz-do-not-send="true"
href="mailto:libstoragemgmt-devel@lists.sourceforge.net">libstoragemgmt-devel(a)lists.sourceforge.net</a>,
<a moz-do-not-send="true" href="mailto:engine-devel@ovirt.org">engine-devel(a)ovirt.org</a>,
VDSM Project Development <<a moz-do-not-send="true"
href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel(a)lists.fedorahosted.org</a>><br>
<br>
<br>
<div class="HOEnZb">
<div class="h5">On Wed, May 30, 2012 at 03:08:46PM +0530,
Deepak C Shetty wrote:<br>
> Hello All,<br>
><br>
> I have a draft write-up on the VDSM-libstoragemgmt
integration.<br>
> I wanted to run this thru' the mailing list(s) to help
tune and<br>
> crystallize it, before putting it on the ovirt wiki.<br>
> I have run this once thru Ayal and Tony, so have some
of their<br>
> comments incorporated.<br>
><br>
> I still have few doubts/questions, which I have posted
below with<br>
> lines ending with '?'<br>
><br>
> Comments / Suggestions are welcome & appreciated.<br>
><br>
> thanx,<br>
> deepak<br>
><br>
> [Ccing engine-devel and libstoragemgmt lists as this
stuff is<br>
> relevant to them too]<br>
><br>
>
--------------------------------------------------------------------------------------------------------------<br>
><br>
> 1) Background:<br>
><br>
> VDSM provides high level API for node virtualization
management. It<br>
> acts in response to the requests sent by oVirt Engine,
which uses<br>
> VDSM to do all node virtualization related tasks,
including but not<br>
> limited to storage management.<br>
><br>
> libstoragemgmt aims to provide vendor agnostic API for
managing<br>
> external storage array. It should help system
administrators<br>
> utilizing open source solutions have a way to
programmatically<br>
> manage their storage hardware in a vendor neutral way.
It also aims<br>
> to facilitate management automation, ease of use and
take advantage<br>
> of storage vendor supported features which improve
storage<br>
> performance and space utilization.<br>
><br>
> Home Page: <a moz-do-not-send="true"
href="http://sourceforge.net/apps/trac/libstoragemgmt/"
target="_blank">http://sourceforge.net/apps/trac/libstoragemgmt/</a><br>
><br>
> libstoragemgmt (LSM) today supports C and python
plugins for talking<br>
> to external storage array using SMI-S as well as native
interfaces<br>
> (eg: netapp plugin )<br>
> Plan is to grow the SMI-S interface as needed over time
and add more<br>
> vendor specific plugins for exploiting features not
possible via<br>
> SMI-S or have better alternatives than using SMI-S.<br>
> For eg: Many of the copy offload features require to
use vendor<br>
> specific commands, which justifies the need for a
vendor specific<br>
> plugin.<br>
><br>
><br>
> 2) Goals:<br>
><br>
> 2a) Ability to plugin external storage array into
oVirt/VDSM<br>
> virtualization stack, in a vendor neutral way.<br>
><br>
> 2b) Ability to list features/capabilities and other
statistical<br>
> info of the array<br>
><br>
> 2c) Ability to utilize the storage array offload
capabilities<br>
> from oVirt/VDSM.<br>
><br>
><br>
> 3) Details:<br>
><br>
> LSM will sit as a new repository engine in VDSM.<br>
> VDSM Repository Engine WIP @ <a moz-do-not-send="true"
href="http://gerrit.ovirt.org/#change,192" target="_blank">http://gerrit.ovirt.org/#change,192</a><br>
><br>
> Current plan is to have LSM co-exist with VDSM on the
virtualization nodes.<br>
><br>
> *Note : 'storage' used below is generic. It can be a
file/nfs-export<br>
> for NAS targets and LUN/logical-drive for SAN targets.<br>
><br>
> VDSM can use LSM and do the following...<br>
> - Provision storage<br>
> - Consume storage<br>
><br>
> 3.1) Provisioning Storage using LSM<br>
><br>
> Typically this will be done by a Storage administrator.<br>
><br>
> oVirt/VDSM should provide storage admin the<br>
> - ability to list the different storage arrays
along with their<br>
> types (NAS/SAN), capabilities, free/used space.<br>
> - ability to provision storage using any of the
array<br>
> capabilities (eg: thin provisioned lun or new NFS
export )<br>
> - ability to manage the provisioned storage (eg:
resize/delete storage)<br>
<br>
</div>
</div>
I guess vdsm will need to model a new type of object (perhaps
StorageTarget) to<br>
be used for performing the above provisioning operations. Then,
to consume the<br>
provisioned storage, we could create a StorageConnectionRef by
passing in a<br>
StorageTarget object and some additional parameters. Sound
about right?<br>
</div>
</blockquote>
<br>
<tt>Sounds right to me, but I am not an expert in VDSM object model,
Saggi/Ayal/Dan can provide<br>
more inputs here. The (proposed) storage array entity in ovirt
engine can use this vdsm object to <br>
communicate and work with the storage array in doing the
provisioning work.<br>
<br>
Going ahead with the change to new Image Repository, I was
envisioning that LSM when integrated as<br>
a new repo engine will exhibit "Storage Provisioning" as a
implicit feature/capability, only then it<br>
will be picked up by the StorageTarget, else not.<br>
</tt><br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div class="im"><br>
> Once the storage is provisioned by the storage admin,
VDSM will have<br>
> to refresh the host(s) for them to be able to see the
newly<br>
> provisioned storage.<br>
<br>
</div>
How would this refresh affect currently connected storage and
running VMs?<br>
</div>
</blockquote>
<br>
<tt>I am not too sure on this... looking for more info from the
experts here. Per ayal, getDeviceInfo<br>
should help refresh, but by 'affect' are you referring to what
happens if post refresh the device<br>
IDs and/or names of the existing storage on the host changes ?
What exactly is the concern here ?<br>
</tt><br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div class="im"><br>
> 3.1.1) Potential flows:<br>
><br>
> Mgmt -> vdsm -> lsm: create LUN + LUN Mapping /
Zoning / whatever is<br>
> needed to make LUN available to list of hosts passed by
mgmt<br>
> Mgmt -> vdsm: getDeviceList (refreshes host and gets
list of devices)<br>
> Repeat above for all relevant hosts (depending on list
passed<br>
> earlier, mostly relevant when extending an existing VG)<br>
> Mgmt -> use LUN in normal flows.<br>
><br>
><br>
> 3.1.2) How oVirt Engine will know which LSM to use ?<br>
><br>
> Normally the way this works today is that user can choose
the host<br>
> to use (default today is SPM), however there are a few
flows where<br>
> mgmt will know which host to use:<br>
> 1. extend storage domain (add LUN to existing VG) - Use
SPM and make<br>
> sure *all* hosts that need access to this SD can see the
new LUN<br>
> 2. attach new LUN to a VM which is pinned to a specific
host - use this host<br>
> 3. attach new LUN to a VM which is not pinned - use a
host from the<br>
> cluster the VM belongs to and make sure all nodes in
cluster can see<br>
> the new LUN<br>
<br>
</div>
You are still going to need to worry about locking the shared
storage resource.<br>
Will libstoragemgmt have storage clustering support baked in or
will we continue<br>
to rely on SPM? If the latter is true, most/all of these
operations would still<br>
need to be done by SPM if I understand correctly.<br>
</div>
</blockquote>
<br>
<tt>The above scenarios were noted by me on behalf of Ayal.<br>
I don't think LSM will worry abt storage clustering. We are just
using LSM to 'talk' with the<br>
storage array. I am not sure if we need locking for the above
scenarios. We are just ensuring<br>
that the newly provisioned LUN is visible to the relevant hosts,
so not sure why we might need<br>
locking?<br>
</tt><br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div class="im"><br>
> Flows for which there is no clear candidate (Maybe we can
use the<br>
> SPM host itself which is the default ?)<br>
> 1. create a new disk without attaching it to any VM<br>
> 2. create a LUN for a new storage domain<br>
<br>
</div>
Yes, SPM would seem correct to me.<br>
<div class="im"><br>
> 3.2) Consuming storage using LSM<br>
><br>
> Typically this will be done by a virtualization
administrator<br>
><br>
> oVirt/VDSM should allow virtualization admin to<br>
> - Create a new storage domain using the storage on
the array.<br>
> - Be able to specify whether VDSM should use the
storage offload<br>
> capability (default) or override it to use its own
internal logic.<br>
<br>
</div>
If vdsm can make the right decisions, I would prefer that vdsm
decides when to use<br>
hardware offload and when to use software algorithms without
administrator<br>
intervention. It's another case where oVirt can provide
value-add by<br>
simplifying the configuration and providing optimal performance.<br>
</div>
</blockquote>
<br>
<tt>Per ayal, the thought was that in scenarios we know where the
storage array implementation is <br>
not optimal, we can override and tell VDSM to use its internal
logic than offload.<br>
</tt><br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div class="im"><br>
> 4) VDSM potential changes:<br>
><br>
> 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV
= 1 VMdisk<br>
> ? which bring another question...1 array == 1 storage
domain OR 1<br>
> LUN/nfs-export on the array == 1 storage domain ?<br>
<br>
</div>
Saggi has mentioned some ideas on this topic so I will encourage
him to explain<br>
his thoughts here.<br>
</div>
</blockquote>
<br>
<tt>Looking forward to Saggi's thoughts :)</tt><br>
<br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<div class="h5"><br>
><br>
> Pros & Cons of each...<br>
><br>
> 1 array == 1 storage domain<br>
> - Each new vmdisk (aka volume) will be a new
lun/file on the array.<br>
> - Easier to exploit offload capabilities, as they
are available<br>
> at the LUN/File granularity<br>
> - Will there be any issues where there will be too
many<br>
> LUNs/Files ... any maxluns limit on linux hosts that we
might hit ?<br>
> -- VDSM has been tested with 1K LUNs and it
worked fine - ayal<br>
> - Storage array limitations on the number of LUNs
can be a<br>
> downside here.<br>
> - Would it be ok to share the array for hosting
another storage<br>
> domain if need be ?<br>
> -- Provided the existing domain is not
utilising all of the<br>
> free space<br>
> -- We can create new LUNs and hand it over to
anyone needed ?<br>
> -- Changes needed in VDSM to work with raw LUNs,
today it only<br>
> has support for consuming LUNs via VG/LV.<br>
><br>
> 1 LUN/nfs-export on the array == 1 storage domain<br>
> - How to represent a new vmdisk (aka vdsm volume)
if its a LUN<br>
> provisioned using SAN target ?<br>
> -- Will it be VG/LV as is done today for block
domains ?<br>
> -- If yes, then it will be difficult to exploit
offload<br>
> capabilities, as they are at LUN level, not at LV
level.<br>
> - Each new vmdisk will be a new file on the
nfs-export, assuming<br>
> offload capability is available at the file level, so
this should<br>
> work for NAS targets ?<br>
> - Can use the storage array for hosting multiple
storage domains.<br>
> -- Provision one more LUN and use it for
another storage<br>
> domain if need be.<br>
> - VDSM already supports this today, as part of
block storage<br>
> domains for LUNs case.<br>
><br>
> Note that we will allow user to do either one of the
two options<br>
> above, depending on need.<br>
><br>
> 4.2) Storage domain metadata will also include the<br>
> features/capabilities of the storage array as reported
by LSM.<br>
> - Capabilities (taken via LSM) will be stored
in the domain<br>
> metadata during storage domain create flow.<br>
> - Need changes in oVirt engine as well ( see
'oVirt Engine<br>
> potential changes' section below )<br>
<br>
</div>
</div>
Do we want to store the exact hw capabilities or some set of
vdsm chosen feature<br>
bits that are set at create time based on the discovered hw
capabilities? The<br>
difference would be that vdsm could choose which features to
enable at create<br>
time and update those features later if needed.<br>
</div>
</blockquote>
<br>
<tt>IIUC, you are saying VDSM will only look for those capabilities,
whcih are of interest to it and<br>
store it? That should be done by way LSM returning its
capabilities as part of it being a Image Repo.<br>
I am referring to how localFSRepo (def capabilities) is shown in
the PoC Saggie posted @<br>
<a href="http://gerrit.ovirt.org/#change,192" target="_blank">http://gerrit.ovirt.org/#change,192</a></tt><br>
<br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div class="im"><br>
> 4.3) VDSM to poll LSM for array capabilities on a regular
basis ?<br>
> Per ayal:<br>
> - If we have a 'storage array' entity in oVirt Engine
(see<br>
> 'oVirt Engine potential changes' section below ) then we
can have a<br>
> 'refresh capabilities' button/verb.<br>
> - We can periodically query the storage array.<br>
> - Query LSM before running operations (sounds
redundant to me,<br>
> but if it's cheap enough it could be simplest).<br>
><br>
> Probably need a combination of 1+2 (query at very low
frequency<br>
> - 1/hour or 1/day + refresh button)<br>
<br>
</div>
This problem can be aleviated by the abstraction I suggested
above. Then, LSM<br>
can be queried only when we may want to adjust the policy
connected with a<br>
particular storage target.<br>
</div>
</blockquote>
<br>
<tt>Not clear to me, can you explain more ?<br>
LSM might need to be contacted for updating the capabilities,
because storage admins can add/remove<br>
capabilities over a period of time. Many storage arrays provide
ability to enable/disable array <br>
features on demand.<br>
</tt><br>
<blockquote
cite="mid:CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<div class="h5"><br>
> 5) oVirt Engine potential changes - as described by
ayal :<br>
><br>
> - We will either need a new 'storage array' entity
in engine to<br>
> keep credentials, or, in case of storage array as
storage domain,<br>
> just keep this info as part of the domain at engine
level.<br>
> - Have a 'storage array' entity in oVirt Engine to
support<br>
> 'refresh capabilities' as a button/verb.<br>
> - When user during storage provisioning, selects a
LUN exported<br>
> from a storage array (via LSM), the oVirt Engine would
know from<br>
> then onwards that this LUN is being served via LSM.<br>
> It would then be able to query the capabilities
of the LUN<br>
> and show it to the virt admin during storage
consumption flow.<br>
><br>
> 6) Potential flows:<br>
> - Create snapshot flow<br>
> -- VDSM will check the snapshot offload
capability in the<br>
> domain metadata<br>
> -- If available, and override is not
configured, it will use<br>
> LSM to offload LUN/File snapshot<br>
> -- If override is configured or capability is
not available,<br>
> it will use its internal logic to create<br>
> snapshot (qcow2).<br>
><br>
> - Copy/Clone vmdisk flow<br>
> -- VDSM will check the copy offload capability
in the domain<br>
> metadata<br>
> -- If available, and override is not
configured, it will use<br>
> LSM to offload LUN/File copy<br>
> -- If override is configured or capability is
not available,<br>
> it will use its internal logic to create<br>
> snapshot (eg: dd cmd in case of LUN).<br>
><br>
> 7) LSM potential changes:<br>
><br>
> - list features/capabilities of the array. Eg: copy
offload,<br>
> thin prov. etc.<br>
> - list containers (aka pools) (present in LSM
today)<br>
> - Ability to list different types of arrays being
managed, their<br>
> capabilities and used/free space<br>
> - Ability to create/list/delete/resize volumes (
LUN or exports,<br>
> available in LSM as of today)<br>
> - Get monitoring info with object
(LUN/snapshot/volume) as<br>
> optional parameter for specific info. eg:
container/pool free/used<br>
> space, raid type etc.<br>
><br>
> Need to make sure above info is listed in a coherent
way across<br>
> arrays (number of LUNs, raid type used? free/total per<br>
> container/pool, per LUN?. Also need I/O statistics
wherever<br>
> possible.<br>
</div>
</div>
</div>
</blockquote>
<br>
<tt>I forgot to add this in the original mail.. adding it now.<br>
<br>
8) Concerns/Issues<br>
</tt><tt><br>
- Per Tony of libstoragemgmt</tt><br>
<pre wrap=""> -- Some additional things to consider.
-- Some of the array vendors may not allow multiple points of control at
the same time. e.g. you may not be able to have 2 or more nodes running
libStorageMgmt at the same time talking to the same array. NetApp
limits what things can be done concurrently.
-- LibStorageMgmt currently just provides the bits to control external
storage arrays. The plug-in daemon and the plug-ins themselves execute
unprivileged.
- How does the change from SPM to SDM will affect the above discussions ?
</pre>
<br>
</body>
</html>
--------------060306070208010807040506--
1
0