February 2014 - Users - oVirt List Archives

[Users] Quotas
by Maurice James 10 Feb '14

10 Feb '14

------=_NextPart_000_0008_01CF21EA.5F08A660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How do I limit the number of VMs that a user can create using quotas? ------=_NextPart_000_0008_01CF21EA.5F08A660 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></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>How do I limit the number of VMs that a user can = create using quotas?<o:p></o:p></div></body></html> ------=_NextPart_000_0008_01CF21EA.5F08A660--

4 5

Re: [Users] How to setup FreeBSD 8.3 Guest on oVirt 3.3
by Dresel Christopher 10 Feb '14

10 Feb '14

Sure already tried that - IDE, no Ethernet at all, everything related to VirtIO disabled - no success. Quoted from the forum: "It has nothing to do with the virtio driver. It is a more deeply rooted problem inside KVM in its emulation of CPU's over Intel chipsets in combination with *BSD amd64." As I already virtualized pfSense with an older Version of Intel Chipset (Sandy Bridge) with KVM and Hardware Virtualization I really think it's related to the newer Haswell chipset. The same configuration with an i386 ISO build works. Best Regards, Christopher -----Original Message----- From: René Koch [mailto:rkoch@linuxland.at] Sent: Donnerstag, 30. Jänner 2014 16:32 To: Dresel Christopher Cc: Joop; users(a)ovirt.org Subject: Re: [Users] How to setup FreeBSD 8.3 Guest on oVirt 3.3 On Thu, 2014-01-30 at 12:27 +0000, Dresel Christopher wrote: > The passing error seems to be a bug when using Run Once - Run behaves as expected. > > Nevertheless my problem seems related to Haswell + KVM + Hardware Virtualisation + FreeBSD (see http://forum.proxmox.com/threads/16564-PVE3-1-FreeBSD8-3-pfsense-KVM-Hardwa…) > > Possible Workarounds: Disable Hardware Virtualization (guess this is not possible on VM basis with oVirt?) or use an i386 Version of FreeBSD. > I'm pretty sure you can't disable hardware virtualization on a vm basis. Btw, does FreeBSD boot if you use an IDE disk and e1000 NIC (did go quickly through the proxmox forum thread and issues seem to be virtio related)? This will decrease performance for sure, but maybe it's sufficient. My Solaris vms are for compiling and Puppet module tests, so IDE and e1000 emulated devices are fine for me. Regards, René > Thanks for your help. > > -----Original Message----- > From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On > Behalf Of Dresel Christopher > Sent: Mittwoch, 29. Jänner 2014 21:24 > To: René Koch; Joop > Cc: users(a)ovirt.org > Subject: Re: [Users] How to setup FreeBSD 8.3 Guest on oVirt 3.3 > > Thank you, I already found your repo and I'm testing. > > The custom property is selectable via the GUI, the hook gets called, > but I don't know why it don’t work - it seems like the custom property > does not get passed to the hook :/ > > -----Original Message----- > From: René Koch [mailto:rkoch@linuxland.at] > Sent: Mittwoch, 29. Jänner 2014 20:51 > To: Joop; Dresel Christopher > Cc: users(a)ovirt.org > Subject: Re: [Users] How to setup FreeBSD 8.3 Guest on oVirt 3.3 > > On Wed, 2014-01-29 at 19:27 +0100, Joop wrote: > > Dresel Christopher <dresel(a)fhwn.ac.at> wrote: > > >Hi, > > > > > >I’m using oVirt 3.3 and trying to setup a FreeBSD 8.3 Guest machine. > > >The machine hangs after the booting screen - I already googled > > >about this, but didn’t find any helpful articles. > > > > > >Cluster uses “Intel Penryn Family“, the VM is configured with 1 > > >virtual CPU as suggested in one of the threads I found on the internet. > > You're probably looking at x2pic cpu flag problems. A vdsm hook might help. Have posted to proxmox forum about this. Also, solaris seems affected, has been discussed on this list. > > > > For Solaris I wrote a hook which can be found here (works fine for Solaris 10/11 on Intel CPUs): > https://github.com/ovido/ovirt-stuff/tree/master/hooks > > Don't know if this is needed for (older versions of) FreeBSD, too. > > > Regards, > René > > > > Joop > > > > > > ________________________________ > > Fachhochschule Wiener Neustadt für Wirtschaft und Technik Ges.m.b.H. > University of Applied Sciences Wiener Neustadt for Business and > Engineering Ltd., Austria Johannes Gutenberg-Straße 3 > 2700 Wiener Neustadt > Austria, Europe > ATU: 37772406 > Firmenbuchnummer: 77005v > Firmenbuchgericht: Landesgericht Wiener Neustadt > DVR: 0769665 > Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. > > This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender. > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > ________________________________ > > Fachhochschule Wiener Neustadt für Wirtschaft und Technik Ges.m.b.H. > University of Applied Sciences Wiener Neustadt for Business and > Engineering Ltd., Austria Johannes Gutenberg-Straße 3 > 2700 Wiener Neustadt > Austria, Europe > ATU: 37772406 > Firmenbuchnummer: 77005v > Firmenbuchgericht: Landesgericht Wiener Neustadt > DVR: 0769665 > Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. > > This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender. ________________________________ Fachhochschule Wiener Neustadt für Wirtschaft und Technik Ges.m.b.H. University of Applied Sciences Wiener Neustadt for Business and Engineering Ltd., Austria Johannes Gutenberg-Straße 3 2700 Wiener Neustadt Austria, Europe ATU: 37772406 Firmenbuchnummer: 77005v Firmenbuchgericht: Landesgericht Wiener Neustadt DVR: 0769665 Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender.

3 3

[Users] Async release for ovirt-engine-reports is now available.
by Yaniv Dary 10 Feb '14

10 Feb '14

Hello all, We have just release a new reports package for 3.3.3 that fixes a critical bug in upgrade of reports (http://gerrit.ovirt.org/23335) We recommend all existing users to update to this package. Thanks! --- Yaniv Dary BI Software Engineer Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 43501 Tel : +972 (9) 7692306 72306 Email: ydary(a)redhat.com IRC : Yaniv D

1 0

[Users] clearing hung task
by david van zeebroeck 10 Feb '14

10 Feb '14

hello i have a task that seems to be hung or anyway in an incorrect state in the gui's task pane i have one task that indicates that it is launching a vm (that no longer exists) when i expand that task it keeps on saying loading because of this when i now launch other task they don't want to expand in the task pane is there a way to clear this or get it back to a correct status?

4 5

[Users] ELT service sampling
by Kevin Tibi 10 Feb '14

10 Feb '14

Hi all, since I upgraded my plateforme in 3.5, i have a error message in ovirt-engine : [image: Images intégrées 1] I don't find anything about this ELT service. thx ;) Kevin.

4 3

[Users] Fwd: oVirt or RHEV ?
by Nathanaël Blanchet 10 Feb '14

10 Feb '14

------=_Part_1917943_185222171.1391852636417 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Mail transf=C3=A9r=C3=A9 ----- De: "Nathana=C3=ABl Blanchet" <blanchet(a)abes.fr>=20 =C3=80: "Ren=C3=A9 Koch" <rkoch(a)linuxland.at>=20 Envoy=C3=A9: Samedi 8 F=C3=A9vrier 2014 10:41:56=20 Objet: Re: [Users] oVirt or RHEV ?=20 Hi Ren=C3=A9, thanks for your answer.=20 My first idea wasn't to redistribute a repackaging of RHEV, but to bring a = more stable build of rhev than the one from ovirt. My idea was to do the sa= me as other project such as centos or scientific linux with RHEL. Yes they = have removed all Red Hat trademarks, it seems to be a hard work. I began ye= sterday, I met a lot of dependance issues, you're right I can't waste such = a time with this kind of work alone, a collaborate work would be better, bu= t unuseful because of the ovirt project. That's why I think centos make a v= ery great job.=20 ----- Mail transf=C3=A9r=C3=A9 ----- De: "Ren=C3=A9 Koch" <rkoch(a)linuxland.at>=20 =C3=80: "Nathana=C3=ABl Blanchet" <blanchet(a)abes.fr>, "Martijn Grendelman" = <martijn.grendelman(a)isaac.nl>=20 Cc: users(a)ovirt.org=20 Envoy=C3=A9: Vendredi 7 F=C3=A9vrier 2014 23:58:48=20 Objet: Re: [Users] oVirt or RHEV ?=20 Hi Nathana=C3=ABl,=20 Imho you need a lot of manpower to make this happen.=20 You have to remove all Red Hat trademarks if you want to distribute it - th= is means remove it from RHEV-manager (engine), RHEV-H (node-image) and all = Windows tools (e.g. USB policy editor, RHEV tools,...) so you not only need= CentOS 6 build servers, but also Windows ones.=20 Next you should have to support each release for 3 years which means in 2 y= ears you maybe have to build packages for 3-6 RHEV releases - again takes a= lot of time. Even if you can automate fetching, building and testing you s= till have to test it manually, too.=20 I'm unsure if someone would do this work. Just speaking for me and the comp= any I work for - RHEV and oVirt is working fine for us, so I wouldn't see m= uch benefit of repackaging RHEV. Contributing to oVirt project with Nagios = plugins, presentations, meetups,... makes more sense for us. Again just spe= aking about us, but I think other companies think in a same way...=20 Regards,=20 Ren=C3=A9=20 On 07.02.2014 10:33, Nathana=C3=ABl Blanchet wrote:=20 Hi everybody,=20 We could consider a third way : why not building RHEV from SRPMs since redh= at provides them on ftp://ftp.redhat.com/redhat/rhev-m/3.x/SRPMS/ ? this ca= n be a compromise between stability of rhev and ovirt free of charge.=20 I'm surprised that nobody has got this idea before.=20 Le 06/02/2014 19:53, Ren=C3=A9 Koch a =C3=A9crit :=20 <blockquote> Hi Martijn, That's a good question and not too easy to answer. I work as a Solution Architect and my company is selling both - RHEV and oVirt consulting and support. The reason for doing both is, that we want to give users a choice which solution fits better. The main benefits (in my opinion) of RHEV are: - Support with SLAs Red Hat provides support for RHEV with service levels. For oVirt you have to wait until someone of the developers or community members helps you on the mailing list or in IRC (or you buy support from a company with provides it). - Updates for each release for 3 years You receive for all releases (RHEV 3.1, 3.2,...) 3 years of support and updates. oVirt provides bugfix releases for the actual release (so you want get bugfix updates for 3.2 anymore, you have to upgrade to 3.3). For me this is the biggest advantage of RHEV. - Red Hat Knowledge Base Red Hat Knowledge Base is one of the best knowledge bases and it helps you greatly solving issues and gives useful tips. I use the knowledge base a lot and wouldn't want to miss it for any Red Hat product. - Stability RHEV is tested by a qa team and the releases are really stable. oVirt has newer features which are less tested. I upgrade oVirt release only to .1 releases (e.g. 3.2.x -> 3.3.1), not to .0 to avoid issues. - Guest agents Guest agents and RHEV tools are packaged for RHEL and Windows guests and are working fine. When using oVirt you miss some of the functionality of Windows guest tools or have to copy it from different locations. For other os'es it doesn't matter if using RHEV or oVirt. - Application / os support You should consider if your applications and operating systems are supported in oVirt as well. All apps certified for RHEL are certified for RHEV as well. Main benefits of oVirt: - Newest features oVirt gives you the latest and greatest. So it will take some time until this feature is available in RHEV, too (due to testing). - No subscription coasts You don't have to buy subscriptions for an oVirt environment, so it saves money. But on the other hand it can also cost you more money, if you have to spend a lot of time in troubleshooting or with upgrading (especially with possible upgrading issues) or having down times of your environment. It's not too easy to say if you should use RHEV or oVirt. I hope I could help you making a decision with my explanations above. You could also have both - a RHEV setup for production vms and an oVirt setup for development and qa vms. Regards, Ren=C3=A9 On Thu, 2014-02-06 at 16:06 +0100, Martijn Grendelman wrote:=20 <blockquote> Hi, This may be the wrong place to ask, but I'm looking for input to form an opinion on an "oVirt or RHEV" question within my company. I have been running oVirt for about 5 months now, and I'm quite comfortable with its features and maintenance procedures. We are now planning to build a private virtualization cluster for hosting clients' applications as well as our own. Some people in the company are questioning whether we should buy RHEV, but at this point, I can't see the benefits. Can anyone on this list shed a light on when RHEV might be a better choice than oVirt? What are the benefits? The trade-offs? I am looking for pragmatic, real-world things, not marketing mumbo jumbo. That, I can get from redhat.com ;-) Best regards, Martijn. _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/= users=20 _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/= users=20 </blockquote> --=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le exploitation et maintenance D=C3=A9partement des syst=C3=A8mes d'information 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr=20 </blockquote> ------=_Part_1917943_185222171.1391852636417 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'> <hr id=3D"zwchr"><div style=3D"color:#000;fon= t-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetic= a,Arial,sans-serif;font-size:12pt;">De: "Nathana=C3=ABl Blanchet" &l= t;blanchet(a)abes.fr> =C3=80: "Ren=C3=A9 Koch" <rkoch@linuxla= nd.at> Envoy=C3=A9: Samedi 8 F=C3=A9vrier 2014 10:41:56 = Objet: Re: [Users] oVirt or RHEV ? <style>p { margin: 0; }</styl= e><div style=3D"font-family: times new roman,new york,times,serif; font-siz= e: 12pt; color: #000000">Hi Ren=C3=A9, thanks for your answer. My first = idea wasn't to redistribute a repackaging of RHEV, but to bring a more stab= le build of rhev than the one from ovirt. My idea was to do the same as oth= er project such as centos or scientific linux with RHEL. Yes they have remo= ved all Red Hat trademarks, it seems to be a hard work. I began yesterday, = I met a lot of dependance issues, you're right I can't waste such a time wi= th this kind of work alone, a collaborate work would be better, but unusefu= l because of the ovirt project. That's why I think centos make a very great= job. <hr id=3D"zwchr"><div style=3D"color:#000;font-weight:normal;f= ont-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-seri= f;font-size:12pt;">De: "Ren=C3=A9 Koch" <rkoch(a)linuxland.at><b= r>=C3=80: "Nathana=C3=ABl Blanchet" <blanchet(a)abes.fr>, "Marti= jn Grendelman" <martijn.grendelman(a)isaac.nl> Cc: users@ovir= t.org Envoy=C3=A9: Vendredi 7 F=C3=A9vrier 2014 23:58:48 Ob= jet: Re: [Users] oVirt or RHEV ? =20 =20 =20 =20 Hi Nathana=C3=ABl, Imho you need a lot of manpower to make this happen. You have to remove all Red Hat trademarks if you want to distribute it - this means remove it from RHEV-manager (engine), RHEV-H (node-image) and all Windows tools (e.g. USB policy editor, RHEV tools,...) so you not only need CentOS 6 build servers, but also Windows ones. Next you should have to support each release for 3 years which means in 2 years you maybe have to build packages for 3-6 RHEV releases - again takes a lot of time. Even if you can automate fetching, building and testing you still have to test it manually, too. I'm unsure if someone would do this work. Just speaking for me and the company I work for - RHEV and oVirt is working fine for us, so I wouldn't see much benefit of repackaging RHEV. Contributing to oVirt project with Nagios plugins, presentations, meetups,... makes more sense for us. Again just speaking about us, but I think other companies think in a same way... Regards, Ren=C3=A9 <div class=3D"moz-cite-prefix">On 07.02.2014 10:33, Nathana=C3=ABl Blan= chet wrote: </div> <blockquote cite=3D"mid:52F4A868.7040901@abes.fr"> =20 Hi everybody, We could consider a third way : why not building RHEV from SRPMs since redhat provides them on <a class=3D"moz-txt-link-freetext" hr= ef=3D"ftp://ftp.redhat.com/redhat/rhev-m/3.x/SRPMS/" target=3D"_blank">ftp:= //ftp.redhat.com/redhat/rhev-m/3.x/SRPMS/</a> ? this can be a compromise between stability of rhev and ovirt free of charge. I'm surprised that nobody has got this idea before. <div class=3D"moz-cite-prefix">Le 06/02/2014 19:53, Ren=C3=A9 Koch a =C3=A9crit : </div> <blockquote cite=3D"mid:20140206185356.EDA1C1682@mail.linuxland.de"> <pre>Hi Martijn, That's a good question and not too easy to answer. I work as a Solution Architect and my company is selling both - RHEV and oVirt consulting and support. The reason for doing both is, that we want to give users a choice which solution fits better. The main benefits (in my opinion) of RHEV are: - Support with SLAs Red Hat provides support for RHEV with service levels. For oVirt you have to wait until someone of the developers or community members helps you on the mailing list or in IRC (or you buy support from a company with provides it). - Updates for each release for 3 years You receive for all releases (RHEV 3.1, 3.2,...) 3 years of support and updates. oVirt provides bugfix releases for the actual release (so you want get bugfix updates for 3.2 anymore, you have to upgrade to 3.3). For me this is the biggest advantage of RHEV. - Red Hat Knowledge Base Red Hat Knowledge Base is one of the best knowledge bases and it helps you greatly solving issues and gives useful tips. I use the knowledge base a lot and wouldn't want to miss it for any Red Hat product. - Stability RHEV is tested by a qa team and the releases are really stable. oVirt has newer features which are less tested. I upgrade oVirt release only to .1 releases (e.g. 3.2.x -> 3.3.1), not to .0 to avoid issues. - Guest agents Guest agents and RHEV tools are packaged for RHEL and Windows guests and are working fine. When using oVirt you miss some of the functionality of Windows guest tools or have to copy it from different locations. For other os'es it doesn't matter if using RHEV or oVirt. - Application / os support You should consider if your applications and operating systems are supported in oVirt as well. All apps certified for RHEL are certified for RHEV as well. Main benefits of oVirt: - Newest features oVirt gives you the latest and greatest. So it will take some time until this feature is available in RHEV, too (due to testing). - No subscription coasts You don't have to buy subscriptions for an oVirt environment, so it saves money. But on the other hand it can also cost you more money, if you have to spend a lot of time in troubleshooting or with upgrading (especially with possible upgrading issues) or having down times of your environment. It's not too easy to say if you should use RHEV or oVirt. I hope I could help you making a decision with my explanations above. You could also have both - a RHEV setup for production vms and an oVirt setup for development and qa vms. Regards, Ren=C3=A9 On Thu, 2014-02-06 at 16:06 +0100, Martijn Grendelman wrote: </pre> <blockquote> <pre>Hi, This may be the wrong place to ask, but I'm looking for input to form an opinion on an "oVirt or RHEV" question within my company. I have been running oVirt for about 5 months now, and I'm quite comfortable with its features and maintenance procedures. We are now planning to build a private virtualization cluster for hosting clients' applications as well as our own. Some people in the company are questioning whether we should buy RHEV, but at this point, I can't see the benefits. Can anyone on this list shed a light on when RHEV might be a better choice than oVirt? What are the benefits? The trade-offs? I am looking for pragmatic, real-world things, not marketing mumbo jumbo. That, I can get from redhat.com ;-) Best regards, Martijn. _______________________________________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Users@ovirt.org" targe= t=3D"_blank">Users(a)ovirt.org</a> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman/l= istinfo/users" target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/us= ers</a> </pre> </blockquote> <pre>_______________________________________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Users@ovirt.org" targe= t=3D"_blank">Users(a)ovirt.org</a> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman/l= istinfo/users" target=3D"_blank">http://lists.ovirt.org/mailman/listinfo/us= ers</a> </pre> </blockquote> <pre class=3D"moz-signature">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le exploitation et maintenance D=C3=A9partement des syst=C3=A8mes d'information 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr" targ= et=3D"_blank">blanchet(a)abes.fr</a> </pre> </blockquote> =20 </div> </div></div> </div></body></html> ------=_Part_1917943_185222171.1391852636417--

2 1

[Users] Gluster question
by Maurice James 10 Feb '14

10 Feb '14

------=_NextPart_000_00FD_01CF22B5.E5FD9560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I currently have a new setup running ovirt 3.3.3. I have a Gluster storage domain with roughly 2.5TB of usable space. Gluster is installed on the same systems as the ovirt hosts. The host break down is as follows Ovirt DC: 4 hosts in the cluster. Each host has 4 physical disks in a RAID 5. Each disk is 500GB. With the OS installed and configured I end up with 1.2TB of usable space left for my data volume Gluster volume: 4 bricks with 1.2TB of space per brick (Distribute Replicate leaves me with about 2.5TB in the storage domain) Does this setup give me enough fault tolerance to survive losing a host and have my HA vm automatically move to an available host and keep running?? ------=_NextPart_000_00FD_01CF22B5.E5FD9560 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=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>I currently have a new setup running ovirt 3.3.3. I = have a Gluster storage domain with roughly 2.5TB of usable space. =  Gluster is installed on the same systems as the ovirt hosts. The = host break down is as follows<o:p></o:p><o:p> </o:p>Ovirt = DC:<o:p></o:p>4 hosts in the cluster. Each host = has 4 physical disks in a RAID 5. Each disk is 500GB. With the OS = installed and configured I end up with 1.2TB of usable space left for my = data volume<o:p></o:p><o:p> </o:p>Gluster volume:<o:p></o:p>4 = bricks with 1.2TB of space per brick (Distribute Replicate leaves me = with about 2.5TB in the storage domain)<o:p></o:p><o:p> </o:p><o:p> </o:p>Does this = setup give me enough fault tolerance to survive losing a host and have = my HA vm automatically move to an available host and keep = running??<o:p></o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_00FD_01CF22B5.E5FD9560--

4 7

[Users] Reattach storage domain
by Alexandr 09 Feb '14

09 Feb '14

Hello! Unfortunately my master storage domain (gluster) is dead. I setup another gluster-storage and attach it to the ovirt. Hostname, path and volume name are same as old ones. Then I restored from tar archive all files. But I cannot activate master domain, operation failed and domain status remains "inactive". I see - it mounted on nodes: vms02.lis.ua:STORAGE on /rhev/data-center/mnt/glusterSD/vms02.lis.ua:STORAGE I attached engine.log, can someone provide me recovery steps? P.S. Sorry for my english

3 10

[Users] New iSCSI domain problem when first input wrong password
by Gianluca Cecchi 09 Feb '14

09 Feb '14

Hello, I have a fedora 19 engine based on 3.3 final. I installed a fedora 19 host (configured as infrastructure server) and then installed from web gui. Then yum update of the host updated vdsm (see separate thread I'm going to open for this). I create iSCSI DC and add that host to it. When I try to create the new iSCSI storage domain (sw iscsi target on a CentOS 6.5 server) I initially input the wrong chap password so that discovery goes ok, while authentication fails. Then I put correct pwd but after apparently going on (I see the exposed lun) then gives error in webadmin gui I have 2014-Feb-05, 16:57 Failed to attach Storage Domain OV01 to Data Center ISCSI. (User: admin@internal) 2014-Feb-05, 16:57 Failed to attach Storage Domains to Data Center ISCSI. (User: admin@internal) 2014-Feb-05, 16:57 The error message for connection 192.168.230.101 iqn.2013-09.local.localdomain:c6iscsit.target11 (LUN 1IET_00010001) returned by VDSM was: Failed to setup iSCSI subsystem 2014-Feb-05, 16:57 Storage Domain OV01 was added by admin@internal A workaround to have it activated is then (see logs 18:11): - put host in maintenance - reactivate it - attach sd to DC - ok (but see watermark message I don't understand) 2014-Feb-05, 18:13 The system has reached the 80% watermark on the VG metadata area size on OV01. This is due to a high number of Vdisks or large Vdisks size allocated on this specific VG. 2014-Feb-05, 18:13 Storage Domains were attached to Data Center ISCSI by admin@internal 2014-Feb-05, 18:13 Storage Domain OV01 (Data Center ISCSI) was activated by admin@internal 2014-Feb-05, 18:13 Storage Pool Manager runs on Host ovnode03 (Address: 192.168.33.44). 2014-Feb-05, 18:12 Data Center is being initialized, please wait for initialization to complete. 2014-Feb-05, 18:12 State was set to Up for host ovnode03. 2014-Feb-05, 18:11 Host ovnode03 was activated by admin@internal. 2014-Feb-05, 18:11 Host ovnode03 was switched to Maintenance mode by admin@internal. See my vdsm.log and supervdsm.log here https://drive.google.com/file/d/0BwoPbcrMv8mval9XMnN4ZGoxa00/edit?usp=shari… https://drive.google.com/file/d/0BwoPbcrMv8mveC1KQmo1dFAtNzQ/edit?usp=shari… Possibly initially wrong password is not optimally managed when putting the correct one, as I see some traceback. Gianluca

2 1

[Users] Cannot install ovirt-engine on Fedora 20 by using YUM
by Karthi Keyan 09 Feb '14

09 Feb '14

Hi All, I am new to Ovirt. I am trying to install ovirt-engine but i cannot able to install it. I have followed this documentation http://www.ovirt.org/Quick_Start_Guide#oVirt_Engine. And i am getting this Error: *[root@localhost yum.repos.d]# yum install ovirt-engine* Loaded plugins: langpacks, refresh-packagekit http://ovirt.org/releases/stable/rpm/Fedora/20/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. No package ovirt-engine available. Error: Nothing to do Please guide me! Regards, Karthikeyan

3 3

[Users] Can't open ovirt console using Spice or VNC - help!
by Drew Showers 09 Feb '14

09 Feb '14

Hello, I'm a nube with ovirt, but have the ovirt-engine and 1 remote host up and running (separate physical servers, same subnet). The network, DNS. NFS all work. I can create VM's, install the ISO OS with no problems. Here is were I get stuck. After a frustrating few hours trying to get a console to launch on my mac, I broke down and created a new Centos 6.4 Desktop VM using Fusion. I've installed - spice-xpi (yum install spice-xpi) virt-manager (yum install virt-manager) Using Firefox, if I try to open the console from the ovirt admin using Spice browser plugin or native client options, nothing happens (no errors either), other than message saying the user is initiating a console session. If using VNC, then it wants to either download the console.vv or open it with the default viewer, which throws and error "Unable to connect to the graphics server file" So, I'm stuck in going any further until I get this worked out. No VM IP or host name (unless I'm missing something)... I actually find this quite unfriendly. I know similar issues have been discussed previously, but none have solved my problem. BTW: I'm running Centos 6.5 on both the engine and host. I'm not sure if I'm missing additional packages or what. Any help would be greatly appreciated. Thanks, Drew

1 0

[Users] A/B network setup
by Pat Pierson 09 Feb '14

09 Feb '14

I am having some issues wrapping my head around this but what I am trying to setup is a A/B testing environment with a 3node cluster. Each node has 2 nics, 1 for ovirtmgmt and 1 for vlaned A/B network. I guess what I am trying to understand is if ovirt is tagging the vlan's I setup and is properly passing that to the switch? This would allow me to have multiple subnets on a host that the switch also can see as multiple vlans. Right? I would still have to configure the switch to allow that port access to both vlans. -- Patrick Pierson

2 3

[Users] FOSDEM slides + recordings available
by Doron Fediuck 09 Feb '14

09 Feb '14

http://www.ovirt.org/FOSDEM_2014#Sessions I will continue to update with recordings (and last slides) as it becomes available. This is also a good chance to thank everyone involved. People who practiced, spoke, volunteered for stand shifts, Video handling, helping with the oVirt-live, carrying maps, laptops, handout-sheets, poster-sign to/from UBL and other logistics. Special thanks to Joop, René, Jorick, Robert and Alexander who joined us in ULB . We got a big and very positive exposure for oVirt, which as you'll be able to hear is getting a lot of community attention now. See you in FOSDEM 2015 ;) Doron

1 0

[Users] Best way to request a new feature?
by Bob Doolittle 09 Feb '14

09 Feb '14

What's the best way to request a new feature? Do we manage a Wiki page for this somewhere? Or should I just open a bug/rfe? The feature I'd like to see: It would be nice if the Admin page had an indication either on the VMs page or in the left navigation frame when everything is in place for starting VMs. Here's an example scenario to illustrate why this would be useful: Every morning I power up my Engine and Host machines. The first thing I have to do is Activate my Host, and then monitor it while it comes up, Contends and eventually assumes SPM responsibility. Then I can change to the tab with my VMs and start up the one(s) I need, and open their consoles. But I have to watch the Host tab until SPM is established, because when looking at the VMs page there's no indication whether they can be started up yet or not. Nothing unless I try to start one, and get a pop-up error. Additional useful features: Is there any way to cause a VM to automatically power on as soon as oVirt is ready to do so? Is there any way to cause a console to automatically open up as soon as a VM is started? -Bob

3 5

[Users] Backups
by Maurice James 08 Feb '14

08 Feb '14

------=_NextPart_000_004D_01CF24F1.1C9886B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What is the recommended enterprise backup solution for RHEV/oVirt? Symantec, Veem, Backula.... ------=_NextPart_000_004D_01CF24F1.1C9886B0 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></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>What is the recommended enterprise backup solution for = RHEV/oVirt?<o:p></o:p>Symantec, Veem, = Backula……..<o:p></o:p></div></body></html> ------=_NextPart_000_004D_01CF24F1.1C9886B0--

1 0

[Users] Resource question
by Maurice James 08 Feb '14

08 Feb '14

------=_NextPart_000_002F_01CF24EA.83D4EAF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This may seem like a silly question but, I just need to wrap my head around a concept Are my VMs limited by host or cluster resources? 4 hosts with the following resources per host: 2 6 core intel processors (24 cores per host) 32GB memory 1.2TB NFS storage So across the cluster I have 96 cpu cores 128GB memory 4.8TB of NFS storage Can I create a single VM with let's say: 25 cpu cores 64GB of RAM 2TB of storage Am I limited by the host or the cluster? ( Keep in mind that I'm not actually going to create such a ridiculous VM but the question is bothering me). Thanks ------=_NextPart_000_002F_01CF24EA.83D4EAF0 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></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>This may seem like a silly question but, I just need = to wrap my head around a concept<o:p></o:p><o:p> </o:p>Are my VMs = limited by host or cluster resources?<o:p></o:p><o:p> </o:p>4 hosts with = the following resources per host:<o:p></o:p>2 6 = core intel processors (24  cores per host)<o:p></o:p>32GB memory<o:p></o:p>1.2TB = NFS storage<o:p></o:p><o:p> </o:p>So across the cluster I have<o:p></o:p>96 cpu cores<o:p></o:p>128GB = memory<o:p></o:p>4.8TB of NFS = storage<o:p></o:p><o:p> </o:p>Can I create a single VM with let’s = say:<o:p></o:p>25 cpu cores<o:p></o:p>64GB of RAM<o:p></o:p>2TB of = storage<o:p></o:p><o:p> </o:p>Am I limited by the host or the cluster? ( Keep in = mind that I’m not actually going to create such a ridiculous VM = but the question is bothering me). = Thanks<o:p></o:p></div></body></html> ------=_NextPart_000_002F_01CF24EA.83D4EAF0--

2 2

[Users] oVirt or RHEV ?
by Martijn Grendelman 07 Feb '14

07 Feb '14

Hi, This may be the wrong place to ask, but I'm looking for input to form an opinion on an "oVirt or RHEV" question within my company. I have been running oVirt for about 5 months now, and I'm quite comfortable with its features and maintenance procedures. We are now planning to build a private virtualization cluster for hosting clients' applications as well as our own. Some people in the company are questioning whether we should buy RHEV, but at this point, I can't see the benefits. Can anyone on this list shed a light on when RHEV might be a better choice than oVirt? What are the benefits? The trade-offs? I am looking for pragmatic, real-world things, not marketing mumbo jumbo. That, I can get from redhat.com ;-) Best regards, Martijn.

7 7

[Users] NAT configuration
by martin.trudel＠cspq.gouv.qc.ca 07 Feb '14

07 Feb '14

--_000_587E1915ECF57147AF48C7A5FC8AD308B1EB973FWITPP01MSG10BIT_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I want to configure NAT in Ovirt with this procedure : http://lists.ovirt.org/pipermail/users/2012-April/001751.html But I don't have the login password of virsh and for the PosgreSQL database= . I used the last version of oVirt with default installation with engine-setu= p Thanks. ________________________________ Ce message est confidentiel et est =E0 l'usage exclusif du destinataire ide= ntifi=E9 ci-dessus. Toute autre personne est, par les pr=E9sentes, avis=E9e= qu'il lui est strictement interdit de le diffuser, de le distribuer, d'en = d=E9voiler le contenu ou de le reproduire. Si vous avez re=E7u cette commun= ication par erreur, veuillez en informer l'exp=E9diteur par courrier =E9lec= tronique imm=E9diatement et d=E9truire l'original de ce message ainsi que t= oute copie. ________________________________ --_000_587E1915ECF57147AF48C7A5FC8AD308B1EB973FWITPP01MSG10BIT_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style id=3D"owaParaStyle" type=3D"text/css">  </style> </head> <body> <div style=3D"direction:ltr; font-family:Tahoma; color:#000000; font-size:1= 0pt">Hi, I want to configure NAT in Ovirt with this procedure : <a href=3D"http://lists.ovirt.org/pipermail/users/2012-= April/001751.html" style=3D"text-decoration:none"><span style=3D"font-size:= 15px; font-family:Consolas; color:#1155cc; background-color:#ffffff; font-w= eight:bold; font-style:normal; font-variant:normal; text-decoration:underli= ne; vertical-align:baseline; white-space:pre-wrap">http://lists.ovirt.org/p= ipermail/users/2012-April/001751.html</a> But I don't have the login password of virsh and for the PosgreSQ= L database. I used the last version of oVirt with default installation with engine-setu= p Thanks. </div> <hr> Ce message est confidentiel et est =E0 l'usage exclusif du destinataire ide= ntifi=E9 ci-dessus. Toute autre personne est, par les pr=E9sentes, avis=E9e= qu'il lui est strictement interdit de le diffuser, de le distribuer, d'en = d=E9voiler le contenu ou de le reproduire. Si vous avez re=E7u cette communication par erreur, veuillez en informer l= 'exp=E9diteur par courrier =E9lectronique imm=E9diatement et d=E9truire l'o= riginal de ce message ainsi que toute copie. <hr> </body> </html> --_000_587E1915ECF57147AF48C7A5FC8AD308B1EB973FWITPP01MSG10BIT_--

6 14

[Users] Timezone Hypervisor/VM
by Markus Stockhausen 07 Feb '14

07 Feb '14

This is a multi-part message in MIME format. ------=_NextPartTM-000-dffb1493-ac33-42c5-8818-feaa500cecb6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=0A= =0A= all my searching/reading left me more confused. My current problem is=0A= a Windows VM that has a wrong "timezone" - at least if I do not activate=0A= internet time server sync.=0A= =0A= Settings are:=0A= =0A= - OVirt VM definition - First Run GMT+1 - thats ok=0A= - hypervisor host: timezone CET (=3D GMT+1) - 18:00 - thats ok=0A= - Windows VM: timezone CET ( =3D GMT+1) - 17:00 - thats wrong=0A= =0A= I got a thread that suggested to look at vm_dynamic. There we have:=0A= =0A= select a.vm_name,b.utc_diff from vm_static a, vm_dynamic b=0A= engine-# where a.vm_guid=3Db.vm_guid;=0A= vm_name | utc_diff=0A= ------------------+----------=0A= Win7x64_Master | 0=0A= =0A= But what should that tell me?=0A= =0A= Although we work with timeservers inside the VMs we want to ensure=0A= that even without them the VM time should match the hypervisor time.=0A= =0A= Has anyone a simple and clear explanation how this should work.=0A= =0A= Thanks in advance.=0A= =0A= Markus=0A= =0A= =0A= ------=_NextPartTM-000-dffb1493-ac33-42c5-8818-feaa500cecb6 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-dffb1493-ac33-42c5-8818-feaa500cecb6--

4 13

[Users] translate the project ovirt-docs, need your help
by 适兕 07 Feb '14

07 Feb '14

Hi: oVirt users. I just create a translate project ovirt-docs from zanata.org. the URL: https://translate.zanata.org/zanata/project/view/ovirt-docs&cid=117680 I just can translate to Chinese, So, I need your help. next I will to do blow things: 0、change ovirt-docs zanata.xml in gerrit 1、upload jp and zh-TW . Thanks. -- 独立之思想，自由之精神。 --陈寅恪

3 2

[Users] Opaque oVirt/RHEV/Proxmox client and source code released
by i iordanov 07 Feb '14

07 Feb '14

Hello! Apologies for the cross-post. I've released Opaque into production on Google Play: https://play.google.com/store/apps/details?id=com.undatech.opaque and on Blackberry World for devices running Blackberry OS 10.2.1 or newer: http://appworld.blackberry.com/webstore/content/46004889 The source code is now part of the renamed (formerly bVNC) repository: https://github.com/iiordanov/remote-desktop-clients The old name of the repository links to the new one. I didn't think it's a good idea to keep calling it bVNC given that it already contains code to build 4 different remote desktop clients. If you are an oVirt or RHEV admin, please ensure that Opaque works in your environment before recommending it to your users. Please start by reading the KNOWN ISSUES section in the description of the application. Thanks for all the feedback I received from the beta test community! I will still be releasing new features to be beta-tested before pushing them to production. Sincerely, iordan -- The conscious mind has only one thread of execution.

1 0

[Users] VNC Console
by ml ml 07 Feb '14

07 Feb '14

Hello List, i am running ovirt 3.3.3-2.el6. It looks really cool and nice. However, the VNC Console drives me Crazy. I can seem to get a proper Key Mapping. My VNC Keyboard Layout is set to "en-us" and i am booting a live cd, also with en-us key mapping. However the keys such as / or = are not working and its driving me carzy that i am failing on this simple task. Can anyone help? What Client do you use in Mac and Windows? Is there anything else i need to take care of? Thanks, Mario

1 0

Re: [Users] oVirt or RHEV ?
by Martijn Grendelman 07 Feb '14

07 Feb '14

Hi Dave (and everyone else who responded), Thank you for your explanations. It was the objectiveness I was looking for, even though you work for Red Hat :-) At least the benefits of RHEV are way more clear to me now, which is what I needed. The choice is still a tough one, expecially since the oVirt users mailing list is one of most helpful ones I know. Thanks again, Martijn. Dave Neary schreef op 6-2-2014 19:32: > Hi, > > On 02/06/2014 04:06 PM, Martijn Grendelman wrote: >> This may be the wrong place to ask, but I'm looking for input to form an >> opinion on an "oVirt or RHEV" question within my company. > > I suspect you'll get a different answer if you ask here vs Red Hat > sales. I'll try to be objective (disclosure: I work for Red Hat). > >> I have been running oVirt for about 5 months now, and I'm quite >> comfortable with its features and maintenance procedures. We are now >> planning to build a private virtualization cluster for hosting clients' >> applications as well as our own. Some people in the company are >> questioning whether we should buy RHEV, but at this point, I can't see >> the benefits. > > If you are running any applications which are certified on RHEL, and you > want to ensure you continue getting the benefits of certification, then > you should check if your supplier will support the configuration of > "application on RHEL guest on oVirt managed hypervisor" - Red Hat does > not support the operating system in this configuration, so if certified > applications and support are important, this is something you may want > to consider. > > In general, oVirt will get less integration testing and QA than RHEV > (purely a resource allocation issue), so you will occasionally hit bugs > in oVirt that are fixed in the equivalent RHEV release. Bug fixes for > RHEV get into oVirt too, but in the master branch usually, so if you're > running a stable release of oVirt, you may still have the issue, unless > the fix is back-ported to the stable release branch. > > On the flip side, features appear first in oVirt, so if there are newer > features you really need, you could use them on oVirt. A few months > later, they will be available in the RHEV product. > > Also, while most RHEV documentation will apply to oVirt, that's not > always the case. A recent example was the Node quick start > documentation, as pointed out by a list member. If you like > documentation matching the actual functionality of the project, you can > help fix the oVirt documentation. > > Actually, that's a key differentiator - your ability to engage with the > community, help update the wiki, test new features while they're still > in design & ensure they fit your needs, are for me the key selling > points of the project. If you want something that is supported, on which > your apps are certified, and for which you can get good support, and > have a reasonable expectation of more stability, RHEV is for you. > > >> Can anyone on this list shed a light on when RHEV might be a better >> choice than oVirt? What are the benefits? The trade-offs? >> >> I am looking for pragmatic, real-world things, not marketing mumbo >> jumbo. That, I can get from redhat.com ;-) > > You also got this from redhat.com - hope I didn't disappoint you. > > Cheers, > Dave. > >

1 0

Re: [Users] oVirt or RHEV ?
by Martijn Grendelman 07 Feb '14

07 Feb '14

Hi René, Sorry for top-posting, but I just wanted to say that this was a really helpful answer, and it actually made me rethink yesterday's decision:-). Thank you very much. Cheers, Martijn. René Koch schreef op 6-2-2014 19:53: > Hi Martijn, > > That's a good question and not too easy to answer. > I work as a Solution Architect and my company is selling both - RHEV and > oVirt consulting and support. The reason for doing both is, that we want > to give users a choice which solution fits better. > > The main benefits (in my opinion) of RHEV are: > > - Support with SLAs > Red Hat provides support for RHEV with service levels. For oVirt you > have to wait until someone of the developers or community members helps > you on the mailing list or in IRC (or you buy support from a company > with provides it). > > - Updates for each release for 3 years > You receive for all releases (RHEV 3.1, 3.2,...) 3 years of support and > updates. oVirt provides bugfix releases for the actual release (so you > want get bugfix updates for 3.2 anymore, you have to upgrade to 3.3). > For me this is the biggest advantage of RHEV. > > - Red Hat Knowledge Base > Red Hat Knowledge Base is one of the best knowledge bases and it helps > you greatly solving issues and gives useful tips. I use the knowledge > base a lot and wouldn't want to miss it for any Red Hat product. > > - Stability > RHEV is tested by a qa team and the releases are really stable. oVirt > has newer features which are less tested. I upgrade oVirt release only > to .1 releases (e.g. 3.2.x -> 3.3.1), not to .0 to avoid issues. > > - Guest agents > Guest agents and RHEV tools are packaged for RHEL and Windows guests and > are working fine. When using oVirt you miss some of the functionality of > Windows guest tools or have to copy it from different locations. For > other os'es it doesn't matter if using RHEV or oVirt. > > - Application / os support > You should consider if your applications and operating systems are > supported in oVirt as well. All apps certified for RHEL are certified > for RHEV as well. > > > Main benefits of oVirt: > > - Newest features > oVirt gives you the latest and greatest. So it will take some time until > this feature is available in RHEV, too (due to testing). > > - No subscription coasts > You don't have to buy subscriptions for an oVirt environment, so it > saves money. But on the other hand it can also cost you more money, if > you have to spend a lot of time in troubleshooting or with upgrading > (especially with possible upgrading issues) or having down times of your > environment. > > > It's not too easy to say if you should use RHEV or oVirt. > I hope I could help you making a decision with my explanations above. > You could also have both - a RHEV setup for production vms and an oVirt > setup for development and qa vms. > > > Regards, > René > > > > On Thu, 2014-02-06 at 16:06 +0100, Martijn Grendelman wrote: >> Hi, >> >> This may be the wrong place to ask, but I'm looking for input to form an >> opinion on an "oVirt or RHEV" question within my company. >> >> I have been running oVirt for about 5 months now, and I'm quite >> comfortable with its features and maintenance procedures. We are now >> planning to build a private virtualization cluster for hosting clients' >> applications as well as our own. Some people in the company are >> questioning whether we should buy RHEV, but at this point, I can't see >> the benefits. >> >> Can anyone on this list shed a light on when RHEV might be a better >> choice than oVirt? What are the benefits? The trade-offs? >> >> I am looking for pragmatic, real-world things, not marketing mumbo >> jumbo. That, I can get from redhat.com ;-) >> >> Best regards, >> Martijn. >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > >

1 0

[Users] SPICE behind NAT
by Alan Murrell 07 Feb '14

07 Feb '14

I have setup a test All-In-One install but it is behind a Linux NAT firewall (IPTables). I have been reading about Spice-Proxy and know the basics of setting it up (install squid, configure the ovirt engine SpiceProxyDefault), however I just wanted to know how I would do this in a NAT situation? Would I install Squid on the firewall? When I configure SpiceProxyDefault on the ovirt-engine, I set it to use the internal IP of the firewall/Squid? Anything else I would possibly need to do? -Alan

2 1

[Users] Constant lopping log of task activity
by Matt Warren 07 Feb '14

07 Feb '14

I'm seeing a constant loop of task issues in the vdsm.log Host is a CentOS 6.5 server otherwise setup as a db lab server. Engine is a CentOS 6.5 vm running on vmware esx host. The host has local storage only. Not sure if related, but I've been trying to attach a Win2k8-hosted NFS share for ISO's and failing. I can manually mount it just fine from the host os, but the ovirt-engine complains of privileges errors. I also had trouble getting the host recognized in ovirt dues to a messed up sudoers file. With that sorted, it added and report fine. Any troubleshooting tips? -------------------------------------------- Thread-84::DEBUG::2014-02-02 16:08:55,459::BindingXMLRPC::167::vds::(wrapper) client [10.1.9.11] Thread-84::DEBUG::2014-02-02 16:08:55,459::task::579::TaskManager.Task::(_updateState) Task=`cc9c6dac-ed6e-4cc9-a3e4-b741c5137caf`::moving from state init -> state preparing Thread-84::INFO::2014-02-02 16:08:55,460::logUtils::44::dispatcher::(wrapper) Run and protect: getSpmStatus(spUUID='b780d909-b6a0-4a38-82e2-3d7fd3a2b745', options=None) Thread-84::INFO::2014-02-02 16:08:55,460::logUtils::47::dispatcher::(wrapper) Run and protect: getSpmStatus, Return response: {'spm_st': {'spmId': 1, 'spmStatus': 'SPM', 'spmLver': 1}} Thread-84::DEBUG::2014-02-02 16:08:55,460::task::1168::TaskManager.Task::(prepare) Task=`cc9c6dac-ed6e-4cc9-a3e4-b741c5137caf`::finished: {'spm_st': {'spmId': 1, 'spmStatus': 'SPM', 'spmLver': 1}} Thread-84::DEBUG::2014-02-02 16:08:55,460::task::579::TaskManager.Task::(_updateState) Task=`cc9c6dac-ed6e-4cc9-a3e4-b741c5137caf`::moving from state preparing -> state finished Thread-84::DEBUG::2014-02-02 16:08:55,460::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-84::DEBUG::2014-02-02 16:08:55,461::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-84::DEBUG::2014-02-02 16:08:55,461::task::974::TaskManager.Task::(_decref) Task=`cc9c6dac-ed6e-4cc9-a3e4-b741c5137caf`::ref 0 aborting False Thread-85::DEBUG::2014-02-02 16:08:55,470::BindingXMLRPC::167::vds::(wrapper) client [10.1.9.11] Thread-85::DEBUG::2014-02-02 16:08:55,470::task::579::TaskManager.Task::(_updateState) Task=`59aa1ec2-64b9-4c6d-bdb8-66154f73915d`::moving from state init -> state preparing Thread-85::INFO::2014-02-02 16:08:55,470::logUtils::44::dispatcher::(wrapper) Run and protect: getStoragePoolInfo(spUUID='b780d909-b6a0-4a38-82e2-3d7fd3a2b745', options=None) Thread-85::DEBUG::2014-02-02 16:08:55,471::resourceManager::197::ResourceManager.Request::(__init__) ResName=`Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745`ReqID=`7bbb6abd-006b- 4b7b-b540-322dfdda7644`::Request was made in '/usr/share/vdsm/storage/hsm.py' line '2553' at 'getStoragePoolInfo' Thread-85::DEBUG::2014-02-02 16:08:55,471::resourceManager::541::ResourceManager::(registerResource) Trying to register resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' for lock type 'shared' Thread-85::DEBUG::2014-02-02 16:08:55,471::resourceManager::600::ResourceManager::(registerResource) Resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' is free. Now locking as 'shared' (1 active user) Thread-85::DEBUG::2014-02-02 16:08:55,471::resourceManager::237::ResourceManager.Request::(grant) ResName=`Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745`ReqID=`7bbb6abd-006b- 4b7b-b540-322dfdda7644`::Granted request Thread-85::DEBUG::2014-02-02 16:08:55,472::task::811::TaskManager.Task::(resourceAcquired) Task=`59aa1ec2-64b9-4c6d-bdb8-66154f73915d`::_resourcesAcquired: Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745 (shared) Thread-85::DEBUG::2014-02-02 16:08:55,472::task::974::TaskManager.Task::(_decref) Task=`59aa1ec2-64b9-4c6d-bdb8-66154f73915d`::ref 1 aborting False Thread-85::INFO::2014-02-02 16:08:55,472::logUtils::47::dispatcher::(wrapper) Run and protect: getStoragePoolInfo, Return response: {'info': {'spm_id': 1, 'master_uuid': 'd9f70b92-3c38-4503-ac69-b48325ead406', 'name': 'hnwdb05-Local', 'version': '3', 'domains': 'd9f70b92-3c38-4503-ac69-b48325ead406:Active', 'pool_status': 'connected', 'isoprefix': '', 'type': 'LOCALFS', 'master_ver': 1, 'lver': 1}, 'dominfo': {'d9f70b92-3c38-4503-ac69-b48325ead406': {'status': 'Active', 'diskfree': '409127440384', 'alerts': [], 'version': 3, 'disktotal': '945068838912'}}} Thread-85::DEBUG::2014-02-02 16:08:55,473::task::1168::TaskManager.Task::(prepare) Task=`59aa1ec2-64b9-4c6d-bdb8-66154f73915d`::finished: {'info': {'spm_id': 1, 'master_uuid': 'd9f70b92-3c38-4503-ac69-b48325ead406', 'name': 'hnwdb05-Local', 'version': '3', 'domains': 'd9f70b92-3c38-4503-ac69-b48325ead406:Active', 'pool_status': 'connected', 'isoprefix': '', 'type': 'LOCALFS', 'master_ver': 1, 'lver': 1}, 'dominfo': {'d9f70b92-3c38-4503-ac69-b48325ead406': {'status': 'Active', 'diskfree': '409127440384', 'alerts': [], 'version': 3, 'disktotal': '945068838912'}}} Thread-85::DEBUG::2014-02-02 16:08:55,473::task::579::TaskManager.Task::(_updateState) Task=`59aa1ec2-64b9-4c6d-bdb8-66154f73915d`::moving from state preparing -> state finished Thread-85::DEBUG::2014-02-02 16:08:55,473::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745': < ResourceRef 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745', isValid: 'True' obj: 'None'>} Thread-85::DEBUG::2014-02-02 16:08:55,473::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-85::DEBUG::2014-02-02 16:08:55,473::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' Thread-85::DEBUG::2014-02-02 16:08:55,473::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' (0 active users) Thread-85::DEBUG::2014-02-02 16:08:55,474::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' is free, finding out if anyone is waiting for it. Thread-85::DEBUG::2014-02-02 16:08:55,474::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745', Clearing records. Thread-85::DEBUG::2014-02-02 16:08:55,474::task::974::TaskManager.Task::(_decref) Task=`59aa1ec2-64b9-4c6d-bdb8-66154f73915d`::ref 0 aborting False [slight pause] Thread-21::DEBUG::2014-02-02 16:08:58,274::fileSD::222::Storage.Misc.excCmd::(getReadDelay) '/bin/dd iflag=direct if=/rhev/data-center/mnt/_data_images/d9f70b92-3c38-4503-ac69-b48325ead406/ dom_md/metadata bs=4096 count=1' (cwd None) Thread-21::DEBUG::2014-02-02 16:08:58,281::fileSD::222::Storage.Misc.excCmd::(getReadDelay) SUCCESS: <err> = '0+1 records in\n0+1 records out\n461 bytes (461 B) copied, 0.000121435 s, 3.8 MB/s\n'; <rc> = 0 [slight pause and repeat] Thread-89::DEBUG::2014-02-02 16:09:05,405::task::579::TaskManager.Task::(_updateState) Task=`86ddb0cb-43c9-4e2f-b779-9ba2ccfaae99`::moving from state init -> state preparing Thread-89::INFO::2014-02-02 16:09:05,406::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-89::INFO::2014-02-02 16:09:05,406::logUtils::47::dispatcher::(wrapper) Run and protect: repoStats, Return response: {'d9f70b92-3c38-4503-ac69-b48325ead406': {'delay': '0.000121435', 'lastCheck': '7.1', 'code': 0, 'valid': True, 'version': 3}} Thread-89::DEBUG::2014-02-02 16:09:05,406::task::1168::TaskManager.Task::(prepare) Task=`86ddb0cb-43c9-4e2f-b779-9ba2ccfaae99`::finished: {'d9f70b92-3c38-4503-ac69-b48325ead406': {'delay': '0.000121435', 'lastCheck': '7.1', 'code': 0, 'valid': True, 'version': 3}} Thread-89::DEBUG::2014-02-02 16:09:05,406::task::579::TaskManager.Task::(_updateState) Task=`86ddb0cb-43c9-4e2f-b779-9ba2ccfaae99`::moving from state preparing -> state finished Thread-89::DEBUG::2014-02-02 16:09:05,406::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-89::DEBUG::2014-02-02 16:09:05,407::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-89::DEBUG::2014-02-02 16:09:05,407::task::974::TaskManager.Task::(_decref) Task=`86ddb0cb-43c9-4e2f-b779-9ba2ccfaae99`::ref 0 aborting False Thread-91::DEBUG::2014-02-02 16:09:05,488::BindingXMLRPC::167::vds::(wrapper) client [10.1.9.11] Thread-91::DEBUG::2014-02-02 16:09:05,488::task::579::TaskManager.Task::(_updateState) Task=`91b6affb-d61c-491e-ba08-6db785402efe`::moving from state init -> state preparing Thread-91::INFO::2014-02-02 16:09:05,489::logUtils::44::dispatcher::(wrapper) Run and protect: getSpmStatus(spUUID='b780d909-b6a0-4a38-82e2-3d7fd3a2b745', options=None) Thread-91::INFO::2014-02-02 16:09:05,489::logUtils::47::dispatcher::(wrapper) Run and protect: getSpmStatus, Return response: {'spm_st': {'spmId': 1, 'spmStatus': 'SPM', 'spmLver': 1}} Thread-91::DEBUG::2014-02-02 16:09:05,489::task::1168::TaskManager.Task::(prepare) Task=`91b6affb-d61c-491e-ba08-6db785402efe`::finished: {'spm_st': {'spmId': 1, 'spmStatus': 'SPM', 'spmLver': 1}} Thread-91::DEBUG::2014-02-02 16:09:05,489::task::579::TaskManager.Task::(_updateState) Task=`91b6affb-d61c-491e-ba08-6db785402efe`::moving from state preparing -> state finished Thread-91::DEBUG::2014-02-02 16:09:05,489::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-91::DEBUG::2014-02-02 16:09:05,489::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-91::DEBUG::2014-02-02 16:09:05,490::task::974::TaskManager.Task::(_decref) Task=`91b6affb-d61c-491e-ba08-6db785402efe`::ref 0 aborting False Thread-92::DEBUG::2014-02-02 16:09:05,496::BindingXMLRPC::167::vds::(wrapper) client [10.1.9.11] Thread-92::DEBUG::2014-02-02 16:09:05,496::task::579::TaskManager.Task::(_updateState) Task=`538b5b93-8e03-4a1c-a1c7-43769926d532`::moving from state init -> state preparing Thread-92::INFO::2014-02-02 16:09:05,497::logUtils::44::dispatcher::(wrapper) Run and protect: getStoragePoolInfo(spUUID='b780d909-b6a0-4a38-82e2-3d7fd3a2b745', options=None) Thread-92::DEBUG::2014-02-02 16:09:05,497::resourceManager::197::ResourceManager.Request::(__init__) ResName=`Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745`ReqID=`128ecb64-c414- 44be-8fb4-ce8688f3a66f`::Request was made in '/usr/share/vdsm/storage/hsm.py' line '2553' at 'getStoragePoolInfo' Thread-92::DEBUG::2014-02-02 16:09:05,497::resourceManager::541::ResourceManager::(registerResource) Trying to register resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' for lock type 'shared' Thread-92::DEBUG::2014-02-02 16:09:05,498::resourceManager::600::ResourceManager::(registerResource) Resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' is free. Now locking as 'shared' (1 active user) Thread-92::DEBUG::2014-02-02 16:09:05,498::resourceManager::237::ResourceManager.Request::(grant) ResName=`Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745`ReqID=`128ecb64-c414- 44be-8fb4-ce8688f3a66f`::Granted request Thread-92::DEBUG::2014-02-02 16:09:05,498::task::811::TaskManager.Task::(resourceAcquired) Task=`538b5b93-8e03-4a1c-a1c7-43769926d532`::_resourcesAcquired: Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745 (shared) Thread-92::DEBUG::2014-02-02 16:09:05,498::task::974::TaskManager.Task::(_decref) Task=`538b5b93-8e03-4a1c-a1c7-43769926d532`::ref 1 aborting False Thread-92::INFO::2014-02-02 16:09:05,499::logUtils::47::dispatcher::(wrapper) Run and protect: getStoragePoolInfo, Return response: {'info': {'spm_id': 1, 'master_uuid': 'd9f70b92-3c38-4503-ac69-b48325ead406', 'name': 'hnwdb05-Local', 'version': '3', 'domains': 'd9f70b92-3c38-4503-ac69-b48325ead406:Active', 'pool_status': 'connected', 'isoprefix': '', 'type': 'LOCALFS', 'master_ver': 1, 'lver': 1}, 'dominfo': {'d9f70b92-3c38-4503-ac69-b48325ead406': {'status': 'Active', 'diskfree': '409127440384', 'alerts': [], 'version': 3, 'disktotal': '945068838912'}}} Thread-92::DEBUG::2014-02-02 16:09:05,499::task::1168::TaskManager.Task::(prepare) Task=`538b5b93-8e03-4a1c-a1c7-43769926d532`::finished: {'info': {'spm_id': 1, 'master_uuid': 'd9f70b92-3c38-4503-ac69-b48325ead406', 'name': 'hnwdb05-Local', 'version': '3', 'domains': 'd9f70b92-3c38-4503-ac69-b48325ead406:Active', 'pool_status': 'connected', 'isoprefix': '', 'type': 'LOCALFS', 'master_ver': 1, 'lver': 1}, 'dominfo': {'d9f70b92-3c38-4503-ac69-b48325ead406': {'status': 'Active', 'diskfree': '409127440384', 'alerts': [], 'version': 3, 'disktotal': '945068838912'}}} Thread-92::DEBUG::2014-02-02 16:09:05,499::task::579::TaskManager.Task::(_updateState) Task=`538b5b93-8e03-4a1c-a1c7-43769926d532`::moving from state preparing -> state finished Thread-92::DEBUG::2014-02-02 16:09:05,499::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745': < ResourceRef 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745', isValid: 'True' obj: 'None'>} Thread-92::DEBUG::2014-02-02 16:09:05,499::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-92::DEBUG::2014-02-02 16:09:05,500::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' Thread-92::DEBUG::2014-02-02 16:09:05,500::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' (0 active users) Thread-92::DEBUG::2014-02-02 16:09:05,500::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745' is free, finding out if anyone is waiting for it. Thread-92::DEBUG::2014-02-02 16:09:05,500::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.b780d909-b6a0-4a38-82e2-3d7fd3a2b745', Clearing records. Thread-92::DEBUG::2014-02-02 16:09:05,500::task::974::TaskManager.Task::(_decref) Task=`538b5b93-8e03-4a1c-a1c7-43769926d532`::ref 0 aborting False [slight pause] Thread-21::DEBUG::2014-02-02 16:09:08,290::fileSD::222::Storage.Misc.excCmd::(getReadDelay) '/bin/dd iflag=direct if=/rhev/data-center/mnt/_data_images/d9f70b92-3c38-4503-ac69-b48325ead406/ dom_md/metadata bs=4096 count=1' (cwd None) Thread-21::DEBUG::2014-02-02 16:09:08,296::fileSD::222::Storage.Misc.excCmd::(getReadDelay) SUCCESS: <err> = '0+1 records in\n0+1 records out\n461 bytes (461 B) copied, 0.000263153 s, 1.8 MB/s\n'; <rc> = 0

3 2

[Users] Will this two node concept scale and work?
by ml ml 06 Feb '14

06 Feb '14

Hello List, my aim is to host multiple VMs which are redundant and are high available. It should also scale well. I think usually people just buy a fat iSCSI Storage and attach this. In my case it should scale well from very small nodes to big ones. Therefore an iSCSI Target will bring a lot of overhead (10GBit Links and two Paths, and really i should have a 2nd Hot Standby SAN, too). This makes scalability very hard. This post is also not meant to be a iscsi discussion. Since oVirt does not support DRBD out of the box i came up with my own concept: http://oi62.tinypic.com/2550xg5.jpg As far as i can tell i have the following advantages: -------------------------------------------------------------------- - i can start with two simple cheap nodes - i could add more disks to my nodes. Maybe even a SSD as a dedicated drbdresource. - i can connect the two nodes directly to each other with bonding or infiniband. i dont need a switch or something between it. Downside: --------------- - i always need two nodes (as a couple) Will this setup work for me. So far i think i will be quite happy with it. Since the DRBD Resources are shared in dual primary mode i am not sure if ovirt can handle it. It is not allowed to write to a vm disk at the same time. The Concept of Linbit ( http://www.linbit.com/en/company/news/333-high-available-virtualization-at-…) seems to much of an overhead with the iSCSI Layer and pacemaker setup. Its just too much for such a simple task. Please tell me that this concept is great and will work and scale well. Otherwise i am also thankful for any hints or critical ideas. Thanks a lot, Mario

6 6

Re: [Users] oVirt or RHEV ?
by Martijn Grendelman 06 Feb '14

06 Feb '14

Martijn Grendelman schreef op 6-2-2014 17:02: > Hi, > > Dan Yasny schreef op 6-2-2014 16:38: >> This is the same question as in RHEL or Fedora IMO: do you want the >> bleeding edge features and lower code stability and reliability, or do >> you want to have techsupport (and that means a real SLA and an >> escalation path up to the engineering, if need be) behind you, stable >> and reliable, well tested code, but less of the advanced features. > > Thank you, this is what I thought. > > It's still a hard decision. If the stability and "testedness" of RHEL is > anything to go by, it's not reassuring at all (although it may be better > than Fedora, I don't know), although I must say that RedHat support is > helpful at times. > > Thanks again, I think I know enough :-) Or not ;-) Would it be possible (and doable) to migrate from oVirt to RHEV? If we start out with oVirt, but after some time we decide that RHEV would be a better fit after all, would it be possible to hook up existing oVirt/VDSM hosts to a RHEV engine, or am I thinking way too simple now? Cheers, Martijn. >> >> >> On Thu, Feb 6, 2014 at 8:06 AM, Martijn Grendelman >> <martijn.grendelman(a)isaac.nl <mailto:martijn.grendelman@isaac.nl>> wrote: >> >> Hi, >> >> This may be the wrong place to ask, but I'm looking for input to form an >> opinion on an "oVirt or RHEV" question within my company. >> >> I have been running oVirt for about 5 months now, and I'm quite >> comfortable with its features and maintenance procedures. We are now >> planning to build a private virtualization cluster for hosting clients' >> applications as well as our own. Some people in the company are >> questioning whether we should buy RHEV, but at this point, I can't see >> the benefits. >> >> Can anyone on this list shed a light on when RHEV might be a better >> choice than oVirt? What are the benefits? The trade-offs? >> >> I am looking for pragmatic, real-world things, not marketing mumbo >> jumbo. That, I can get from redhat.com <http://redhat.com> ;-) >> >> Best regards, >> Martijn. >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >

6 6

Re: [Users] oVirt or RHEV ?
by Martijn Grendelman 06 Feb '14

06 Feb '14

Hi, Dan Yasny schreef op 6-2-2014 16:38: > This is the same question as in RHEL or Fedora IMO: do you want the > bleeding edge features and lower code stability and reliability, or do > you want to have techsupport (and that means a real SLA and an > escalation path up to the engineering, if need be) behind you, stable > and reliable, well tested code, but less of the advanced features. Thank you, this is what I thought. It's still a hard decision. If the stability and "testedness" of RHEL is anything to go by, it's not reassuring at all (although it may be better than Fedora, I don't know), although I must say that RedHat support is helpful at times. Thanks again, I think I know enough :-) Best regards, Martijn Grendelman > > > > > On Thu, Feb 6, 2014 at 8:06 AM, Martijn Grendelman > <martijn.grendelman(a)isaac.nl <mailto:martijn.grendelman@isaac.nl>> wrote: > > Hi, > > This may be the wrong place to ask, but I'm looking for input to form an > opinion on an "oVirt or RHEV" question within my company. > > I have been running oVirt for about 5 months now, and I'm quite > comfortable with its features and maintenance procedures. We are now > planning to build a private virtualization cluster for hosting clients' > applications as well as our own. Some people in the company are > questioning whether we should buy RHEV, but at this point, I can't see > the benefits. > > Can anyone on this list shed a light on when RHEV might be a better > choice than oVirt? What are the benefits? The trade-offs? > > I am looking for pragmatic, real-world things, not marketing mumbo > jumbo. That, I can get from redhat.com <http://redhat.com> ;-) > > Best regards, > Martijn. > _______________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > >

1 0

Re: [Users] Storage server
by Koen Vanoppen 06 Feb '14

06 Feb '14

Thanks. Found the command! For further reference to users: update storageconnection <storageconnectionid> --address <IP-Address> Kind regards, Koen 2014-02-06 Itamar Heim <iheim(a)redhat.com>: > On 02/06/2014 01:48 PM, Koen Vanoppen wrote: > >> I would like to keep the vms... >> I know that there is a command in the CLI "update storageconnection", >> but how do I use this to change only the IP of the storage connection? >> >> Kind regards, >> >> Koen >> On Feb 6, 2014 12:55 PM, "Itamar Heim" <iheim(a)redhat.com >> <mailto:iheim@redhat.com>> wrote: >> >> On 02/06/2014 12:54 PM, Koen Vanoppen wrote: >> >> What if I remove the "old ip" storage domains and import the >> same iscsi >> luns with the new IP, would that work? >> >> >> removing a domain *deletes* all disks/vms, other than that... >> >> (we are working on ability to detach/attach domains post 3.4) >> >> >> Kind Regards >> >> >> 2014-02-06 Koen Vanoppen <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com >> >> <mailto:vanoppen.koen@gmail.com>>>: >> >> Can I change the storagedomain ip from the ovirt-shell? >> Thanks in advance >> >> >> 2014-02-06 Itamar Heim <iheim(a)redhat.com >> <mailto:iheim@redhat.com> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com>>>: >> >> On 02/06/2014 12:03 PM, Koen Vanoppen wrote: >> >> Can I change the storagedomain ip from the >> ovirt-shell? >> Thanks in advance >> >> >> please reply to list, thanks >> >> >> >> 2014-02-06 Itamar Heim <iheim(a)redhat.com >> <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com >> >>>>: >> >> >> >> On 02/06/2014 05:16 AM, Koen Vanoppen wrote: >> >> It's not on DNS... The storage server in >> ovirt is >> on IP... So... >> What >> are my options in this case? >> >> >> you would need to 'edit the connection'. since >> 3.3.1 >> this is >> possible via the rest api without hacking the >> db: >> http://www.ovirt.org/Features/______Manage_Storage_Connections >> <http://www.ovirt.org/Features/____Manage_Storage_Connections> >> >> <http://www.ovirt.org/__Features/__Manage_Storage___Connections >> <http://www.ovirt.org/Features/__Manage_Storage_Connections>> >> >> >> >> <http://www.ovirt.org/____Features/Manage_Storage_____Connections< >> http://www.ovirt.org/__Features/Manage_Storage___Connections> >> >> <http://www.ovirt.org/__Features/Manage_Storage___Connections >> <http://www.ovirt.org/Features/Manage_Storage_Connections>>> >> >> Thanx! >> >> Kind regards, >> Koen >> >> On Feb 5, 2014 9:08 AM, "Itamar Heim" >> <iheim(a)redhat.com <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>> >> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com>>> >> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com>> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>>>>> wrote: >> >> On 02/04/2014 03:10 PM, Elad Ben >> Aharon wrote: >> >> Actually, the best way to do it >> would be >> to create another >> storage domain and migrate all >> the VMs's >> disks to it >> (you can do >> it while the VMs are running), >> then you >> won't suffer >> from a down >> time. >> >> >> notice this will create a snapshot >> for your >> vms and may >> change them >> from raw to qcow. also, this not >> supported for >> shared disks. >> >> If you don't have the option to >> do so, the >> best way to >> do it >> would be to shut down the VMs, >> put the >> storage domain to >> 'Maintenance' and then perform >> the storage >> server network >> change. When the connection to >> the storage >> is fixed, >> activate >> the domain and resume the VMs >> manually. >> >> >> that's assuming the domain was added >> using dns >> and not ip >> address, >> and that the dns expiration/caching >> on all >> hosts will >> notice the new >> ip address. >> >> >> >> ----- Original Message ----- >> From: "Koen Vanoppen" >> <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com <mailto:vanoppen.koen@gmail.com >> >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>. >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>.>______com >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>>>> >> To: "Elad Ben Aharon" >> <ebenahar(a)redhat.com <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>>>__>__, users(a)ovirt.org >> >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org >> <mailto:users@ovirt.org> <mailto:users@ovirt.org >> <mailto:users@ovirt.org>>> >> <mailto:users@ovirt.org >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>>>> >> >> >> Sent: Tuesday, February 4, 2014 >> 2:57:57 PM >> Subject: Re: [Users] Storage server >> >> For the moment, nothing is going >> on. The >> change is >> planned on >> Thursday. So, >> correct me if I'm wrong, you say >> that the >> fastest and >> easiest >> way is to >> suspend all the machines, make >> the change >> of the >> storage server, >> rediscover >> the iscsi server and then bring >> the vm's >> back up? >> >> Kind regards, >> Koen >> On Feb 4, 2014 1:47 PM, "Elad Ben >> Aharon" >> <ebenahar(a)redhat.com >> <mailto:ebenahar@redhat.com> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>>>__> wrote: >> >> Hi, >> >> I suppose that those VMs are >> now in >> 'Paused' state, >> correct >> me if I'm >> wrong. >> After connectivity with >> storage comes >> back, all VMs >> which >> couldn't detect >> their disks should be resumed >> from >> 'Paused' to 'Up' >> state >> automatically. It >> shouldn't take them a long >> time to >> change their >> state (a few >> minutes). >> >> ----- Original Message ----- >> From: "Koen Vanoppen" >> <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com <mailto:vanoppen.koen@gmail.com >> >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>. >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>.>______com >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>>>> >> To: users(a)ovirt.org >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>>> >> <mailto:users@ovirt.org >> <mailto:users@ovirt.org> <mailto:users@ovirt.org >> <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>>>> >> Sent: Tuesday, February 4, >> 2014 2:32:46 PM >> Subject: [Users] Storage server >> >> Dear All, >> >> At work, the network guys >> have come to >> a discovery >> that they >> have made a >> mistake in their network >> configuration... The >> Storage server >> that we use as >> ISCSI target in oVirt, is in >> the wrong >> VLAN, so the >> wrong IP >> address... >> >> What is the best way to make >> sure that >> all of our >> vms (40) >> that are using >> this scsi storage will come >> up again >> after the storage >> server has changed >> his ip? >> What are the best steps to be >> taken...? >> We are using oVirt Engine >> Version: >> 3.3.1-2.el6 >> >> Kind Regards, >> >> Koen >> >> >> >> _______________________________________________________ >> >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>>>> >> http://lists.ovirt.org/________mailman/listinfo/users >> <http://lists.ovirt.org/______mailman/listinfo/users> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users>> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>>> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>> >> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>>>> >> >> >> >> _______________________________________________________ >> >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>>>> >> http://lists.ovirt.org/________mailman/listinfo/users >> <http://lists.ovirt.org/______mailman/listinfo/users> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users>> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>>> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>> >> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>>>> >> >> >> >> >> >> >> >> >> >> _________________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > juan replied to that >

2 2

Re: [Users] Storage server
by Koen Vanoppen 06 Feb '14

06 Feb '14

Can I change the storagedomain ip from the ovirt-shell? Thanks in advance 2014-02-06 Itamar Heim <iheim(a)redhat.com>: > On 02/06/2014 12:03 PM, Koen Vanoppen wrote: > >> Can I change the storagedomain ip from the ovirt-shell? >> Thanks in advance >> > > please reply to list, thanks > > >> >> 2014-02-06 Itamar Heim <iheim(a)redhat.com <mailto:iheim@redhat.com>>: >> >> >> On 02/06/2014 05:16 AM, Koen Vanoppen wrote: >> >> It's not on DNS... The storage server in ovirt is on IP... So... >> What >> are my options in this case? >> >> >> you would need to 'edit the connection'. since 3.3.1 this is >> possible via the rest api without hacking the db: >> http://www.ovirt.org/Features/__Manage_Storage_Connections >> >> <http://www.ovirt.org/Features/Manage_Storage_Connections> >> >> Thanx! >> >> Kind regards, >> Koen >> >> On Feb 5, 2014 9:08 AM, "Itamar Heim" <iheim(a)redhat.com >> <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>>> wrote: >> >> On 02/04/2014 03:10 PM, Elad Ben Aharon wrote: >> >> Actually, the best way to do it would be to create >> another >> storage domain and migrate all the VMs's disks to it >> (you can do >> it while the VMs are running), then you won't suffer >> from a down >> time. >> >> >> notice this will create a snapshot for your vms and may >> change them >> from raw to qcow. also, this not supported for shared disks. >> >> If you don't have the option to do so, the best way to >> do it >> would be to shut down the VMs, put the storage domain to >> 'Maintenance' and then perform the storage server network >> change. When the connection to the storage is fixed, >> activate >> the domain and resume the VMs manually. >> >> >> that's assuming the domain was added using dns and not ip >> address, >> and that the dns expiration/caching on all hosts will >> notice the new >> ip address. >> >> >> >> ----- Original Message ----- >> From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> To: "Elad Ben Aharon" <ebenahar(a)redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>>, users(a)ovirt.org >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> >> Sent: Tuesday, February 4, 2014 2:57:57 PM >> Subject: Re: [Users] Storage server >> >> For the moment, nothing is going on. The change is >> planned on >> Thursday. So, >> correct me if I'm wrong, you say that the fastest and >> easiest >> way is to >> suspend all the machines, make the change of the >> storage server, >> rediscover >> the iscsi server and then bring the vm's back up? >> >> Kind regards, >> Koen >> On Feb 4, 2014 1:47 PM, "Elad Ben Aharon" >> <ebenahar(a)redhat.com <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> >> <mailto:ebenahar@redhat.com>>> wrote: >> >> Hi, >> >> I suppose that those VMs are now in 'Paused' state, >> correct >> me if I'm >> wrong. >> After connectivity with storage comes back, all VMs >> which >> couldn't detect >> their disks should be resumed from 'Paused' to 'Up' >> state >> automatically. It >> shouldn't take them a long time to change their >> state (a few >> minutes). >> >> ----- Original Message ----- >> From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> To: users(a)ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> Sent: Tuesday, February 4, 2014 2:32:46 PM >> Subject: [Users] Storage server >> >> Dear All, >> >> At work, the network guys have come to a discovery >> that they >> have made a >> mistake in their network configuration... The >> Storage server >> that we use as >> ISCSI target in oVirt, is in the wrong VLAN, so the >> wrong IP >> address... >> >> What is the best way to make sure that all of our >> vms (40) >> that are using >> this scsi storage will come up again after the >> storage >> server has changed >> his ip? >> What are the best steps to be taken...? >> We are using oVirt Engine Version: 3.3.1-2.el6 >> >> Kind Regards, >> >> Koen >> >> ___________________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>> >> >> ___________________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>> >> >> >> >> >> >

3 5

[Users] Python SDK list vms slow, excessive cpu usage
by Sander Grendelman 06 Feb '14

06 Feb '14

Fetching the list of vms through the API with the python SDK takes several seconds[1] with 100% cpu usage in the python script. When I look at the engine log there is only one (fast) fetch from the API. The rest of the time is spent in the SDK processing a relatively small bit of XML data (only 26 VMs in my environment). This seems an excessive amount of CPU for processing ~6KB of XML. I've included some sample code [2] and output [3]. Attached is the cProfile output for this call and a visualization. [1] ~6,5 seconds on an oVirt VM with 1 vcpu on older hardware, ~3,5 seconds on a fast physical machine with an i5 cpu. [2] Sample code, add your own url/credentials/certificate: #!/usr/bin/python """Get ovirt VM names""" import time from ovirtsdk.api import API from ovirtsdk.xml import params def print_elapsed(logString): elapsed = time.time() - startTime print "%fs %s" % (elapsed, logString) startTime = time.time() print_elapsed("before connect") api = API( url="https://my.engine.url/api", username="user@domain", password="password", ca_file="./ca.crt", ) print_elapsed("after connect") print_elapsed("before fetch list") vmList = api.vms.list() print_elapsed("after fetch list") print_elapsed("before use list") count = 0 for vm in vmList: vmName = vm.get_name() count += 1 print "\t number of VMs %d" % count [3] Example of output: [grendelmans@bungee src]$ /usr/bin/time ./vm_list_test.py 0.000003s before connect 0.338248s after connect 0.338299s before fetch list 6.795967s after fetch list 6.796041s before use list number of VMs 26 6.796181s after use list 7.28user 0.05system 0:07.64elapsed 96%CPU (0avgtext+0avgdata 84624maxresident)k 0inputs+0outputs (0major+5605minor)pagefaults 0swaps [grendelmans@bungee src]$

5 6

Re: [Users] Storage server
by Itamar Heim 06 Feb '14

06 Feb '14

On 02/06/2014 05:16 AM, Koen Vanoppen wrote: > It's not on DNS... The storage server in ovirt is on IP... So... What > are my options in this case? you would need to 'edit the connection'. since 3.3.1 this is possible via the rest api without hacking the db: http://www.ovirt.org/Features/Manage_Storage_Connections > Thanx! > > Kind regards, > Koen > > On Feb 5, 2014 9:08 AM, "Itamar Heim" <iheim(a)redhat.com > <mailto:iheim@redhat.com>> wrote: > > On 02/04/2014 03:10 PM, Elad Ben Aharon wrote: > > Actually, the best way to do it would be to create another > storage domain and migrate all the VMs's disks to it (you can do > it while the VMs are running), then you won't suffer from a down > time. > > > notice this will create a snapshot for your vms and may change them > from raw to qcow. also, this not supported for shared disks. > > If you don't have the option to do so, the best way to do it > would be to shut down the VMs, put the storage domain to > 'Maintenance' and then perform the storage server network > change. When the connection to the storage is fixed, activate > the domain and resume the VMs manually. > > > that's assuming the domain was added using dns and not ip address, > and that the dns expiration/caching on all hosts will notice the new > ip address. > > > > ----- Original Message ----- > From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com > <mailto:vanoppen.koen@gmail.com>> > To: "Elad Ben Aharon" <ebenahar(a)redhat.com > <mailto:ebenahar@redhat.com>>, users(a)ovirt.org > <mailto:users@ovirt.org> > Sent: Tuesday, February 4, 2014 2:57:57 PM > Subject: Re: [Users] Storage server > > For the moment, nothing is going on. The change is planned on > Thursday. So, > correct me if I'm wrong, you say that the fastest and easiest > way is to > suspend all the machines, make the change of the storage server, > rediscover > the iscsi server and then bring the vm's back up? > > Kind regards, > Koen > On Feb 4, 2014 1:47 PM, "Elad Ben Aharon" <ebenahar(a)redhat.com > <mailto:ebenahar@redhat.com>> wrote: > > Hi, > > I suppose that those VMs are now in 'Paused' state, correct > me if I'm > wrong. > After connectivity with storage comes back, all VMs which > couldn't detect > their disks should be resumed from 'Paused' to 'Up' state > automatically. It > shouldn't take them a long time to change their state (a few > minutes). > > ----- Original Message ----- > From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com > <mailto:vanoppen.koen@gmail.com>> > To: users(a)ovirt.org <mailto:users@ovirt.org> > Sent: Tuesday, February 4, 2014 2:32:46 PM > Subject: [Users] Storage server > > Dear All, > > At work, the network guys have come to a discovery that they > have made a > mistake in their network configuration... The Storage server > that we use as > ISCSI target in oVirt, is in the wrong VLAN, so the wrong IP > address... > > What is the best way to make sure that all of our vms (40) > that are using > this scsi storage will come up again after the storage > server has changed > his ip? > What are the best steps to be taken...? > We are using oVirt Engine Version: 3.3.1-2.el6 > > Kind Regards, > > Koen > > _________________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/__mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > _________________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/__mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >

1 0

[Users] Import VMware
by Maurice James 06 Feb '14

06 Feb '14

--_14551f3c-807e-4ead-9bc7-e8dee89e0f36_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is it possible to import vmware images into ovirt 3.3=2C Or is a running Es= x instance still required? = --_14551f3c-807e-4ead-9bc7-e8dee89e0f36_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'>Is it possible to import vmware = images into ovirt 3.3=2C Or is a running Esx instance still required? = </div></body> </html>= --_14551f3c-807e-4ead-9bc7-e8dee89e0f36_--

4 9

[Users] Mixing tagged and untagged VLANs
by Trey Dockendorf 06 Feb '14

06 Feb '14

Using 3.3.2 I seem unable to mix tagged and untagged VLANs on a single interface. I'm trying to put the following logical networks on a host's eth0. ovirtmgmt: - Display Network - Migration Network - NOT VM Network - NO VLAN private: - VM network - NO VLAN ipmi: - VM Network - VLAN 2 In the host's network setup ovirtmgmt is already linked to eth0. If I attach 'ipmi (VLAN 2)' then try and attach 'private' the message is "Cannot have more than one non-VLAN network on one interface". Same occurs if I try and attach 'private' when only 'ovirtmgmt' is assigned to eth0. Is it not possible to have multiple untagged VLAN networks associated to one interface in oVirt? Thanks - Trey

3 3

[Users] ovirt 3.3.3 host deploy push an "old" vdsm
by Gianluca Cecchi 05 Feb '14

05 Feb '14

Hello, fedora 19 engine 3.3.3 with ovirt-host-deploy-1.1.3-1.fc19.noarch when I deploy a fedora 19 host from web admin gui I get on it vdsm-4.13.0-11.fc19.x86_64 (it seems updated at november 2013) If after that I explicitly enable ovirt 3.3.3 yum repo and run yum update on host it correctly passes to : vdsm-4.13.3-3.fc19.x86_64 Gianluca

3 4

[Users] Putting a Gluster host into an ISCSI DC
by Gianluca Cecchi 05 Feb '14

05 Feb '14

Hello, in a test infra I would to temporarily put a Host that is part of Gluster DC and has gluster volumes active into an ISCSI DC. I put Gluster DC in maintenance, stop glustervolume and put both hosts in maintenance. Then I try to edit host and put into the ISCSI DC. But I receive error Error while executing action: node02: Cannot Edit host. Server having Gluster volume Is there any basic check so that I cannot do this at all? Any tip? Thanks, Gianluca

3 3

[Users] My first wiki page
by Juan Pablo Lorier 05 Feb '14

05 Feb '14

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --deoiLO4vfFDeGT8PRV00k91A9xPxiS603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I've created my first wiki page and I'd like someone to review it and tell me if there's something that need to be changed (besides it does not have any style yet) The URL is http://www.ovirt.org/oVirt_Wiki:How_to_change_Gluster%27s_network_interfa= ce Regards, --deoiLO4vfFDeGT8PRV00k91A9xPxiS603 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS754aAAoJEC5KDDg2+NMMAnMIAKRXKtYFHfo/PSqEJOaacWom B8L1px+Vy2HpL9m71ofaaGhl1fvGP8hGYGFuAwTDT2zXxheE5BQlnM6sh0Dc2KS9 f4sNwylw9axbMdTmhr/6rGfsTSuv/616FRumOHJ+lUoxg0q4xd4kIMfN56o+E2TQ MC5x/ZMtSimaTZeoP8ZZsXFSBwVoX3Y3PSI0FJ6PbsMz9/v/XPDoYSdLP/ZhSptj NV9PVUqyVEj0A/8T0HPY2Uja9AXmWZL0Z1DYTms0uBkk7jwvzbGOYbJ/9WXckaxn uOTxrMrkfa1qsyzsun26Qxi6mTj04Kp03bnwnFgXDXt4ey4EZ+mfWh6U5ezYGQY= =GZ12 -----END PGP SIGNATURE----- --deoiLO4vfFDeGT8PRV00k91A9xPxiS603--

4 4

[Users] Networking. Hosted Setup. All in One Host. Hetzner
by Peter Styk 05 Feb '14

05 Feb '14

Greetings, I'm writing here as to share some of my findings about hosting with Hetzner. All in one setups on single remote host can be tricky. Provider mounted an extra /29 subnet to the main host but none is routed by default and host has to become router itself. At the same time single mistake in bridging configuration and lost access results in need for re-bootstrap. It's still tempting to try and with many trials I eventually got to see guests talking to the net. Scenario 1: Working. Package bridge-utils, oVirt engine, setup bridge, VDSM, add host to engine, add routing to host routing table. Networking by trial and error. Still something is not right. Occasionally on ping out I'm getting "Redirect Host (New nexthop" messages. http://styk.tv/wp-content/uploads/2014/01/oVirtHosted1_almost_working.png Scenario 2: Dreaming. Private network with private router/dhcp/nat. Private 10.0.0.0/24 network. No problems with routing as gateway 10.0.0.1 would be on the same subnet. Thought of using pfSense but can't seem to bring up an instance with two network cards on two different networks. I thought this would be easy. Go to Networks, click create new network, type private, save ok. then go to new instance. point at iso, attach two network cards. save ok. Launch "Host did not satisfy internal filter Network" No idea what that is. Maybe I don't understand how this works. I even tried removing ovirtmgmt network and leaving private network by itself. Tried with all 3 network card types (rtl8139/e1000/VirtIO) http://styk.tv/wp-content/uploads/2014/01/oVirtHosted2_preferred.png Either way if you have a minute or two please take a look at both attached diagrams. Deliberately making it difficult by forcing all elements on single box in hosted environment. Maybe there is a way to have this all installed with Neutron or vSwitch on the same box or is that pushing it? Regards, Peter

3 3

[Users] Engine-setup Fail
by Kevin Tibi 05 Feb '14

05 Feb '14

Hi all, i try to update my ovirt-engine. I use nightly repo. For moment, i am on 3.4. When i try to up 3.5 i have a fail when it download the package: [ INFO ] Yum Downloading: (7/7): ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm 48 M(47%) [ ERROR ] Yum [u'Des erreurs ont \xe9t\xe9 rencontr\xe9e durant le t\xe9l\xe9chargement des paquets.', u'ovirt-engine-dbscripts-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-dbscripts-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-dbscripts-3.5.…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-restapi-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-restapi-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-restapi-3.5.0-…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-tools-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-tools-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-tools-3.5.0-0.…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-webadmin-porta…: [Errno 14] curl#18 - "transfer closed with 54679208 bytes remaining to read"', u'ovirt-engine-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-3.5.0-0.0.mast…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-backend-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-backend-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-backend-3.5.0-…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable'] [ ERROR ] Failed to execute stage 'Package installation': [u'Des erreurs ont \xe9t\xe9 rencontr\xe9e durant le t\xe9l\xe9chargement des paquets.', u'ovirt-engine-dbscripts-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-dbscripts-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-dbscripts-3.5.…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-restapi-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-restapi-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-restapi-3.5.0-…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-tools-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-tools-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-tools-3.5.0-0.…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-webadmin-porta…: [Errno 14] curl#18 - "transfer closed with 54679208 bytes remaining to read"', u'ovirt-engine-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-3.5.0-0.0.mast…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable', u'ovirt-engine-backend-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch: failure: noarch/ovirt-engine-backend-3.5.0-0.0.master.20140130171441.git9257b30.fc19.noarch.rpm from ovirt-nightly: [Errno 256] No more mirrors to try.\nhttp:// ovirt.org/releases/nightly/rpm/Fedora/19/noarch/ovirt-engine-backend-3.5.0-…: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable'] [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20140204133303.log [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed I try to manual download, its work. I add the package in cache of yum and it's dont work. Thx for your help ;) Kevin.

3 10

[Users] ovirt engine and vdsm on same node
by Hans Emmanuel 05 Feb '14

05 Feb '14

Can we install ovirt engine and vdsm on same node ? If so any down side ? -- *Hans Emmanuel* *NOthing to FEAR but something to FEEL......*

3 3

[Users] Storage server
by Koen Vanoppen 05 Feb '14

05 Feb '14

Dear All, At work, the network guys have come to a discovery that they have made a mistake in their network configuration... The Storage server that we use as ISCSI target in oVirt, is in the wrong VLAN, so the wrong IP address... What is the best way to make sure that all of our vms (40) that are using this scsi storage will come up again after the storage server has changed his ip? What are the best steps to be taken...? We are using oVirt Engine Version: 3.3.1-2.el6 Kind Regards, Koen

3 5

[Users] Limit bandwidths for VM
by Hans Emmanuel 05 Feb '14

05 Feb '14

Hi all, I was thinking whether it is possible to limit bandwidth used by a particular vm ? So that we can make sure that its not eating up bw for other vms also. -- *Hans Emmanuel*

2 2

[Users] Problems with migration on a VM and not detected by gui
by Gianluca Cecchi 05 Feb '14

05 Feb '14

Hello, passing from 3.3.3rc to 3.3.3 final on fedora 19 based infra. Two hosts and one engine. Gluster DC. I have 3 VMs: CentOS 5.10, 6.5, Fedora 20 Main steps: 1) update engine with usual procedure 2) all VMs are on one node; I put into maintenance the other one and update it and reboot 3) activate the new node and migrate all VMs to it. >From webadmin gui point of view it seems all ok. Only "strange" thing is that the CentOS 6.5 VM has no ip shown, when usually it has becuse of ovrt-guest-agent installed on it So I try to connect to its console (configured as VNC). But I get error (the other two are ok and they are spice) Also, I cannot ping or ssh into the VM so there is indeed some problem. I didn't connect since 30th January so I don't knw if any probem arised before today. >From the original host /var/log/libvirt/qemu/c6s.log I see: 2014-01-30 11:21:37.561+0000: shutting down 2014-01-30 11:22:14.595+0000: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name c6s -S -machine pc-1.0,accel=kvm,usb=off -cpu Opteron_G2 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid 4147e0d3-19a7-447b-9d88-2ff19365bec0 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=19-5,serial=34353439-3036-435A-4A38-303330393338,uuid=4147e0d3-19a7-447b-9d88-2ff19365bec0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/c6s.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-01-23T11:42:26,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/glusterSD/f18ovn01.ceda.polimi.it:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/a5e4f67b-50b5-4740-9990-39deb8812445/53408cb0-bcd4-40de-bc69-89d59b7b5bc2,if=none,id=drive-virtio-disk0,format=raw,serial=a5e4f67b-50b5-4740-9990-39deb8812445,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/rhev/data-center/mnt/glusterSD/f18ovn01.ceda.polimi.it:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/c1477133-6b06-480d-a233-1dae08daf8b3/c2a82c64-9dee-42bb-acf2-65b8081f2edf,if=none,id=drive-scsi0-0-0-0,format=raw,serial=c1477133-6b06-480d-a233-1dae08daf8b3,cache=none,werror=stop,rerror=stop,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:8f:04:f8,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/4147e0d3-19a7-447b-9d88-2ff19365bec0.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/4147e0d3-19a7-447b-9d88-2ff19365bec0.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -device usb-tablet,id=input0 -vnc 0:0,password -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 char device redirected to /dev/pts/0 (label charconsole0) 2014-02-04 12:48:01.855+0000: shutting down qemu: terminating on signal 15 from pid 1021 >From the updated host where I apparently migrated it I see: 2014-02-04 12:47:54.674+0000: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name c6s -S -machine pc-1.0,accel=kvm,usb=off -cpu Opteron_G2 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid 4147e0d3-19a7-447b-9d88-2ff19365bec0 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=19-5,serial=34353439-3036-435A-4A38-303330393338,uuid=4147e0d3-19a7-447b-9d88-2ff19365bec0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/c6s.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-01-28T13:08:06,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/mnt/glusterSD/f18ovn01.ceda.polimi.it:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/a5e4f67b-50b5-4740-9990-39deb8812445/53408cb0-bcd4-40de-bc69-89d59b7b5bc2,if=none,id=drive-virtio-disk0,format=raw,serial=a5e4f67b-50b5-4740-9990-39deb8812445,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/rhev/data-center/mnt/glusterSD/f18ovn01.ceda.polimi.it:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/c1477133-6b06-480d-a233-1dae08daf8b3/c2a82c64-9dee-42bb-acf2-65b8081f2edf,if=none,id=drive-scsi0-0-0-0,format=raw,serial=c1477133-6b06-480d-a233-1dae08daf8b3,cache=none,werror=stop,rerror=stop,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:8f:04:f8,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/4147e0d3-19a7-447b-9d88-2ff19365bec0.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/4147e0d3-19a7-447b-9d88-2ff19365bec0.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -device usb-tablet,id=input0 -vnc 0:0,password -k en-us -vga cirrus -incoming tcp:[::]:51152 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 char device redirected to /dev/pts/1 (label charconsole0) engine log https://drive.google.com/file/d/0BwoPbcrMv8mvZWpqOHNqc0dnenc/edit?usp=shari… source vdsm log: https://drive.google.com/file/d/0BwoPbcrMv8mvYlluMDh1Y19jdEU/edit?usp=shari… dest vdsm log https://drive.google.com/file/d/0BwoPbcrMv8mvT1JxcmdKWlloOFU/edit?usp=shari… First error I see in source host log: Thread-728830::ERROR::2014-02-04 13:42:59,735::BindingXMLRPC::984::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 970, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/gluster/api.py", line 53, in wrapper rv = func(*args, **kwargs) File "/usr/share/vdsm/gluster/api.py", line 206, in volumeStatus statusOption) File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ return callMethod() File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> **kwargs) File "<string>", line 2, in glusterVolumeStatus File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result) KeyError: 'path' Thread-728831::ERROR::2014-02-04 13:42:59,805::BindingXMLRPC::984::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 970, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/gluster/api.py", line 53, in wrapper rv = func(*args, **kwargs) File "/usr/share/vdsm/gluster/api.py", line 206, in volumeStatus statusOption) File "/usr/share/vdsm/supervdsm.py", line 50, in __call__ return callMethod() File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda> **kwargs) File "<string>", line 2, in glusterVolumeStatus File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result) KeyError: 'path' Thread-323::INFO::2014-02-04 13:43:05,765::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291', spUUID='eb679feb-4da2-4fd0-a185-abbe459ffa70', imgUUID='a3d332c0-c302-4f28-9ed3-e2e83566343f', volUUID='701eca86-df87-4b16-ac6d-e9f51e7ac171', options=None) Apart the problem itself, another one is in my opinion the engine that doesn't know about it at all.... For this VM, in its event tab I can see only: 2014-Feb-04, 13:57 user admin@internal initiated console session for VM c6s 1b78630c oVirt 2014-Feb-04, 13:51 user admin@internal initiated console session for VM c6s 1d77f16a oVirt 2014-Feb-04, 13:48 Migration completed (VM: c6s, Source: f18ovn03, Destination: f18ovn01, Duration: 8 sec). 17c547cc oVirt 2014-Feb-04, 13:47 Migration started (VM: c6s, Source: f18ovn03, Destination: f18ovn01, User: admin@internal). 17c547cc oVirt 2014-Jan-30, 12:30 user admin@internal initiated console session for VM c6s 5536edb8 oVirt 2014-Jan-30, 12:23 VM c6s started on Host f18ovn03 45209312 oVirt 2014-Jan-30, 12:22 user admin@internal initiated console session for VM c6s 19c766c8 oVirt 2014-Jan-30, 12:22 user admin@internal initiated console session for VM c6s 79815897 oVirt 2014-Jan-30, 12:22 VM c6s was started by admin@internal (Host: f18ovn03). 45209312 oVirt 2014-Jan-30, 12:22 VM c6s configuration was updated by admin@internal. 76cbc53 oVirt 2014-Jan-30, 12:21 VM c6s is down. Exit message: User shut down oVirt 2014-Jan-30, 12:20 VM shutdown initiated by admin@internal on VM c6s (Host: f18ovn03). 213c3a55 oVirt Gianluca

4 6

[Users] VM install failures on a stateless node
by David Li 04 Feb '14

04 Feb '14

Hi, I have been trying to install my first VM on a stateless node. so far I have failed twice with the node ending up in the "Non-responsive" mode. I had to reboot to recover and it took a while to reconfigure everything since this is stateless. I can still get into the node via the console. It's not dead. But the ovirtmgmt interface seems to be dead. The other iSCSI interface is running ok. Can anyone recommend ways how to debug this problem? Thanks. David

2 5

[Users] Ovirt 3.3.2 Cannot attach POSIX (gluster) storage domain
by Steve Dainard 04 Feb '14

04 Feb '14

I can successfully create a POSIX storage domain backed by gluster, but at the end of creation I get an error message "failed to acquire host id". Note that I have successfully created/activated NFS DC/SD on the same ovirt/hosts. I have some logs when I tried to attach to the DC after failure: *engine.log* 2014-02-04 09:54:04,324 INFO [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (ajp--127.0.0.1-8702-3) [1dd40406] Lock Acquired to object EngineLock [ex clusiveLocks= key: 8c4e8898-c91a-4d49-98e8-b6467791a9cc value: POOL , sharedLocks= ] 2014-02-04 09:54:04,473 INFO [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (pool-6-thread-42) [1dd40406] Running command: AddStoragePoolWithStorages Command internal: false. Entities affected : ID: 8c4e8898-c91a-4d49-98e8-b6467791a9cc Type: StoragePool 2014-02-04 09:54:04,673 INFO [org.ovirt.engine.core.bll.storage.ConnectStorageToVdsCommand] (pool-6-thread-42) [3f86c31b] Running command: ConnectStorageToVdsCommand intern al: true. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: System 2014-02-04 09:54:04,682 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (pool-6-thread-42) [3f86c31b] START, ConnectStorageServerVDSCommand( HostName = ovirt001, HostId = 48f13d47-8346-4ff6-81ca-4f4324069db3, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = POSIXFS, connectionList = [{ id: 87f9 ff74-93c4-4fe5-9a56-ed5338290af9, connection: 10.0.10.3:/rep2, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), lo g id: 332ff091 2014-02-04 09:54:05,089 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (pool-6-thread-42) [3f86c31b] FINISH, ConnectStorageServerVDSCommand , return: {87f9ff74-93c4-4fe5-9a56-ed5338290af9=0}, log id: 332ff091 2014-02-04 09:54:05,093 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand] (pool-6-thread-42) [3f86c31b] START, CreateStoragePoolVDSCommand(HostNa me = ovirt001, HostId = 48f13d47-8346-4ff6-81ca-4f4324069db3, storagePoolId=8c4e8898-c91a-4d49-98e8-b6467791a9cc, storageType=POSIXFS, storagePoolName=IT, masterDomainId=471 487ed-2946-4dfc-8ec3-96546006be12, domainsIdList=[471487ed-2946-4dfc-8ec3-96546006be12], masterVersion=3), log id: 1be84579 2014-02-04 09:54:08,833 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorag ePoolVDSCommand] (pool-6-thread-42) [3f86c31b] Failed in CreateStoragePoolVDS method 2014-02-04 09:54:08,834 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand] (pool-6-thread-42) [3f86c31b] Error code AcquireHostIdFailure and error message VDSGenericException: VDSErrorException: Failed to CreateStoragePoolVDS, error = Cannot acquire host id: ('471487ed-2946-4dfc-8ec3-96546006be12', SanlockException(22, 'Sanlock lockspace add failure', 'Invalid argument')) 2014-02-04 09:54:08,835 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand] (pool-6-thread-42) [3f86c31b] Command org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand return value StatusOnlyReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=661, mMessage=Cannot acquire host id: ('471487ed-2946-4dfc-8ec3-96546006be12', SanlockException(22, 'Sanlock lockspace add failure', 'Invalid argument'))]] 2014-02-04 09:54:08,836 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand] (pool-6-thread-42) [3f86c31b] HostName = ovirt001 2014-02-04 09:54:08,840 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand] (pool-6-thread-42) [3f86c31b] Command CreateStoragePoolVDS execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStoragePoolVDS, error = Cannot acquire host id: ('471487ed-2946-4dfc-8ec3-96546006be12', SanlockException(22, 'Sanlock lockspace add failure', 'Invalid argument')) 2014-02-04 09:54:08,840 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStoragePoolVDSCommand] (pool-6-thread-42) [3f86c31b] FINISH, CreateStoragePoolVDSCommand, log id: 1be84579 2014-02-04 09:54:08,841 ERROR [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (pool-6-thread-42) [3f86c31b] Command org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStoragePoolVDS, error = Cannot acquire host id: ('471487ed-2946-4dfc-8ec3-96546006be12', SanlockException(22, 'Sanlock lockspace add failure', 'Invalid argument')) (Failed with error AcquireHostIdFailure and code 661) 2014-02-04 09:54:08,867 INFO [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (pool-6-thread-42) [3f86c31b] Command [id=373987cb-b54d-4174-b4a9-195be631f0d7]: Compensating CHANGED_ENTITY of org.ovirt.engine.core.common.businessentities.StoragePool; snapshot: id=8c4e8898-c91a-4d49-98e8-b6467791a9cc. 2014-02-04 09:54:08,871 INFO [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (pool-6-thread-42) [3f86c31b] Command [id=373987cb-b54d-4174-b4a9-195be631f0d7]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.StoragePoolIsoMap; snapshot: storagePoolId = 8c4e8898-c91a-4d49-98e8-b6467791a9cc, storageId = 471487ed-2946-4dfc-8ec3-96546006be12. 2014-02-04 09:54:08,879 INFO [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (pool-6-thread-42) [3f86c31b] Command [id=373987cb-b54d-4174-b4a9-195be631f0d7]: Compensating CHANGED_ENTITY of org.ovirt.engine.core.common.businessentities.StorageDomainStatic; snapshot: id=471487ed-2946-4dfc-8ec3-96546006be12. 2014-02-04 09:54:08,951 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-6-thread-42) [3f86c31b] Correlation ID: 1dd40406, Job ID: 07003dff-9e0e-42ae-8f88-6b055b45f797, Call Stack: null, Custom Event ID: -1, Message: Failed to attach Storage Domains to Data Center IT. (User: admin@internal) 2014-02-04 09:54:08,975 INFO [org.ovirt.engine.core.bll.storage.AddStoragePoolWithStoragesCommand] (pool-6-thread-42) [3f86c31b] Lock freed to object EngineLock [exclusiveLocks= key: 8c4e8898-c91a-4d49-98e8-b6467791a9cc value: POOL , sharedLocks= ] *vdsm.log* Thread-30::DEBUG::2014-02-04 09:54:04,692::BindingXMLRPC::167::vds::(wrapper) client [10.0.10.2] flowID [3f86c31b] Thread-30::DEBUG::2014-02-04 09:54:04,692::task::579::TaskManager.Task::(_updateState) Task=`218dcde9-bbc7-4d5a-ad53-0bab556c6261`::moving from state init -> state preparing Thread-30::INFO::2014-02-04 09:54:04,693::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '10.0.10.3:/rep2', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '87f9ff74-93c4-4fe5-9a56-ed5338290af9'}], options=None) Thread-30::DEBUG::2014-02-04 09:54:04,698::mount::226::Storage.Misc.excCmd::(_runcmd) '/usr/bin/sudo -n /bin/mount -t glusterfs 10.0.10.3:/rep2 /rhev/data-center/mnt/10.0.10.3:_rep2' (cwd None) Thread-30::DEBUG::2014-02-04 09:54:05,067::hsm::2315::Storage.HSM::(__prefetchDomains) posix local path: /rhev/data-center/mnt/10.0.10.3:_rep2 Thread-30::DEBUG::2014-02-04 09:54:05,078::hsm::2333::Storage.HSM::(__prefetchDomains) Found SD uuids: ('471487ed-2946-4dfc-8ec3-96546006be12',) Thread-30::DEBUG::2014-02-04 09:54:05,078::hsm::2389::Storage.HSM::(connectStorageServer) knownSDs: {471487ed-2946-4dfc-8ec3-96546006be12: storage.nfsSD.findDomain} Thread-30::INFO::2014-02-04 09:54:05,078::logUtils::47::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 0, 'id': '87f9ff74-93c4-4fe5-9a56-ed5338290af9'}]} Thread-30::DEBUG::2014-02-04 09:54:05,079::task::1168::TaskManager.Task::(prepare) Task=`218dcde9-bbc7-4d5a-ad53-0bab556c6261`::finished: {'statuslist': [{'status': 0, 'id': '87f9ff74-93c4-4fe5-9a56-ed5338290af9'}]} Thread-30::DEBUG::2014-02-04 09:54:05,079::task::579::TaskManager.Task::(_updateState) Task=`218dcde9-bbc7-4d5a-ad53-0bab556c6261`::moving from state preparing -> state finished Thread-30::DEBUG::2014-02-04 09:54:05,079::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-30::DEBUG::2014-02-04 09:54:05,079::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-30::DEBUG::2014-02-04 09:54:05,079::task::974::TaskManager.Task::(_decref) Task=`218dcde9-bbc7-4d5a-ad53-0bab556c6261`::ref 0 aborting False Thread-31::DEBUG::2014-02-04 09:54:05,098::BindingXMLRPC::167::vds::(wrapper) client [10.0.10.2] flowID [3f86c31b] Thread-31::DEBUG::2014-02-04 09:54:05,099::task::579::TaskManager.Task::(_updateState) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::moving from state init -> state preparing Thread-31::INFO::2014-02-04 09:54:05,099::logUtils::44::dispatcher::(wrapper) Run and protect: createStoragePool(poolType=None, spUUID='8c4e8898-c91a-4d49-98e8-b6467791a9cc', poolName='IT', masterDom='471487ed-2946-4dfc-8ec3-96546006be12', domList=['471487ed-2946-4dfc-8ec3-96546006be12'], masterVersion=3, lockPolicy=None, lockRenewalIntervalSec=5, leaseTimeSec=60, ioOpTimeoutSec=10, leaseRetries=3, options=None) Thread-31::DEBUG::2014-02-04 09:54:05,099::misc::809::SamplingMethod::(__call__) Trying to enter sampling method (storage.sdc.refreshStorage) Thread-31::DEBUG::2014-02-04 09:54:05,100::misc::811::SamplingMethod::(__call__) Got in to sampling method Thread-31::DEBUG::2014-02-04 09:54:05,100::misc::809::SamplingMethod::(__call__) Trying to enter sampling method (storage.iscsi.rescan) Thread-31::DEBUG::2014-02-04 09:54:05,100::misc::811::SamplingMethod::(__call__) Got in to sampling method Thread-31::DEBUG::2014-02-04 09:54:05,100::iscsiadm::91::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /sbin/iscsiadm -m session -R' (cwd None) Thread-31::DEBUG::2014-02-04 09:54:05,114::iscsiadm::91::Storage.Misc.excCmd::(_runCmd) FAILED: <err> = 'iscsiadm: No session found.\n'; <rc> = 21 Thread-31::DEBUG::2014-02-04 09:54:05,115::misc::819::SamplingMethod::(__call__) Returning last result Thread-31::DEBUG::2014-02-04 09:54:07,144::multipath::112::Storage.Misc.excCmd::(rescan) '/usr/bin/sudo -n /sbin/multipath -r' (cwd None) Thread-31::DEBUG::2014-02-04 09:54:07,331::multipath::112::Storage.Misc.excCmd::(rescan) SUCCESS: <err> = ''; <rc> = 0 Thread-31::DEBUG::2014-02-04 09:54:07,332::lvm::510::OperationMutex::(_invalidateAllPvs) Operation 'lvm invalidate operation' got the operation mutex Thread-31::DEBUG::2014-02-04 09:54:07,333::lvm::512::OperationMutex::(_invalidateAllPvs) Operation 'lvm invalidate operation' released the operation mutex Thread-31::DEBUG::2014-02-04 09:54:07,333::lvm::521::OperationMutex::(_invalidateAllVgs) Operation 'lvm invalidate operation' got the operation mutex Thread-31::DEBUG::2014-02-04 09:54:07,333::lvm::523::OperationMutex::(_invalidateAllVgs) Operation 'lvm invalidate operation' released the operation mutex Thread-31::DEBUG::2014-02-04 09:54:07,333::lvm::541::OperationMutex::(_invalidateAllLvs) Operation 'lvm invalidate operation' got the operation mutex Thread-31::DEBUG::2014-02-04 09:54:07,334::lvm::543::OperationMutex::(_invalidateAllLvs) Operation 'lvm invalidate operation' released the operation mutex Thread-31::DEBUG::2014-02-04 09:54:07,334::misc::819::SamplingMethod::(__call__) Returning last result Thread-31::DEBUG::2014-02-04 09:54:07,499::fileSD::137::Storage.StorageDomain::(__init__) Reading domain in path /rhev/data-center/mnt/10.0.10.3: _rep2/471487ed-2946-4dfc-8ec3-96546006be12 Thread-31::DEBUG::2014-02-04 09:54:07,605::persistentDict::192::Storage.PersistentDict::(__init__) Created a persistent dict with FileMetadataRW backend Thread-31::DEBUG::2014-02-04 09:54:07,647::persistentDict::234::Storage.PersistentDict::(refresh) read lines (FileMetadataRW)=['CLASS=Data', 'DESCRIPTION=gluster-store-rep2', 'IOOPTIMEOUTSEC=10', 'LEASERETRIES=3', 'LEASETIMESEC=60', 'LOCKPOLICY=', 'LOCKRENEWALINTERVALSEC=5', 'POOL_UUID=', 'REMOTE_PATH=10.0.10.3:/rep2', 'ROLE=Regular', 'SDUUID=471487ed-2946-4dfc-8ec3-96546006be12', 'TYPE=POSIXFS', 'VERSION=3', '_SHA_CKSUM=469191aac3fb8ef504b6a4d301b6d8be6fffece1'] Thread-31::DEBUG::2014-02-04 09:54:07,683::fileSD::558::Storage.StorageDomain::(imageGarbageCollector) Removing remnants of deleted images [] Thread-31::DEBUG::2014-02-04 09:54:07,684::resourceManager::420::ResourceManager::(registerNamespace) Registering namespace '471487ed-2946-4dfc-8ec3-96546006be12_imageNS' Thread-31::DEBUG::2014-02-04 09:54:07,684::resourceManager::420::ResourceManager::(registerNamespace) Registering namespace '471487ed-2946-4dfc-8ec3-96546006be12_volumeNS' Thread-31::INFO::2014-02-04 09:54:07,684::fileSD::299::Storage.StorageDomain::(validate) sdUUID=471487ed-2946-4dfc-8ec3-96546006be12 Thread-31::DEBUG::2014-02-04 09:54:07,692::persistentDict::234::Storage.PersistentDict::(refresh) read lines (FileMetadataRW)=['CLASS=Data', 'DESCRIPTION=gluster-store-rep2', 'IOOPTIMEOUTSEC=10', 'LEASERETRIES=3', 'LEASETIMESEC=60', 'LOCKPOLICY=', 'LOCKRENEWALINTERVALSEC=5', 'POOL_UUID=', 'REMOTE_PATH=10.0.10.3:/rep2', 'ROLE=Regular', 'SDUUID=471487ed-2946-4dfc-8ec3-96546006be12', 'TYPE=POSIXFS', 'VERSION=3', '_SHA_CKSUM=469191aac3fb8ef504b6a4d301b6d8be6fffece1'] Thread-31::DEBUG::2014-02-04 09:54:07,693::resourceManager::197::ResourceManager.Request::(__init__) ResName=`Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc`ReqID=`e0a3d477-b953-49d9-ab78-67695a6bc6d5`::Request was made in '/usr/share/vdsm/storage/hsm.py' line '971' at 'createStoragePool' Thread-31::DEBUG::2014-02-04 09:54:07,693::resourceManager::541::ResourceManager::(registerResource) Trying to register resource 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc' for lock type 'exclusive' Thread-31::DEBUG::2014-02-04 09:54:07,693::resourceManager::600::ResourceManager::(registerResource) Resource 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc' is free. Now locking as 'exclusive' (1 active user) Thread-31::DEBUG::2014-02-04 09:54:07,693::resourceManager::237::ResourceManager.Request::(grant) ResName=`Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc`ReqID=`e0a3d477-b953-49d9-ab78-67695a6bc6d5`::Granted request Thread-31::DEBUG::2014-02-04 09:54:07,694::task::811::TaskManager.Task::(resourceAcquired) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::_resourcesAcquired: Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc (exclusive) Thread-31::DEBUG::2014-02-04 09:54:07,694::task::974::TaskManager.Task::(_decref) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::ref 1 aborting False Thread-31::DEBUG::2014-02-04 09:54:07,694::resourceManager::197::ResourceManager.Request::(__init__) ResName=`Storage.471487ed-2946-4dfc-8ec3-96546006be12`ReqID=`bc20dd7e-d351-47c5-8ed3-78b1b11d703a`::Request was made in '/usr/share/vdsm/storage/hsm.py' line '973' at 'createStoragePool' Thread-31::DEBUG::2014-02-04 09:54:07,694::resourceManager::541::ResourceManager::(registerResource) Trying to register resource 'Storage.471487ed-2946-4dfc-8ec3-96546006be12' for lock type 'exclusive' Thread-31::DEBUG::2014-02-04 09:54:07,695::resourceManager::600::ResourceManager::(registerResource) Resource 'Storage.471487ed-2946-4dfc-8ec3-96546006be12' is free. Now locking as 'exclusive' (1 active user) Thread-31::DEBUG::2014-02-04 09:54:07,695::resourceManager::237::ResourceManager.Request::(grant) ResName=`Storage.471487ed-2946-4dfc-8ec3-96546006be12`ReqID=`bc20dd7e-d351-47c5-8ed3-78b1b11d703a`::Granted request Thread-31::DEBUG::2014-02-04 09:54:07,695::task::811::TaskManager.Task::(resourceAcquired) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::_resourcesAcquired: Storage.471487ed-2946-4dfc-8ec3-96546006be12 (exclusive) Thread-31::DEBUG::2014-02-04 09:54:07,695::task::974::TaskManager.Task::(_decref) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::ref 1 aborting False Thread-31::INFO::2014-02-04 09:54:07,696::sp::593::Storage.StoragePool::(create) spUUID=8c4e8898-c91a-4d49-98e8-b6467791a9cc poolName=IT master_sd=471487ed-2946-4dfc-8ec3-96546006be12 domList=['471487ed-2946-4dfc-8ec3-96546006be12'] masterVersion=3 {'LEASETIMESEC': 60, 'IOOPTIMEOUTSEC': 10, 'LEASERETRIES': 3, 'LOCKRENEWALINTERVALSEC': 5} Thread-31::INFO::2014-02-04 09:54:07,696::fileSD::299::Storage.StorageDomain::(validate) sdUUID=471487ed-2946-4dfc-8ec3-96546006be12 Thread-31::DEBUG::2014-02-04 09:54:07,703::persistentDict::234::Storage.PersistentDict::(refresh) read lines (FileMetadataRW)=['CLASS=Data', 'DESCRIPTION=gluster-store-rep2', 'IOOPTIMEOUTSEC=10', 'LEASERETRIES=3', 'LEASETIMESEC=60', 'LOCKPOLICY=', 'LOCKRENEWALINTERVALSEC=5', 'POOL_UUID=', 'REMOTE_PATH=10.0.10.3:/rep2', 'ROLE=Regular', 'SDUUID=471487ed-2946-4dfc-8ec3-96546006be12', 'TYPE=POSIXFS', 'VERSION=3', '_SHA_CKSUM=469191aac3fb8ef504b6a4d301b6d8be6fffece1'] Thread-31::DEBUG::2014-02-04 09:54:07,710::persistentDict::234::Storage.PersistentDict::(refresh) read lines (FileMetadataRW)=['CLASS=Data', 'DESCRIPTION=gluster-store-rep2', 'IOOPTIMEOUTSEC=10', 'LEASERETRIES=3', 'LEASETIMESEC=60', 'LOCKPOLICY=', 'LOCKRENEWALINTERVALSEC=5', 'POOL_UUID=', 'REMOTE_PATH=10.0.10.3:/rep2', 'ROLE=Regular', 'SDUUID=471487ed-2946-4dfc-8ec3-96546006be12', 'TYPE=POSIXFS', 'VERSION=3', '_SHA_CKSUM=469191aac3fb8ef504b6a4d301b6d8be6fffece1'] Thread-31::DEBUG::2014-02-04 09:54:07,711::persistentDict::167::Storage.PersistentDict::(transaction) Starting transaction Thread-31::DEBUG::2014-02-04 09:54:07,711::persistentDict::175::Storage.PersistentDict::(transaction) Finished transaction Thread-31::INFO::2014-02-04 09:54:07,711::clusterlock::174::SANLock::(acquireHostId) Acquiring host id for domain 471487ed-2946-4dfc-8ec3-96546006be12 (id: 250) Thread-31::ERROR::2014-02-04 09:54:08,722::task::850::TaskManager.Task::(_setError) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 857, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 45, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 977, in createStoragePool masterVersion, leaseParams) File "/usr/share/vdsm/storage/sp.py", line 618, in create self._acquireTemporaryClusterLock(msdUUID, leaseParams) File "/usr/share/vdsm/storage/sp.py", line 560, in _acquireTemporaryClusterLock msd.acquireHostId(self.id) File "/usr/share/vdsm/storage/sd.py", line 458, in acquireHostId self._clusterLock.acquireHostId(hostId, async) File "/usr/share/vdsm/storage/clusterlock.py", line 189, in acquireHostId raise se.AcquireHostIdFailure(self._sdUUID, e) AcquireHostIdFailure: Cannot acquire host id: ('471487ed-2946-4dfc-8ec3-96546006be12', SanlockException(22, 'Sanlock lockspace add failure', 'Invalid argument')) Thread-31::DEBUG::2014-02-04 09:54:08,826::task::869::TaskManager.Task::(_run) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::Task._run: 66924dbf-5a1c-473e-a158-d038aae38dc3 (None, '8c4e8898-c91a-4d49-98e8-b6467791a9cc', 'IT', '471487ed-2946-4dfc-8ec3-96546006be12', ['471487ed-2946-4dfc-8ec3-96546006be12'], 3, None, 5, 60, 10, 3) {} failed - stopping task Thread-31::DEBUG::2014-02-04 09:54:08,826::task::1194::TaskManager.Task::(stop) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::stopping in state preparing (force False) Thread-31::DEBUG::2014-02-04 09:54:08,826::task::974::TaskManager.Task::(_decref) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::ref 1 aborting True Thread-31::INFO::2014-02-04 09:54:08,826::task::1151::TaskManager.Task::(prepare) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::aborting: Task is aborted: 'Cannot acquire host id' - code 661 Thread-31::DEBUG::2014-02-04 09:54:08,826::task::1156::TaskManager.Task::(prepare) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::Prepare: aborted: Cannot acquire host id Thread-31::DEBUG::2014-02-04 09:54:08,827::task::974::TaskManager.Task::(_decref) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::ref 0 aborting True Thread-31::DEBUG::2014-02-04 09:54:08,827::task::909::TaskManager.Task::(_doAbort) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::Task._doAbort: force False Thread-31::DEBUG::2014-02-04 09:54:08,827::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-31::DEBUG::2014-02-04 09:54:08,827::task::579::TaskManager.Task::(_updateState) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::moving from state preparing -> state aborting Thread-31::DEBUG::2014-02-04 09:54:08,827::task::534::TaskManager.Task::(__state_aborting) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::_aborting: recover policy none Thread-31::DEBUG::2014-02-04 09:54:08,827::task::579::TaskManager.Task::(_updateState) Task=`66924dbf-5a1c-473e-a158-d038aae38dc3`::moving from state aborting -> state failed Thread-31::DEBUG::2014-02-04 09:54:08,827::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {'Storage.471487ed-2946-4dfc-8ec3-96546006be12': < ResourceRef 'Storage.471487ed-2946-4dfc-8ec3-96546006be12', isValid: 'True' obj: 'None'>, 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc': < ResourceRef 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc', isValid: 'True' obj: 'None'>} Thread-31::DEBUG::2014-02-04 09:54:08,828::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-31::DEBUG::2014-02-04 09:54:08,828::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.471487ed-2946-4dfc-8ec3-96546006be12' Thread-31::DEBUG::2014-02-04 09:54:08,828::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.471487ed-2946-4dfc-8ec3-96546006be12' (0 active users) Thread-31::DEBUG::2014-02-04 09:54:08,828::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.471487ed-2946-4dfc-8ec3-96546006be12' is free, finding out if anyone is waiting for it. Thread-31::DEBUG::2014-02-04 09:54:08,828::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.471487ed-2946-4dfc-8ec3-96546006be12', Clearing records. Thread-31::DEBUG::2014-02-04 09:54:08,828::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc' Thread-31::DEBUG::2014-02-04 09:54:08,829::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc' (0 active users) Thread-31::DEBUG::2014-02-04 09:54:08,829::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc' is free, finding out if anyone is waiting for it. Thread-31::DEBUG::2014-02-04 09:54:08,829::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.8c4e8898-c91a-4d49-98e8-b6467791a9cc', Clearing records. Thread-31::ERROR::2014-02-04 09:54:08,829::dispatcher::67::Storage.Dispatcher.Protect::(run) {'status': {'message': "Cannot acquire host id: ('471487ed-2946-4dfc-8ec3-96546006be12', SanlockException(22, 'Sanlock lockspace add failure', 'Invalid argument'))", 'code': 661}} *Storage domain metadata file:* CLASS=Data DESCRIPTION=gluster-store-rep2 IOOPTIMEOUTSEC=10 LEASERETRIES=3 LEASETIMESEC=60 LOCKPOLICY= LOCKRENEWALINTERVALSEC=5 POOL_UUID= REMOTE_PATH=10.0.10.3:/rep2 ROLE=Regular SDUUID=471487ed-2946-4dfc-8ec3-96546006be12 TYPE=POSIXFS VERSION=3 _SHA_CKSUM=469191aac3fb8ef504b6a4d301b6d8be6fffece1 *Steve Dainard * IT Infrastructure Manager Miovision <http://miovision.com/> | *Rethink Traffic* 519-513-2407 ex.250 877-646-8476 (toll-free) *Blog <http://miovision.com/blog> | **LinkedIn <https://www.linkedin.com/company/miovision-technologies> | Twitter <https://twitter.com/miovision> | Facebook <https://www.facebook.com/miovision>* ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.

3 4

Re: [Users] I can't remove VM
by Dafna Ron 04 Feb '14

04 Feb '14

Any time. If you manage to reproduce please let us know. Dafna On 02/04/2014 05:00 PM, Eduardo Ramos wrote: > Hi Dafna! Thanks for responding. > > In order to collect full logs, I migrated my 61 machines from 16 to 2 > hosts. When I tried to remove, it worked without any problem. I did > not understand why. I'm investigating. > > Thanks again for your attention. > > On 02/03/2014 11:43 AM, Dafna Ron wrote: >> please attach full vdsm and engine logs. >> >> Thanks, >> >> Dafna >> >> >> On 02/03/2014 12:11 PM, Eduardo Ramos wrote: >>> Hi all! >>> >>> I'm having trouble on removing virtual machines. My environment run >>> on a ISCSI domain storage. When I try remove, the SPM logs: >>> >>> # Start vdsm SPM log # >>> Thread-6019517::INFO::2014-02-03 >>> 09:58:09,293::logUtils::41::dispatcher::(wrapper) Run and protect: >>> deleteImage(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', >>> spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> imgUUID='57ba1906-2035-4503-acbc-5f6f077f75cc', postZero='false', >>> force='false') >>> Thread-6019517::INFO::2014-02-03 >>> 09:58:09,293::blockSD::816::Storage.StorageDomain::(validate) >>> sdUUID=c332da29-ba9f-4c94-8fa9-346bb8e04e2a >>> Thread-6019517::ERROR::2014-02-03 >>> 09:58:10,061::task::833::TaskManager.Task::(_setError) >>> Task=`8cbf9978-ed51-488a-af52-a3db030e44ff`::Unexpected error >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/task.py", line 840, in _run >>> return fn(*args, **kargs) >>> File "/usr/share/vdsm/logUtils.py", line 42, in wrapper >>> res = f(*args, **kwargs) >>> File "/usr/share/vdsm/storage/hsm.py", line 1429, in deleteImage >>> allVols = dom.getAllVolumes() >>> File "/usr/share/vdsm/storage/blockSD.py", line 972, in getAllVolumes >>> return getAllVolumes(self.sdUUID) >>> File "/usr/share/vdsm/storage/blockSD.py", line 172, in getAllVolumes >>> vImg not in res[vPar]['imgs']): >>> KeyError: '63650a24-7e83-4c0a-851d-0ce9869a294d' >>> Thread-6019517::INFO::2014-02-03 >>> 09:58:10,063::task::1134::TaskManager.Task::(prepare) >>> Task=`8cbf9978-ed51-488a-af52-a3db030e44ff`::aborting: Task is >>> aborted: u"'63650a24-7e83-4c0a-851d-0ce9869a294d'" - code 100 >>> Thread-6019517::ERROR::2014-02-03 >>> 09:58:10,066::dispatcher::70::Storage.Dispatcher.Protect::(run) >>> '63650a24-7e83-4c0a-851d-0ce9869a294d' >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run >>> result = ctask.prepare(self.func, *args, **kwargs) >>> File "/usr/share/vdsm/storage/task.py", line 1142, in prepare >>> raise self.error >>> KeyError: '63650a24-7e83-4c0a-851d-0ce9869a294d' >>> Thread-6019518::INFO::2014-02-03 >>> 09:58:10,087::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getSpmStatus(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> options=None) >>> Thread-6019518::INFO::2014-02-03 >>> 09:58:10,088::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getSpmStatus, Return response: {'spm_st': {'spmId': 14, 'spmStatus': >>> 'SPM', 'spmLver': 64}} >>> Thread-6019519::INFO::2014-02-03 >>> 09:58:10,100::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getAllTasksStatuses(spUUID=None, options=None) >>> Thread-6019519::INFO::2014-02-03 >>> 09:58:10,101::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getAllTasksStatuses, Return response: {'allTasksStatus': {}} >>> Thread-6019520::INFO::2014-02-03 >>> 09:58:10,109::logUtils::41::dispatcher::(wrapper) Run and protect: >>> spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) >>> Thread-6019520::INFO::2014-02-03 >>> 09:58:10,681::clusterlock::121::SafeLease::(release) Releasing >>> cluster lock for domain c332da29-ba9f-4c94-8fa9-346bb8e04e2a >>> Thread-6019521::INFO::2014-02-03 >>> 09:58:11,054::logUtils::41::dispatcher::(wrapper) Run and protect: >>> repoStats(options=None) >>> Thread-6019521::INFO::2014-02-03 >>> 09:58:11,054::logUtils::44::dispatcher::(wrapper) Run and protect: >>> repoStats, Return response: >>> {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': >>> '0.00799298286438', 'lastCheck': '5.3', 'code': 0, 'valid': True}, >>> u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': >>> '0.0197920799255', 'lastCheck': '4.9', 'code': 0, 'valid': True}, >>> u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': >>> '0.00803208351135', 'lastCheck': '5.3', 'code': 0, 'valid': True}} >>> Thread-6019520::INFO::2014-02-03 >>> 09:58:11,732::logUtils::44::dispatcher::(wrapper) Run and protect: >>> spmStop, Return response: None >>> Thread-6019523::INFO::2014-02-03 >>> 09:58:11,835::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getAllTasksStatuses(spUUID=None, options=None) >>> Thread-6019523::INFO::2014-02-03 >>> 09:58:11,835::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getAllTasksStatuses, Return response: {'allTasksStatus': {}} >>> Thread-6019524::INFO::2014-02-03 >>> 09:58:11,844::logUtils::41::dispatcher::(wrapper) Run and protect: >>> spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) >>> Thread-6019524::ERROR::2014-02-03 >>> 09:58:11,846::task::833::TaskManager.Task::(_setError) >>> Task=`00df5ff7-bbf4-4a0e-b60b-1b06dcaa7683`::Unexpected error >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/task.py", line 840, in _run >>> return fn(*args, **kargs) >>> File "/usr/share/vdsm/logUtils.py", line 42, in wrapper >>> res = f(*args, **kwargs) >>> File "/usr/share/vdsm/storage/hsm.py", line 601, in spmStop >>> pool.stopSpm() >>> File "/usr/share/vdsm/storage/securable.py", line 66, in wrapper >>> raise SecureError() >>> SecureError >>> Thread-6019524::INFO::2014-02-03 >>> 09:58:11,855::task::1134::TaskManager.Task::(prepare) >>> Task=`00df5ff7-bbf4-4a0e-b60b-1b06dcaa7683`::aborting: Task is >>> aborted: u'' - code 100 >>> Thread-6019524::ERROR::2014-02-03 >>> 09:58:11,857::dispatcher::70::Storage.Dispatcher.Protect::(run) >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run >>> result = ctask.prepare(self.func, *args, **kwargs) >>> File "/usr/share/vdsm/storage/task.py", line 1142, in prepare >>> raise self.error >>> SecureError >>> Dummy-6018624::INFO::2014-02-03 >>> 09:58:14,220::storage_mailbox::674::Storage.MailBox.SpmMailMonitor::(run) >>> SPM_MailMonitor - Incoming mail monitoring thread stopped >>> Thread-34627::INFO::2014-02-03 >>> 09:58:17,696::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', >>> spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> imgUUID='974d9602-8fbe-485b-a12d-59b6c34826b7', >>> volUUID='c1bcfe5c-20ab-4f50-a88b-e2e0e1184bf8', options=None) >>> Thread-34757::INFO::2014-02-03 >>> 09:58:17,696::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', >>> spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> imgUUID='49f65bfd-8592-42b9-9a31-91268402903f', >>> volUUID='511e6584-4f19-426d-9379-b223d0c2d9c6', options=None) >>> Thread-34627::INFO::2014-02-03 >>> 09:58:17,697::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getVolumeSize, Return response: {'truesize': '10737418240', >>> 'apparentsize': '10737418240'} >>> Thread-34757::INFO::2014-02-03 >>> 09:58:17,698::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getVolumeSize, Return response: {'truesize': '32212254720', >>> 'apparentsize': '32212254720'} >>> Thread-6019529::INFO::2014-02-03 >>> 09:58:21,672::logUtils::41::dispatcher::(wrapper) Run and protect: >>> repoStats(options=None) >>> Thread-6019529::INFO::2014-02-03 >>> 09:58:21,673::logUtils::44::dispatcher::(wrapper) Run and protect: >>> repoStats, Return response: >>> {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': >>> '0.00730204582214', 'lastCheck': '5.9', 'code': 0, 'valid': True}, >>> u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': >>> '0.0207469463348', 'lastCheck': '5.3', 'code': 0, 'valid': True}, >>> u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': >>> '0.00734615325928', 'lastCheck': '5.9', 'code': 0, 'valid': True}} >>> Thread-243::INFO::2014-02-03 >>> 09:58:27,800::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', >>> spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> imgUUID='50f2c3e9-aa94-4ad1-9c3f-91b452292374', >>> volUUID='d7cddb76-a5b7-49ed-9efe-44d92ec18d93', options=None) >>> Thread-34590::INFO::2014-02-03 >>> 09:58:27,801::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', >>> spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> imgUUID='c36bb1da-babd-47bd-a406-58f0cb529c00', >>> volUUID='6ea83f9e-c614-4e11-ab57-314ed4efeeaa', options=None) >>> Thread-243::INFO::2014-02-03 >>> 09:58:27,802::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getVolumeSize, Return response: {'truesize': '10737418240', >>> 'apparentsize': '10737418240'} >>> Thread-34590::INFO::2014-02-03 >>> 09:58:27,803::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getVolumeSize, Return response: {'truesize': '107374182400', >>> 'apparentsize': '107374182400'} >>> Thread-6019535::INFO::2014-02-03 >>> 09:58:32,337::logUtils::41::dispatcher::(wrapper) Run and protect: >>> repoStats(options=None) >>> Thread-6019535::INFO::2014-02-03 >>> 09:58:32,337::logUtils::44::dispatcher::(wrapper) Run and protect: >>> repoStats, Return response: >>> {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': >>> '0.0119340419769', 'lastCheck': '6.6', 'code': 0, 'valid': True}, >>> u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': >>> '0.0190720558167', 'lastCheck': '6.0', 'code': 0, 'valid': True}, >>> u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': >>> '0.00720596313477', 'lastCheck': '6.6', 'code': 0, 'valid': True}} >>> Thread-2017487::INFO::2014-02-03 >>> 09:58:37,692::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', >>> spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', >>> imgUUID='827f2d81-dc8c-414e-90d2-75e76b3250a0', >>> volUUID='f86ec330-0815-4361-8ce7-abf3318a8939', options=None) >>> Thread-2017487::INFO::2014-02-03 >>> 09:58:37,693::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getVolumeSize, Return response: {'truesize': '10737418240', >>> 'apparentsize': '10737418240'} >>> Thread-6019540::INFO::2014-02-03 >>> 09:58:39,118::logUtils::41::dispatcher::(wrapper) Run and protect: >>> getAllTasksStatuses(spUUID=None, options=None) >>> Thread-6019540::INFO::2014-02-03 >>> 09:58:39,118::logUtils::44::dispatcher::(wrapper) Run and protect: >>> getAllTasksStatuses, Return response: {'allTasksStatus': {}} >>> Thread-6019541::INFO::2014-02-03 >>> 09:58:39,126::logUtils::41::dispatcher::(wrapper) Run and protect: >>> spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) >>> Thread-6019541::ERROR::2014-02-03 >>> 09:58:39,127::task::833::TaskManager.Task::(_setError) >>> Task=`1f478485-401b-4b9b-b58b-1e7973cf64a2`::Unexpected error >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/task.py", line 840, in _run >>> return fn(*args, **kargs) >>> File "/usr/share/vdsm/logUtils.py", line 42, in wrapper >>> res = f(*args, **kwargs) >>> File "/usr/share/vdsm/storage/hsm.py", line 601, in spmStop >>> pool.stopSpm() >>> File "/usr/share/vdsm/storage/securable.py", line 66, in wrapper >>> raise SecureError() >>> SecureError >>> Thread-6019541::INFO::2014-02-03 >>> 09:58:39,128::task::1134::TaskManager.Task::(prepare) >>> Task=`1f478485-401b-4b9b-b58b-1e7973cf64a2`::aborting: Task is >>> aborted: u'' - code 100 >>> Thread-6019541::ERROR::2014-02-03 >>> 09:58:39,130::dispatcher::70::Storage.Dispatcher.Protect::(run) >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run >>> result = ctask.prepare(self.func, *args, **kwargs) >>> File "/usr/share/vdsm/storage/task.py", line 1142, in prepare >>> raise self.error >>> SecureError >>> # End vdsm SPM log # >>> >>> And after, the cluster elects another SPM. >>> >>> The webgui shows on 'events' tab: >>> >>> # Start webgui events # >>> Data Center is being initialized, please wait for initialization to >>> complete. >>> Failed to remove VM _12.147_postgresql_default.sir.inpe.br_apagar >>> (User: eduardo.ramos). >>> # End webgui events # >>> >>> Engine logs nothing but normal change of SPM. >>> >>> I would like to know how I can identify what is stuck, and if I can >>> delete by hand, deleting entry from DB and lvremove. >>> >>> Thanks! >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> >> > > -- Dafna Ron

1 0

[Users] oVirt 3.3.3 RC EL6 Live Snapshot
by Karli Sjöberg 04 Feb '14

04 Feb '14

Hi! I´ve gone through upgrading from 3.3.2 to 3.3.3 RC on CentOS 6.5 in our test environment, went off without a hitch, so "good job" guys! However something I´d very much like to see fixed is live snapshots for CentOS, especially since it seems to be fixed already for Fedora. Issue already been discussed: http://lists.ovirt.org/pipermail/users/2013-December/019090.html Is this something that can be targeted for 3.3.3 GA? -- 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

8 25

[Users] Install on CentOS6.5 fails
by ml ml 04 Feb '14

04 Feb '14

Hello List, i am trying to install oVirt on CentOS6.5 The Howto from: http://www.ovirt.org/Download fails with: [root@ovirt ovirt-engine]# yum localinstall http://ovirt.org/releases/ovirt-release-el.noarch.rpm Loaded plugins: fastestmirror, versionlock Setting up Local Package Process ovirt-release-el.noarch.rpm | 8.1 kB 00:00 Examining /var/tmp/yum-root-200V5v/ovirt-release-el.noarch.rpm: ovirt-release-el6-10.0.1-3.noarch Marking /var/tmp/yum-root-200V5v/ovirt-release-el.noarch.rpm to be installed Loading mirror speeds from cached hostfile * base: ftp.plusline.de * extras: mirror.skylink-datacenter.de * updates: ftp-stud.fht-esslingen.de Resolving Dependencies --> Running transaction check ---> Package ovirt-release-el6.noarch 0:10.0.1-3 will be installed --> Processing Dependency: epel-release for package: ovirt-release-el6-10.0.1-3.noarch --> Finished Dependency Resolution Error: Package: ovirt-release-el6-10.0.1-3.noarch (/ovirt-release-el.noarch) Requires: epel-release You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest So i used: http://wiki.centos.org/HowTos/oVirt The Install runs without any errors. However, i am getting a blank page now when i try to access my webadmin page. My Server.log: 1. 2014-02-04 12:19:49,332 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "jaxrs")]): org.jboss.modules.ModuleLoadError: Error loading module from /usr/share/ovirt-engine/modules/org/apache/httpcomponents/main/module.xml at org.jboss.modules.ModuleLoadException.toError(ModuleLoadException.java:78) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.Module.getPathsUnchecked(Module.java:1166) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.Module.loadModuleClass(Module.java:512) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.1.GA] at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrapClasses.<clinit>(ResteasyBootstrapClasses.java:11) at org.jboss.as.jaxrs.deployment.JaxrsScanningProcessor.<clinit>(JaxrsScanningProcessor.java:121) at org.jboss.as.jaxrs.JaxrsSubsystemAdd$1.execute(JaxrsSubsystemAdd.java:61) at org.jboss.as.server.AbstractDeploymentChainStep.execute(AbstractDeploymentChainStep.java:45) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:311) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_30] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_30] at java.lang.Thread.run(Thread.java:701) [rt.jar:1.6.0_30] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[31,47] Message: Failed to add resource root 'httpclient.jar' at path 'httpclient.jar' at org.jboss.modules.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:898) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:854) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:676) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:548) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:287) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:242) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.LocalModuleLoader.parseModuleInfoFile(LocalModuleLoader.java:138) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.LocalModuleLoader.findModule(LocalModuleLoader.java:122) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:275) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:222) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.LocalModuleLoader.preloadModule(LocalModuleLoader.java:94) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.Module.addPaths(Module.java:841) [jboss-modules.jar: 1.1.1.GA] at org.jboss.modules.Module.link(Module.java:1181) [jboss-modules.jar:1.1.1.GA] at org.jboss.modules.Module.getPaths(Module.java:1153) [jboss-modules.jar: 1.1.1.GA] at org.jboss.modules.Module.getPathsUnchecked(Module.java:1164) [jboss-modules.jar:1.1.1.GA] ... 19 more my processes: [root@ovirt ovirt-engine]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 19232 1488 ? Ss 12:01 0:01 /sbin/init root 2 0.0 0.0 0 0 ? S 12:01 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S 12:01 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S 12:01 0:00 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S 12:01 0:00 [migration/0] root 6 0.0 0.0 0 0 ? S 12:01 0:00 [watchdog/0] root 7 0.0 0.0 0 0 ? S 12:01 0:00 [events/0] root 8 0.0 0.0 0 0 ? S 12:01 0:00 [cgroup] root 9 0.0 0.0 0 0 ? S 12:01 0:00 [khelper] root 10 0.0 0.0 0 0 ? S 12:01 0:00 [netns] root 11 0.0 0.0 0 0 ? S 12:01 0:00 [async/mgr] root 12 0.0 0.0 0 0 ? S 12:01 0:00 [pm] root 13 0.0 0.0 0 0 ? S 12:01 0:00 [sync_supers] root 14 0.0 0.0 0 0 ? S 12:01 0:00 [bdi-default] root 15 0.0 0.0 0 0 ? S 12:01 0:00 [kintegrityd/0] root 16 0.0 0.0 0 0 ? S 12:01 0:00 [kblockd/0] root 17 0.0 0.0 0 0 ? S 12:01 0:00 [kacpid] root 18 0.0 0.0 0 0 ? S 12:01 0:00 [kacpi_notify] root 19 0.0 0.0 0 0 ? S 12:01 0:00 [kacpi_hotplug] root 20 0.0 0.0 0 0 ? S 12:01 0:00 [ata_aux] root 21 0.0 0.0 0 0 ? S 12:01 0:00 [ata_sff/0] root 22 0.0 0.0 0 0 ? S 12:01 0:00 [ksuspend_usbd] root 23 0.0 0.0 0 0 ? S 12:01 0:00 [khubd] root 24 0.0 0.0 0 0 ? S 12:01 0:00 [kseriod] root 25 0.0 0.0 0 0 ? S 12:01 0:00 [md/0] root 26 0.0 0.0 0 0 ? S 12:01 0:00 [md_misc/0] root 27 0.0 0.0 0 0 ? S 12:01 0:00 [linkwatch] root 28 0.0 0.0 0 0 ? S 12:01 0:00 [khungtaskd] root 29 0.0 0.0 0 0 ? S 12:01 0:00 [kswapd0] root 30 0.0 0.0 0 0 ? SN 12:01 0:00 [ksmd] root 31 0.0 0.0 0 0 ? SN 12:01 0:00 [khugepaged] root 32 0.0 0.0 0 0 ? S 12:01 0:00 [aio/0] root 33 0.0 0.0 0 0 ? S 12:01 0:00 [crypto/0] root 38 0.0 0.0 0 0 ? S 12:01 0:00 [kthrotld/0] root 39 0.0 0.0 0 0 ? S 12:01 0:00 [pciehpd] root 41 0.0 0.0 0 0 ? S 12:02 0:00 [kpsmoused] root 42 0.0 0.0 0 0 ? S 12:02 0:00 [usbhid_resumer] root 72 0.0 0.0 0 0 ? S 12:02 0:00 [kstriped] root 133 0.0 0.0 0 0 ? S 12:02 0:00 [scsi_eh_0] root 134 0.0 0.0 0 0 ? S 12:02 0:00 [scsi_eh_1] root 195 0.0 0.0 0 0 ? S 12:02 0:00 [scsi_eh_2] root 196 0.0 0.0 0 0 ? S 12:02 0:00 [vmw_pvscsi_wq_2] root 272 0.0 0.0 0 0 ? S 12:02 0:00 [kdmflush] root 274 0.0 0.0 0 0 ? S 12:02 0:00 [kdmflush] root 291 0.0 0.0 0 0 ? S 12:02 0:00 [jbd2/dm-0-8] root 292 0.0 0.0 0 0 ? S 12:02 0:00 [ext4-dio-unwrit] root 369 0.0 0.0 11076 1164 ? S<s 12:02 0:00 /sbin/udevd -d root 533 0.0 0.0 0 0 ? S 12:02 0:00 [vmmemctl] root 656 0.0 0.0 0 0 ? S 12:02 0:00 [jbd2/sda1-8] root 657 0.0 0.0 0 0 ? S 12:02 0:00 [ext4-dio-unwrit] root 695 0.0 0.0 0 0 ? S 12:02 0:00 [kauditd] root 765 0.0 0.0 0 0 ? S 12:02 0:00 [flush-253:0] root 903 0.0 0.0 27640 792 ? S<sl 12:02 0:00 auditd root 919 0.0 0.0 249088 1580 ? Sl 12:02 0:00 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5 root 956 0.0 0.0 0 0 ? S 12:02 0:00 [rpciod/0] rpcuser 962 0.0 0.0 23348 1328 ? Ss 12:02 0:00 rpc.statd -p 662 -o 2020 root 1081 0.0 0.0 66608 1228 ? Ss 12:02 0:00 /usr/sbin/sshd root 1203 0.0 0.0 81280 3400 ? Ss 12:02 0:00 /usr/libexec/postfix/master postfix 1211 0.0 0.0 81360 3372 ? S 12:02 0:00 pickup -l -t fifo -u postfix 1212 0.0 0.0 81532 3416 ? S 12:02 0:00 qmgr -l -t fifo -u root 1228 0.0 0.0 117300 1380 ? Ss 12:02 0:00 crond root 1232 0.0 0.0 100360 4060 ? Ss 12:02 0:00 sshd: root@pts/0 root 1245 0.0 0.0 4064 572 tty1 Ss+ 12:02 0:00 /sbin/mingetty /dev/tty1 root 1247 0.0 0.0 4064 568 tty2 Ss+ 12:02 0:00 /sbin/mingetty /dev/tty2 root 1249 0.0 0.0 4064 568 tty3 Ss+ 12:02 0:00 /sbin/mingetty /dev/tty3 root 1252 0.0 0.0 4064 572 tty4 Ss+ 12:02 0:00 /sbin/mingetty /dev/tty4 root 1254 0.0 0.0 12280 2580 ? S< 12:02 0:00 /sbin/udevd -d root 1255 0.0 0.0 12280 2576 ? S< 12:02 0:00 /sbin/udevd -d root 1256 0.0 0.0 4064 568 tty5 Ss+ 12:02 0:00 /sbin/mingetty /dev/tty5 root 1258 0.0 0.0 4064 568 tty6 Ss+ 12:02 0:00 /sbin/mingetty /dev/tty6 root 1263 0.0 0.0 108304 1852 pts/0 Ss+ 12:02 0:00 -bash root 1327 0.0 0.0 100360 4104 ? Ss 12:05 0:00 sshd: root@pts/1 root 1333 0.0 0.0 108304 1916 pts/1 Ss 12:05 0:00 -bash root 1574 0.0 0.0 100360 4088 ? Ss 12:08 0:00 sshd: root@pts/2 root 1578 0.0 0.0 108304 1896 pts/2 Ss+ 12:09 0:00 -bash rpc 6827 0.0 0.0 18976 872 ? Ss 12:11 0:00 rpcbind root 6923 0.0 0.0 21656 964 ? Ss 12:11 0:00 rpc.mountd -p 892 root 6928 0.0 0.0 0 0 ? S 12:11 0:00 [lockd] root 6929 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd4] root 6930 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd4_callbacks] root 6931 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6932 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6933 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6934 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6935 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6936 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6937 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6938 0.0 0.0 0 0 ? S 12:11 0:00 [nfsd] root 6961 0.0 0.0 25164 576 ? Ss 12:11 0:00 rpc.idmapd postgres 11279 0.0 0.1 217620 7044 ? S 12:19 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data postgres 11281 0.0 0.0 179264 1480 ? Ss 12:19 0:00 postgres: logger process postgres 11283 0.0 0.0 217736 2860 ? Ss 12:19 0:00 postgres: writer process postgres 11284 0.0 0.0 217620 1676 ? Ss 12:19 0:00 postgres: wal writer process postgres 11285 0.0 0.0 217884 2060 ? Ss 12:19 0:00 postgres: autovacuum launcher process postgres 11286 0.0 0.0 179548 1792 ? Ss 12:19 0:00 postgres: stats collector process ovirt 12406 0.9 6.0 2164440 300836 ? Ssl 12:19 0:08 engine-service -server -XX:+TieredCompilation -Xms1g -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -D postgres 12464 0.0 0.0 218848 3872 ? Ss 12:19 0:00 postgres: engine engine 127.0.0.1(42069) idle root 12494 0.0 0.1 201080 5532 ? Ss 12:20 0:00 /usr/sbin/httpd apache 12496 0.0 0.0 201220 3868 ? S 12:20 0:00 /usr/sbin/httpd apache 12497 0.0 0.0 201228 4044 ? S 12:20 0:00 /usr/sbin/httpd apache 12498 0.0 0.0 201228 4044 ? S 12:20 0:00 /usr/sbin/httpd apache 12499 0.0 0.0 201228 4004 ? S 12:20 0:00 /usr/sbin/httpd apache 12500 0.0 0.0 201228 4408 ? S 12:20 0:00 /usr/sbin/httpd apache 12501 0.0 0.0 201228 4536 ? S 12:20 0:00 /usr/sbin/httpd apache 12502 0.0 0.0 201228 4516 ? S 12:20 0:00 /usr/sbin/httpd apache 12503 0.0 0.0 201080 3124 ? S 12:20 0:00 /usr/sbin/httpd root 12557 0.0 0.0 110232 1168 pts/1 R+ 12:34 0:00 ps aux my packages: [root@ovirt ovirt-engine]# rpm -qa | grep ovirt ovirt-engine-sdk-3.2.0.3-1.el6.centos.alt.noarch ovirt-image-uploader-3.1.0-26.el6.centos.alt.noarch ovirt-engine-userportal-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-restapi-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-config-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-tools-common-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-webadmin-portal-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-backend-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-log-collector-3.1.0-26.el6.centos.alt.noarch ovirt-iso-uploader-3.1.0-26.el6.centos.alt.noarch ovirt-engine-cli-3.2.0.6-1.el6.centos.alt.noarch ovirt-engine-jbossas711-1-3.el6.alt.x86_64 ovirt-engine-dbscripts-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-setup-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-notification-service-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-genericapi-3.1.0-3.26.3.el6.centos.alt.noarch ovirt-engine-3.1.0-3.26.3.el6.centos.alt.noarch What i am doing wrong? Thank you! Cheers, Mario

5 4

[Users] ovirt-report Forbidden access error
by Alessandro Bianchi 04 Feb '14

04 Feb '14

Hi all I installed ovirt-engine-reports-3.3.2-1.fc19.noarch using yum Now I have reports listed when right clicking on Vms but on any report i see this error: Forbidden You don't have permission to access /ovirt-engine-reports/flow.html on this server. This seems to be related to apache redirection but how to fix it? I have three files in conf.d ovirt-engine-root-redirect.conf z-ovirt-engine-proxy.conf z-ovirt-engine-reports-proxy.conf but can't figure how to fix them I applied no changes to these files Any hint? Thank you

3 19

[Users] CPU and Memory sharing
by Jaison peter 04 Feb '14

04 Feb '14

Hi all , I would like to know whether CPU or memory sharing among physical nodes are possible in ovirt . Suppose I have 3 physical nodes in my cluster with 24GB RAM and 8 cores each . Then one of my client needs a VM with 32GB RAM and 12 cores , that means vm need resources more than a physical server . So is that possible in ovirt cluster .? If it is not directly possible is they are any cloning & Load balancing methods like in amzon auto scaling ?

2 1

[Users] [QE] oVirt 3.4.0 beta status
by Sandro Bonazzola 04 Feb '14

04 Feb '14

Hi, oVirt 3.4.0 beta has been released and is actually on QA. We're going to tart composing oVirt 3.4.0 beta2 this Thursday 2014-02-06 09:00 UTC from 3.4 branches. This build will be used for a second Test Day scheduled for 2014-02-11. The bug tracker [1] shows the following bugs blocking the release: Whiteboard Bug ID Status Summary gluster 1038988 POST Gluster brick sync does not work when host has multiple interfaces gluster 1059606 POST Errors in rebalance and remove-brick status and sync integration 1054080 POST gracefully warn about unsupported upgrade from legacy releases integration 1058018 POST upgrade from 3.3 overwrites exports with acl None There are still 393 bugs [2] targeted to 3.4.0. Excluding node and documentation bugs we still have 238 bugs [3] targeted to 3.4.0. Please review them as soon as possible. Maintainers: - Please remember to rebuild your packages before 2014-02-06 09:00 UTC if you want them to be included in 3.4.0 beta. - Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed. - Please provide ETA on blockers bugs - 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-11 For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug. Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-02-11! Thanks to all people already testing 3.4.0 beta! [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

2 2

[Users] Migration failed (previous migrations succeded)
by Markus Stockhausen 04 Feb '14

04 Feb '14

This is a multi-part message in MIME format. ------=_NextPartTM-000-16e476a9-dc0a-459b-91a5-33c52e66e68f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=0A= =0A= we did some migration tests this day and all of a sudden the migration=0A= failed. That particular VM was moved around several times that day without= =0A= any problems. During the migration the VM was running a download.=0A= =0A= The logs are attached. If you need more, do not hesitate to ask.=0A= =0A= Thanks in advance.=0A= =0A= Markus=0A= =0A= **************************=0A= web log:=0A= =0A= 2014-Jan-30, 16:17 Migration failed due to Error: Migration not in progress= (VM: Win7x64_Master, Source: colovn02, Destination: colovn04).=0A= 2014-Jan-30, 16:11 Migration started (VM: Win7x64_Master, Source: colovn02,= Destination: colovn04, User: hil1).=0A= 2014-Jan-30, 16:10 Migration completed (VM: Win7x64_Master, Source: colovn0= 4, Destination: colovn02, Duration: 52 sec).=0A= 2014-Jan-30, 16:05 Migration started (VM: Win7x64_Master, Source: colovn04,= Destination: colovn02, User: hil1).=0A= 2014-Jan-30, 16:04 Migration completed (VM: Win7x64_Master, Source: colovn0= 3, Destination: colovn04, Duration: 24 sec).=0A= 2014-Jan-30, 16:01 Migration started (VM: Win7x64_Master, Source: colovn03,= Destination: colovn04, User: hil1).=0A= =0A= **************************=0A= Engine=0A= =0A= 2014-01-30 16:17:31,871 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-97) RefreshVmList vm id ce64f528-9= 981-4ec6-a172-9d70a00a34cd status =3D Paused on vds colovn04 ignoring it in= the refresh until migration is done=0A= 2014-01-30 16:17:34,955 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-96) RefreshVmList vm id ce64f528-9= 981-4ec6-a172-9d70a00a34cd status =3D Paused on vds colovn04 ignoring it in= the refresh until migration is done=0A= 2014-01-30 16:17:38,067 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-2) RefreshVmList vm id ce64f528-99= 81-4ec6-a172-9d70a00a34cd status =3D Paused on vds colovn04 ignoring it in = the refresh until migration is done=0A= 2014-01-30 16:17:41,147 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-100) RefreshVmList vm id ce64f528-= 9981-4ec6-a172-9d70a00a34cd status =3D Paused on vds colovn04 ignoring it i= n the refresh until migration is done=0A= 2014-01-30 16:17:44,268 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-88) RefreshVmList vm id ce64f528-9= 981-4ec6-a172-9d70a00a34cd status =3D Paused on vds colovn04 ignoring it in= the refresh until migration is done=0A= 2014-01-30 16:17:46,440 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-13) VM Win7x64_Master ce64f528-998= 1-4ec6-a172-9d70a00a34cd moved from MigratingFrom --> Up=0A= 2014-01-30 16:17:46,444 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-13) Adding VM ce64f528-9981-4ec6-a= 172-9d70a00a34cd to re-run list=0A= 2014-01-30 16:17:46,456 ERROR [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-13) Rerun vm ce64f528-9981-4ec6-a1= 72-9d70a00a34cd. Called from vds colovn02=0A= 2014-01-30 16:17:46,475 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) START, MigrateStatusVDSCommand(Ho= stName =3D colovn02, HostId =3D 1303e86e-cd91-406b-8a27-e75ef0a9defb, vmId= =3Dce64f528-9981-4ec6-a172-9d70a00a34cd), log id: 91bccfb=0A= 2014-01-30 16:17:46,485 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) Failed in MigrateStatusVDS method= =0A= 2014-01-30 16:17:46,488 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) Error code MIGRATION_CANCEL_ERROR= and error message VDSGenericException: VDSErrorException: Failed to Migrat= eStatusVDS, error =3D Migration canceled=0A= 2014-01-30 16:17:46,492 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) Command org.ovirt.engine.core.vds= broker.vdsbroker.MigrateStatusVDSCommand return value=0A= StatusOnlyReturnForXmlRpc [mStatus=3DStatusForXmlRpc [mCode=3D47, mMessage= =3DMigration canceled]]=0A= 2014-01-30 16:17:46,495 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) HostName =3D colovn02=0A= 2014-01-30 16:17:46,508 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) Command MigrateStatusVDS executio= n failed. Exception: VDSErrorException: VDSGenericException: VDSErrorExcept= ion: Failed to MigrateStatusVDS, error =3D Migration canceled=0A= 2014-01-30 16:17:46,511 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Mi= grateStatusVDSCommand] (pool-6-thread-48) FINISH, MigrateStatusVDSCommand, = log id: 91bccfb=0A= 2014-01-30 16:17:46,522 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (pool-6-thread-48) Correlation ID: 71aa9786, Job = ID: 4f805590-135a-49a6-871a-91389ae99d9a, Call Stack: null, Custom Event ID= : -1, Message: Migration failed due to Error: Migration not in progress (VM= : Win7x64_Master, Source: colovn02, Destination: colovn04).=0A= 2014-01-30 16:18:27,016 INFO [org.ovirt.engine.core.bll.MigrateVmToServerC= ommand] (ajp--127.0.0.1-8702-2) [5fed7321] Failed to Acquire Lock to object= EngineLock [exclusiveLocks=3D key: ce64f528-9981-4ec6-a172-9d70a00a34cd va= lue: VM=0A= , sharedLocks=3D ]=0A= 2014-01-30 16:18:27,020 WARN [org.ovirt.engine.core.bll.MigrateVmToServerC= ommand] (ajp--127.0.0.1-8702-2) [5fed7321] CanDoAction of action MigrateVmT= oServer failed. Reasons:VAR__ACTION__MIGRATE,VAR__TYPE__VM,ACTION_TYPE_FAIL= ED_VM_IS_BEING_MIGRATED,$VmName Win7x64_Master=0A= 2014-01-30 16:18:56,318 INFO [org.ovirt.engine.core.bll.MigrateVmToServerC= ommand] (ajp--127.0.0.1-8702-12) [4b6f62e9] Failed to Acquire Lock to objec= t EngineLock [exclusiveLocks=3D key: ce64f528-9981-4ec6-a172-9d70a00a34cd v= alue: VM=0A= =0A= **************************=0A= vdsm_source:=0A= =0A= Thread-290096::DEBUG::2014-01-30 16:17:04,874::task::1168::TaskManager.Task= ::(prepare) Task=3D`d313ee92-9094-49ad-8850-fbb6df383a22`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.000176962', 'lastCheck': '1= .8', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4= a9e58545': {'delay': '0.000154703', 'lastCheck': '8.0', 'code': 0, 'valid':= True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.= 000147093', 'lastCheck': '7.5', 'code': 0, 'valid': True, 'version': 0}, '6= 3041fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000179083', 'lastCheck':= '7.1', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-7= 32789dd18d4': {'delay': '0.000224103', 'lastCheck': '6.3', 'code': 0, 'vali= d': True, 'version': 3}}=0A= Thread-290096::DEBUG::2014-01-30 16:17:04,874::task::579::TaskManager.Task:= :(_updateState) Task=3D`d313ee92-9094-49ad-8850-fbb6df383a22`::moving from = state preparing -> state finished=0A= Thread-290096::DEBUG::2014-01-30 16:17:04,874::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-290096::DEBUG::2014-01-30 16:17:04,874::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-290096::DEBUG::2014-01-30 16:17:04,874::task::974::TaskManager.Task:= :(_decref) Task=3D`d313ee92-9094-49ad-8850-fbb6df383a22`::ref 0 aborting Fa= lse=0A= Thread-289929::WARNING::2014-01-30 16:17:05,585::vm::800::vm.Vm::(run) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration stalling: dataRemainin= g (24MiB) > smallest_dataRemaining (9MiB). Refer to RHBZ#919201.=0A= Thread-289929::INFO::2014-01-30 16:17:05,585::vm::812::vm.Vm::(run) vmId=3D= `ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration Progress: 360 seconds ela= psed, 99% of data processed, 99% of mem processed=0A= Thread-26::DEBUG::2014-01-30 16:17:06,907::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-26::DEBUG::2014-01-30 16:17:06,913::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000192548 s, 2.9 MB/s\n'; <rc> =3D 0=0A= Thread-27::DEBUG::2014-01-30 16:17:07,394::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-27::DEBUG::2014-01-30 16:17:07,400::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000213713 s, 1.7 MB/s\n'; <rc> =3D 0=0A= Thread-33::DEBUG::2014-01-30 16:17:07,771::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-33::DEBUG::2014-01-30 16:17:07,778::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000190935 s, 1.9 MB/s\n'; <rc> =3D 0=0A= Thread-38::DEBUG::2014-01-30 16:17:08,586::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-38::DEBUG::2014-01-30 16:17:08,593::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000184154 s, 3.0 MB/s\n'; <rc> =3D 0=0A= Thread-25::DEBUG::2014-01-30 16:17:13,044::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-25::DEBUG::2014-01-30 16:17:13,050::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.00017907 s, 3.6 MB/s\n'; <rc> =3D 0=0A= Thread-289929::WARNING::2014-01-30 16:17:15,586::vm::800::vm.Vm::(run) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration stalling: dataRemainin= g (16MiB) > smallest_dataRemaining (9MiB). Refer to RHBZ#919201.=0A= Thread-289929::INFO::2014-01-30 16:17:15,587::vm::812::vm.Vm::(run) vmId=3D= `ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration Progress: 370 seconds ela= psed, 99% of data processed, 99% of mem processed=0A= Thread-26::DEBUG::2014-01-30 16:17:16,923::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-26::DEBUG::2014-01-30 16:17:16,929::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000248981 s, 2.2 MB/s\n'; <rc> =3D 0=0A= Thread-27::DEBUG::2014-01-30 16:17:17,412::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-27::DEBUG::2014-01-30 16:17:17,418::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000252188 s, 1.4 MB/s\n'; <rc> =3D 0=0A= Thread-33::DEBUG::2014-01-30 16:17:17,789::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-33::DEBUG::2014-01-30 16:17:17,796::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000203099 s, 1.8 MB/s\n'; <rc> =3D 0=0A= Thread-38::DEBUG::2014-01-30 16:17:18,604::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-38::DEBUG::2014-01-30 16:17:18,611::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000177334 s, 3.1 MB/s\n'; <rc> =3D 0=0A= Thread-290102::DEBUG::2014-01-30 16:17:20,057::task::579::TaskManager.Task:= :(_updateState) Task=3D`0d381417-48c8-4035-99e5-01f34f55f98c`::moving from = state init -> state preparing=0A= Thread-290102::INFO::2014-01-30 16:17:20,057::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-290102::INFO::2014-01-30 16:17:20,058::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.00017907', 'lastCheck': '7.0', 'code': 0, 'v= alid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'delay= ': '0.000248981', 'lastCheck': '3.1', 'code': 0, 'valid': True, 'version': = 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.000252188', 'lastC= heck': '2.6', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b44-= b36f-f39f16d3974f': {'delay': '0.000203099', 'lastCheck': '2.3', 'code': 0,= 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'de= lay': '0.000177334', 'lastCheck': '1.4', 'code': 0, 'valid': True, 'version= ': 3}}=0A= Thread-290102::DEBUG::2014-01-30 16:17:20,058::task::1168::TaskManager.Task= ::(prepare) Task=3D`0d381417-48c8-4035-99e5-01f34f55f98c`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.00017907', 'lastCheck': '7.= 0', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a= 9e58545': {'delay': '0.000248981', 'lastCheck': '3.1', 'code': 0, 'valid': = True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.0= 00252188', 'lastCheck': '2.6', 'code': 0, 'valid': True, 'version': 0}, '63= 041fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000203099', 'lastCheck': = '2.3', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-73= 2789dd18d4': {'delay': '0.000177334', 'lastCheck': '1.4', 'code': 0, 'valid= ': True, 'version': 3}}=0A= Thread-290102::DEBUG::2014-01-30 16:17:20,058::task::579::TaskManager.Task:= :(_updateState) Task=3D`0d381417-48c8-4035-99e5-01f34f55f98c`::moving from = state preparing -> state finished=0A= Thread-290102::DEBUG::2014-01-30 16:17:20,058::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-290102::DEBUG::2014-01-30 16:17:20,058::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-290102::DEBUG::2014-01-30 16:17:20,059::task::974::TaskManager.Task:= :(_decref) Task=3D`0d381417-48c8-4035-99e5-01f34f55f98c`::ref 0 aborting Fa= lse=0A= Thread-289906::DEBUG::2014-01-30 16:17:22,908::task::579::TaskManager.Task:= :(_updateState) Task=3D`308ddd49-b5c0-43a5-93fc-ccfd6220eb28`::moving from = state init -> state preparing=0A= Thread-289906::INFO::2014-01-30 16:17:22,909::logUtils::44::dispatcher::(wr= apper) Run and protect: getVolumeSize(sdUUID=3D'965ca3b6-4f9c-4e81-b6e8-5ed= 4a9e58545', spUUID=3D'94ed7a19-fade-4bd6-83f2-2cbb2f730b95', imgUUID=3D'1b2= 3ac73-0748-49cd-94b6-11555e35be81', volUUID=3D'5156a43b-c9dc-40fa-a9b7-a35b= 7f22f0eb', options=3DNone)=0A= Thread-289906::INFO::2014-01-30 16:17:22,911::logUtils::47::dispatcher::(wr= apper) Run and protect: getVolumeSize, Return response: {'truesize': '17700= 114432', 'apparentsize': '21474836480'}=0A= Thread-289906::DEBUG::2014-01-30 16:17:22,911::task::1168::TaskManager.Task= ::(prepare) Task=3D`308ddd49-b5c0-43a5-93fc-ccfd6220eb28`::finished: {'true= size': '17700114432', 'apparentsize': '21474836480'}=0A= Thread-289906::DEBUG::2014-01-30 16:17:22,911::task::579::TaskManager.Task:= :(_updateState) Task=3D`308ddd49-b5c0-43a5-93fc-ccfd6220eb28`::moving from = state preparing -> state finished=0A= Thread-289906::DEBUG::2014-01-30 16:17:22,911::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-289906::DEBUG::2014-01-30 16:17:22,912::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-289906::DEBUG::2014-01-30 16:17:22,912::task::974::TaskManager.Task:= :(_decref) Task=3D`308ddd49-b5c0-43a5-93fc-ccfd6220eb28`::ref 0 aborting Fa= lse=0A= Thread-25::DEBUG::2014-01-30 16:17:23,063::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-25::DEBUG::2014-01-30 16:17:23,069::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000189592 s, 3.4 MB/s\n'; <rc> =3D 0=0A= VM Channels Listener::DEBUG::2014-01-30 16:17:23,109::vmChannels::91::vds::= (_handle_timeouts) Timeout on fileno 105.=0A= Thread-289929::WARNING::2014-01-30 16:17:25,588::vm::800::vm.Vm::(run) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration stalling: dataRemainin= g (15MiB) > smallest_dataRemaining (9MiB). Refer to RHBZ#919201.=0A= Thread-289929::INFO::2014-01-30 16:17:25,588::vm::812::vm.Vm::(run) vmId=3D= `ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration Progress: 380 seconds ela= psed, 99% of data processed, 99% of mem processed=0A= Thread-26::DEBUG::2014-01-30 16:17:26,940::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-26::DEBUG::2014-01-30 16:17:26,947::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.00019559 s, 2.8 MB/s\n'; <rc> =3D 0=0A= Thread-27::DEBUG::2014-01-30 16:17:27,430::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-27::DEBUG::2014-01-30 16:17:27,439::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.00317489 s, 112 kB/s\n'; <rc> =3D 0=0A= Thread-33::DEBUG::2014-01-30 16:17:27,808::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-33::DEBUG::2014-01-30 16:17:27,815::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000189549 s, 1.9 MB/s\n'; <rc> =3D 0=0A= Thread-38::DEBUG::2014-01-30 16:17:28,621::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-38::DEBUG::2014-01-30 16:17:28,632::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.00469703 s, 119 kB/s\n'; <rc> =3D 0=0A= Thread-25::DEBUG::2014-01-30 16:17:33,081::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-25::DEBUG::2014-01-30 16:17:33,087::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000191272 s, 3.4 MB/s\n'; <rc> =3D 0=0A= Thread-290108::DEBUG::2014-01-30 16:17:35,257::task::579::TaskManager.Task:= :(_updateState) Task=3D`c598fcf4-774b-4420-af70-090d43cd58b5`::moving from = state init -> state preparing=0A= Thread-290108::INFO::2014-01-30 16:17:35,257::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-290108::INFO::2014-01-30 16:17:35,257::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.000191272', 'lastCheck': '2.2', 'code': 0, '= valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'dela= y': '0.00019559', 'lastCheck': '8.3', 'code': 0, 'valid': True, 'version': = 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.00317489', 'lastCh= eck': '7.8', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b44-b= 36f-f39f16d3974f': {'delay': '0.000189549', 'lastCheck': '7.4', 'code': 0, = 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'del= ay': '0.00469703', 'lastCheck': '6.6', 'code': 0, 'valid': True, 'version':= 3}}=0A= Thread-290108::DEBUG::2014-01-30 16:17:35,258::task::1168::TaskManager.Task= ::(prepare) Task=3D`c598fcf4-774b-4420-af70-090d43cd58b5`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.000191272', 'lastCheck': '2= .2', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4= a9e58545': {'delay': '0.00019559', 'lastCheck': '8.3', 'code': 0, 'valid': = True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.0= 0317489', 'lastCheck': '7.8', 'code': 0, 'valid': True, 'version': 0}, '630= 41fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000189549', 'lastCheck': '= 7.4', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732= 789dd18d4': {'delay': '0.00469703', 'lastCheck': '6.6', 'code': 0, 'valid':= True, 'version': 3}}=0A= Thread-290108::DEBUG::2014-01-30 16:17:35,258::task::579::TaskManager.Task:= :(_updateState) Task=3D`c598fcf4-774b-4420-af70-090d43cd58b5`::moving from = state preparing -> state finished=0A= Thread-290108::DEBUG::2014-01-30 16:17:35,258::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-290108::DEBUG::2014-01-30 16:17:35,258::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-290108::DEBUG::2014-01-30 16:17:35,258::task::974::TaskManager.Task:= :(_decref) Task=3D`c598fcf4-774b-4420-af70-090d43cd58b5`::ref 0 aborting Fa= lse=0A= Thread-289929::WARNING::2014-01-30 16:17:35,590::vm::800::vm.Vm::(run) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration stalling: dataRemainin= g (33MiB) > smallest_dataRemaining (9MiB). Refer to RHBZ#919201.=0A= Thread-289929::INFO::2014-01-30 16:17:35,590::vm::812::vm.Vm::(run) vmId=3D= `ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration Progress: 390 seconds ela= psed, 99% of data processed, 99% of mem processed=0A= Thread-26::DEBUG::2014-01-30 16:17:36,959::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-26::DEBUG::2014-01-30 16:17:36,966::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000212972 s, 2.6 MB/s\n'; <rc> =3D 0=0A= Thread-27::DEBUG::2014-01-30 16:17:37,450::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-27::DEBUG::2014-01-30 16:17:37,457::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000199826 s, 1.8 MB/s\n'; <rc> =3D 0=0A= Thread-33::DEBUG::2014-01-30 16:17:37,826::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-33::DEBUG::2014-01-30 16:17:37,833::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000200537 s, 1.8 MB/s\n'; <rc> =3D 0=0A= Thread-38::DEBUG::2014-01-30 16:17:38,644::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-38::DEBUG::2014-01-30 16:17:38,650::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000206259 s, 2.7 MB/s\n'; <rc> =3D 0=0A= Thread-25::DEBUG::2014-01-30 16:17:43,099::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-25::DEBUG::2014-01-30 16:17:43,105::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000187228 s, 3.4 MB/s\n'; <rc> =3D 0=0A= Thread-289929::WARNING::2014-01-30 16:17:45,592::vm::789::vm.Vm::(run) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Migration is stuck: Hasn't progr= essed in 300.055635929 seconds. Aborting.=0A= Thread-289929::DEBUG::2014-01-30 16:17:45,594::vm::815::vm.Vm::(stop) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::stopping migration monitor threa= d=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:45,918::vm::4840::vm.Vm::(_onLibv= irtLifecycleEvent) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::event Res= umed detail 1 opaque None=0A= Thread-289927::DEBUG::2014-01-30 16:17:45,920::libvirtconnection::108::libv= irtconnection::(wrapper) Unknown libvirterror: ecode: 78 edom: 10 level: 2 = message: Operation abgebrochen: Migrations-Job: abgebrochen durch Client=0A= Thread-289927::DEBUG::2014-01-30 16:17:45,920::vm::745::vm.Vm::(cancel) vmI= d=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::canceling migration downtime th= read=0A= Thread-289927::DEBUG::2014-01-30 16:17:45,920::vm::815::vm.Vm::(stop) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::stopping migration monitor threa= d=0A= Thread-289927::ERROR::2014-01-30 16:17:45,920::vm::238::vm.Vm::(_recover) v= mId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Operation abgebrochen: Migrat= ions-Job: abgebrochen durch Client=0A= Thread-289927::ERROR::2014-01-30 16:17:45,949::vm::337::vm.Vm::(run) vmId= =3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Failed to migrate=0A= Traceback (most recent call last):=0A= File "/usr/share/vdsm/vm.py", line 323, in run=0A= self._startUnderlyingMigration()=0A= File "/usr/share/vdsm/vm.py", line 400, in _startUnderlyingMigration=0A= None, maxBandwidth)=0A= File "/usr/share/vdsm/vm.py", line 838, in f=0A= ret =3D attr(*args, **kwargs)=0A= File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line= 76, in wrapper=0A= ret =3D f(*args, **kwargs)=0A= File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1274, in migra= teToURI2=0A= if ret =3D=3D -1: raise libvirtError ('virDomainMigrateToURI2() failed'= , dom=3Dself)=0A= libvirtError: Operation abgebrochen: Migrations-Job: abgebrochen durch Clie= nt=0A= Thread-26::DEBUG::2014-01-30 16:17:46,976::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-26::DEBUG::2014-01-30 16:17:46,982::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000163843 s, 3.4 MB/s\n'; <rc> =3D 0=0A= Thread-290114::DEBUG::2014-01-30 16:17:47,444::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-290114::DEBUG::2014-01-30 16:17:47,445::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Up', 'username': 'Unknown', 'memUsage': '0', 'acpiE= nable': 'true', 'guestFQDN': '', 'pid': '14467', 'displayIp': '192.168.11.4= 2', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'5900'= , 'timeOffset': '0', 'hash': '3172497814970917300', 'balloonInfo': {'balloo= n_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152', '= balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network': {= u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '605', 'rxErrors': = '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '1.4', 'txErrors': '0', '= state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f528-9= 981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '35.99', 'dis= ks': {u'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0'= , 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0= .00'}, u'sda': {'readLatency': '0', 'apparentsize': '21474836480', 'writeLa= tency': '2110228', 'imageID': '1b23ac73-0748-49cd-94b6-11555e35be81', 'flus= hLatency': '0', 'readRate': '0.00', 'truesize': '17700114432', 'writeRate':= '1640924.26'}}, 'monitorResponse': '0', 'statsAge': '0.49', 'elapsedTime':= '1235', 'vmType': 'kvm', 'cpuSys': '35.99', 'appsList': [], 'guestIPs': ''= }]}=0A= Thread-27::DEBUG::2014-01-30 16:17:47,468::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-27::DEBUG::2014-01-30 16:17:47,474::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000176178 s, 2.0 MB/s\n'; <rc> =3D 0=0A= Thread-290115::DEBUG::2014-01-30 16:17:47,493::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetMigrationStatus with ('ce64f528-998= 1-4ec6-a172-9d70a00a34cd',) {}=0A= Thread-290115::DEBUG::2014-01-30 16:17:47,493::BindingXMLRPC::981::vds::(wr= apper) return vmGetMigrationStatus with {'status': {'message': 'Migration c= anceled', 'code': 47}, 'progress': 99}=0A= Thread-33::DEBUG::2014-01-30 16:17:47,845::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-33::DEBUG::2014-01-30 16:17:47,851::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000191543 s, 1.9 MB/s\n'; <rc> =3D 0=0A= Thread-38::DEBUG::2014-01-30 16:17:48,662::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-38::DEBUG::2014-01-30 16:17:48,668::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000225105 s, 2.5 MB/s\n'; <rc> =3D 0=0A= Thread-290116::DEBUG::2014-01-30 16:17:50,490::task::579::TaskManager.Task:= :(_updateState) Task=3D`cd241aee-e845-4143-bfe3-01383c65e90e`::moving from = state init -> state preparing=0A= Thread-290116::INFO::2014-01-30 16:17:50,490::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= =0A= **************************=0A= vdsm_target:=0A= =0A= Thread-285228::DEBUG::2014-01-30 16:17:07,460::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285228::DEBUG::2014-01-30 16:17:07,460::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285228::DEBUG::2014-01-30 16:17:07,461::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '867', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.38', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '0.44', 'elap= sedTime': '1212', 'vmType': 'kvm', 'cpuSys': '2.07', 'appsList': [], 'guest= IPs': ''}]}=0A= Thread-40::DEBUG::2014-01-30 16:17:07,811::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:17:07,818::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000160605 s, 4.0 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:17:08,363::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:17:08,369::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000144136 s, 2.5 MB/s\n'; <rc> =3D 0=0A= Thread-47::DEBUG::2014-01-30 16:17:10,080::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:17:10,086::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000213518 s, 1.7 MB/s\n'; <rc> =3D 0=0A= Thread-285230::DEBUG::2014-01-30 16:17:10,569::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285230::DEBUG::2014-01-30 16:17:10,569::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285230::DEBUG::2014-01-30 16:17:10,569::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285230::DEBUG::2014-01-30 16:17:10,569::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285230::DEBUG::2014-01-30 16:17:10,570::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285230::DEBUG::2014-01-30 16:17:10,571::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '887', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.38', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '1.55', 'elap= sedTime': '1215', 'vmType': 'kvm', 'cpuSys': '2.07', 'appsList': [], 'guest= IPs': ''}]}=0A= Thread-41::DEBUG::2014-01-30 16:17:11,570::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:17:11,577::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000211434 s, 2.6 MB/s\n'; <rc> =3D 0=0A= Thread-285232::DEBUG::2014-01-30 16:17:13,656::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285232::DEBUG::2014-01-30 16:17:13,656::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285232::DEBUG::2014-01-30 16:17:13,657::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285232::DEBUG::2014-01-30 16:17:13,657::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285232::DEBUG::2014-01-30 16:17:13,657::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285232::DEBUG::2014-01-30 16:17:13,658::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '887', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.38', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '0.63', 'elap= sedTime': '1218', 'vmType': 'kvm', 'cpuSys': '2.07', 'appsList': [], 'guest= IPs': ''}]}=0A= Thread-52::DEBUG::2014-01-30 16:17:14,494::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:17:14,501::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000228157 s, 2.4 MB/s\n'; <rc> =3D 0=0A= Thread-285233::DEBUG::2014-01-30 16:17:16,719::task::579::TaskManager.Task:= :(_updateState) Task=3D`3b433b6a-d9ed-4edc-adcc-b9994ba7877a`::moving from = state init -> state preparing=0A= Thread-285233::INFO::2014-01-30 16:17:16,720::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-285233::INFO::2014-01-30 16:17:16,720::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.000160605', 'lastCheck': '8.9', 'code': 0, '= valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'dela= y': '0.000211434', 'lastCheck': '5.1', 'code': 0, 'valid': True, 'version':= 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.000144136', 'last= Check': '8.3', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b44= -b36f-f39f16d3974f': {'delay': '0.000213518', 'lastCheck': '6.6', 'code': 0= , 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'d= elay': '0.000228157', 'lastCheck': '2.2', 'code': 0, 'valid': True, 'versio= n': 3}}=0A= Thread-285233::DEBUG::2014-01-30 16:17:16,720::task::1168::TaskManager.Task= ::(prepare) Task=3D`3b433b6a-d9ed-4edc-adcc-b9994ba7877a`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.000160605', 'lastCheck': '8= .9', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4= a9e58545': {'delay': '0.000211434', 'lastCheck': '5.1', 'code': 0, 'valid':= True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.= 000144136', 'lastCheck': '8.3', 'code': 0, 'valid': True, 'version': 0}, '6= 3041fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000213518', 'lastCheck':= '6.6', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-7= 32789dd18d4': {'delay': '0.000228157', 'lastCheck': '2.2', 'code': 0, 'vali= d': True, 'version': 3}}=0A= Thread-285233::DEBUG::2014-01-30 16:17:16,720::task::579::TaskManager.Task:= :(_updateState) Task=3D`3b433b6a-d9ed-4edc-adcc-b9994ba7877a`::moving from = state preparing -> state finished=0A= Thread-285233::DEBUG::2014-01-30 16:17:16,720::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-285233::DEBUG::2014-01-30 16:17:16,721::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-285233::DEBUG::2014-01-30 16:17:16,721::task::974::TaskManager.Task:= :(_decref) Task=3D`3b433b6a-d9ed-4edc-adcc-b9994ba7877a`::ref 0 aborting Fa= lse=0A= Thread-285234::DEBUG::2014-01-30 16:17:16,733::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285234::DEBUG::2014-01-30 16:17:16,733::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285234::DEBUG::2014-01-30 16:17:16,733::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285234::DEBUG::2014-01-30 16:17:16,733::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-40::DEBUG::2014-01-30 16:17:17,821::domainMonitor::182::Storage.Doma= inMonitorThread::(_monitorDomain) Refreshing domain 2c51d320-88ce-4f23-8215= -e15f55f66906=0A= Thread-40::DEBUG::2014-01-30 16:17:17,834::fileSD::154::Storage.StorageDoma= in::(__init__) Reading domain in path /rhev/data-center/mnt/10.10.30.253:_v= ar_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906=0A= Thread-40::DEBUG::2014-01-30 16:17:17,835::persistentDict::192::Storage.Per= sistentDict::(__init__) Created a persistent dict with FileMetadataRW backe= nd=0A= Thread-40::DEBUG::2014-01-30 16:17:17,842::persistentDict::234::Storage.Per= sistentDict::(refresh) read lines (FileMetadataRW)=3D['CLASS=3DData', 'DESC= RIPTION=3Dcolnas03_IB', 'IOOPTIMEOUTSEC=3D10', 'LEASERETRIES=3D3', 'LEASETI= MESEC=3D60', 'LOCKPOLICY=3D', 'LOCKRENEWALINTERVALSEC=3D5', 'MASTER_VERSION= =3D3', 'POOL_DESCRIPTION=3DCollogia', 'POOL_DOMAINS=3D272ec473-6041-42ee-bd= 1a-732789dd18d4:Active,965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545:Active,2c51d320= -88ce-4f23-8215-e15f55f66906:Active,63041fa9-e093-4b44-b36f-f39f16d3974f:Ac= tive,bff3a2be-fdd9-4e37-b416-fa4ef7fafba2:Active', 'POOL_SPM_ID=3D2', 'POOL= _SPM_LVER=3D33', 'POOL_UUID=3D94ed7a19-fade-4bd6-83f2-2cbb2f730b95', 'REMOT= E_PATH=3D10.10.30.253:/var/nas3/OVirtIB', 'ROLE=3DMaster', 'SDUUID=3D2c51d3= 20-88ce-4f23-8215-e15f55f66906', 'TYPE=3DNFS', 'VERSION=3D3', '_SHA_CKSUM= =3D75ca15b219476f472d87a8c375650d35eabb8d16']=0A= Thread-40::DEBUG::2014-01-30 16:17:17,843::fileSD::572::Storage.StorageDoma= in::(imageGarbageCollector) Removing remnants of deleted images []=0A= Thread-40::INFO::2014-01-30 16:17:17,844::sd::374::Storage.StorageDomain::(= _registerResourceNamespaces) Resource namespace 2c51d320-88ce-4f23-8215-e15= f55f66906_imageNS already registered=0A= Thread-40::INFO::2014-01-30 16:17:17,844::sd::382::Storage.StorageDomain::(= _registerResourceNamespaces) Resource namespace 2c51d320-88ce-4f23-8215-e15= f55f66906_volumeNS already registered=0A= Thread-40::DEBUG::2014-01-30 16:17:17,854::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:17:17,860::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000216469 s, 3.0 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:17:18,381::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:17:18,387::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000243463 s, 1.5 MB/s\n'; <rc> =3D 0=0A= Thread-285241::DEBUG::2014-01-30 16:17:19,814::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285241::DEBUG::2014-01-30 16:17:19,815::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285241::DEBUG::2014-01-30 16:17:19,815::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285241::DEBUG::2014-01-30 16:17:19,815::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285241::DEBUG::2014-01-30 16:17:19,815::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285241::DEBUG::2014-01-30 16:17:19,816::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '909', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.44', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '0.78', 'elap= sedTime': '1224', 'vmType': 'kvm', 'cpuSys': '1.93', 'appsList': [], 'guest= IPs': ''}]}=0A= VM Channels Listener::DEBUG::2014-01-30 16:17:20,026::vmChannels::91::vds::= (_handle_timeouts) Timeout on fileno 98.=0A= Thread-47::DEBUG::2014-01-30 16:17:20,096::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:17:20,103::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.00022031 s, 1.6 MB/s\n'; <rc> =3D 0=0A= Thread-41::DEBUG::2014-01-30 16:17:21,589::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:17:21,596::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.0002126 s, 2.6 MB/s\n'; <rc> =3D 0=0A= Thread-285243::DEBUG::2014-01-30 16:17:22,928::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285243::DEBUG::2014-01-30 16:17:22,928::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285243::DEBUG::2014-01-30 16:17:22,928::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285243::DEBUG::2014-01-30 16:17:22,928::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285243::DEBUG::2014-01-30 16:17:22,929::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285243::DEBUG::2014-01-30 16:17:22,930::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '909', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.44', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '1.88', 'elap= sedTime': '1227', 'vmType': 'kvm', 'cpuSys': '1.93', 'appsList': [], 'guest= IPs': ''}]}=0A= Thread-52::DEBUG::2014-01-30 16:17:24,512::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:17:24,519::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000195213 s, 2.9 MB/s\n'; <rc> =3D 0=0A= Thread-285245::DEBUG::2014-01-30 16:17:26,006::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285245::DEBUG::2014-01-30 16:17:26,006::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285245::DEBUG::2014-01-30 16:17:26,006::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285245::DEBUG::2014-01-30 16:17:26,007::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285245::DEBUG::2014-01-30 16:17:26,007::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285245::DEBUG::2014-01-30 16:17:26,008::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '929', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.44', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '0.95', 'elap= sedTime': '1230', 'vmType': 'kvm', 'cpuSys': '1.93', 'appsList': [], 'guest= IPs': ''}]}=0A= Thread-40::DEBUG::2014-01-30 16:17:27,875::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:17:27,881::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000195778 s, 3.3 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:17:28,399::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:17:28,406::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.00021875 s, 1.6 MB/s\n'; <rc> =3D 0=0A= Thread-285247::DEBUG::2014-01-30 16:17:29,119::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.2]::call vmGetStats with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285247::DEBUG::2014-01-30 16:17:29,119::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc stats not avail= able=0A= Thread-285247::DEBUG::2014-01-30 16:17:29,119::vm::645::vm.Vm::(_getDiskSta= ts) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda stats not avail= able=0A= Thread-285247::DEBUG::2014-01-30 16:17:29,119::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk hdc latency not a= vailable=0A= Thread-285247::DEBUG::2014-01-30 16:17:29,120::vm::684::vm.Vm::(_getDiskLat= ency) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Disk sda latency not a= vailable=0A= Thread-285247::DEBUG::2014-01-30 16:17:29,121::BindingXMLRPC::981::vds::(wr= apper) return vmGetStats with {'status': {'message': 'Done', 'code': 0}, 's= tatsList': [{'status': 'Paused', 'username': 'Unknown', 'memUsage': '0', 'a= cpiEnable': 'true', 'guestFQDN': '', 'pid': '7671', 'displayIp': '192.168.1= 1.44', 'displayPort': '-1', 'session': 'Unknown', 'displaySecurePort': u'59= 00', 'timeOffset': '0', 'hash': '7219603903902024642', 'balloonInfo': {'bal= loon_max': '2097152', 'balloon_target': '2097152', 'balloon_cur': '2097152'= , 'balloon_min': '2097152'}, 'clientIp': '', 'kvmEnable': 'true', 'network'= : {u'vnet0': {'macAddr': '00:1a:4a:ee:d3:4a', 'rxDropped': '946', 'rxErrors= ': '0', 'txDropped': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0'= , 'state': 'unknown', 'speed': '1000', 'name': u'vnet0'}}, 'vmId': 'ce64f52= 8-9981-4ec6-a172-9d70a00a34cd', 'displayType': 'qxl', 'cpuUser': '0.44', 'd= isks': {u'hdc': {'truesize': '0', 'apparentsize': '0'}, u'sda': {'truesize'= : '17700114432', 'apparentsize': '21474836480', 'imageID': '1b23ac73-0748-4= 9cd-94b6-11555e35be81'}}, 'monitorResponse': '0', 'statsAge': '0.07', 'elap= sedTime': '1233', 'vmType': 'kvm', 'cpuSys': '1.93', 'appsList': [], 'guest= IPs': ''}]}=0A= VM Channels Listener::ERROR::2014-01-30 16:17:29,729::vmChannels::53::vds::= (_handle_event) Received 00000019 on fileno 98=0A= VM Channels Listener::DEBUG::2014-01-30 16:17:29,729::vmChannels::128::vds:= :(_handle_unconnected) Trying to connect fileno 98.=0A= VM Channels Listener::DEBUG::2014-01-30 16:17:29,730::guestIF::147::vm.Vm::= (_connect) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Attempting connec= tion to /var/lib/libvirt/qemu/channels/ce64f528-9981-4ec6-a172-9d70a00a34cd= .com.redhat.rhevm.vdsm=0A= VM Channels Listener::DEBUG::2014-01-30 16:17:29,730::guestIF::158::vm.Vm::= (_connect) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Failed to connect= to /var/lib/libvirt/qemu/channels/ce64f528-9981-4ec6-a172-9d70a00a34cd.com= .redhat.rhevm.vdsm with 111=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,770::vm::4840::vm.Vm::(_onLibv= irtLifecycleEvent) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::event Sto= pped detail 5 opaque None=0A= libvirtEventLoop::INFO::2014-01-30 16:17:29,770::vm::2166::vm.Vm::(_onQemuD= eath) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::underlying process dis= connected=0A= libvirtEventLoop::INFO::2014-01-30 16:17:29,770::vm::4320::vm.Vm::(releaseV= m) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Release VM resources=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,775::libvirtconnection::108::l= ibvirtconnection::(wrapper) Unknown libvirterror: ecode: 42 edom: 10 level:= 2 message: Domain nicht gefunden: Keine Domain mit ?bereinstimmender UUID = 'ce64f528-9981-4ec6-a172-9d70a00a34cd' (Win7x64_Master)=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,776::sampling::292::vm.Vm::(st= op) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Stop statistics collecti= on=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,776::vmChannels::205::vds::(un= register) Delete fileno 98 from listener.=0A= Thread-285161::DEBUG::2014-01-30 16:17:29,776::sampling::323::vm.Vm::(run) = vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Stats thread finished=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,777::libvirtconnection::108::l= ibvirtconnection::(wrapper) Unknown libvirterror: ecode: 42 edom: 10 level:= 2 message: Domain nicht gefunden: Keine Domain mit ?bereinstimmender UUID = 'ce64f528-9981-4ec6-a172-9d70a00a34cd' (Win7x64_Master)=0A= libvirtEventLoop::WARNING::2014-01-30 16:17:29,777::clientIF::362::vds::(te= ardownVolumePath) Drive is not a vdsm image: VOLWM_CHUNK_MB:1024 VOLWM_CHUN= K_REPLICATE_MULT:2 VOLWM_FREE_PCT:50 _blockDev:False _checkIoTuneCategories= :<bound method Drive._checkIoTuneCategories of <vm.Drive object at 0x7f3560= 03bb90>> _customize:<bound method Drive._customize of <vm.Drive object at 0= x7f356003bb90>> _deviceXML:<disk device=3D"cdrom" type=3D"file">=0A= <driver name=3D"qemu" type=3D"raw"/>=0A= <source startupPolicy=3D"optional"/>=0A= <target bus=3D"ide" dev=3D"hdc"/>=0A= <readonly/>=0A= <serial/>=0A= <alias name=3D"ide0-1-0"/>=0A= <address bus=3D"1" controller=3D"0" target=3D"0" type=3D"drive" unit= =3D"0"/>=0A= </disk> _makeName:<bound method Drive._makeName of <vm.Drive object at = 0x7f356003bb90>> _setExtSharedState:<bound method Drive._setExtSharedState = of <vm.Drive object at 0x7f356003bb90>> _validateIoTuneParams:<bound method= Drive._validateIoTuneParams of <vm.Drive object at 0x7f356003bb90>> addres= s:{u'bus': u'1', u'controller': u'0', u'type': u'drive', u'target': u'0', u= 'unit': u'0'} alias:ide0-1-0 apparentsize:0 blockDev:False cache:none conf:= {'acpiEnable': 'true', 'emulatedMachine': 'pc-1.0', 'afterMigrationStatus':= '', 'pid': '7671', 'memGuaranteedSize': 2048, 'transparentHugePages': 'tru= e', 'displaySecurePort': u'5900', 'timeOffset': '0', 'cpuType': 'Nehalem', = 'smp': '2', 'custom': {'device_aff6efaa-b33b-4385-a311-0c770cf56cf2device_3= 073f208-c700-4b39-99f1-56c33e884c78device_0c7f4f0b-98d4-4a1a-934e-6210ecabd= 3e9device_50fb5c9c-d9b3-4422-b216-3ff71ac6d774device_bb8234b4-44d4-4086-906= c-744b572ddbd9': 'VmDevice {vmId=3Dce64f528-9981-4ec6-a172-9d70a00a34cd, de= viceId=3Dbb8234b4-44d4-4086-906c-744b572ddbd9, device=3Dspicevmc, type=3DCH= ANNEL, bootOrder=3D0, specParams=3D{}, address=3D{port=3D3, bus=3D0, contro= ller=3D0, type=3Dvirtio-serial}, managed=3Dfalse, plugged=3Dtrue, readOnly= =3Dfalse, deviceAlias=3Dchannel2, customProperties=3D{}, snapshotId=3Dnull}= ', 'device_aff6efaa-b33b-4385-a311-0c770cf56cf2device_3073f208-c700-4b39-99= f1-56c33e884c78': 'VmDevice {vmId=3Dce64f528-9981-4ec6-a172-9d70a00a34cd, d= eviceId=3D3073f208-c700-4b39-99f1-56c33e884c78, device=3Dvirtio-serial, typ= e=3DCONTROLLER, bootOrder=3D0, specParams=3D{}, address=3D{bus=3D0x00, doma= in=3D0x0000, type=3Dpci, slot=3D0x06, function=3D0x0}, managed=3Dfalse, plu= gged=3Dtrue, readOnly=3Dfalse, deviceAlias=3Dvirtio-serial0, customProperti= es=3D{}, snapshotId=3Dnull}', 'device_aff6efaa-b33b-4385-a311-0c770cf56cf2d= evice_3073f208-c700-4b39-99f1-56c33e884c78device_0c7f4f0b-98d4-4a1a-934e-62= 10ecabd3e9device_50fb5c9c-d9b3-4422-b216-3ff71ac6d774': 'VmDevice {vmId=3Dc= e64f528-9981-4ec6-a172-9d70a00a34cd, deviceId=3D50fb5c9c-d9b3-4422-b216-3ff= 71ac6d774, device=3Dunix, type=3DCHANNEL, bootOrder=3D0, specParams=3D{}, a= ddress=3D{port=3D2, bus=3D0, controller=3D0, type=3Dvirtio-serial}, managed= =3Dfalse, plugged=3Dtrue, readOnly=3Dfalse, deviceAlias=3Dchannel1, customP= roperties=3D{}, snapshotId=3Dnull}', 'sap_agent': 'false', 'device_aff6efaa= -b33b-4385-a311-0c770cf56cf2': 'VmDevice {vmId=3Dce64f528-9981-4ec6-a172-9d= 70a00a34cd, deviceId=3Daff6efaa-b33b-4385-a311-0c770cf56cf2, device=3Dide, = type=3DCONTROLLER, bootOrder=3D0, specParams=3D{}, address=3D{bus=3D0x00, d= omain=3D0x0000, type=3Dpci, slot=3D0x01, function=3D0x1}, managed=3Dfalse, = plugged=3Dtrue, readOnly=3Dfalse, deviceAlias=3Dide0, customProperties=3D{}= , snapshotId=3Dnull}', 'device_aff6efaa-b33b-4385-a311-0c770cf56cf2device_3= 073f208-c700-4b39-99f1-56c33e884c78device_0c7f4f0b-98d4-4a1a-934e-6210ecabd= 3e9': 'VmDevice {vmId=3Dce64f528-9981-4ec6-a172-9d70a00a34cd, deviceId=3D0c= 7f4f0b-98d4-4a1a-934e-6210ecabd3e9, device=3Dunix, type=3DCHANNEL, bootOrde= r=3D0, specParams=3D{}, address=3D{port=3D1, bus=3D0, controller=3D0, type= =3Dvirtio-serial}, managed=3Dfalse, plugged=3Dtrue, readOnly=3Dfalse, devic= eAlias=3Dchannel0, customProperties=3D{}, snapshotId=3Dnull}'}, 'vmType': '= kvm', 'spiceSslCipherSuite': 'DEFAULT', 'memSize': 2048, 'vmName': 'Win7x64= _Master', 'nice': '0', 'clientIp': '', 'vmId': 'ce64f528-9981-4ec6-a172-9d7= 0a00a34cd', 'displayIp': '192.168.11.44', 'keyboardLayout': 'de', 'displayP= ort': '-1', 'smartcardEnable': 'false', 'spiceSecureChannels': 'smain,sinpu= ts,scursor,splayback,srecord,sdisplay,susbredir,ssmartcard', 'nicModel': 'r= tl8139,pv', 'smpCoresPerSocket': '2', 'kvmEnable': 'true', 'displayNetwork'= : 'ovirtmgmt', 'devices': [{'device': 'unix', 'alias': 'channel0', 'type': = 'channel', 'address': {'bus': '0', 'controller': '0', 'type': 'virtio-seria= l', 'port': '1'}}, {'device': 'unix', 'alias': 'channel1', 'type': 'channel= ', 'address': {'bus': '0', 'controller': '0', 'type': 'virtio-serial', 'por= t': '2'}}, {'device': 'spicevmc', 'alias': 'channel2', 'type': 'channel', '= address': {'bus': '0', 'controller': '0', 'type': 'virtio-serial', 'port': = '3'}}, {'specParams': {}, 'alias': u'scsi0', 'deviceId': '294da3e7-42c8-487= 2-918c-cafa13cec438', 'address': {u'slot': u'0x04', u'bus': u'0x00', u'doma= in': u'0x0000', u'type': u'pci', u'function': u'0x0'}, 'device': 'scsi', 'm= odel': 'virtio-scsi', 'type': 'controller'}, {'device': 'usb', 'alias': u'u= sb0', 'type': 'controller', 'address': {u'slot': u'0x01', u'bus': u'0x00', = u'domain': u'0x0000', u'type': u'pci', u'function': u'0x2'}}, {'device': 'i= de', 'alias': u'ide0', 'type': 'controller', 'address': {u'slot': u'0x01', = u'bus': u'0x00', u'domain': u'0x0000', u'type': u'pci', u'function': u'0x1'= }}, {'device': 'virtio-serial', 'alias': u'virtio-serial0', 'type': 'contro= ller', 'address': {u'slot': u'0x06', u'bus': u'0x00', u'domain': u'0x0000',= u'type': u'pci', u'function': u'0x0'}}, {'specParams': {'vram': '32768', '= heads': '1'}, 'alias': 'video0', 'deviceId': '14faa0f4-9b5f-4997-bcdb-889d4= 9672122', 'address': {'slot': '0x02', 'bus': '0x00', 'domain': '0x0000', 't= ype': 'pci', 'function': '0x0'}, 'device': 'qxl', 'type': 'video'}, {'nicMo= del': 'pv', 'macAddr': '00:1a:4a:ee:d3:4a', 'linkActive': True, 'network': = 'ovirtmgmt', 'specParams': {}, 'filter': 'vdsm-no-mac-spoofing', 'alias': u= 'net0', 'deviceId': '0109b881-8911-40ef-9e19-ad0d8daf5917', 'address': {u's= lot': u'0x03', u'bus': u'0x00', u'domain': u'0x0000', u'type': u'pci', u'fu= nction': u'0x0'}, 'device': 'bridge', 'type': 'interface', 'name': u'vnet0'= }, {'index': '2', 'iface': 'ide', 'name': u'hdc', 'alias': u'ide0-1-0', 'sp= ecParams': {'path': ''}, 'readonly': 'True', 'deviceId': '6aad5e48-613b-48d= b-838a-fc923fb0cdd7', 'address': {u'bus': u'1', u'controller': u'0', u'type= ': u'drive', u'target': u'0', u'unit': u'0'}, 'device': 'cdrom', 'shared': = 'false', 'path': '', 'type': 'disk'}, {'address': {u'bus': u'0', u'controll= er': u'0', u'type': u'drive', u'target': u'0', u'unit': u'0'}, 'reqsize': '= 0', 'index': 0, 'iface': 'scsi', 'apparentsize': '21474836480', 'specParams= ': {}, 'imageID': '1b23ac73-0748-49cd-94b6-11555e35be81', 'readonly': 'Fals= e', 'shared': 'false', 'truesize': '17698430976', 'type': 'disk', 'domainID= ': '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545', 'volumeInfo': {'domainID': '965c= a3b6-4f9c-4e81-b6e8-5ed4a9e58545', 'volType': 'path', 'leaseOffset': 0, 'pa= th': '/rhev/data-center/mnt/10.10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e= 81-b6e8-5ed4a9e58545/images/1b23ac73-0748-49cd-94b6-11555e35be81/5156a43b-c= 9dc-40fa-a9b7-a35b7f22f0eb', 'volumeID': '5156a43b-c9dc-40fa-a9b7-a35b7f22f= 0eb', 'leasePath': '/rhev/data-center/mnt/10.10.30.251:_var_nas1_OVirtIB/96= 5ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/images/1b23ac73-0748-49cd-94b6-11555e35b= e81/5156a43b-c9dc-40fa-a9b7-a35b7f22f0eb.lease', 'imageID': '1b23ac73-0748-= 49cd-94b6-11555e35be81'}, 'format': 'raw', 'deviceId': '1b23ac73-0748-49cd-= 94b6-11555e35be81', 'poolID': '94ed7a19-fade-4bd6-83f2-2cbb2f730b95', 'devi= ce': 'disk', 'path': '/rhev/data-center/mnt/10.10.30.251:_var_nas1_OVirtIB/= 965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/images/1b23ac73-0748-49cd-94b6-11555e3= 5be81/5156a43b-c9dc-40fa-a9b7-a35b7f22f0eb', 'propagateErrors': 'off', 'opt= ional': 'false', 'name': u'sda', 'bootOrder': u'1', 'volumeID': '5156a43b-c= 9dc-40fa-a9b7-a35b7f22f0eb', 'alias': u'scsi0-0-0-0', 'volumeChain': [{'dom= ainID': '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545', 'volType': 'path', 'leaseOf= fset': 0, 'path': '/rhev/data-center/mnt/10.10.30.251:_var_nas1_OVirtIB/965= ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/images/1b23ac73-0748-49cd-94b6-11555e35be= 81/5156a43b-c9dc-40fa-a9b7-a35b7f22f0eb', 'volumeID': '5156a43b-c9dc-40fa-a= 9b7-a35b7f22f0eb', 'leasePath': '/rhev/data-center/mnt/10.10.30.251:_var_na= s1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/images/1b23ac73-0748-49cd-9= 4b6-11555e35be81/5156a43b-c9dc-40fa-a9b7-a35b7f22f0eb.lease', 'imageID': '1= b23ac73-0748-49cd-94b6-11555e35be81'}]}, {'specParams': {}, 'alias': 'sound= 0', 'deviceId': '38b39d1b-7573-4112-b04f-669402652413', 'address': {'slot':= '0x05', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0= '}, 'device': 'ich6', 'type': 'sound'}, {'target': 2097152, 'specParams': {= 'model': 'virtio'}, 'alias': 'balloon0', 'deviceId': '7c9ed232-f54e-4382-a2= 2e-f74c2b6412f4', 'address': {'slot': '0x07', 'bus': '0x00', 'domain': '0x0= 000', 'type': 'pci', 'function': '0x0'}, 'device': 'memballoon', 'type': 'b= alloon'}], 'status': 'Paused', 'display': 'qxl'} createXmlElem:<bound metho= d Drive.createXmlElem of <vm.Drive object at 0x7f356003bb90>> device:cdrom = deviceId:6aad5e48-613b-48db-838a-fc923fb0cdd7 drv:raw extSharedState:none g= etLeasesXML:<bound method Drive.getLeasesXML of <vm.Drive object at 0x7f356= 003bb90>> getNextVolumeSize:<bound method Drive.getNextVolumeSize of <vm.Dr= ive object at 0x7f356003bb90>> getXML:<bound method Drive.getXML of <vm.Dri= ve object at 0x7f356003bb90>> hasVolumeLeases:False iface:ide index:2 isDis= kReplicationInProgress:<bound method Drive.isDiskReplicationInProgress of <= vm.Drive object at 0x7f356003bb90>> isVdsmImage:<bound method Drive.isVdsmI= mage of <vm.Drive object at 0x7f356003bb90>> log:<logUtils.SimpleLogAdapter= object at 0x7f356002ef90> name:hdc networkDev:False path: readonly:True re= qsize:0 serial: shared:false specParams:{'path': ''} truesize:0 type:cdrom = volExtensionChunk:1024 watermarkLimit:536870912=0A= Traceback (most recent call last):=0A= File "/usr/share/vdsm/clientIF.py", line 356, in teardownVolumePath=0A= res =3D self.irs.teardownImage(drive['domainID'],=0A= File "/usr/share/vdsm/vm.py", line 1389, in __getitem__=0A= raise KeyError(key)=0A= KeyError: 'domainID'=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,779::task::579::TaskManager.Ta= sk::(_updateState) Task=3D`b2f2b540-29c7-436f-b28a-e3fa961e9ddd`::moving fr= om state init -> state preparing=0A= libvirtEventLoop::INFO::2014-01-30 16:17:29,779::logUtils::44::dispatcher::= (wrapper) Run and protect: teardownImage(sdUUID=3D'965ca3b6-4f9c-4e81-b6e8-= 5ed4a9e58545', spUUID=3D'94ed7a19-fade-4bd6-83f2-2cbb2f730b95', imgUUID=3D'= 1b23ac73-0748-49cd-94b6-11555e35be81', volUUID=3DNone)=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,780::resourceManager::197::Res= ourceManager.Request::(__init__) ResName=3D`Storage.965ca3b6-4f9c-4e81-b6e8= -5ed4a9e58545`ReqID=3D`ce6ba549-acf2-49fa-8b36-2194b81606a5`::Request was m= ade in '/usr/share/vdsm/storage/hsm.py' line '3283' at 'teardownImage'=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,780::resourceManager::541::Res= ourceManager::(registerResource) Trying to register resource 'Storage.965ca= 3b6-4f9c-4e81-b6e8-5ed4a9e58545' for lock type 'shared'=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,780::resourceManager::600::Res= ourceManager::(registerResource) Resource 'Storage.965ca3b6-4f9c-4e81-b6e8-= 5ed4a9e58545' is free. Now locking as 'shared' (1 active user)=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,780::resourceManager::237::Res= ourceManager.Request::(grant) ResName=3D`Storage.965ca3b6-4f9c-4e81-b6e8-5e= d4a9e58545`ReqID=3D`ce6ba549-acf2-49fa-8b36-2194b81606a5`::Granted request= =0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,780::task::811::TaskManager.Ta= sk::(resourceAcquired) Task=3D`b2f2b540-29c7-436f-b28a-e3fa961e9ddd`::_reso= urcesAcquired: Storage.965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545 (shared)=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,781::task::974::TaskManager.Ta= sk::(_decref) Task=3D`b2f2b540-29c7-436f-b28a-e3fa961e9ddd`::ref 1 aborting= False=0A= libvirtEventLoop::INFO::2014-01-30 16:17:29,781::logUtils::47::dispatcher::= (wrapper) Run and protect: teardownImage, Return response: None=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,781::task::1168::TaskManager.T= ask::(prepare) Task=3D`b2f2b540-29c7-436f-b28a-e3fa961e9ddd`::finished: Non= e=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,781::task::579::TaskManager.Ta= sk::(_updateState) Task=3D`b2f2b540-29c7-436f-b28a-e3fa961e9ddd`::moving fr= om state preparing -> state finished=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,781::resourceManager::939::Res= ourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {'S= torage.965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': < ResourceRef 'Storage.965ca3= b6-4f9c-4e81-b6e8-5ed4a9e58545', isValid: 'True' obj: 'None'>}=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,781::resourceManager::976::Res= ourceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,782::resourceManager::615::Res= ourceManager::(releaseResource) Trying to release resource 'Storage.965ca3b= 6-4f9c-4e81-b6e8-5ed4a9e58545'=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,782::resourceManager::634::Res= ourceManager::(releaseResource) Released resource 'Storage.965ca3b6-4f9c-4e= 81-b6e8-5ed4a9e58545' (0 active users)=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,782::resourceManager::640::Res= ourceManager::(releaseResource) Resource 'Storage.965ca3b6-4f9c-4e81-b6e8-5= ed4a9e58545' is free, finding out if anyone is waiting for it.=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,782::resourceManager::648::Res= ourceManager::(releaseResource) No one is waiting for resource 'Storage.965= ca3b6-4f9c-4e81-b6e8-5ed4a9e58545', Clearing records.=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,782::task::974::TaskManager.Ta= sk::(_decref) Task=3D`b2f2b540-29c7-436f-b28a-e3fa961e9ddd`::ref 0 aborting= False=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,783::task::579::TaskManager.Ta= sk::(_updateState) Task=3D`889a75b9-0702-40d3-99da-f7994e33c40c`::moving fr= om state init -> state preparing=0A= libvirtEventLoop::INFO::2014-01-30 16:17:29,783::logUtils::44::dispatcher::= (wrapper) Run and protect: inappropriateDevices(thiefId=3D'ce64f528-9981-4e= c6-a172-9d70a00a34cd')=0A= libvirtEventLoop::INFO::2014-01-30 16:17:29,783::logUtils::47::dispatcher::= (wrapper) Run and protect: inappropriateDevices, Return response: None=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,784::task::1168::TaskManager.T= ask::(prepare) Task=3D`889a75b9-0702-40d3-99da-f7994e33c40c`::finished: Non= e=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,784::task::579::TaskManager.Ta= sk::(_updateState) Task=3D`889a75b9-0702-40d3-99da-f7994e33c40c`::moving fr= om state preparing -> state finished=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,784::resourceManager::939::Res= ourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}= =0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,784::resourceManager::976::Res= ourceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,784::task::974::TaskManager.Ta= sk::(_decref) Task=3D`889a75b9-0702-40d3-99da-f7994e33c40c`::ref 0 aborting= False=0A= Thread-285248::DEBUG::2014-01-30 16:17:29,787::BindingXMLRPC::974::vds::(wr= apper) client [192.168.11.42]::call vmDestroy with ('ce64f528-9981-4ec6-a17= 2-9d70a00a34cd',) {}=0A= Thread-285248::INFO::2014-01-30 16:17:29,787::API::318::vds::(destroy) vmCo= ntainerLock acquired by vm ce64f528-9981-4ec6-a172-9d70a00a34cd=0A= Thread-285248::DEBUG::2014-01-30 16:17:29,787::vm::4374::vm.Vm::(destroy) v= mId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::destroy Called=0A= Thread-285248::DEBUG::2014-01-30 16:17:29,788::vm::4368::vm.Vm::(deleteVm) = vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Total desktops after destroy= of ce64f528-9981-4ec6-a172-9d70a00a34cd is 0=0A= Thread-285248::DEBUG::2014-01-30 16:17:29,788::BindingXMLRPC::981::vds::(wr= apper) return vmDestroy with {'status': {'message': 'Machine destroyed', 'c= ode': 0}}=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,792::libvirtconnection::108::l= ibvirtconnection::(wrapper) Unknown libvirterror: ecode: 42 edom: 10 level:= 2 message: Domain nicht gefunden: Keine Domain mit ?bereinstimmender UUID = 'ce64f528-9981-4ec6-a172-9d70a00a34cd' (Win7x64_Master)=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,792::vm::2577::vm.Vm::(setDown= Status) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Changed state to Dow= n: Lost connection with qemu process=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,792::sampling::292::vm.Vm::(st= op) vmId=3D`ce64f528-9981-4ec6-a172-9d70a00a34cd`::Stop statistics collecti= on=0A= libvirtEventLoop::DEBUG::2014-01-30 16:17:29,793::libvirtconnection::108::l= ibvirtconnection::(wrapper) Unknown libvirterror: ecode: 42 edom: 10 level:= 2 message: Domain nicht gefunden: Keine Domain mit ?bereinstimmender UUID = 'ce64f528-9981-4ec6-a172-9d70a00a34cd' (Win7x64_Master)=0A= Thread-47::DEBUG::2014-01-30 16:17:30,113::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:17:30,120::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000169437 s, 2.1 MB/s\n'; <rc> =3D 0=0A= VM Channels Listener::DEBUG::2014-01-30 16:17:30,731::vmChannels::112::vds:= :(_do_del_channels) fileno 98 was removed from listener.=0A= Thread-41::DEBUG::2014-01-30 16:17:31,606::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:17:31,612::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000246606 s, 2.3 MB/s\n'; <rc> =3D 0=0A= Thread-285249::DEBUG::2014-01-30 16:17:32,200::task::579::TaskManager.Task:= :(_updateState) Task=3D`e44ca35a-0638-43b2-99b7-85790a96f8a2`::moving from = state init -> state preparing=0A= Thread-285249::INFO::2014-01-30 16:17:32,200::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-285249::INFO::2014-01-30 16:17:32,201::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.000195778', 'lastCheck': '4.3', 'code': 0, '= valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'dela= y': '0.000246606', 'lastCheck': '0.6', 'code': 0, 'valid': True, 'version':= 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.00021875', 'lastC= heck': '3.8', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b44-= b36f-f39f16d3974f': {'delay': '0.000169437', 'lastCheck': '2.1', 'code': 0,= 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'de= lay': '0.000195213', 'lastCheck': '7.7', 'code': 0, 'valid': True, 'version= ': 3}}=0A= Thread-285249::DEBUG::2014-01-30 16:17:32,201::task::1168::TaskManager.Task= ::(prepare) Task=3D`e44ca35a-0638-43b2-99b7-85790a96f8a2`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.000195778', 'lastCheck': '4= .3', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4= a9e58545': {'delay': '0.000246606', 'lastCheck': '0.6', 'code': 0, 'valid':= True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.= 00021875', 'lastCheck': '3.8', 'code': 0, 'valid': True, 'version': 0}, '63= 041fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000169437', 'lastCheck': = '2.1', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-73= 2789dd18d4': {'delay': '0.000195213', 'lastCheck': '7.7', 'code': 0, 'valid= ': True, 'version': 3}}=0A= Thread-285249::DEBUG::2014-01-30 16:17:32,201::task::579::TaskManager.Task:= :(_updateState) Task=3D`e44ca35a-0638-43b2-99b7-85790a96f8a2`::moving from = state preparing -> state finished=0A= Thread-285249::DEBUG::2014-01-30 16:17:32,201::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-285249::DEBUG::2014-01-30 16:17:32,201::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-285249::DEBUG::2014-01-30 16:17:32,201::task::974::TaskManager.Task:= :(_decref) Task=3D`e44ca35a-0638-43b2-99b7-85790a96f8a2`::ref 0 aborting Fa= lse=0A= Thread-52::DEBUG::2014-01-30 16:17:34,531::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:17:34,538::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000202672 s, 2.7 MB/s\n'; <rc> =3D 0=0A= Thread-40::DEBUG::2014-01-30 16:17:37,893::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:17:37,899::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000200736 s, 3.2 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:17:38,418::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:17:38,423::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000239232 s, 1.5 MB/s\n'; <rc> =3D 0=0A= Thread-47::DEBUG::2014-01-30 16:17:40,132::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:17:40,137::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000199954 s, 1.8 MB/s\n'; <rc> =3D 0=0A= Thread-41::DEBUG::2014-01-30 16:17:41,622::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:17:41,628::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000177973 s, 3.1 MB/s\n'; <rc> =3D 0=0A= Thread-52::DEBUG::2014-01-30 16:17:44,549::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:17:44,555::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000217367 s, 2.6 MB/s\n'; <rc> =3D 0=0A= Thread-285255::DEBUG::2014-01-30 16:17:47,564::task::579::TaskManager.Task:= :(_updateState) Task=3D`feb38342-e432-4cdf-afc4-39582ee67c68`::moving from = state init -> state preparing=0A= Thread-285255::INFO::2014-01-30 16:17:47,564::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-285255::INFO::2014-01-30 16:17:47,564::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.000200736', 'lastCheck': '9.7', 'code': 0, '= valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'dela= y': '0.000177973', 'lastCheck': '5.9', 'code': 0, 'valid': True, 'version':= 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.000239232', 'last= Check': '9.1', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b44= -b36f-f39f16d3974f': {'delay': '0.000199954', 'lastCheck': '7.4', 'code': 0= , 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'d= elay': '0.000217367', 'lastCheck': '3.0', 'code': 0, 'valid': True, 'versio= n': 3}}=0A= Thread-285255::DEBUG::2014-01-30 16:17:47,564::task::1168::TaskManager.Task= ::(prepare) Task=3D`feb38342-e432-4cdf-afc4-39582ee67c68`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.000200736', 'lastCheck': '9= .7', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4= a9e58545': {'delay': '0.000177973', 'lastCheck': '5.9', 'code': 0, 'valid':= True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.= 000239232', 'lastCheck': '9.1', 'code': 0, 'valid': True, 'version': 0}, '6= 3041fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000199954', 'lastCheck':= '7.4', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-7= 32789dd18d4': {'delay': '0.000217367', 'lastCheck': '3.0', 'code': 0, 'vali= d': True, 'version': 3}}=0A= Thread-285255::DEBUG::2014-01-30 16:17:47,565::task::579::TaskManager.Task:= :(_updateState) Task=3D`feb38342-e432-4cdf-afc4-39582ee67c68`::moving from = state preparing -> state finished=0A= Thread-285255::DEBUG::2014-01-30 16:17:47,565::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-285255::DEBUG::2014-01-30 16:17:47,565::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-285255::DEBUG::2014-01-30 16:17:47,565::task::974::TaskManager.Task:= :(_decref) Task=3D`feb38342-e432-4cdf-afc4-39582ee67c68`::ref 0 aborting Fa= lse=0A= Thread-40::DEBUG::2014-01-30 16:17:47,913::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:17:47,919::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000156636 s, 4.1 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:17:48,435::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:17:48,440::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000219512 s, 1.6 MB/s\n'; <rc> =3D 0=0A= Thread-47::DEBUG::2014-01-30 16:17:50,153::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:17:50,158::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000129306 s, 2.8 MB/s\n'; <rc> =3D 0=0A= Thread-41::DEBUG::2014-01-30 16:17:51,639::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:17:51,645::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000299809 s, 1.9 MB/s\n'; <rc> =3D 0=0A= Thread-52::DEBUG::2014-01-30 16:17:54,565::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:17:54,571::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.00023204 s, 2.4 MB/s\n'; <rc> =3D 0=0A= Thread-40::DEBUG::2014-01-30 16:17:57,934::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:17:57,940::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000197083 s, 3.3 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:17:58,453::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:17:58,458::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000150387 s, 2.4 MB/s\n'; <rc> =3D 0=0A= Thread-47::DEBUG::2014-01-30 16:18:00,168::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:18:00,174::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000222782 s, 1.6 MB/s\n'; <rc> =3D 0=0A= Thread-41::DEBUG::2014-01-30 16:18:01,655::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:18:01,661::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000197351 s, 2.8 MB/s\n'; <rc> =3D 0=0A= Thread-285261::DEBUG::2014-01-30 16:18:02,942::task::579::TaskManager.Task:= :(_updateState) Task=3D`5683bb8f-2158-4c8f-a263-46b6e7a086da`::moving from = state init -> state preparing=0A= Thread-285261::INFO::2014-01-30 16:18:02,943::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-285261::INFO::2014-01-30 16:18:02,943::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.000197083', 'lastCheck': '5.0', 'code': 0, '= valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'dela= y': '0.000197351', 'lastCheck': '1.3', 'code': 0, 'valid': True, 'version':= 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.000150387', 'last= Check': '4.5', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b44= -b36f-f39f16d3974f': {'delay': '0.000222782', 'lastCheck': '2.8', 'code': 0= , 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'d= elay': '0.00023204', 'lastCheck': '8.4', 'code': 0, 'valid': True, 'version= ': 3}}=0A= Thread-285261::DEBUG::2014-01-30 16:18:02,943::task::1168::TaskManager.Task= ::(prepare) Task=3D`5683bb8f-2158-4c8f-a263-46b6e7a086da`::finished: {'2c51= d320-88ce-4f23-8215-e15f55f66906': {'delay': '0.000197083', 'lastCheck': '5= .0', 'code': 0, 'valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4= a9e58545': {'delay': '0.000197351', 'lastCheck': '1.3', 'code': 0, 'valid':= True, 'version': 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.= 000150387', 'lastCheck': '4.5', 'code': 0, 'valid': True, 'version': 0}, '6= 3041fa9-e093-4b44-b36f-f39f16d3974f': {'delay': '0.000222782', 'lastCheck':= '2.8', 'code': 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-7= 32789dd18d4': {'delay': '0.00023204', 'lastCheck': '8.4', 'code': 0, 'valid= ': True, 'version': 3}}=0A= Thread-285261::DEBUG::2014-01-30 16:18:02,944::task::579::TaskManager.Task:= :(_updateState) Task=3D`5683bb8f-2158-4c8f-a263-46b6e7a086da`::moving from = state preparing -> state finished=0A= Thread-285261::DEBUG::2014-01-30 16:18:02,944::resourceManager::939::Resour= ceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}=0A= Thread-285261::DEBUG::2014-01-30 16:18:02,944::resourceManager::976::Resour= ceManager.Owner::(cancelAll) Owner.cancelAll requests {}=0A= Thread-285261::DEBUG::2014-01-30 16:18:02,944::task::974::TaskManager.Task:= :(_decref) Task=3D`5683bb8f-2158-4c8f-a263-46b6e7a086da`::ref 0 aborting Fa= lse=0A= Thread-52::DEBUG::2014-01-30 16:18:04,581::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:18:04,588::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000218219 s, 2.6 MB/s\n'; <rc> =3D 0=0A= Thread-40::DEBUG::2014-01-30 16:18:07,953::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:18:07,959::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.00019818 s, 3.3 MB/s\n'; <rc> =3D 0=0A= Thread-42::DEBUG::2014-01-30 16:18:08,470::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtISO/bff3a2be-fdd9-4e37-b416-fa4ef7fafba2/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-42::DEBUG::2014-01-30 16:18:08,475::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n357 b= ytes (357 B) copied, 0.000178019 s, 2.0 MB/s\n'; <rc> =3D 0=0A= Thread-47::DEBUG::2014-01-30 16:18:10,186::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtEXP/63041fa9-e093-4b44-b36f-f39f16d3974f/dom_md/me= tadata bs=3D4096 count=3D1' (cwd None)=0A= Thread-47::DEBUG::2014-01-30 16:18:10,192::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n363 b= ytes (363 B) copied, 0.000189951 s, 1.9 MB/s\n'; <rc> =3D 0=0A= Thread-41::DEBUG::2014-01-30 16:18:11,671::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.251:_var_nas1_OVirtIB/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-41::DEBUG::2014-01-30 16:18:11,677::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000247616 s, 2.2 MB/s\n'; <rc> =3D 0=0A= Thread-52::DEBUG::2014-01-30 16:18:14,598::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.252:_var_nas2_OVirtIB/272ec473-6041-42ee-bd1a-732789dd18d4/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-52::DEBUG::2014-01-30 16:18:14,604::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n557 b= ytes (557 B) copied, 0.000208255 s, 2.7 MB/s\n'; <rc> =3D 0=0A= Thread-40::DEBUG::2014-01-30 16:18:17,974::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) '/usr/bin/dd iflag=3Ddirect if=3D/rhev/data-center/mnt/10.= 10.30.253:_var_nas3_OVirtIB/2c51d320-88ce-4f23-8215-e15f55f66906/dom_md/met= adata bs=3D4096 count=3D1' (cwd None)=0A= Thread-40::DEBUG::2014-01-30 16:18:17,979::fileSD::239::Storage.Misc.excCmd= ::(getReadDelay) SUCCESS: <err> =3D '0+1 records in\n0+1 records out\n645 b= ytes (645 B) copied, 0.000217282 s, 3.0 MB/s\n'; <rc> =3D 0=0A= Thread-285267::DEBUG::2014-01-30 16:18:18,464::task::579::TaskManager.Task:= :(_updateState) Task=3D`1e0fc684-6d0b-4694-996c-728b66ae9fc2`::moving from = state init -> state preparing=0A= Thread-285267::INFO::2014-01-30 16:18:18,465::logUtils::44::dispatcher::(wr= apper) Run and protect: repoStats(options=3DNone)=0A= Thread-285267::INFO::2014-01-30 16:18:18,465::logUtils::47::dispatcher::(wr= apper) Run and protect: repoStats, Return response: {'2c51d320-88ce-4f23-82= 15-e15f55f66906': {'delay': '0.000217282', 'lastCheck': '0.5', 'code': 0, '= valid': True, 'version': 3}, '965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545': {'dela= y': '0.000247616', 'lastCheck': '6.8', 'code': 0, 'valid': True, 'version':= 3}, 'bff3a2be-fdd9-4e37-b416-fa4ef7fafba2': {'delay': '0.000178019', 'last= Check': '10.0', 'code': 0, 'valid': True, 'version': 0}, '63041fa9-e093-4b4= 4-b36f-f39f16d3974f': {'delay': '0.000189951', 'lastCheck': '8.3', 'code': = 0, 'valid': True, 'version': 0}, '272ec473-6041-42ee-bd1a-732789dd18d4': {'= delay': '0.000208255', 'lastCheck': '3.9', 'code': 0, 'valid': True, 'versi= on': 3}}=0A= ------=_NextPartTM-000-16e476a9-dc0a-459b-91a5-33c52e66e68f Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-16e476a9-dc0a-459b-91a5-33c52e66e68f--

5 11

[Users] (quick tip) Controlling glusterfsd CPU outbreaks with cgroups
by Andrew Lau 04 Feb '14

04 Feb '14

Hi all, I've seen quite a few posts with people using similar scenarios of running gluster and ovirt on the same physical box so I think this may be relevant. After some discussions on the gluster mailing list, I put together a quick post [1] about how you can limit glusters CPU resources so when it comes to self-healing etc. your VMs will have higher priority and not crawl to a halt when glusterfsd takes all the resources. So far, I haven't been able to apply these cgroup rules without losing the dynamic ones set by libvirt so you must do this in maintenance mode followed by a full host restart after following those instructions. I'm open to suggestions and feedback. Thanks, Andre w [1] http://www.andrewklau.com/controlling-glusterfsd-cpu-outbreaks-with-cgroups/

1 0

[Users] oVirt January 2014 Updates
by Itamar Heim 03 Feb '14

03 Feb '14

1. VERSIONS - oVirt 3.3.3 in last phases http://www.ovirt.org/OVirt_3.3.3_release_notes - oVirt 3.4 with another slew of features is getting into test day, beta, etc. http://red.ht/1eo9TiS 2. WORKSHOPS - Fosdem - oVirt stand wass packed as well as a virt & IaaS devroom, with many oVirt talks. more details next time. - more oVirt talks in cfgmgmtcamp and infra.next this week, including: -- Hervé Leclerc "How we build a cloud with CentOS, oVirt, and Cisco-UCS" Wednesday 5th February in Infrastructure.Next Ghent http://bit.ly/1fjTJVC -- oVirt Node being used as a Discovery Node in The Foreman project talk at cfgmgmtcamp, february 3rd http://bit.ly/1gAnneI - oVirt Korea group meeting this Saturday in Seoul Register here http://onoffmix.com/event/23134 - Open Virtualization Workshop in Tehran (26,27 February 2014) & Isfahan (5,6 March 2014) http://t.co/9PR3BxOnpd 3. USING oVirt - More details on Wind River using ovirt http://bit.ly/1i2LtLI - New Case Study: Nieuwland Geo-Informati http://www.ovirt.org/Nieuwland_case_study - oVirt Node being used as a Discovery Node in The Foreman project talk at cfgmgmtcamp, february 3rd http://bit.ly/1gAnneI 4. Users - Double the amount of emails on users mailing list- up from 800 to 1600 this month! - Karli updated how to use spice with ovirt from OS X http://www.ovirt.org/SPICE_Remote-Viewer_on_OS_X - Opaque (spice android ovirt client) v1.1.8 beta released https://plus.google.com/communities/116099119712127782216 - how to deploy windows guest agent on windows: http://bit.ly/1kr5tJo - Andrew Lau posted on working through Hosted Engine with 3.4.0 beta http://bit.ly/1eobzZw - Deep Dive into oVirt 3.3.3 by Li Jiansheng (chinese) http://slidesha.re/1eFWQ8G - Matthew Bingham posted a series of video on setting up ovirt: Install oVirt 3.3.2 http://www.youtube.com/watch?v=GWT-m-oWSjQ Optional export nfs mount for oVirt 3.3.2 http://www.youtube.com/watch?v=MLbPln5-2jE Initial webgui oVirt 3.3.2 Steps for storage http://www.youtube.com/watch?v=dL0_03ZICw4 Download and upload client iso to ISO_DOMAIN for oVirt 3.3.2 http://www.youtube.com/watch?v=pDzTHFSmvGE

2 1

Re: [Users] Users Digest, Vol 29, Issue 20
by Juan Pablo Lorier 03 Feb '14

03 Feb '14

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SrctK3eHuNcu9HUllglOI7BKUK26Qjgpj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have to appologise as I moved the page after sending to the list. Here it is: http://www.ovirt.org/Change_network_interface_for_Gluster Matt: I don't get your post, are you suggesting me to start like that? Regards, --SrctK3eHuNcu9HUllglOI7BKUK26Qjgpj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS79RrAAoJEC5KDDg2+NMMNzMIAK3Tt5mavkFq/OE3FKyEysGP CkI8CW78sbIUF+sTQJk5T197QHmDjCqz5mkUpjebBXhqkugnSRHuBPMm4/q/64TQ MgYNFTJRw/UaEsH5jshwT9aZpDM4OPE/1/DyHti5LkLZ6mj8YOM+gj5XQKZ9+UPc STDZ4pHvQGgUihfLK1fxin79ex4Y3eu57y3GJniHozFlwR6aAKBfehgpOsJaOmzv A5Da/N/VNqLNYWyGcAY/e+W3OJlhzh3J2BCsOH/W0RQGpkv3BXxSp6mKec3jY9ps cZgsc/eW9inWul9EYIosrpxXaIx0cXdvyFhuHi2pZ5nGiL2dt+WUCh7JLrgNO7g= =+E37 -----END PGP SIGNATURE----- --SrctK3eHuNcu9HUllglOI7BKUK26Qjgpj--

1 0

[Users] oVirt 3.3.3 release
by Sandro Bonazzola 03 Feb '14

03 Feb '14

The oVirt development team is very happy to announce the general availability of oVirt 3.3.3 as of February 3rd 2013. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. IMPORTANT NOTE: If you're upgrading from a previous version, please update ovirt-release to the latest version (10.0.1-3) and verify you have the correct repositories enabled by running the following commands # yum update ovirt-release # yum repolist enabled before upgrading with the usual procedure. You should see the ovirt-3.3.3 and ovirt-stable repositories listed in the output of the repolist command. A new oVirt Node build will be available soon as well. [1] http://www.ovirt.org/OVirt_3.3.3_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Users] ovirt-3.3.3 release postponed due to blockers
by Sandro Bonazzola 03 Feb '14

03 Feb '14

Hi, oVirt 3.3.3 release need to be postponed. A recent release of python-cpopen-1.3 is breaking dependency resolution on EL6 and F19 so vdsm can't be installed and node can't be composed. A recent change in vdsm-python-cpopen added the needed conflict against python-cpopen and removed Provides / Obsoletes on python-cpopen. But no new releases of python-cpopen is available fixing the correct Provides / Obsoletes pair. oVirt 3.3.2 / stable is affected too. Please fix Bug 1056470 - python-cpopen-1.3 is not providing obsoleted package. Bug 1056464 - python-cpopen-1.3 is not providing obsoleted package. ASAP. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

11 26

[Users] I can't remove VM
by Eduardo Ramos 03 Feb '14

03 Feb '14

This is a multi-part message in MIME format. --------------090502050908090103050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all! I'm having trouble on removing virtual machines. My environment run on a ISCSI domain storage. When I try remove, the SPM logs: # Start vdsm SPM log # Thread-6019517::INFO::2014-02-03 09:58:09,293::logUtils::41::dispatcher::(wrapper) Run and protect: deleteImage(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='57ba1906-2035-4503-acbc-5f6f077f75cc', postZero='false', force='false') Thread-6019517::INFO::2014-02-03 09:58:09,293::blockSD::816::Storage.StorageDomain::(validate) sdUUID=c332da29-ba9f-4c94-8fa9-346bb8e04e2a Thread-6019517::ERROR::2014-02-03 09:58:10,061::task::833::TaskManager.Task::(_setError) Task=`8cbf9978-ed51-488a-af52-a3db030e44ff`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 840, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 42, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 1429, in deleteImage allVols = dom.getAllVolumes() File "/usr/share/vdsm/storage/blockSD.py", line 972, in getAllVolumes return getAllVolumes(self.sdUUID) File "/usr/share/vdsm/storage/blockSD.py", line 172, in getAllVolumes vImg not in res[vPar]['imgs']): KeyError: '63650a24-7e83-4c0a-851d-0ce9869a294d' Thread-6019517::INFO::2014-02-03 09:58:10,063::task::1134::TaskManager.Task::(prepare) Task=`8cbf9978-ed51-488a-af52-a3db030e44ff`::aborting: Task is aborted: u"'63650a24-7e83-4c0a-851d-0ce9869a294d'" - code 100 Thread-6019517::ERROR::2014-02-03 09:58:10,066::dispatcher::70::Storage.Dispatcher.Protect::(run) '63650a24-7e83-4c0a-851d-0ce9869a294d' Traceback (most recent call last): File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run result = ctask.prepare(self.func, *args, **kwargs) File "/usr/share/vdsm/storage/task.py", line 1142, in prepare raise self.error KeyError: '63650a24-7e83-4c0a-851d-0ce9869a294d' Thread-6019518::INFO::2014-02-03 09:58:10,087::logUtils::41::dispatcher::(wrapper) Run and protect: getSpmStatus(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019518::INFO::2014-02-03 09:58:10,088::logUtils::44::dispatcher::(wrapper) Run and protect: getSpmStatus, Return response: {'spm_st': {'spmId': 14, 'spmStatus': 'SPM', 'spmLver': 64}} Thread-6019519::INFO::2014-02-03 09:58:10,100::logUtils::41::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-6019519::INFO::2014-02-03 09:58:10,101::logUtils::44::dispatcher::(wrapper) Run and protect: getAllTasksStatuses, Return response: {'allTasksStatus': {}} Thread-6019520::INFO::2014-02-03 09:58:10,109::logUtils::41::dispatcher::(wrapper) Run and protect: spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019520::INFO::2014-02-03 09:58:10,681::clusterlock::121::SafeLease::(release) Releasing cluster lock for domain c332da29-ba9f-4c94-8fa9-346bb8e04e2a Thread-6019521::INFO::2014-02-03 09:58:11,054::logUtils::41::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-6019521::INFO::2014-02-03 09:58:11,054::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': '0.00799298286438', 'lastCheck': '5.3', 'code': 0, 'valid': True}, u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': '0.0197920799255', 'lastCheck': '4.9', 'code': 0, 'valid': True}, u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': '0.00803208351135', 'lastCheck': '5.3', 'code': 0, 'valid': True}} Thread-6019520::INFO::2014-02-03 09:58:11,732::logUtils::44::dispatcher::(wrapper) Run and protect: spmStop, Return response: None Thread-6019523::INFO::2014-02-03 09:58:11,835::logUtils::41::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-6019523::INFO::2014-02-03 09:58:11,835::logUtils::44::dispatcher::(wrapper) Run and protect: getAllTasksStatuses, Return response: {'allTasksStatus': {}} Thread-6019524::INFO::2014-02-03 09:58:11,844::logUtils::41::dispatcher::(wrapper) Run and protect: spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019524::ERROR::2014-02-03 09:58:11,846::task::833::TaskManager.Task::(_setError) Task=`00df5ff7-bbf4-4a0e-b60b-1b06dcaa7683`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 840, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 42, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 601, in spmStop pool.stopSpm() File "/usr/share/vdsm/storage/securable.py", line 66, in wrapper raise SecureError() SecureError Thread-6019524::INFO::2014-02-03 09:58:11,855::task::1134::TaskManager.Task::(prepare) Task=`00df5ff7-bbf4-4a0e-b60b-1b06dcaa7683`::aborting: Task is aborted: u'' - code 100 Thread-6019524::ERROR::2014-02-03 09:58:11,857::dispatcher::70::Storage.Dispatcher.Protect::(run) Traceback (most recent call last): File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run result = ctask.prepare(self.func, *args, **kwargs) File "/usr/share/vdsm/storage/task.py", line 1142, in prepare raise self.error SecureError Dummy-6018624::INFO::2014-02-03 09:58:14,220::storage_mailbox::674::Storage.MailBox.SpmMailMonitor::(run) SPM_MailMonitor - Incoming mail monitoring thread stopped Thread-34627::INFO::2014-02-03 09:58:17,696::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='974d9602-8fbe-485b-a12d-59b6c34826b7', volUUID='c1bcfe5c-20ab-4f50-a88b-e2e0e1184bf8', options=None) Thread-34757::INFO::2014-02-03 09:58:17,696::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='49f65bfd-8592-42b9-9a31-91268402903f', volUUID='511e6584-4f19-426d-9379-b223d0c2d9c6', options=None) Thread-34627::INFO::2014-02-03 09:58:17,697::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '10737418240', 'apparentsize': '10737418240'} Thread-34757::INFO::2014-02-03 09:58:17,698::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '32212254720', 'apparentsize': '32212254720'} Thread-6019529::INFO::2014-02-03 09:58:21,672::logUtils::41::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-6019529::INFO::2014-02-03 09:58:21,673::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': '0.00730204582214', 'lastCheck': '5.9', 'code': 0, 'valid': True}, u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': '0.0207469463348', 'lastCheck': '5.3', 'code': 0, 'valid': True}, u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': '0.00734615325928', 'lastCheck': '5.9', 'code': 0, 'valid': True}} Thread-243::INFO::2014-02-03 09:58:27,800::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='50f2c3e9-aa94-4ad1-9c3f-91b452292374', volUUID='d7cddb76-a5b7-49ed-9efe-44d92ec18d93', options=None) Thread-34590::INFO::2014-02-03 09:58:27,801::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='c36bb1da-babd-47bd-a406-58f0cb529c00', volUUID='6ea83f9e-c614-4e11-ab57-314ed4efeeaa', options=None) Thread-243::INFO::2014-02-03 09:58:27,802::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '10737418240', 'apparentsize': '10737418240'} Thread-34590::INFO::2014-02-03 09:58:27,803::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '107374182400', 'apparentsize': '107374182400'} Thread-6019535::INFO::2014-02-03 09:58:32,337::logUtils::41::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-6019535::INFO::2014-02-03 09:58:32,337::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': '0.0119340419769', 'lastCheck': '6.6', 'code': 0, 'valid': True}, u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': '0.0190720558167', 'lastCheck': '6.0', 'code': 0, 'valid': True}, u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': '0.00720596313477', 'lastCheck': '6.6', 'code': 0, 'valid': True}} Thread-2017487::INFO::2014-02-03 09:58:37,692::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='827f2d81-dc8c-414e-90d2-75e76b3250a0', volUUID='f86ec330-0815-4361-8ce7-abf3318a8939', options=None) Thread-2017487::INFO::2014-02-03 09:58:37,693::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '10737418240', 'apparentsize': '10737418240'} Thread-6019540::INFO::2014-02-03 09:58:39,118::logUtils::41::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-6019540::INFO::2014-02-03 09:58:39,118::logUtils::44::dispatcher::(wrapper) Run and protect: getAllTasksStatuses, Return response: {'allTasksStatus': {}} Thread-6019541::INFO::2014-02-03 09:58:39,126::logUtils::41::dispatcher::(wrapper) Run and protect: spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019541::ERROR::2014-02-03 09:58:39,127::task::833::TaskManager.Task::(_setError) Task=`1f478485-401b-4b9b-b58b-1e7973cf64a2`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 840, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 42, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 601, in spmStop pool.stopSpm() File "/usr/share/vdsm/storage/securable.py", line 66, in wrapper raise SecureError() SecureError Thread-6019541::INFO::2014-02-03 09:58:39,128::task::1134::TaskManager.Task::(prepare) Task=`1f478485-401b-4b9b-b58b-1e7973cf64a2`::aborting: Task is aborted: u'' - code 100 Thread-6019541::ERROR::2014-02-03 09:58:39,130::dispatcher::70::Storage.Dispatcher.Protect::(run) Traceback (most recent call last): File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run result = ctask.prepare(self.func, *args, **kwargs) File "/usr/share/vdsm/storage/task.py", line 1142, in prepare raise self.error SecureError # End vdsm SPM log # And after, the cluster elects another SPM. The webgui shows on 'events' tab: # Start webgui events # Data Center is being initialized, please wait for initialization to complete. Failed to remove VM _12.147_postgresql_default.sir.inpe.br_apagar (User: eduardo.ramos). # End webgui events # Engine logs nothing but normal change of SPM. I would like to know how I can identify what is stuck, and if I can delete by hand, deleting entry from DB and lvremove. Thanks! --------------090502050908090103050606 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"> Hi all! I'm having trouble on removing virtual machines. My environment run on a ISCSI domain storage. When I try remove, the SPM logs: # Start vdsm SPM log # Thread-6019517::INFO::2014-02-03 09:58:09,293::logUtils::41::dispatcher::(wrapper) Run and protect: deleteImage(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='57ba1906-2035-4503-acbc-5f6f077f75cc', postZero='false', force='false') Thread-6019517::INFO::2014-02-03 09:58:09,293::blockSD::816::Storage.StorageDomain::(validate) sdUUID=c332da29-ba9f-4c94-8fa9-346bb8e04e2a Thread-6019517::ERROR::2014-02-03 09:58:10,061::task::833::TaskManager.Task::(_setError) Task=`8cbf9978-ed51-488a-af52-a3db030e44ff`::Unexpected error Traceback (most recent call last):   File "/usr/share/vdsm/storage/task.py", line 840, in _run     return fn(*args, **kargs)   File "/usr/share/vdsm/logUtils.py", line 42, in wrapper     res = f(*args, **kwargs)   File "/usr/share/vdsm/storage/hsm.py", line 1429, in deleteImage     allVols = dom.getAllVolumes()   File "/usr/share/vdsm/storage/blockSD.py", line 972, in getAllVolumes     return getAllVolumes(self.sdUUID)   File "/usr/share/vdsm/storage/blockSD.py", line 172, in getAllVolumes     vImg not in res[vPar]['imgs']): KeyError: '63650a24-7e83-4c0a-851d-0ce9869a294d' Thread-6019517::INFO::2014-02-03 09:58:10,063::task::1134::TaskManager.Task::(prepare) Task=`8cbf9978-ed51-488a-af52-a3db030e44ff`::aborting: Task is aborted: u"'63650a24-7e83-4c0a-851d-0ce9869a294d'" - code 100 Thread-6019517::ERROR::2014-02-03 09:58:10,066::dispatcher::70::Storage.Dispatcher.Protect::(run) '63650a24-7e83-4c0a-851d-0ce9869a294d' Traceback (most recent call last):   File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run     result = ctask.prepare(self.func, *args, **kwargs)   File "/usr/share/vdsm/storage/task.py", line 1142, in prepare     raise self.error KeyError: '63650a24-7e83-4c0a-851d-0ce9869a294d' Thread-6019518::INFO::2014-02-03 09:58:10,087::logUtils::41::dispatcher::(wrapper) Run and protect: getSpmStatus(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019518::INFO::2014-02-03 09:58:10,088::logUtils::44::dispatcher::(wrapper) Run and protect: getSpmStatus, Return response: {'spm_st': {'spmId': 14, 'spmStatus': 'SPM', 'spmLver': 64}} Thread-6019519::INFO::2014-02-03 09:58:10,100::logUtils::41::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-6019519::INFO::2014-02-03 09:58:10,101::logUtils::44::dispatcher::(wrapper) Run and protect: getAllTasksStatuses, Return response: {'allTasksStatus': {}} Thread-6019520::INFO::2014-02-03 09:58:10,109::logUtils::41::dispatcher::(wrapper) Run and protect: spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019520::INFO::2014-02-03 09:58:10,681::clusterlock::121::SafeLease::(release) Releasing cluster lock for domain c332da29-ba9f-4c94-8fa9-346bb8e04e2a Thread-6019521::INFO::2014-02-03 09:58:11,054::logUtils::41::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-6019521::INFO::2014-02-03 09:58:11,054::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': '0.00799298286438', 'lastCheck': '5.3', 'code': 0, 'valid': True}, u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': '0.0197920799255', 'lastCheck': '4.9', 'code': 0, 'valid': True}, u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': '0.00803208351135', 'lastCheck': '5.3', 'code': 0, 'valid': True}} Thread-6019520::INFO::2014-02-03 09:58:11,732::logUtils::44::dispatcher::(wrapper) Run and protect: spmStop, Return response: None Thread-6019523::INFO::2014-02-03 09:58:11,835::logUtils::41::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-6019523::INFO::2014-02-03 09:58:11,835::logUtils::44::dispatcher::(wrapper) Run and protect: getAllTasksStatuses, Return response: {'allTasksStatus': {}} Thread-6019524::INFO::2014-02-03 09:58:11,844::logUtils::41::dispatcher::(wrapper) Run and protect: spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019524::ERROR::2014-02-03 09:58:11,846::task::833::TaskManager.Task::(_setError) Task=`00df5ff7-bbf4-4a0e-b60b-1b06dcaa7683`::Unexpected error Traceback (most recent call last):   File "/usr/share/vdsm/storage/task.py", line 840, in _run     return fn(*args, **kargs)   File "/usr/share/vdsm/logUtils.py", line 42, in wrapper     res = f(*args, **kwargs)   File "/usr/share/vdsm/storage/hsm.py", line 601, in spmStop     pool.stopSpm()   File "/usr/share/vdsm/storage/securable.py", line 66, in wrapper     raise SecureError() SecureError Thread-6019524::INFO::2014-02-03 09:58:11,855::task::1134::TaskManager.Task::(prepare) Task=`00df5ff7-bbf4-4a0e-b60b-1b06dcaa7683`::aborting: Task is aborted: u'' - code 100 Thread-6019524::ERROR::2014-02-03 09:58:11,857::dispatcher::70::Storage.Dispatcher.Protect::(run) Traceback (most recent call last):   File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run     result = ctask.prepare(self.func, *args, **kwargs)   File "/usr/share/vdsm/storage/task.py", line 1142, in prepare     raise self.error SecureError Dummy-6018624::INFO::2014-02-03 09:58:14,220::storage_<a class="moz-txt-link-freetext" href="mailbox::674::Storage.MailBox.SpmMailMonitor::(run)">mailbox::674::Storage.MailBox.SpmMailMonitor::(run)</a> SPM_MailMonitor - Incoming mail monitoring thread stopped Thread-34627::INFO::2014-02-03 09:58:17,696::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='974d9602-8fbe-485b-a12d-59b6c34826b7', volUUID='c1bcfe5c-20ab-4f50-a88b-e2e0e1184bf8', options=None) Thread-34757::INFO::2014-02-03 09:58:17,696::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='49f65bfd-8592-42b9-9a31-91268402903f', volUUID='511e6584-4f19-426d-9379-b223d0c2d9c6', options=None) Thread-34627::INFO::2014-02-03 09:58:17,697::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '10737418240', 'apparentsize': '10737418240'} Thread-34757::INFO::2014-02-03 09:58:17,698::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '32212254720', 'apparentsize': '32212254720'} Thread-6019529::INFO::2014-02-03 09:58:21,672::logUtils::41::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-6019529::INFO::2014-02-03 09:58:21,673::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': '0.00730204582214', 'lastCheck': '5.9', 'code': 0, 'valid': True}, u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': '0.0207469463348', 'lastCheck': '5.3', 'code': 0, 'valid': True}, u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': '0.00734615325928', 'lastCheck': '5.9', 'code': 0, 'valid': True}} Thread-243::INFO::2014-02-03 09:58:27,800::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='50f2c3e9-aa94-4ad1-9c3f-91b452292374', volUUID='d7cddb76-a5b7-49ed-9efe-44d92ec18d93', options=None) Thread-34590::INFO::2014-02-03 09:58:27,801::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='c36bb1da-babd-47bd-a406-58f0cb529c00', volUUID='6ea83f9e-c614-4e11-ab57-314ed4efeeaa', options=None) Thread-243::INFO::2014-02-03 09:58:27,802::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '10737418240', 'apparentsize': '10737418240'} Thread-34590::INFO::2014-02-03 09:58:27,803::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '107374182400', 'apparentsize': '107374182400'} Thread-6019535::INFO::2014-02-03 09:58:32,337::logUtils::41::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-6019535::INFO::2014-02-03 09:58:32,337::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'51eb6183-157d-4015-ae0f-1c7ffb1731c0': {'delay': '0.0119340419769', 'lastCheck': '6.6', 'code': 0, 'valid': True}, u'c332da29-ba9f-4c94-8fa9-346bb8e04e2a': {'delay': '0.0190720558167', 'lastCheck': '6.0', 'code': 0, 'valid': True}, u'0e0be898-6e04-4469-bb32-91f3cf8146d1': {'delay': '0.00720596313477', 'lastCheck': '6.6', 'code': 0, 'valid': True}} Thread-2017487::INFO::2014-02-03 09:58:37,692::logUtils::41::dispatcher::(wrapper) Run and protect: getVolumeSize(sdUUID='c332da29-ba9f-4c94-8fa9-346bb8e04e2a', spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', imgUUID='827f2d81-dc8c-414e-90d2-75e76b3250a0', volUUID='f86ec330-0815-4361-8ce7-abf3318a8939', options=None) Thread-2017487::INFO::2014-02-03 09:58:37,693::logUtils::44::dispatcher::(wrapper) Run and protect: getVolumeSize, Return response: {'truesize': '10737418240', 'apparentsize': '10737418240'} Thread-6019540::INFO::2014-02-03 09:58:39,118::logUtils::41::dispatcher::(wrapper) Run and protect: getAllTasksStatuses(spUUID=None, options=None) Thread-6019540::INFO::2014-02-03 09:58:39,118::logUtils::44::dispatcher::(wrapper) Run and protect: getAllTasksStatuses, Return response: {'allTasksStatus': {}} Thread-6019541::INFO::2014-02-03 09:58:39,126::logUtils::41::dispatcher::(wrapper) Run and protect: spmStop(spUUID='9dbc7bb1-c460-4202-8f10-862d2ed3ed9a', options=None) Thread-6019541::ERROR::2014-02-03 09:58:39,127::task::833::TaskManager.Task::(_setError) Task=`1f478485-401b-4b9b-b58b-1e7973cf64a2`::Unexpected error Traceback (most recent call last):   File "/usr/share/vdsm/storage/task.py", line 840, in _run     return fn(*args, **kargs)   File "/usr/share/vdsm/logUtils.py", line 42, in wrapper     res = f(*args, **kwargs)   File "/usr/share/vdsm/storage/hsm.py", line 601, in spmStop     pool.stopSpm()   File "/usr/share/vdsm/storage/securable.py", line 66, in wrapper     raise SecureError() SecureError Thread-6019541::INFO::2014-02-03 09:58:39,128::task::1134::TaskManager.Task::(prepare) Task=`1f478485-401b-4b9b-b58b-1e7973cf64a2`::aborting: Task is aborted: u'' - code 100 Thread-6019541::ERROR::2014-02-03 09:58:39,130::dispatcher::70::Storage.Dispatcher.Protect::(run) Traceback (most recent call last):   File "/usr/share/vdsm/storage/dispatcher.py", line 62, in run     result = ctask.prepare(self.func, *args, **kwargs)   File "/usr/share/vdsm/storage/task.py", line 1142, in prepare     raise self.error SecureError # End vdsm SPM log # And after, the cluster elects another SPM. The webgui shows on 'events' tab: # Start webgui events # <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Data Center is being initialized, please wait for initialization to complete. <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Failed to remove VM _12.147_postgresql_default.sir.inpe.br_apagar (User: eduardo.ramos). # End webgui events # Engine logs nothing but normal change of SPM. I would like to know how I can identify what is stuck, and if I can delete by hand, deleting entry from DB and lvremove. Thanks! </body> </html> --------------090502050908090103050606--

2 1

[Users] Hosted Engine always reports "unknown stale-data"
by Andrew Lau 03 Feb '14

03 Feb '14

Hi, I was wondering if anyone has this same notice when they run: hosted-engine --vm-status The "engine status" will always be "unknown stale-data" even when the VM is powered on and the engine is online. engine-health will actually report the correct status. eg. --== Host 1 status ==-- Status up-to-date : False Hostname : 172.16.0.11 Host ID : 1 Engine status : unknown stale-data Is it some sort of blocked port causing this or is this by design? Thanks, Andrew

3 11

[Users] Full-size display Windows vs Fedora 20 guests
by Bob Doolittle 03 Feb '14

03 Feb '14

Hi, When I select View/Full Screen on a VM running a Windows guest, the display resolution automatically adjusts to fit the new canvas. However, when I do this on a VM running Fedora 20, it doesn't. Nor do I know how to query the new canvas size so that I can issue a manual xrandr command to fit it (without doing an ssh into the system and somehow finagling xwininfo to give me the size). In the guest I am running spice-vdagent-0.15.0-1, and restarting it has no effect. Shouldn't it be the one responsible for display optimization? -Bob

3 5

[Users] changing hostname in ovirt
by Sven Kieske 03 Feb '14

03 Feb '14

Hi, maybe I should write an RFE BZ for this but there might be a technical limitation, I don't know. What I want: I have a Host in ovirt which is in status "down" and/or "maintenance". I want to change the hostname/ip ovirt uses to connect to this host. 2. RFEs: 1. This is not possible via webadmin, the address field is grayed out (there seem to be conflicting design patterns for the webadmin, other buttons which don't work don't get grayed out for some reason, instead they throw errors..) 2. make it possible to change the hostname/ip via API from what I've seen so far I have to hack the database to make this change happen in 3.3.2 Is there any technical reason why this is not possible? ovirt should be happy with the UUIDs for the host and should not bother about the hostname. Is there a way to alter the hostname/ip which I don't know? Could someone point me to the right table and how to alter it without breaking it? Thank you! -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

4 9

[Users] ovirt test day: HA VM Reservation feature test summary
by Moti Asayag 03 Feb '14

03 Feb '14

Hi All, In the latest ovirt-test-day i've tested the HA VM resource reservation feature [1] according to the basic scenarios as described on [2]. The new feature notifies the admin via an event log about his cluster inability to preserve resources for HA VMs. I've reported 2 bugs based on the behavior: The cluster check doesn't consider the state of the cluster's hosts when it calculates the resources [3] and a minor issue of the audit log translation into a message [4]. [1] http://www.ovirt.org/Features/HA_VM_reservation [2] http://www.ovirt.org/OVirt_3.4_TestDay#SLA [3] Bug 1057579 - HA Vm reservation check ignores host status https://bugzilla.redhat.com/show_bug.cgi?id=1057579 [4] Bug 1057584 - HA Vm reservation event log is not well resolved https://bugzilla.redhat.com/show_bug.cgi?id=1057584 Thanks, Moti

2 3

[Users] Error message constantly being reported
by Jon Archer 03 Feb '14

03 Feb '14

Hi All, Constantly seeing this message in the logs: vdsm vds ERROR vdsm exception occured#012Traceback (most recent call last):#012 File "/usr/share/vdsm/BindingXMLRPC.py", line 952, in wrapper#012 res = f(*args, **kwargs)#012 File "/usr/share/vdsm/gluster/api.py", line 54, in wrapper#012 rv = func(*args, **kwargs)#012 File "/usr/share/vdsm/gluster/api.py", line 306, in tasksList#012 status = self.svdsmProxy.glusterTasksList(taskIds)#012 File "/usr/share/vdsm/supervdsm.py", line 50, in __call__#012 return callMethod()#012 File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>#012 **kwargs)#012 File "<string>", line 2, in glusterTasksList#012 File "/usr/lib64/python2.6/multiprocessing/managers.py", line 740, in _callmethod#012 raise convert_to_error(kind, result)#012GlusterCmdExecFailedException: Command execution failed#012error: tasks is not a valid status option#012Usage: volume status [all | <VOLNAME> [nfs|shd|<BRICK>]] [detail|clients|mem|inode|fd|callpool]#012return code: 1 looks like an option which isn't recognised by the "gluster volume status" command. Any ideas how to resolve? It's not causing any problems, but I would like to stop it. Cheers Jon

3 5

[Users] about the size of an offline snapshot
by Sandy Sun 03 Feb '14

03 Feb '14

Assign 20G virtio disk for VM, create an offline snapshot, find the true size of Vm-disk bigger than the virtual size (assign size)? I want to know how to compute the true size of vm-disk. Anbody can tell me the answer ? thanks.

4 5

[Users] oVirt Node Interface Renaming Problem
by David Li 03 Feb '14

03 Feb '14

Hi, I am using oVirt node 3.0.3. It seems systemd renames all the interfaces from ethx to something else. Not sure why but this creates lots of problems for some old scripts. For example: [root@localhost ~]# dmesg | grep -i eth0 [ 2.441579] bnx2 0000:10:00.0 eth0: Broadcom NetXtreme II BCM5709 1000Base-SX (C0) PCI Express found at mem fa000000, IRQ 30, node addr 5c:f3:fc:20:6e:58 [ 27.222803] systemd-udevd[822]: renamed network interface eth0 to enp16s0f0 Is there anyway to prevent this? Thanks.

3 2

[Users] How to scratch previous versions reports and dwh installation?
by Gianluca Cecchi 03 Feb '14

03 Feb '14

Hello, I have some problems, I think they are also due to PosgreSQL access rules changes from f18 to f19. In particular if one has passed from fedora 18 to Fedora 19 and form 3.2 to 3.3 as I did; see https://bugzilla.redhat.com/show_bug.cgi?id=1009335 Right now I have a problem with my AIO installation where trying to upgrade from 3.3.2 to 3.3.3 I got many problems related to RDBMS. Is there a way to completely get rid of prevous installtion and reinstall cleanly in 3.3.3 as I did on another system without getting problems. I tried removing packages: yum remove ovirt-engine-dwh ovirt-engine-reports and deleting related databases: drop database ovirt_engine_history; drop database ovirtenginereports; But then trying to install again packages and runnign setup I get this in log: 2014-01-30 00:37:30::DEBUG::common_utils::446::root:: running sql query on host: localhost, port: 5432, db: ovirt_engine_history, user: engine, query: 'select 1 from history_configuration;'. 2014-01-30 00:37:30::DEBUG::common_utils::907::root:: Executing command --> '/usr/bin/psql --pset=tuples_only=on --set ON_ERROR_STOP=1 --dbname ovirt_engine_history --host localhost --port 5432 --username engine -w -c select 1 from history_configuration;' in working directory '/root' 2014-01-30 00:37:30::DEBUG::common_utils::962::root:: output = 2014-01-30 00:37:30::DEBUG::common_utils::963::root:: stderr = ERROR: relation "history_configuration" does not exist LINE 1: select 1 from history_configuration; Can anyone tell if I have to run any other purge operation, suche as any users or table on engine db itself? And also what would be the expected configuration of /var/lib/pgsql/data/pg_hba.conf and eventually /var/lib/pgsql/data/postgresql.conf for a fedora 19 system so that a setup for reports and dwh could complete? Gianluca

2 5

[Users] ovirt 3.4.0-0.5.beta1 and OpenLDAP groups
by Winfried de Heiden - Voorwinde 03 Feb '14

03 Feb '14

Hi All, I managed to use OpenLDAP to integrate with oVirt 3.4.0-0.5.beta1. For this, I followed (more or less, I used a Raspberry Pi and Raspbian) instructions as found on http://www.ovirt.org/LDAP_Quick_Start It all seems to work well, I am able to connect to a domain, login etc. and assign some roles to users. However, I cannot use (ldap) groups it seems. I cann add a group in the ovirt gui, but (in the tab General) "Active" remain "false". A I missing something...? Winfried

3 3

[Users] EL6 manual hypervisor bare minimum with ovirt-hosted-engine packages
by Zach Musselman 03 Feb '14

03 Feb '14

Hello, I'd like to run the new ovirt-hosted-engine option in RHEV/Ovirt. This appears to not be a built in option of the Ovirt node image. I'd like to create an EL 6 install that as closely resembles the Node/Hypervisor image. How can I keep the amount of installed packages to a minimum and have the self hosted packages installed? Please post how I can get to the node/rhev-h image manually with as similar of packages and the ovirt-hosted-engine packages. # yum install ovirt-hosted-engine-setup # yum install ovirt-hosted-engine-ha Thanks -- Zach

2 1

Re: [Users] [URGENT] hacking the DB
by jplorier＠gmail.com 02 Feb '14

02 Feb '14

Hi Eli, Thanks for the reply. My first measure was to backup the db. I have managed to clean up the mess and as soon as I get the time, I'll send the data so you can figure out what went wrong. I'll also try to post my findings on several matters. I thank you all for the fast help to get this problem fixed so I can get to my dead line. Regards, El 01/02/2014 20:10, <users-request(a)ovirt.org> escribió: > Send Users mailing list submissions to > users(a)ovirt.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.ovirt.org/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-request(a)ovirt.org > > You can reach the person managing the list at > users-owner(a)ovirt.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: Reattach storage domain (Itamar Heim) > 2. Re: Reattach storage domain (Alexandr) > 3. Re: Reattach storage domain (Itamar Heim) > 4. Re: Reattach storage domain (Meital Bourvine) > 5. Re: Reattach storage domain (Alexandr) > 6. Re: Reattach storage domain (Itamar Heim) > 7. Re: [URGENT] hacking the DB (Eli Mesika) > 8. Re: Host x is installed with VDSM version (<UNKNOWN>) > (Dan Kenigsberg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 01 Feb 2014 18:51:19 +0100 > From: Itamar Heim <iheim(a)redhat.com> > To: Alexandr <shuriku(a)shurik.kiev.ua>, users(a)ovirt.org > Subject: Re: [Users] Reattach storage domain > Message-ID: <52ED3417.4050706(a)redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 02/01/2014 06:38 PM, Alexandr wrote: > > Hello! > > > > Unfortunately my master storage domain (gluster) is dead. I setup > > another gluster-storage and attach it to the ovirt. Hostname, path and > > volume name are same as old ones. Then I restored from tar archive all > > files. But I cannot activate master domain, operation failed and domain > > status remains "inactive". I see - it mounted on nodes: > > > > vms02.lis.ua:STORAGE on /rhev/data-center/mnt/glusterSD/vms02.lis.ua: > STORAGE > > > > I attached engine.log, can someone provide me recovery steps? > > > > P.S. Sorry for my english > > > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > the right way to do this would be to restore it not via engine, then use > the rest api to edit the storage domain connection (mount) in the engine. > > > ------------------------------ > > Message: 2 > Date: Sat, 01 Feb 2014 19:56:36 +0200 > From: Alexandr <shuriku(a)shurik.kiev.ua> > To: Itamar Heim <iheim(a)redhat.com>, users(a)ovirt.org > Subject: Re: [Users] Reattach storage domain > Message-ID: <52ED3554.8080205(a)shurik.kiev.ua> > Content-Type: text/plain; charset=UTF-8 > > Thank you. Can you provide me more detailed steps, I'm not familiar with > rest api :( > > 01.02.2014 19:51, Itamar Heim ?????: > > On 02/01/2014 06:38 PM, Alexandr wrote: > >> Hello! > >> > >> Unfortunately my master storage domain (gluster) is dead. I setup > >> another gluster-storage and attach it to the ovirt. Hostname, path and > >> volume name are same as old ones. Then I restored from tar archive all > >> files. But I cannot activate master domain, operation failed and domain > >> status remains "inactive". I see - it mounted on nodes: > >> > >> vms02.lis.ua:STORAGE on > >> /rhev/data-center/mnt/glusterSD/vms02.lis.ua:STORAGE > >> > >> I attached engine.log, can someone provide me recovery steps? > >> > >> P.S. Sorry for my english > >> > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > > > > the right way to do this would be to restore it not via engine, then > > use the rest api to edit the storage domain connection (mount) in the > > engine. > > > > ------------------------------ > > Message: 3 > Date: Sat, 01 Feb 2014 18:58:56 +0100 > From: Itamar Heim <iheim(a)redhat.com> > To: Alexandr <shuriku(a)shurik.kiev.ua>, users(a)ovirt.org > Subject: Re: [Users] Reattach storage domain > Message-ID: <52ED35E0.6000308(a)redhat.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 02/01/2014 06:56 PM, Alexandr wrote: > > Thank you. Can you provide me more detailed steps, I'm not familiar with > > rest api :( > > sorry i can't give more details right now: > manage connection details: > http://www.ovirt.org/Features/Manage_Storage_Connections > > rest api (and other things): > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtu… > > > > > > 01.02.2014 19:51, Itamar Heim ?????: > >> On 02/01/2014 06:38 PM, Alexandr wrote: > >>> Hello! > >>> > >>> Unfortunately my master storage domain (gluster) is dead. I setup > >>> another gluster-storage and attach it to the ovirt. Hostname, path and > >>> volume name are same as old ones. Then I restored from tar archive all > >>> files. But I cannot activate master domain, operation failed and domain > >>> status remains "inactive". I see - it mounted on nodes: > >>> > >>> vms02.lis.ua:STORAGE on > >>> /rhev/data-center/mnt/glusterSD/vms02.lis.ua:STORAGE > >>> > >>> I attached engine.log, can someone provide me recovery steps? > >>> > >>> P.S. Sorry for my english > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/users > >>> > >> > >> the right way to do this would be to restore it not via engine, then > >> use the rest api to edit the storage domain connection (mount) in the > >> engine. > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 1 Feb 2014 14:57:02 -0500 (EST) > From: Meital Bourvine <mbourvin(a)redhat.com> > To: Itamar Heim <iheim(a)redhat.com> > Cc: users(a)ovirt.org > Subject: Re: [Users] Reattach storage domain > Message-ID: > <1126371345.3012583.1391284622988.JavaMail.root(a)redhat.com> > Content-Type: text/plain; charset=utf-8 > > I think that it should be something like this: > > Method: PUT > > URL: https://<IP>/api/storageconnections/<ID> > > Body: > <storage_connection> > <address></address> > <type></type> > <port></port> > <target></target> > </storage_connection> > > (Add the correct details to the body. > > ----- Original Message ----- > > From: "Itamar Heim" <iheim(a)redhat.com> > > To: "Alexandr" <shuriku(a)shurik.kiev.ua>, users(a)ovirt.org > > Sent: Saturday, February 1, 2014 7:58:56 PM > > Subject: Re: [Users] Reattach storage domain > > > > On 02/01/2014 06:56 PM, Alexandr wrote: > > > Thank you. Can you provide me more detailed steps, I'm not familiar > with > > > rest api :( > > > > sorry i can't give more details right now: > > manage connection details: > > http://www.ovirt.org/Features/Manage_Storage_Connections > > > > rest api (and other things): > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtu… > > > > > > > > > > 01.02.2014 19:51, Itamar Heim ?????: > > >> On 02/01/2014 06:38 PM, Alexandr wrote: > > >>> Hello! > > >>> > > >>> Unfortunately my master storage domain (gluster) is dead. I setup > > >>> another gluster-storage and attach it to the ovirt. Hostname, path > and > > >>> volume name are same as old ones. Then I restored from tar archive > all > > >>> files. But I cannot activate master domain, operation failed and > domain > > >>> status remains "inactive". I see - it mounted on nodes: > > >>> > > >>> vms02.lis.ua:STORAGE on > > >>> /rhev/data-center/mnt/glusterSD/vms02.lis.ua:STORAGE > > >>> > > >>> I attached engine.log, can someone provide me recovery steps? > > >>> > > >>> P.S. Sorry for my english > > >>> > > >>> > > >>> _______________________________________________ > > >>> Users mailing list > > >>> Users(a)ovirt.org > > >>> http://lists.ovirt.org/mailman/listinfo/users > > >>> > > >> > > >> the right way to do this would be to restore it not via engine, then > > >> use the rest api to edit the storage domain connection (mount) in the > > >> engine. > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > ------------------------------ > > Message: 5 > Date: Sat, 01 Feb 2014 22:58:22 +0200 > From: Alexandr <shuriku(a)shurik.kiev.ua> > To: Meital Bourvine <mbourvin(a)redhat.com>, Itamar Heim > <iheim(a)redhat.com> > Cc: users(a)ovirt.org > Subject: Re: [Users] Reattach storage domain > Message-ID: <52ED5FEE.7090402(a)shurik.kiev.ua> > Content-Type: text/plain; charset="utf-8" > > 01.02.2014 21:57, Meital Bourvine ?????: > > I think that it should be something like this: > > > > Method: PUT > > > > URL: https://<IP>/api/storageconnections/<ID> > > > > Body: > > <storage_connection> > > <address></address> > > <type></type> > > <port></port> > > <target></target> > > </storage_connection> > > > > (Add the correct details to the body. > > > > ----- Original Message ----- > >> From: "Itamar Heim" <iheim(a)redhat.com> > >> To: "Alexandr" <shuriku(a)shurik.kiev.ua>, users(a)ovirt.org > >> Sent: Saturday, February 1, 2014 7:58:56 PM > >> Subject: Re: [Users] Reattach storage domain > >> > >> On 02/01/2014 06:56 PM, Alexandr wrote: > >>> Thank you. Can you provide me more detailed steps, I'm not familiar > with > >>> rest api :( > >> sorry i can't give more details right now: > >> manage connection details: > >> http://www.ovirt.org/Features/Manage_Storage_Connections > >> > >> rest api (and other things): > >> > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtu… > >> > >> > >>> 01.02.2014 19:51, Itamar Heim ?????: > >>>> On 02/01/2014 06:38 PM, Alexandr wrote: > >>>>> Hello! > >>>>> > >>>>> Unfortunately my master storage domain (gluster) is dead. I setup > >>>>> another gluster-storage and attach it to the ovirt. Hostname, path > and > >>>>> volume name are same as old ones. Then I restored from tar archive > all > >>>>> files. But I cannot activate master domain, operation failed and > domain > >>>>> status remains "inactive". I see - it mounted on nodes: > >>>>> > >>>>> vms02.lis.ua:STORAGE on > >>>>> /rhev/data-center/mnt/glusterSD/vms02.lis.ua:STORAGE > >>>>> a > >>>>> I attached engine.log, can someone provide me recovery steps? > >>>>> > >>>>> P.S. Sorry for my english > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users(a)ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>> > >>>> the right way to do this would be to restore it not via engine, then > >>>> use the rest api to edit the storage domain connection (mount) in the > >>>> engine. > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > I tried to change it via ovirt-shell and receive an error: > > [oVirt shell (connected)]# update storageconnection > 4a1d8b07-f393-4134-86cc-4f46145cca2b --address vms02.lis.ua --path STORAGE > > error: > status: 400 > reason: Bad Request > detail: Cannot edit Storage Connection. Storage connection parameters > can be edited only for NFS, Posix, local or iSCSI data domains. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.ovirt.org/pipermail/users/attachments/20140201/7c4ad39f/attach… > > > > ------------------------------ > > Message: 6 > Date: Sat, 01 Feb 2014 22:12:56 +0100 > From: Itamar Heim <iheim(a)redhat.com> > To: Alexandr <shuriku(a)shurik.kiev.ua>, Meital Bourvine > <mbourvin(a)redhat.com> > Cc: users(a)ovirt.org > Subject: Re: [Users] Reattach storage domain > Message-ID: <52ED6358.7060203(a)redhat.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 02/01/2014 09:58 PM, Alexandr wrote: > > 01.02.2014 21:57, Meital Bourvine ?????: > >> I think that it should be something like this: > >> > >> Method: PUT > >> > >> URL:https://<IP>/api/storageconnections/<ID> > >> > >> Body: > >> <storage_connection> > >> <address></address> > >> <type></type> > >> <port></port> > >> <target></target> > >> </storage_connection> > >> > >> (Add the correct details to the body. > >> > >> ----- Original Message ----- > >>> From: "Itamar Heim"<iheim(a)redhat.com> > >>> To: "Alexandr"<shuriku(a)shurik.kiev.ua>,users(a)ovirt.org > >>> Sent: Saturday, February 1, 2014 7:58:56 PM > >>> Subject: Re: [Users] Reattach storage domain > >>> > >>> On 02/01/2014 06:56 PM, Alexandr wrote: > >>>> Thank you. Can you provide me more detailed steps, I'm not familiar > with > >>>> rest api :( > >>> sorry i can't give more details right now: > >>> manage connection details: > >>> http://www.ovirt.org/Features/Manage_Storage_Connections > >>> > >>> rest api (and other things): > >>> > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtu… > >>> > >>> > >>>> 01.02.2014 19:51, Itamar Heim ?????: > >>>>> On 02/01/2014 06:38 PM, Alexandr wrote: > >>>>>> Hello! > >>>>>> > >>>>>> Unfortunately my master storage domain (gluster) is dead. I setup > >>>>>> another gluster-storage and attach it to the ovirt. Hostname, path > and > >>>>>> volume name are same as old ones. Then I restored from tar archive > all > >>>>>> files. But I cannot activate master domain, operation failed and > domain > >>>>>> status remains "inactive". I see - it mounted on nodes: > >>>>>> > >>>>>> vms02.lis.ua:STORAGE on > >>>>>> /rhev/data-center/mnt/glusterSD/vms02.lis.ua:STORAGE > >>>>>> a > >>>>>> I attached engine.log, can someone provide me recovery steps? > >>>>>> > >>>>>> P.S. Sorry for my english > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Users mailing list > >>>>>> Users(a)ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>>> > >>>>> the right way to do this would be to restore it not via engine, then > >>>>> use the rest api to edit the storage domain connection (mount) in the > >>>>> engine. > >>> _______________________________________________ > >>> Users mailing list > >>> Users(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/users > >>> > > I tried to change it via ovirt-shell and receive an error: > > > > [oVirt shell (connected)]# update storageconnection > > 4a1d8b07-f393-4134-86cc-4f46145cca2b --address vms02.lis.ua --path > STORAGE > > > > error: > > status: 400 > > reason: Bad Request > > detail: Cannot edit Storage Connection. Storage connection parameters > > can be edited only for NFS, Posix, local or iSCSI data domains. > > alisa/derez - any reason we don't support edit connection for gluster sd? > > > ------------------------------ > > Message: 7 > Date: Sat, 1 Feb 2014 16:13:37 -0500 (EST) > From: Eli Mesika <emesika(a)redhat.com> > To: Juan Pablo Lorier <jplorier(a)gmail.com> > Cc: users <users(a)ovirt.org> > Subject: Re: [Users] [URGENT] hacking the DB > Message-ID: > <1814059864.10645949.1391289217257.JavaMail.root(a)redhat.com> > Content-Type: text/plain; charset=utf-8 > > > > ----- Original Message ----- > > From: "Juan Pablo Lorier" <jplorier(a)gmail.com> > > To: "Sahina Bose" <sabose(a)redhat.com>, "users" <users(a)ovirt.org> > > Sent: Friday, January 31, 2014 4:18:47 PM > > Subject: Re: [Users] [URGENT] hacking the DB > > > > It also has a foreign key at vds_statistics, > > Thanks for everything, I'll keep you updated on this matter. > > Regards, > > Hi Juan > First of all let me recommend to backup your DB before playing with it. > My second comment is that this should not occur in the first place so if > you removed something and have leftovers that you been forced to delete > manually it is certainly a bug and I will appreciate if you can open one , > describe the scenario and attach the relevant logs > > Thanks > Eli > > > > > > > > On 31/01/14 11:30, Sahina Bose wrote: > > > > > > On 01/31/2014 05:49 PM, Juan Pablo Lorier wrote: > > >> Hi again, > > >> > > >> I'm now in the process of deleting the removed cluster from the > hosts. I > > >> can't just delete it from vds_groups as is a external key to > vds_static, > > >> and it looks like vds_static has the hosts definition. > > >> Can I safely update the vds_group_id to ' ' in the hosts to "detach" > > >> them from the cluster? > > >> Regards, > > > > > > I think it would be safer to remove the host and then remove the > cluster. > > > You would have to remove the host entry from vds_static as well as > > > vds_dynamic. > > > > > >> > > >> On 31/01/14 09:35, Sahina Bose wrote: > > >>> delete from gluster_volume_bricks where volume_id = " > > >> > > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > ------------------------------ > > Message: 8 > Date: Sat, 1 Feb 2014 22:09:51 +0000 > From: Dan Kenigsberg <danken(a)redhat.com> > To: Matt Warren <mwarren(a)hnw.com> > Cc: "users(a)ovirt.org" <users(a)ovirt.org> > Subject: Re: [Users] Host x is installed with VDSM version (<UNKNOWN>) > Message-ID: <20140201220951.GI9811(a)redhat.com> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jan 31, 2014 at 01:26:20PM -0500, Matt Warren wrote: > > Any troubleshooting ideas for vdsm reporting UNKNONW version when it's > > clearly 4.13 installed? > > > > >>> Host x is installed with VDSM version (<UNKNOWN>) and cannot join > > >>>cluster Default which is compatible with VDSM versions [4.13, 4.9, > 4.11, > > >>>4.12, 4.10]. > > >>>In reading some google searches, suggestion was to first run > "vdsClient > > >>>-s 0 getVdsCaps". This returns "Failed to initialize storage" for any > > >>>vdsClient command. > > Engine cannot tell which Vdsm is install, since there's a serious > problem there - so serious that Vdsm cannot report its own version. > > Could you restart Vdsm and follow vdsm.log and supervdsm.log for hints > on why does the storage subsystem fail to start? > > > ------------------------------ > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > > End of Users Digest, Vol 29, Issue 4 > ************************************ >

1 0

[Users] Hosted Engine adding host SSL Failure (w/ engine custom cert)
by Andrew Lau 02 Feb '14

02 Feb '14

Hi, After running through the new patch posted in BZ 1055153 I'm adding a second host to the hosted-engine cluster but it seems to fail right before the finish: [ ERROR ] Failed to execute stage 'Closing up': [ERROR]::oVirt API connection failure, [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Couple Extra Notes: Engine has a custom SSL cert but the CA has been trusted by the new host. When I temporarily return the engine's SSL back to the default generated one the install will succeed. Setup logs: http://www.fpaste.org/72624/13909770/ What confuses me is: curl https://engine.example.net with the custom SSL cert will succeed but with the original self-signed gives the expected "insecure" message. What criteria need to be met so the install will pass? Thanks, Andrew

2 12

[Users] Host x is installed with VDSM version (<UNKNOWN>)
by Matt Warren 02 Feb '14

02 Feb '14

Hello ovirt users. New to ovirt and having troubles. Trying to setup a dedicated ovirt engine host and use a separate, exiting CentOS 6.5 host to run some guests as a node. When I tried to add the host, it recognizes it but throws errors of: Host x is installed with VDSM version (<UNKNOWN>) and cannot join cluster Default which is compatible with VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10]. In reading some google searches, suggestion was to first run "vdsClient -s 0 getVdsCaps". This returns "Failed to initialize storage" for any vdsClient command. I'm looking to run this host with it's local storage. I've tried to add a local storage path on the host via ovirt of "/data/images" but it seems to have no effect. Any help appreciated. Thanks, Matt

3 5

[Users] [URGENT] hacking the DB
by Juan Pablo Lorier 01 Feb '14

01 Feb '14

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5U5vHVe2c4gErPcwPMiguIxge1AAH6cqN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I'm about to hack engine db to remove a gluster volume and I'd like someone to advise me on this. The environment is in production, I've backed up the db and I'm planning to remove every entry I can find of the volume (host members, cluster, etc) but I found that there's no clusters table (and I need to remove a cluster that no longer exists after a force remove of the DC but somehow the volume still is attached to it). I'll try IRC also to see if someone can give me a hand. Regards, --5U5vHVe2c4gErPcwPMiguIxge1AAH6cqN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS64asAAoJEC5KDDg2+NMM9oIH/3i/XzV0VPnCS0TgrxiPY1Ik AxK7MRt6hWCC1ZERZfJ0pURfd3MIzd4u08+Wy5NQaH2PWNGn4bTd8FxidaxqjJuU a8JR6EuL5H91DDzoj4kaXxwg2kIKcjMT7CNnLnrR5AT7cYhB3ArqOE9qzqXXKY0j G7ZtPg7+4H2qYbmALo6GnH9/Bd1RXDhNE2v2LPf/0/7xvkSW//e4YDm3Cf1P0sxs gCz30sAvBvdplqRHWmHHMqD1CKpj+JVbwWujqmTh3PBqGasRgmqcXeY4Hr41VsZX r9OJYtQodW7f+Qq2qMn46OlOLCTD69ONwqBs1h7pG5PTRp9thU+ZOQcAGd4GjUY= =PjE8 -----END PGP SIGNATURE----- --5U5vHVe2c4gErPcwPMiguIxge1AAH6cqN--

3 6

[Users] CustomProperties not being passed when using Run Once
by Dresel Christopher 01 Feb '14

01 Feb '14

--_000_9B9655665ED7604FA398BAA731A9059E2CE5DB55VERENA5fhwnacat_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCndoZW4gdXNpbmcgQ3VzdG9tUHJvcGVydGllcyB0aGV5IGFyZSBub3QgYmVpbmcgcGFz c2VkIHdoZW4gc3RhcnRpbmcgVk0gd2l0aCBSdW4uIEhvdyB0byByZXByb2R1Y2U6DQoNCnZpbSAv dXNyL2xpYmV4ZWMvdmRzbS9ob29rcy9iZWZvcmVfdm1fc3RhcnQvOTlfcmVtb3ZlX2NwdQ0KDQoj IS91c3IvYmluL3B5dGhvbg0KDQppbXBvcnQgb3MNCmltcG9ydCBzeXMNCmltcG9ydCBob29raW5n DQoNCmlmIGhvb2tpbmcudG9ib29sKG9zLmVudmlyb24uZ2V0KCdyZW1vdmVfY3B1JykpOg0KICAg ICAgICBzeXMuc3RkZXJyLndyaXRlKCdUUlVFJykNCmVsc2U6DQogICAgICAgIHN5cy5zdGRlcnIu d3JpdGUoJ0ZBTFNFJykNCg0Kc3lzLmV4aXQoMCkNCg0KY2htb2QgNzU1IC91c3IvbGliZXhlYy92 ZHNtL2hvb2tzL2JlZm9yZV92bV9zdGFydC85OV9yZW1vdmVfY3B1DQoNCmVuZ2luZS1jb25maWcg LXMgVXNlckRlZmluZWRWTVByb3BlcnRpZXM9J3JlbW92ZV9jcHU9Xih0cnVlfGZhbHNlKSQnIC0t Y3Zlcj0zLjMNCnNlcnZpY2Ugb3ZpcnQtZW5naW5lIHJlc3RhcnQNCg0KU2V0dXAgVmlydHVhbCBN YWNoaW5lIHdpdGggY3VzdG9tIHByb3BlcnR5IHNldC4gV2hlbiBzdGFydGluZyBWTSB2aWEgUnVu LCB2ZHNtLmxvZyBzaG93cyDigJhUUlVF4oCZOg0KDQpUaHJlYWQtMTgzMDo6REVCVUc6OjIwMTQt MDEtMzAgMDg6NTg6MzUsNzY3Ojp1dGlsczo6NDg5Ojpyb290OjooZXhlY0NtZCkgJy91c3IvbGli ZXhlYy92ZHNtL2hvb2tzL2JlZm9yZV92bV9zdGFydC85OV9yZW1vdmVfY3B1JyAoY3dkIE5vbmUp DQpUaHJlYWQtMTgzMDo6REVCVUc6OjIwMTQtMDEtMzAgMDg6NTg6MzUsNzk0Ojp1dGlsczo6NTA5 Ojpyb290OjooZXhlY0NtZCkgU1VDQ0VTUzogPGVycj4gPSAnVFJVRSc7IDxyYz4gPSAwDQoNCldo ZW4gY2FsbGluZyB0aGUgc2FtZSB2aWEgUnVuIE9uY2UgKHRoZSBkaWFsb2cgZXZlbiBzaG93cyB0 aGF0IHRoZSBjdXN0b20gcHJvcGVydHkgaXMgc2V0OiBodHRwOi8vaW1ndXIuY29tL3dWU2U3NUwp LCB0aGUgdmRzbS5sb2cgc2hvd3Mg4oCYRkFMU0XigJk6DQoNClRocmVhZC0xNTg5OjpERUJVRzo6 MjAxNC0wMS0zMCAwODo1MjoyNCwyMTk6OnV0aWxzOjo0ODk6OnJvb3Q6OihleGVjQ21kKSAnL3Vz ci9saWJleGVjL3Zkc20vaG9va3MvYmVmb3JlX3ZtX3N0YXJ0Lzk5X3JlbW92ZV9jcHUnIChjd2Qg Tm9uZSkNClRocmVhZC0xNTg5OjpERUJVRzo6MjAxNC0wMS0zMCAwODo1MjoyNCwyNDY6OnV0aWxz Ojo1MDk6OnJvb3Q6OihleGVjQ21kKSBTVUNDRVNTOiA8ZXJyPiA9ICdGQUxTRSc7IDxyYz4gPSAw DQoNCkJlc3QgUmVnYXJkcywNCkNocmlzdG9waGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkZhY2hob2Noc2NodWxlIFdpZW5lciBOZXVzdGFkdCBmw7xyIFdpcnRzY2hh ZnQgdW5kIFRlY2huaWsgR2VzLm0uYi5ILg0KVW5pdmVyc2l0eSBvZiBBcHBsaWVkIFNjaWVuY2Vz IFdpZW5lciBOZXVzdGFkdCBmb3IgQnVzaW5lc3MgYW5kIEVuZ2luZWVyaW5nIEx0ZC4sIEF1c3Ry aWENCkpvaGFubmVzIEd1dGVuYmVyZy1TdHJhw59lIDMNCjI3MDAgV2llbmVyIE5ldXN0YWR0DQpB dXN0cmlhLCBFdXJvcGUNCkFUVTogMzc3NzI0MDYNCkZpcm1lbmJ1Y2hudW1tZXI6IDc3MDA1dg0K RmlybWVuYnVjaGdlcmljaHQ6IExhbmRlc2dlcmljaHQgV2llbmVyIE5ldXN0YWR0DQpEVlI6IDA3 Njk2NjUNCkRlciBJbmhhbHQgZGllc2VzIEUtTWFpbHMgaXN0IGF1c3NjaGxpZXNzbGljaCBmdWVy IGRlbiBiZXplaWNobmV0ZW4gQWRyZXNzYXRlbiBiZXN0aW1tdC4gSmVkZSBGb3JtIGRlciBLZW5u dG5pc25haG1lLCBWZXJvZWZmZW50bGljaHVuZywgVmVydmllbGZhZWx0aWd1bmcgb2RlciBXZWl0 ZXJnYWJlIGRlcyBJbmhhbHRzIGRpZXNlcyBFLU1haWxzIGR1cmNoIHVuYmVyZWNodGlndGUgRHJp dHRlIGlzdCB1bnp1bGFlc3NpZy4gV2lyIGJpdHRlbiBTaWUsIHNpY2ggbWl0IGRlbSBBYnNlbmRl ciBkZXMgRS1NYWlscyBpbiBWZXJiaW5kdW5nIHp1IHNldHplbiwgZmFsbHMgU2llIG5pY2h0IGRl ciBBZHJlc3NhdCBkaWVzZXMgRS1NYWlscyBzaW5kIHVuZCBkYXMgTWF0ZXJpYWwgdm9uIElocmVt IENvbXB1dGVyIHp1IGxvZXNjaGVuLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4g VGhlIHBlcnVzYWwsIHB1YmxpY2F0aW9uLCBjb3B5aW5nIG9yIGRpc3NlbWluYXRpb24gb2YgdGhl IGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGJ5IHVuYXV0aG9yaXNlZCB0aGlyZCBwYXJ0aWVzIGlz IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBlLW1haWwsIHBsZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2Vu ZGVyLg0K --_000_9B9655665ED7604FA398BAA731A9059E2CE5DB55VERENA5fhwnacat_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERS1B VCIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+d2hlbiB1c2luZyBDdXN0b21Qcm9wZXJ0aWVzIHRoZXkgYXJlIG5v dCBiZWluZyBwYXNzZWQgd2hlbiBzdGFydGluZyBWTSB3aXRoIFJ1bi4gSG93IHRvIHJlcHJvZHVj ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnZpbSAvdXNyL2xpYmV4ZWMvdmRzbS9ob29rcy9iZWZvcmVf dm1fc3RhcnQvOTlfcmVtb3ZlX2NwdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+IyEvdXNyL2Jpbi9weXRob248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPmltcG9ydCBvczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbXBvcnQgc3lzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmltcG9ydCBob29raW5nPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5pZiBob29r aW5nLnRvYm9vbChvcy5lbnZpcm9uLmdldCgncmVtb3ZlX2NwdScpKTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHN5cy5zdGRlcnIud3JpdGUoJ1RSVUUnKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5lbHNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3lzLnN0ZGVyci53cml0ZSgnRkFMU0UnKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+c3lzLmV4aXQoMCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNobW9kIDc1NSAv dXNyL2xpYmV4ZWMvdmRzbS9ob29rcy9iZWZvcmVfdm1fc3RhcnQvOTlfcmVtb3ZlX2NwdTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+ZW5naW5lLWNvbmZpZyAtcyBVc2VyRGVmaW5lZFZNUHJvcGVydGllcz0n cmVtb3ZlX2NwdT1eKHRydWV8ZmFsc2UpJCcgLS1jdmVyPTMuMzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zZXJ2aWNlIG92aXJ0 LWVuZ2luZSByZXN0YXJ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZXR1cCBWaXJ0dWFsIE1hY2hpbmUg d2l0aCBjdXN0b20gcHJvcGVydHkgc2V0LiBXaGVuIHN0YXJ0aW5nIFZNIHZpYSBSdW4sIHZkc20u bG9nIHNob3dzIOKAmFRSVUXigJk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaHJlYWQtMTgzMDo6REVC VUc6OjIwMTQtMDEtMzAgMDg6NTg6MzUsNzY3Ojp1dGlsczo6NDg5Ojpyb290OjooZXhlY0NtZCkg Jy91c3IvbGliZXhlYy92ZHNtL2hvb2tzL2JlZm9yZV92bV9zdGFydC85OV9yZW1vdmVfY3B1JyAo Y3dkIE5vbmUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRocmVhZC0xODMwOjpERUJVRzo6MjAxNC0wMS0zMCAwODo1ODozNSw3 OTQ6OnV0aWxzOjo1MDk6OnJvb3Q6OihleGVjQ21kKSBTVUNDRVNTOiAmbHQ7ZXJyJmd0OyA9ICdU UlVFJzsgJmx0O3JjJmd0OyA9IDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoZW4gY2FsbGluZyB0aGUg c2FtZSB2aWEgUnVuIE9uY2UgKHRoZSBkaWFsb2cgZXZlbiBzaG93cyB0aGF0IHRoZSBjdXN0b20g cHJvcGVydHkgaXMgc2V0Og0KPGEgaHJlZj0iaHR0cDovL2ltZ3VyLmNvbS93VlNlNzVMIj5odHRw Oi8vaW1ndXIuY29tL3dWU2U3NUw8L2E+KSwgdGhlIHZkc20ubG9nIHNob3dzIOKAmEZBTFNF4oCZ OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhyZWFkLTE1ODk6OkRFQlVHOjoyMDE0LTAxLTMwIDA4OjUy OjI0LDIxOTo6dXRpbHM6OjQ4OTo6cm9vdDo6KGV4ZWNDbWQpICcvdXNyL2xpYmV4ZWMvdmRzbS9o b29rcy9iZWZvcmVfdm1fc3RhcnQvOTlfcmVtb3ZlX2NwdScgKGN3ZCBOb25lKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaHJl YWQtMTU4OTo6REVCVUc6OjIwMTQtMDEtMzAgMDg6NTI6MjQsMjQ2Ojp1dGlsczo6NTA5Ojpyb290 OjooZXhlY0NtZCkgU1VDQ0VTUzogJmx0O2VyciZndDsgPSAnRkFMU0UnOyAmbHQ7cmMmZ3Q7ID0g MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RvcGhlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iVmVyZGFu YSIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkZhY2hob2Noc2NodWxlIFdpZW5lciBOZXVz dGFkdCBmw7xyIFdpcnRzY2hhZnQgdW5kIFRlY2huaWsgR2VzLm0uYi5ILjxicj4NClVuaXZlcnNp dHkgb2YgQXBwbGllZCBTY2llbmNlcyBXaWVuZXIgTmV1c3RhZHQgZm9yIEJ1c2luZXNzIGFuZCBF bmdpbmVlcmluZyBMdGQuLCBBdXN0cmlhPGJyPg0KSm9oYW5uZXMgR3V0ZW5iZXJnLVN0cmHDn2Ug Mzxicj4NCjI3MDAgV2llbmVyIE5ldXN0YWR0PGJyPg0KQXVzdHJpYSwgRXVyb3BlPGJyPg0KQVRV OiAzNzc3MjQwNjxicj4NCkZpcm1lbmJ1Y2hudW1tZXI6IDc3MDA1djxicj4NCkZpcm1lbmJ1Y2hn ZXJpY2h0OiBMYW5kZXNnZXJpY2h0IFdpZW5lciBOZXVzdGFkdDxicj4NCkRWUjogMDc2OTY2NTxi cj4NCkRlciBJbmhhbHQgZGllc2VzIEUtTWFpbHMgaXN0IGF1c3NjaGxpZXNzbGljaCBmdWVyIGRl biBiZXplaWNobmV0ZW4gQWRyZXNzYXRlbiBiZXN0aW1tdC4gSmVkZSBGb3JtIGRlciBLZW5udG5p c25haG1lLCBWZXJvZWZmZW50bGljaHVuZywgVmVydmllbGZhZWx0aWd1bmcgb2RlciBXZWl0ZXJn YWJlIGRlcyBJbmhhbHRzIGRpZXNlcyBFLU1haWxzIGR1cmNoIHVuYmVyZWNodGlndGUgRHJpdHRl IGlzdCB1bnp1bGFlc3NpZy4gV2lyIGJpdHRlbiBTaWUsDQogc2ljaCBtaXQgZGVtIEFic2VuZGVy IGRlcyBFLU1haWxzIGluIFZlcmJpbmR1bmcgenUgc2V0emVuLCBmYWxscyBTaWUgbmljaHQgZGVy IEFkcmVzc2F0IGRpZXNlcyBFLU1haWxzIHNpbmQgdW5kIGRhcyBNYXRlcmlhbCB2b24gSWhyZW0g Q29tcHV0ZXIgenUgbG9lc2NoZW4uPGJyPg0KPGJyPg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy ZXNzZWUuIFRoZSBwZXJ1c2FsLCBwdWJsaWNhdGlvbiwgY29weWluZyBvciBkaXNzZW1pbmF0aW9u IG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBieSB1bmF1dGhvcmlzZWQgdGhpcmQgcGFy dGllcyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMNCiBlLW1haWwsIHBsZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlm eSB0aGUgc2VuZGVyLjxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9B9655665ED7604FA398BAA731A9059E2CE5DB55VERENA5fhwnacat_--

3 2

[Users] vdsm re setup?
by Matt Warren 01 Feb '14

01 Feb '14

I'm putting vdsm on a host that is also managed by puppet. I'm tracing some of my troubles to the fact that puppet stepped on some sudoers config done by vdsm. Is it possible to re-run the setup scripts for vdsm to regenerate the sudoers changes?

3 3

Re: [Users] Extremely poor disk access speeds in Windows guest
by Nicholas Kesick 01 Feb '14

01 Feb '14

--_9a4ce072-90af-4283-8756-2cce79d93e12_ Content-Type: multipart/alternative; boundary="_7268CB10-E597-419C-B2BE-EEC079156B7D_" --_7268CB10-E597-419C-B2BE-EEC079156B7D_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" U3RldmUsDQoNCldoYXQgaXMgdGhlIENQVSBsb2FkIG9mIHRoZSBHbHVzdGVyRlMgaG9zdCB3aGVu IGNvbXBhcmluZyB0aGUgcmF3IGJyaWNrIHRlc3QgdG8gdGhlIGdsdXN0ZXIgbW91bnQgcG9pbnQg dGVzdD8gR2l2ZSBpdCAzMCBzZWNvbmRzIGFuZCBzZWUgd2hhdCB0b3AgcmVwb3J0cy4gWW914oCZ bGwgcHJvYmFibHkgaGF2ZSB0byBzaWduaWZpY2FudGx5IGluY3JlYXNlIHRoZSBjb3VudCBvbiB0 aGUgdGVzdCBzbyB0aGF0IGl0IHJ1bnMgdGhhdCBsb25nLg0KDQoNCg0KDQoNCg0KLSBOaWNrDQoN Cg0KDQoNCg0KRnJvbTogU2FuamF5IFJhbw0KU2VudDog4oCORnJpZGF54oCOLCDigI5KYW51YXJ5 4oCOIOKAjjI04oCOLCDigI4yMDE0IOKAjjPigI464oCOMzXigI4g4oCOUE0NClRvOiBTdGV2ZSBE YWluYXJkDQpDYzogQm9iIFNpYmxleSwgb1ZpcnQgTWFpbGluZyBMaXN0LCBSb25lbiBIb2QNCg0K DQoNCg0KDQoNCkFkZGluZyBCb2IgU2libGV5IHRvIHRoaXMgdGhyZWFkLiANCg0KDQoNCg0KDQoN Cg0KDQoNCg0KRnJvbTogIlN0ZXZlIERhaW5hcmQiIDxzZGFpbmFyZEBtaW92aXNpb24uY29tPg0K VG86ICJBbmRyZXcgQ2F0aHJvdyIgPGFjYXRocm93QHJlZGhhdC5jb20+DQpDYzogIlJvbmVuIEhv ZCIgPHJob2RAcmVkaGF0LmNvbT4sICJ1c2VycyIgPHVzZXJzQG92aXJ0Lm9yZz4sICJTYW5qYXkg UmFvIiA8c3Jhb0ByZWRoYXQuY29tPiwgIkl0YW1hciBIZWltIiA8aWhlaW1AcmVkaGF0LmNvbT4N ClNlbnQ6IEZyaWRheSwgSmFudWFyeSAyNCwgMjAxNCAzOjAxOjI1IFBNDQpTdWJqZWN0OiBSZTog W1VzZXJzXSBFeHRyZW1lbHkgcG9vciBkaXNrIGFjY2VzcyBzcGVlZHMgaW4gV2luZG93cyBndWVz dA0KDQoNCg0KDQpOb3Qgc3VyZSB3aGF0IGEgZ29vZCBtZXRob2QgdG8gYmVuY2ggdGhpcyB3b3Vs ZCBiZSwgYnV0Og0KDQoNCg0KQW4gTkZTIG1vdW50IHBvaW50IG9uIHZpcnQgaG9zdDoNCg0KDQpb cm9vdEBvdmlydDAwMSBpc28tc3RvcmVdIyBkZCBpZj0vZGV2L3plcm8gb2Y9dGVzdDEgYnM9NGsg Y291bnQ9MTAwMDAwDQoNCjEwMDAwMCswIHJlY29yZHMgaW4NCg0KMTAwMDAwKzAgcmVjb3JkcyBv dXQNCg0KNDA5NjAwMDAwIGJ5dGVzICg0MTAgTUIpIGNvcGllZCwgMy45NTM5OSBzLCAxMDQgTUIv cw0KDQoNCg0KDQpSYXcgYnJpY2sgcGVyZm9ybWFuY2Ugb24gZ2x1c3RlciBzZXJ2ZXIgKHllcywg SSBrbm93IEkgc2hvdWxkbid0IHdyaXRlIGRpcmVjdGx5IHRvIHRoZSBicmljayk6DQoNCg0KW3Jv b3RAZ2x1c3RlcjEgaXNvLXN0b3JlXSMgZGQgaWY9L2Rldi96ZXJvIG9mPXRlc3QgYnM9NGsgY291 bnQ9MTAwMDAwDQoNCjEwMDAwMCswIHJlY29yZHMgaW4NCg0KMTAwMDAwKzAgcmVjb3JkcyBvdXQN Cg0KNDA5NjAwMDAwIGJ5dGVzICg0MTAgTUIpIGNvcGllZCwgMy4wNjc0MyBzLCAxMzQgTUIvcw0K DQoNCg0KDQpHbHVzdGVyIG1vdW50IHBvaW50IG9uIGdsdXN0ZXIgc2VydmVyOg0KDQoNCltyb290 QGdsdXN0ZXIxIGlzby1zdG9yZV0jIGRkIGlmPS9kZXYvemVybyBvZj10ZXN0IGJzPTRrIGNvdW50 PTEwMDAwMA0KDQoxMDAwMDArMCByZWNvcmRzIGluDQoNCjEwMDAwMCswIHJlY29yZHMgb3V0DQoN CjQwOTYwMDAwMCBieXRlcyAoNDEwIE1CKSBjb3BpZWQsIDE5LjU3NjYgcywgMjAuOSBNQi9zDQoN Cg0KDQoNClRoZSBzdG9yYWdlIHNlcnZlcnMgYXJlIGEgYml0IG9sZGVyLCBidXQgYXJlIGJvdGgg ZHVhbCBzb2NrZXQgcXVhZCBjb3JlIG9wdGVyb25zIHdpdGggNHggNzIwMHJwbSBkcml2ZXMuIA0K DQoNCg0KDQpJJ20gaW4gdGhlIHByb2Nlc3Mgb2Ygc2V0dGluZyB1cCBhIHNoYXJlIGZyb20gbXkg ZGVza3RvcCBhbmQgSSdsbCBzZWUgaWYgSSBjYW4gYmVuY2ggYmV0d2VlbiB0aGUgdHdvIHN5c3Rl bXMuIE5vdCBzdXJlIGlmIG15IHNzZCB3aWxsIGltcGFjdCB0aGUgdGVzdHMsIEkndmUgaGVhcmQg dGhlcmUgaXNuJ3QgYW4gYWR2YW50YWdlIHVzaW5nIHNzZCBzdG9yYWdlIGZvciBnbHVzdGVyZnMu DQoNCg0KDQoNCkRvZXMgYW55b25lIGhhdmUgYSBoYXJkd2FyZSByZWZlcmVuY2UgZGVzaWduIGZv ciBnbHVzdGVyZnMgYXMgYSBiYWNrZW5kIGZvciB2aXJ0PyBPciBpcyB0aGVyZSBhIGJlbmNobWFy ayB1dGlsaXR5Pw0KDQoNCg0KDQpTdGV2ZSBEYWluYXJkIA0KSVQgSW5mcmFzdHJ1Y3R1cmUgTWFu YWdlcg0KTWlvdmlzaW9uIHwgUmV0aGluayBUcmFmZmljDQo1MTktNTEzLTI0MDcgZXguMjUwDQo4 NzctNjQ2LTg0NzYgKHRvbGwtZnJlZSkNCg0KQmxvZyAgfCAgTGlua2VkSW4gIHwgIFR3aXR0ZXIg IHwgIEZhY2Vib29rIA0KDQoNCk1pb3Zpc2lvbiBUZWNobm9sb2dpZXMgSW5jLiB8IDE0OCBNYW5p dG91IERyaXZlLCBTdWl0ZSAxMDEsIEtpdGNoZW5lciwgT04sIENhbmFkYSB8IE4yQyAxTDMNClRo aXMgZS1tYWlsIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdlZCBvciBj b25maWRlbnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhlIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBub3RpZnkgdXMgaW1t ZWRpYXRlbHkuDQoNCg0KDQoNCg0KT24gVGh1LCBKYW4gMjMsIDIwMTQgYXQgNzoxOCBQTSwgQW5k cmV3IENhdGhyb3cgPGFjYXRocm93QHJlZGhhdC5jb20+IHdyb3RlOg0KDQoNCg0KQXJlIHdlIHN1 cmUgdGhhdCB0aGUgaXNzdWUgaXMgdGhlIGd1ZXN0IEkvTyAtIHdoYXQncyB0aGUgcmF3IHBlcmZv cm1hbmNlIG9uIHRoZSBob3N0IGFjY2Vzc2luZyB0aGUgZ2x1c3RlciBzdG9yYWdlPw0KDQoNCg0K DQoNCg0KRnJvbTogIlN0ZXZlIERhaW5hcmQiIDxzZGFpbmFyZEBtaW92aXNpb24uY29tPg0KVG86 ICJJdGFtYXIgSGVpbSIgPGloZWltQHJlZGhhdC5jb20+DQpDYzogIlJvbmVuIEhvZCIgPHJob2RA cmVkaGF0LmNvbT4sICJ1c2VycyIgPHVzZXJzQG92aXJ0Lm9yZz4sICJTYW5qYXkgUmFvIiA8c3Jh b0ByZWRoYXQuY29tPg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjMsIDIwMTQgNDo1Njo1OCBQ TQ0KU3ViamVjdDogUmU6IFtVc2Vyc10gRXh0cmVtZWx5IHBvb3IgZGlzayBhY2Nlc3Mgc3BlZWRz IGluIFdpbmRvd3MgZ3Vlc3QNCg0KDQoNCg0KDQoNCkkgaGF2ZSB0d28gb3B0aW9ucywgdmlydGlv IGFuZCB2aXJ0aW8tc2NzaS4NCg0KDQoNCkkgd2FzIHVzaW5nIHZpcnRpbywgYW5kIGhhdmUgYWxz byBhdHRlbXB0ZWQgdmlydGlvLXNjc2kgb24gYW5vdGhlciBXaW5kb3dzIGd1ZXN0IHdpdGggdGhl IHNhbWUgcmVzdWx0cy4NCg0KDQoNCg0KVXNpbmcgdGhlIG5ld2VzdCBkcml2ZXJzLCB2aXJ0aW8t d2luLTAuMS03NC5pc28uDQoNCg0KDQoNClN0ZXZlIERhaW5hcmQgDQpJVCBJbmZyYXN0cnVjdHVy ZSBNYW5hZ2VyDQpNaW92aXNpb24gfCBSZXRoaW5rIFRyYWZmaWMNCjUxOS01MTMtMjQwNyBleC4y NTANCjg3Ny02NDYtODQ3NiAodG9sbC1mcmVlKQ0KDQpCbG9nICB8ICBMaW5rZWRJbiAgfCAgVHdp dHRlciAgfCAgRmFjZWJvb2sgDQoNCg0KTWlvdmlzaW9uIFRlY2hub2xvZ2llcyBJbmMuIHwgMTQ4 IE1hbml0b3UgRHJpdmUsIFN1aXRlIDEwMSwgS2l0Y2hlbmVyLCBPTiwgQ2FuYWRhIHwgTjJDIDFM Mw0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2Vk IG9yIGNvbmZpZGVudGlhbC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIG5vdGlmeSB1 cyBpbW1lZGlhdGVseS4NCg0KDQoNCg0KDQpPbiBUaHUsIEphbiAyMywgMjAxNCBhdCA0OjI0IFBN LCBJdGFtYXIgSGVpbSA8aWhlaW1AcmVkaGF0LmNvbT4gd3JvdGU6DQoNCg0KT24gMDEvMjMvMjAx NCAwNzo0NiBQTSwgU3RldmUgRGFpbmFyZCB3cm90ZToNCg0KQmFja2luZyBTdG9yYWdlOiBHbHVz dGVyIFJlcGxpY2ENClN0b3JhZ2UgRG9tYWluOiBORlMNCk92aXJ0IEhvc3RzOiBDZW50T1MgNi41 DQpPdmlydCB2ZXJzaW9uOiAzLjMuMg0KTmV0d29yazogR2lnRQ0KIyBvZiBWTSdzOiAzIC0gdHdv IExpbnV4IGd1ZXN0cyBhcmUgaWRsZSwgb25lIFdpbmRvd3MgZ3Vlc3QgaXMNCmluc3RhbGxpbmcg dXBkYXRlcy4NCg0KSSd2ZSBpbnN0YWxsZWQgYSBXaW5kb3dzIDIwMDggUjIgZ3Vlc3Qgd2l0aCB2 aXJ0aW8gZGlzaywgYW5kIGFsbCB0aGUNCmRyaXZlcnMgZnJvbSB0aGUgbGF0ZXN0IHZpcnRpbyBp c28uIEkndmUgYWxzbyBpbnN0YWxsZWQgdGhlIHNwaWNlIGFnZW50DQpkcml2ZXJzLg0KDQpHdWVz dCBkaXNrIGFjY2VzcyBpcyBob3JyaWJseSBzbG93LCBSZXNvdXJjZSBtb25pdG9yIGR1cmluZyBX aW5kb3dzDQp1cGRhdGVzIHNob3dzIERpc2sgcGVha2luZyBhdCAxTUIvc2VjIChzY2FsZSBuZXZl ciBpbmNyZWFzZXMpIGFuZCBEaXNrDQpRdWV1ZSBMZW5ndGggUGVha2luZyBhdCA1IGFuZCBsb29r cyB0byBiZSBzaXR0aW5nIGF0IHRoYXQgbGV2ZWwgOTklIG9mDQp0aGUgdGltZS4gMTEzIHVwZGF0 ZXMgaW4gV2luZG93cyBoYXMgYmVlbiBydW5uaW5nIHNvbGlkbHkgZm9yIGFib3V0IDIuNQ0KaG91 cnMgYW5kIGlzIGF0IDg5LzExMyB1cGRhdGVzIGNvbXBsZXRlLg0KDQoNCnZpcnRpby1ibG9jayBv ciB2aXJ0aW8tc2NzaT8NCndoaWNoIHdpbmRvd3MgZ3Vlc3QgZHJpdmVyIHZlcnNpb24gZm9yIHRo YXQ/DQoNCg0KDQoNCkkgY2FuJ3Qgc2F5IG15IExpbnV4IGd1ZXN0cyBhcmUgYmxpc3RlcmluZ2x5 IGZhc3QsIGJ1dCB1cGRhdGluZyBhIGd1ZXN0DQpmcm9tIFJIRUwgNi4zIGZyZXNoIGluc3RhbGwg dG8gNi41IHRvb2sgYWJvdXQgMjUgbWludXRlcy4NCg0KSWYgYW55b25lIGhhcyBhbnkgaWRlYXMs IHBsZWFzZSBsZXQgbWUga25vdyAtIEkgaGF2ZW4ndCBmb3VuZCBhbnkgdHVuaW5nDQpkb2NzIGZv ciBXaW5kb3dzIGd1ZXN0cyB0aGF0IGNvdWxkIGV4cGxhaW4gdGhpcyBpc3N1ZS4NCg0KVGhhbmtz LA0KDQoNCg0KKlN0ZXZlIERhaW5hcmQgKg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClVzZXJzIG1haWxpbmcgbGlzdA0KVXNlcnNAb3ZpcnQu b3JnDQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMNCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVzZXJz IG1haWxpbmcgbGlzdA0KVXNlcnNAb3ZpcnQub3JnDQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21h aWxtYW4vbGlzdGluZm8vdXNlcnMNCg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0gDQoNCg0KU2FuamF5 IFJhbyANClByaW5jaXBhbCBQZXJmb3JtYW5jZSBFbmdpbmVlciAgICAgICAgICAgICAgICAgICBQ aG9uZTogOTc4LTM5Mi0yNDc5IA0KUmVkIEhhdCwgSW5jLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEZBWDogOTc4LTM5Mi0xMDAxIA0KMzE0IExpdHRsZXRvbiBSb2FkICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEVtYWlsOiBzcmFvQHJlZGhhdC5jb20gDQpXZXN0Zm9y ZCwgTUEgMDE4ODY= --_7268CB10-E597-419C-B2BE-EEC079156B7D_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwMzE1Ij4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206 MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0 b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48 ZGl2PlN0ZXZlLDwvZGl2PjxkaXY+V2hhdCBpcyB0aGUgQ1BVIGxvYWQgb2YgdGhlIEdsdXN0ZXJG UyBob3N0IHdoZW4gY29tcGFyaW5nIHRoZSByYXcgYnJpY2sgdGVzdCB0byB0aGUgZ2x1c3RlciBt b3VudCBwb2ludCB0ZXN0PyBHaXZlIGl0Jm5ic3A7MzAgc2Vjb25kcyBhbmQgc2VlIHdoYXQgdG9w IHJlcG9ydHMuIFlvdeKAmWxsIHByb2JhYmx5IGhhdmUgdG8gc2lnbmlmaWNhbnRseSBpbmNyZWFz ZSB0aGUgY291bnQgb24gdGhlIHRlc3Qgc28gdGhhdCBpdCBydW5zIHRoYXQgbG9uZy48YnI+PC9k aXY+PGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi0g TmljazwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1 cHg7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0 aDogMXB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPjxkaXY+PGZvbnQgZmFjZT0iICdDYWxp YnJpJywgJ1NlZ29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9z b2Z0IEpoZW5nSGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZiciIHN0eWxlPSds aW5lLWhlaWdodDogMTVwdDsgbGV0dGVyLXNwYWNpbmc6IDAuMDJlbTsgZm9udC1mYW1pbHk6ICJD YWxpYnJpIiwgIlNlZ29lIFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWlj cm9zb2Z0IEpoZW5nSGVpIFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IGZvbnQt c2l6ZTogMTJwdDsnPjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzcmFvQHJlZGhh dC5jb20iIHRhcmdldD0iX3BhcmVudCI+U2FuamF5IFJhbzwvYT48YnI+PGI+U2VudDo8L2I+Jm5i c3A74oCORnJpZGF54oCOLCDigI5KYW51YXJ54oCOIOKAjjI04oCOLCDigI4yMDE0IOKAjjPigI46 4oCOMzXigI4g4oCOUE08YnI+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzZGFpbmFy ZEBtaW92aXNpb24uY29tIiB0YXJnZXQ9Il9wYXJlbnQiPlN0ZXZlIERhaW5hcmQ8L2E+PGJyPjxi PkNjOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86cnNpYmxleUByZWRoYXQuY29tIiB0YXJnZXQ9 Il9wYXJlbnQiPkJvYiBTaWJsZXk8L2E+LCA8YSBocmVmPSJtYWlsdG86dXNlcnNAb3ZpcnQub3Jn IiB0YXJnZXQ9Il9wYXJlbnQiPm9WaXJ0IE1haWxpbmcgTGlzdDwvYT4sIDxhIGhyZWY9Im1haWx0 bzpyaG9kQHJlZGhhdC5jb20iIHRhcmdldD0iX3BhcmVudCI+Um9uZW4gSG9kPC9hPjwvZm9udD48 L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0iIj48ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGlt ZXMsIHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij48ZGl2PkFkZGluZyBCb2IgU2libGV5IHRvIHRo aXMgdGhyZWFkLiA8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGhyIGlk PSJ6d2NociI+PGJsb2NrcXVvdGUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IHBhZGRpbmct bGVmdDogNXB4OyBmb250LWZhbWlseTogSGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBt YXJnaW4tbGVmdDogNXB4OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDE2LCAxNiwgMjU1KTsgYm9y ZGVyLWxlZnQtd2lkdGg6IDJweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyIgZGF0YS1tY2Ut c3R5bGU9ImJvcmRlci1sZWZ0OiAycHggc29saWQgIzEwMTBGRjsgbWFyZ2luLWxlZnQ6IDVweDsg cGFkZGluZy1sZWZ0OiA1cHg7IGNvbG9yOiAjMDAwOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250 LXN0eWxlOiBub3JtYWw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYSxBcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij48Yj5Gcm9tOiA8L2I+IlN0 ZXZlIERhaW5hcmQiICZsdDtzZGFpbmFyZEBtaW92aXNpb24uY29tJmd0Ozxicj48Yj5UbzogPC9i PiJBbmRyZXcgQ2F0aHJvdyIgJmx0O2FjYXRocm93QHJlZGhhdC5jb20mZ3Q7PGJyPjxiPkNjOiA8 L2I+IlJvbmVuIEhvZCIgJmx0O3Job2RAcmVkaGF0LmNvbSZndDssICJ1c2VycyIgJmx0O3VzZXJz QG92aXJ0Lm9yZyZndDssICJTYW5qYXkgUmFvIiAmbHQ7c3Jhb0ByZWRoYXQuY29tJmd0OywgIkl0 YW1hciBIZWltIiAmbHQ7aWhlaW1AcmVkaGF0LmNvbSZndDs8YnI+PGI+U2VudDogPC9iPkZyaWRh eSwgSmFudWFyeSAyNCwgMjAxNCAzOjAxOjI1IFBNPGJyPjxiPlN1YmplY3Q6IDwvYj5SZTogW1Vz ZXJzXSBFeHRyZW1lbHkgcG9vciBkaXNrIGFjY2VzcyBzcGVlZHMgaW4gV2luZG93cyBndWVzdDxi cj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0ibHRyIj5Ob3Qgc3VyZSB3aGF0IGEgZ29vZCBtZXRo b2QgdG8gYmVuY2ggdGhpcyB3b3VsZCBiZSwgYnV0OjxkaXY+PGJyPjwvZGl2PjxkaXY+QW4gTkZT IG1vdW50IHBvaW50IG9uIHZpcnQgaG9zdDo8L2Rpdj48ZGl2PjxkaXY+W3Jvb3RAb3ZpcnQwMDEg aXNvLXN0b3JlXSMgZGQgaWY9L2Rldi96ZXJvIG9mPXRlc3QxIGJzPTRrIGNvdW50PTEwMDAwMDwv ZGl2PjxkaXY+MTAwMDAwKzAgcmVjb3JkcyBpbjwvZGl2PjxkaXY+MTAwMDAwKzAgcmVjb3JkcyBv dXQ8L2Rpdj48ZGl2PjQwOTYwMDAwMCBieXRlcyAoNDEwIE1CKSBjb3BpZWQsIDMuOTUzOTkgcywg MTA0IE1CL3M8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlJhdyBicmljayBwZXJmb3Jt YW5jZSBvbiBnbHVzdGVyIHNlcnZlciAoeWVzLCBJIGtub3cgSSBzaG91bGRuJ3Qgd3JpdGUgZGly ZWN0bHkgdG8gdGhlIGJyaWNrKTo8L2Rpdj48ZGl2PjxkaXY+W3Jvb3RAZ2x1c3RlcjEgaXNvLXN0 b3JlXSMgZGQgaWY9L2Rldi96ZXJvIG9mPXRlc3QgYnM9NGsgY291bnQ9MTAwMDAwPC9kaXY+PGRp dj4xMDAwMDArMCByZWNvcmRzIGluPC9kaXY+PGRpdj4xMDAwMDArMCByZWNvcmRzIG91dDwvZGl2 PjxkaXY+NDA5NjAwMDAwIGJ5dGVzICg0MTAgTUIpIGNvcGllZCwgMy4wNjc0MyBzLCAxMzQgTUIv czwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+R2x1c3RlciBtb3VudCBwb2ludCBvbiBn bHVzdGVyIHNlcnZlcjo8L2Rpdj48ZGl2PjxkaXY+W3Jvb3RAZ2x1c3RlcjEgaXNvLXN0b3JlXSMg ZGQgaWY9L2Rldi96ZXJvIG9mPXRlc3QgYnM9NGsgY291bnQ9MTAwMDAwPC9kaXY+PGRpdj4xMDAw MDArMCByZWNvcmRzIGluPC9kaXY+PGRpdj4xMDAwMDArMCByZWNvcmRzIG91dDwvZGl2PjxkaXY+ NDA5NjAwMDAwIGJ5dGVzICg0MTAgTUIpIGNvcGllZCwgMTkuNTc2NiBzLCAyMC45IE1CL3M8L2Rp dj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBzdG9yYWdlIHNlcnZlcnMgYXJlIGEgYml0 IG9sZGVyLCBidXQgYXJlIGJvdGggZHVhbCBzb2NrZXQgcXVhZCBjb3JlIG9wdGVyb25zIHdpdGgg NHggNzIwMHJwbSBkcml2ZXMuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JJ20gaW4g dGhlIHByb2Nlc3Mgb2Ygc2V0dGluZyB1cCBhIHNoYXJlIGZyb20gbXkgZGVza3RvcCBhbmQgSSds bCBzZWUgaWYgSSBjYW4gYmVuY2ggYmV0d2VlbiB0aGUgdHdvIHN5c3RlbXMuIE5vdCBzdXJlIGlm IG15IHNzZCB3aWxsIGltcGFjdCB0aGUgdGVzdHMsIEkndmUgaGVhcmQgdGhlcmUgaXNuJ3QgYW4g YWR2YW50YWdlIHVzaW5nIHNzZCBzdG9yYWdlIGZvciBnbHVzdGVyZnMuPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5Eb2VzIGFueW9uZSBoYXZlIGEgaGFyZHdhcmUgcmVmZXJlbmNlIGRlc2lnbiBm b3IgZ2x1c3RlcmZzIGFzIGEgYmFja2VuZCBmb3IgdmlydD8gT3IgaXMgdGhlcmUgYSBiZW5jaG1h cmsgdXRpbGl0eT88L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsZWFy PSJhbGwiPjxkaXY+PGRpdiBkaXI9Imx0ciI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlh bCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1p bHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsiPjxzdHJvbmc+U3RldmUmbmJz cDtEYWluYXJkJm5ic3A7PC9zdHJvbmc+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEy cHg7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PC9zcGFuPjxicj4gPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IiBk YXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJweDsiPklUIEluZnJhc3RydWN0dXJlIE1hbmFnZXI8YnI+IDxhIGhyZWY9Imh0dHA6Ly9taW92 aXNpb24uY29tLyIgdGFyZ2V0PSJfcGFyZW50IiBkYXRhLW1jZS1ocmVmPSJodHRwOi8vbWlvdmlz aW9uLmNvbS8iPk1pb3Zpc2lvbjwvYT4gfCA8ZW0+UmV0aGluayBUcmFmZmljPC9lbT48YnI+IDUx OS01MTMtMjQwNyBleC4yNTA8YnI+IDg3Ny02NDYtODQ3NiAodG9sbC1mcmVlKTxicj4gPGJyPiA8 c3Ryb25nIHN0eWxlPSJjb2xvcjogcmdiKDE1MywgMTUzLCAxNTMpOyBmb250LWZhbWlseTogYXJp YWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFt aWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGNvbG9yOiAjOTk5OTk5OyI+ PGEgaHJlZj0iaHR0cDovL21pb3Zpc2lvbi5jb20vYmxvZyIgdGFyZ2V0PSJfcGFyZW50IiBkYXRh LW1jZS1ocmVmPSJodHRwOi8vbWlvdmlzaW9uLmNvbS9ibG9nIj5CbG9nPC9hPiZuYnNwOyB8ICZu YnNwOzwvc3Ryb25nPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDE1MywgMTUzLCAxNTMpOyBmb250 LWZhbWlseTogYXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyIgZGF0YS1tY2Utc3R5 bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGNvbG9y OiAjOTk5OTk5OyI+PHN0cm9uZz48YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29t cGFueS9taW92aXNpb24tdGVjaG5vbG9naWVzIiB0YXJnZXQ9Il9wYXJlbnQiIGRhdGEtbWNlLWhy ZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9jb21wYW55L21pb3Zpc2lvbi10ZWNobm9sb2dp ZXMiPkxpbmtlZEluPC9hPiZuYnNwOyZuYnNwO3wgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90d2l0 dGVyLmNvbS9taW92aXNpb24iIHRhcmdldD0iX3BhcmVudCIgZGF0YS1tY2UtaHJlZj0iaHR0cHM6 Ly90d2l0dGVyLmNvbS9taW92aXNpb24iPlR3aXR0ZXI8L2E+Jm5ic3A7Jm5ic3A7fCAmbmJzcDs8 YSBocmVmPSJodHRwczovL3d3dy5mYWNlYm9vay5jb20vbWlvdmlzaW9uIiB0YXJnZXQ9Il9wYXJl bnQiIGRhdGEtbWNlLWhyZWY9Imh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9taW92aXNpb24iPkZh Y2Vib29rPC9hPjwvc3Ryb25nPjwvc3Bhbj4gPC9zcGFuPjxociBzdHlsZT0iY29sb3I6IHJnYig1 MSwgNTEsIDUxKTsgY2xlYXI6IGJvdGg7IGZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBm b250LXNpemU6IDEzcHg7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgY29sb3I6ICMzMzMzMzM7IGNsZWFyOiBib3RoOyI+PGRp diBzdHlsZT0iY29sb3I6IHJnYigxNTMsIDE1MywgMTUzKTsgcGFkZGluZy10b3A6IDVweDsgZm9u dC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsiIGRhdGEtbWNlLXN0 eWxlPSJjb2xvcjogIzk5OTk5OTsgZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTNweDsgcGFkZGluZy10b3A6IDVweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog YXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQt ZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7Ij5NaW92aXNpb24gVGVj aG5vbG9naWVzIEluYy4gfCAxNDggTWFuaXRvdSBEcml2ZSwgU3VpdGUgMTAxLCBLaXRjaGVuZXIs IE9OLCBDYW5hZGEgfCZuYnNwO04yQyAxTDM8L3NwYW4+PGJyPiA8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsiIGRhdGEtbWNlLXN0eWxl PSJmb250LWZhbWlseTogYXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyI+VGhpcyBl LW1haWwgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRl bGV0ZSB0aGUgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS48L3NwYW4+PC9kaXY+PC9kaXY+PC9kaXY+PGJyPjxkaXY+PGJyPjwvZGl2PjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEphbiAyMywgMjAxNCBhdCA3OjE4IFBNLCBBbmRyZXcg Q2F0aHJvdyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzphY2F0aHJvd0ByZWRo YXQuY29tIiB0YXJnZXQ9Il9wYXJlbnQiIGRhdGEtbWNlLWhyZWY9Im1haWx0bzphY2F0aHJvd0By ZWRoYXQuY29tIj5hY2F0aHJvd0ByZWRoYXQuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIw NCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlk OyIgZGF0YS1tY2Utc3R5bGU9Im1hcmdpbjogMCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6IDFweCAj Y2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6IDFleDsiPjxkaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IGFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwcHQ7IiBkYXRhLW1j ZS1zdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogYXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Ij5BcmUgd2Ugc3VyZSB0aGF0IHRoZSBpc3N1ZSBpcyB0aGUgZ3Vlc3QgSS9PIC0g d2hhdCdzIHRoZSByYXcgcGVyZm9ybWFuY2Ugb24gdGhlIGhvc3QgYWNjZXNzaW5nIHRoZSBnbHVz dGVyIHN0b3JhZ2U/PGJyPjxkaXY+PGJyPjwvZGl2Pjxocj48YmxvY2txdW90ZSBzdHlsZT0icGFk ZGluZy1sZWZ0OiA1cHg7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxMnB0OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IG1hcmdpbi1sZWZ0OiA1cHg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTYsIDE2LCAyNTUp OyBib3JkZXItbGVmdC13aWR0aDogMnB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IiBkYXRh LW1jZS1zdHlsZT0icGFkZGluZy1sZWZ0OiA1cHg7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1zdHls ZTogbm9ybWFsOyBtYXJnaW4tbGVmdDogNXB4OyBmb250LWZhbWlseTogSGVsdmV0aWNhLEFyaWFs LHNhbnMtc2VyaWY7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg Ym9yZGVyLWxlZnQ6IDJweCBzb2xpZCAjMTAxMGZmOyI+PGI+RnJvbTogPC9iPiJTdGV2ZSBEYWlu YXJkIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNkYWluYXJkQG1pb3Zpc2lvbi5jb20iIHRhcmdldD0i X3BhcmVudCIgZGF0YS1tY2UtaHJlZj0ibWFpbHRvOnNkYWluYXJkQG1pb3Zpc2lvbi5jb20iPnNk YWluYXJkQG1pb3Zpc2lvbi5jb208L2E+Jmd0Ozxicj48Yj5UbzogPC9iPiJJdGFtYXIgSGVpbSIg Jmx0OzxhIGhyZWY9Im1haWx0bzppaGVpbUByZWRoYXQuY29tIiB0YXJnZXQ9Il9wYXJlbnQiIGRh dGEtbWNlLWhyZWY9Im1haWx0bzppaGVpbUByZWRoYXQuY29tIj5paGVpbUByZWRoYXQuY29tPC9h PiZndDs8YnI+IDxiPkNjOiA8L2I+IlJvbmVuIEhvZCIgJmx0OzxhIGhyZWY9Im1haWx0bzpyaG9k QHJlZGhhdC5jb20iIHRhcmdldD0iX3BhcmVudCIgZGF0YS1tY2UtaHJlZj0ibWFpbHRvOnJob2RA cmVkaGF0LmNvbSI+cmhvZEByZWRoYXQuY29tPC9hPiZndDssICJ1c2VycyIgJmx0OzxhIGhyZWY9 Im1haWx0bzp1c2Vyc0BvdmlydC5vcmciIHRhcmdldD0iX3BhcmVudCIgZGF0YS1tY2UtaHJlZj0i bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9hPiZndDssICJTYW5qYXkg UmFvIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNyYW9AcmVkaGF0LmNvbSIgdGFyZ2V0PSJfcGFyZW50 IiBkYXRhLW1jZS1ocmVmPSJtYWlsdG86c3Jhb0ByZWRoYXQuY29tIj5zcmFvQHJlZGhhdC5jb208 L2E+Jmd0Ozxicj4gPGI+U2VudDogPC9iPlRodXJzZGF5LCBKYW51YXJ5IDIzLCAyMDE0IDQ6NTY6 NTggUE08YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbVXNlcnNdIEV4dHJlbWVseSBwb29yIGRpc2sg YWNjZXNzIHNwZWVkcyBpbiBXaW5kb3dzIGd1ZXN0PGRpdj48ZGl2IGNsYXNzPSJoNSI+PGJyPjxk aXY+PGJyPjwvZGl2PjxkaXYgZGlyPSJsdHIiPkkgaGF2ZSB0d28gb3B0aW9ucywgdmlydGlvIGFu ZCB2aXJ0aW8tc2NzaS48ZGl2Pjxicj48L2Rpdj48ZGl2Pkkgd2FzIHVzaW5nIHZpcnRpbywgYW5k IGhhdmUgYWxzbyBhdHRlbXB0ZWQgdmlydGlvLXNjc2kgb24gYW5vdGhlciBXaW5kb3dzIGd1ZXN0 IHdpdGggdGhlIHNhbWUgcmVzdWx0cy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlVzaW5nIHRo ZSBuZXdlc3QgZHJpdmVycywgdmlydGlvLXdpbi0wLjEtNzQuaXNvLjwvZGl2PjwvZGl2PjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xlYXI9ImFsbCI+PGRpdj48ZGl2IGRpcj0ibHRyIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZw eDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogYXJpYWwsc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNnB4OyI+PHN0cm9uZz5TdGV2ZSZuYnNwO0RhaW5hcmQmbmJzcDs8L3N0cm9uZz48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LXNp emU6IDEycHg7Ij48L3NwYW4+PGJyPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTog YXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyI+SVQgSW5mcmFzdHJ1Y3R1cmUgTWFu YWdlcjxicj4gPGEgaHJlZj0iaHR0cDovL21pb3Zpc2lvbi5jb20vIiB0YXJnZXQ9Il9wYXJlbnQi IGRhdGEtbWNlLWhyZWY9Imh0dHA6Ly9taW92aXNpb24uY29tLyI+TWlvdmlzaW9uPC9hPiB8IDxl bT5SZXRoaW5rIFRyYWZmaWM8L2VtPjxicj4gPGEgaHJlZj0idGVsOjUxOS01MTMtMjQwNyIgdGFy Z2V0PSJfcGFyZW50IiBkYXRhLW1jZS1ocmVmPSJ0ZWw6NTE5LTUxMy0yNDA3Ij41MTktNTEzLTI0 MDc8L2E+IGV4LjI1MDxicj4gPGEgaHJlZj0idGVsOjg3Ny02NDYtODQ3NiIgdGFyZ2V0PSJfcGFy ZW50IiBkYXRhLW1jZS1ocmVmPSJ0ZWw6ODc3LTY0Ni04NDc2Ij44NzctNjQ2LTg0NzY8L2E+ICh0 b2xsLWZyZWUpPGJyPiA8YnI+IDxzdHJvbmcgc3R5bGU9ImNvbG9yOiByZ2IoMTUzLCAxNTMsIDE1 Myk7IGZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEzcHg7IiBkYXRh LW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNw eDsgY29sb3I6ICM5OTk5OTk7Ij48YSBocmVmPSJodHRwOi8vbWlvdmlzaW9uLmNvbS9ibG9nIiB0 YXJnZXQ9Il9wYXJlbnQiIGRhdGEtbWNlLWhyZWY9Imh0dHA6Ly9taW92aXNpb24uY29tL2Jsb2ci PkJsb2c8L2E+Jm5ic3A7IHwgJm5ic3A7PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io MTUzLCAxNTMsIDE1Myk7IGZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6 IDEzcHg7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTNweDsgY29sb3I6ICM5OTk5OTk7Ij48c3Ryb25nPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmxpbmtlZGluLmNvbS9jb21wYW55L21pb3Zpc2lvbi10ZWNobm9sb2dpZXMiIHRhcmdldD0i X3BhcmVudCIgZGF0YS1tY2UtaHJlZj0iaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkv bWlvdmlzaW9uLXRlY2hub2xvZ2llcyI+TGlua2VkSW48L2E+Jm5ic3A7Jm5ic3A7fCAmbmJzcDs8 YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL21pb3Zpc2lvbiIgdGFyZ2V0PSJfcGFyZW50IiBk YXRhLW1jZS1ocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL21pb3Zpc2lvbiI+VHdpdHRlcjwvYT4m bmJzcDsmbmJzcDt8ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9taW92 aXNpb24iIHRhcmdldD0iX3BhcmVudCIgZGF0YS1tY2UtaHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJv b2suY29tL21pb3Zpc2lvbiI+RmFjZWJvb2s8L2E+PC9zdHJvbmc+PC9zcGFuPiA8L3NwYW4+PGhy IHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBjbGVhcjogYm90aDsgZm9udC1mYW1pbHk6 IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsiIGRhdGEtbWNlLXN0eWxlPSJmb250 LWZhbWlseTogYXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBjb2xvcjogIzMzMzMz MzsgY2xlYXI6IGJvdGg7Ij48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDE1MywgMTUzLCAxNTMpOyBw YWRkaW5nLXRvcDogNXB4OyBmb250LWZhbWlseTogYXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxM3B4OyIgZGF0YS1tY2Utc3R5bGU9ImNvbG9yOiAjOTk5OTk5OyBmb250LWZhbWlseTogYXJp YWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBwYWRkaW5nLXRvcDogNXB4OyI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IiBk YXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJweDsiPk1pb3Zpc2lvbiBUZWNobm9sb2dpZXMgSW5jLiB8IDE0OCBNYW5pdG91IERyaXZlLCBT dWl0ZSAxMDEsIEtpdGNoZW5lciwgT04sIENhbmFkYSB8Jm5ic3A7TjJDIDFMMzwvc3Bhbj48YnI+ IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx MnB4OyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCxzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHg7Ij5UaGlzIGUtbWFpbCBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlz IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoZSBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48YnI+PGRp dj48YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgSmFuIDIzLCAyMDE0 IGF0IDQ6MjQgUE0sIEl0YW1hciBIZWltIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFp bHRvOmloZWltQHJlZGhhdC5jb20iIHRhcmdldD0iX3BhcmVudCIgZGF0YS1tY2UtaHJlZj0ibWFp bHRvOmloZWltQHJlZGhhdC5jb20iPmloZWltQHJlZGhhdC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4 IDBweCAwcHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyBib3JkZXItbGVmdC1jb2xvcjogcmdi KDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHls ZTogc29saWQ7IiBkYXRhLW1jZS1zdHlsZT0ibWFyZ2luOiAwIDAgMCAuOGV4OyBib3JkZXItbGVm dDogMXB4ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdj5PbiAwMS8yMy8yMDE0 IDA3OjQ2IFBNLCBTdGV2ZSBEYWluYXJkIHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6 IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQt d2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyIgZGF0YS1tY2Utc3R5bGU9Im1h cmdpbjogMCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6IDFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxl ZnQ6IDFleDsiPkJhY2tpbmcgU3RvcmFnZTogR2x1c3RlciBSZXBsaWNhPGJyPiBTdG9yYWdlIERv bWFpbjogTkZTPGJyPiBPdmlydCBIb3N0czogQ2VudE9TIDYuNTxicj4gT3ZpcnQgdmVyc2lvbjog My4zLjI8YnI+IE5ldHdvcms6IEdpZ0U8YnI+ICMgb2YgVk0nczogMyAtIHR3byBMaW51eCBndWVz dHMgYXJlIGlkbGUsIG9uZSBXaW5kb3dzIGd1ZXN0IGlzPGJyPiBpbnN0YWxsaW5nIHVwZGF0ZXMu PGJyPiA8YnI+IEkndmUgaW5zdGFsbGVkIGEgV2luZG93cyAyMDA4IFIyIGd1ZXN0IHdpdGggdmly dGlvIGRpc2ssIGFuZCBhbGwgdGhlPGJyPiBkcml2ZXJzIGZyb20gdGhlIGxhdGVzdCB2aXJ0aW8g aXNvLiBJJ3ZlIGFsc28gaW5zdGFsbGVkIHRoZSBzcGljZSBhZ2VudDxicj4gZHJpdmVycy48YnI+ IDxicj4gR3Vlc3QgZGlzayBhY2Nlc3MgaXMgaG9ycmlibHkgc2xvdywgUmVzb3VyY2UgbW9uaXRv ciBkdXJpbmcgV2luZG93czxicj4gdXBkYXRlcyBzaG93cyBEaXNrIHBlYWtpbmcgYXQgMU1CL3Nl YyAoc2NhbGUgbmV2ZXIgaW5jcmVhc2VzKSBhbmQgRGlzazxicj4gUXVldWUgTGVuZ3RoIFBlYWtp bmcgYXQgNSBhbmQgbG9va3MgdG8gYmUgc2l0dGluZyBhdCB0aGF0IGxldmVsIDk5JSBvZjxicj4g dGhlIHRpbWUuIDExMyB1cGRhdGVzIGluIFdpbmRvd3MgaGFzIGJlZW4gcnVubmluZyBzb2xpZGx5 IGZvciBhYm91dCAyLjU8YnI+IGhvdXJzIGFuZCBpcyBhdCA4OS8xMTMgdXBkYXRlcyBjb21wbGV0 ZS48YnI+PC9ibG9ja3F1b3RlPjxicj48L2Rpdj52aXJ0aW8tYmxvY2sgb3IgdmlydGlvLXNjc2k/ PGJyPiB3aGljaCB3aW5kb3dzIGd1ZXN0IGRyaXZlciB2ZXJzaW9uIGZvciB0aGF0Pzxicj4gPGJy PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAw cHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwg MjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29s aWQ7IiBkYXRhLW1jZS1zdHlsZT0ibWFyZ2luOiAwIDAgMCAuOGV4OyBib3JkZXItbGVmdDogMXB4 ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdj48YnI+IEkgY2FuJ3Qgc2F5IG15 IExpbnV4IGd1ZXN0cyBhcmUgYmxpc3RlcmluZ2x5IGZhc3QsIGJ1dCB1cGRhdGluZyBhIGd1ZXN0 PGJyPiBmcm9tIFJIRUwgNi4zIGZyZXNoIGluc3RhbGwgdG8gNi41IHRvb2sgYWJvdXQgMjUgbWlu dXRlcy48YnI+IDxicj4gSWYgYW55b25lIGhhcyBhbnkgaWRlYXMsIHBsZWFzZSBsZXQgbWUga25v dyAtIEkgaGF2ZW4ndCBmb3VuZCBhbnkgdHVuaW5nPGJyPiBkb2NzIGZvciBXaW5kb3dzIGd1ZXN0 cyB0aGF0IGNvdWxkIGV4cGxhaW4gdGhpcyBpc3N1ZS48YnI+IDxicj4gVGhhbmtzLDxicj4gPGJy PiA8YnI+PC9kaXY+KlN0ZXZlIERhaW5hcmQgKjxicj4gPGJyPiA8YnI+IDxicj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgZGF0YS1tY2Utc3R5bGU9InRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+PC9zcGFu Pl9fX19fX19fX19fX19fX19fPGJyPiBVc2VycyBtYWlsaW5nIGxpc3Q8YnI+IDxhIGhyZWY9Im1h aWx0bzpVc2Vyc0BvdmlydC5vcmciIHRhcmdldD0iX3BhcmVudCIgZGF0YS1tY2UtaHJlZj0ibWFp bHRvOlVzZXJzQG92aXJ0Lm9yZyI+VXNlcnNAb3ZpcnQub3JnPC9hPjxicj4gPGEgaHJlZj0iaHR0 cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIiB0YXJnZXQ9Il9wYXJl bnQiIGRhdGEtbWNlLWhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5m by91c2VycyI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy88c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7IiBkYXRhLW1jZS1zdHlsZT0idGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7Ij48L3NwYW4+bWFpbG1hbi9saXN0aW5mby91c2VyczwvYT48YnI+IDxicj48L2Jsb2NrcXVv dGU+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PGJyPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlVzZXJzIG1haWxpbmcgbGlzdDxicj48 YSBocmVmPSJtYWlsdG86VXNlcnNAb3ZpcnQub3JnIiB0YXJnZXQ9Il9wYXJlbnQiIGRhdGEtbWNl LWhyZWY9Im1haWx0bzpVc2Vyc0BvdmlydC5vcmciPlVzZXJzQG92aXJ0Lm9yZzwvYT48YnI+PGEg aHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIiB0YXJn ZXQ9Il9wYXJlbnQiIGRhdGEtbWNlLWhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1h bi9saXN0aW5mby91c2VycyI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZv L3VzZXJzPC9hPjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJyPjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi0tIDxicj48L2Rpdj48ZGl2PjxzcGFuPjwvc3Bhbj5TYW5q YXkgUmFvIDxicj5QcmluY2lwYWwgUGVyZm9ybWFuY2UgRW5naW5lZXIgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGhvbmU6IDk3 OC0zOTItMjQ3OSA8YnI+UmVkIEhhdCwgSW5jLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZBWDogOTc4LTM5Mi0xMDAx IDxicj4zMTQgTGl0dGxldG9uIFJvYWQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRW1haWw6IHNyYW9AcmVkaGF0LmNvbSA8YnI+V2VzdGZvcmQsIE1BIDAx ODg2IDxzcGFuPjwvc3Bhbj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+CjwvYm9keT4KPC9o dG1sPgo= --_7268CB10-E597-419C-B2BE-EEC079156B7D_-- --_9a4ce072-90af-4283-8756-2cce79d93e12_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users --_9a4ce072-90af-4283-8756-2cce79d93e12_--

6 13

[Users] Unable to log on with expired passord
by Sigbjorn Lie 01 Feb '14

01 Feb '14

Hi, I am doing a POC of RHEV 3.2 VDI for a customer. Their users are located in an IPA server, and RHEV and IPA has been connected using rhevm-manage-domains. During the POC we discovered that users which have expired password cannot log on. They receive an Incorrect password error message. 1. They should at least receive a Your password has expired error instead of the Incorrect password error message as this is confusing for the user. 2. This creates a problem, as every time a password is reset in IPA, it's automatically set to be expired so the user will change password at next logon. Is there a way around this? I would like to see the user being able to log on the User Portal with the expired password, and then he will be asked to change his password as usual once he's logging into his Linux VDI machine. Regards, Siggi

2 6