[Users] Reimporting storage domains after reinstalling ovirt
by Boudewijn Ector
Hi Guys,
Currently I've got a Centos machine running the latest ovirt-release.
This machine is using a local raid set containing a directory with
ovirt-based VMs from my previous install. The ovirt install is a
completely fresh install, no storage/VMs have been created yet.
What's the best way to reimport those? I might try to create a new
storage domain and copy all old VMs into it (if that works anyway...) ,
or just reimport the old domain from the web-interface.
Does either trick have any advantage, or is there a best practice I
should adhere to?
Cheers,
Boudewijn
10 years, 11 months
Re: [ovirt-users] New VM from template, vm disk creation time very high
by Steve Dainard
Hi
Yes I'm using glusterfs as storage domain, and glusterd is running on the
ovirt nodes.
*Steve *
On Mon, Apr 21, 2014 at 11:46 AM, Ovirt User <ldrt8789(a)gmail.com> wrote:
> hi steve,
>
> are you using bluster fs as storage domain ? if yes, inside compute node
> or you dedicated 2 or more node for GLUSTER ?
>
> Il giorno 21/apr/2014, alle ore 16:00, Steve Dainard <
> sdainard(a)miovision.com> ha scritto:
>
> This may have been lost over the weekend...
>
>
> *Steve*
>
>
> On Thu, Apr 17, 2014 at 1:21 PM, Steve wrote:
>
>> When I create a new vm from a template (centos 6, 20gig thin disk) it
>> takes close to 40 minutes to clone the disk image.
>>
>> Are there any settings that control how much bandwidth the cloning
>> process can use, or how its prioritized? This is brutally slow, and
>> although a quick clone isn't needed often, occasionally when someone is
>> asking for a resource it would be nice to expedite the process.
>>
>> Storage: Gluster replica 2 volume
>> Network: 10gig
>> Ovirt: 3.3.4, Centos 6.5
>>
>> Thanks,
>>
>>
>> *Steve *
>>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
10 years, 11 months
New VM from template, vm disk creation time very high
by Steve Dainard
When I create a new vm from a template (centos 6, 20gig thin disk) it takes
close to 40 minutes to clone the disk image.
Are there any settings that control how much bandwidth the cloning process
can use, or how its prioritized? This is brutally slow, and although a
quick clone isn't needed often, occasionally when someone is asking for a
resource it would be nice to expedite the process.
Storage: Gluster replica 2 volume
Network: 10gig
Ovirt: 3.3.4, Centos 6.5
Thanks,
*Steve*
10 years, 11 months
VDSM Shutdown Scenario
by Neil
Hi guys,
I'm trying to setup the simplest yet safest way of protecting my
guests during an unexpected power outage.
If I'm running ovirt with 3 hosts, and the ovirt-engine machine as
well as the hosts have SNMP UPS monitoring software installed and
configured to shutdown if the UPS starts running out of power, what
would happen to the guests when the hosts commence the shutdown
sequence caused by the UPS software? The ovirt-engine would also be
configured to shutdown during the outage.
Would the guests try to migrate to another host (despite all of the
hosts commencing the shutdown)? Would the guests be paused?
What is the recommended practice to safely protect the VM's ?
Thank you!
Regards.
Neil Wilson.
10 years, 11 months
New host ssh error
by Drew Showers
Hello,
I'm trying to add a 2nd vdsm host in an existing working cluster and host
(host 1). It seems all the service are running (vdsmd, nfs, and network) on
host 2.
When I create the new host, it begins installing packages, but then get the
following error:
"Host Host-2 installation failed. Command returned failure code 1 during
SSH session [user@host]".
I can't seem to find the solution on google. I can ssh into host 2 from the
ovirt engine. I've tried it with iptables on and iptables off.
Any help would be greatly appreciated.
Many thanks,
Drew
10 years, 11 months
[Users] ui plugin problems, cannot read from a file.
by aditya mamidwar
hey, am trying to display the contents of a text file in a java applet as a
ui plugin in ovirt.
The same applet performs successfully when run as a standalone, but fails
to deliver when the it is run through ovirt.
any plausible explanation?
PFA the screenshot of both cases
--
-Aditya Mamidwar
10 years, 11 months
Call for Papers Deadline in Two Weeks: LinuxCon/CloudOpen North America
by Brian Proffitt
Conference: LinuxCon North America
Information: LinuxCon is the only event covering all matters Linux - offering collaboration and education for everyone in the ecosystem from developers and maintainers to sys admins and architects to business executives and community members.
Date: August 20-22, 2014
Location: Chicago, Illinois
Website: http://events.linuxfoundation.org/events/linuxcon-north-america
Call for Papers Deadline: May 2, 2014
Call for Papers URL: http://events.linuxfoundation.org/events/linuxcon-north-america/program/cfp
Conference: CloudOpen North America
Information: CloudOpen is the only conference offering collaboration and education for all matters of open source cloud, from CloudStack to KVM to Xen, Hadoop, Gluster, OpenStack and more.
Date: August 20-22, 2014
Location: Chicago, Illinois
Website: http://events.linuxfoundation.org/events/cloudopen-north-america
Call for Papers Deadline: May 2, 2014
Call for Papers URL: http://events.linuxfoundation.org/events/cloudopen-north-america/program/cfp
--
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC
10 years, 11 months
Re: [ovirt-users] VMs get hang
by Maurice James
----_com.android.email_1034179695696460
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
V2hpY2ggd291bGRudCBtYXR0ZXIgdGhlIG5ldHdvcmsgY29udGVudGlvbiBhbmQgc2xvdyBkaXNr
cywgb3IgdGhlIG1hbmFnZXIgaG9zdGluZyBWTXM/CgoKU2VudCBmcm9tIG15IEdhbGF4eSBTwq5J
SUkKCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogTWljaGFsIFNrcml2
YW5layA8bWljaGFsLnNrcml2YW5la0ByZWRoYXQuY29tPiAKRGF0ZTowNC8xNy8yMDE0ICA1OjUz
IEFNICAoR01ULTA1OjAwKSAKVG86IFl1c3VmaSBNIFIgPHl1c3VmQGdsb2JhbC1hbmFseXRpY3Mu
Y29tPiAKQ2M6IHVzZXJzQG92aXJ0Lm9yZyxNYXVyaWNlIEphbWVzIDxtamFtZXNAbWVkaWEtbm9k
ZS5jb20+IApTdWJqZWN0OiBSZTogW292aXJ0LXVzZXJzXSBWTXMgZ2V0IGhhbmcgCgoKT24gQXBy
IDE1LCAyMDE0LCBhdCAxNDoxOCAsIE1hdXJpY2UgSmFtZXMgPG1qYW1lc0BtZWRpYS1ub2RlLmNv
bT4gd3JvdGU6Cgo+IEZyb20gbXkgZXhwZXJpZW5jZSBpdCBjb3VsZCBiZSB0aGUgZm9sbG93aW5n
LAo+IAo+IE5ldHdvcmsgY29udGVudGlvbgo+IERpc2sgbGF0ZW5jeSAoc2xvdyBkaXNrcykKPiAK
PiBJcyB0aGUgb3ZpcnQgbWFuYWdlciBhbHNvIGEgVk0gaG9zdD8KCnRoYXQgd291bGRuJ3QgbWF0
dGVyLCB0aGUgY29tbXVuaWNhdGlvbiBpcyBiZXR3ZWVuIHRoZSBob3N0IGFuZCBTUElDRSBjbGll
bnQgb25seSwgZW5naW5lIGlzIG5vdCBpbnZvbHZlZC4KCj4gCj4gRnJvbTogIll1c3VmaSBNIFIi
IDx5dXN1ZkBnbG9iYWwtYW5hbHl0aWNzLmNvbT4KPiBUbzogdXNlcnNAb3ZpcnQub3JnCj4gU2Vu
dDogVHVlc2RheSwgQXByaWwgMTUsIDIwMTQgNjoxMjoyNCBBTQo+IFN1YmplY3Q6IFtvdmlydC11
c2Vyc10gVk1zIGdldCBoYW5nCj4gCj4gSGVsbG8gRXZlcnlvbmUsCj7CoCAKPiBJIGhhdmUgb3Zp
cnQgMy4zIHNldHVwIHdpdGggYXJvdW5kIDE1IFZNcyBjcmVhdGVkIGluIGl0LiBXZSBoYXZlIENl
bnRPUzUgb24gdGhpcyBWTS4gVGhlIHVzZXJzIGhhdmUgcHJvYmxlbSBhY2Nlc3NpbmcgdGhlIFZN
cyBhdCB0aW1lcy4gV2hpbGUgdGhleSBhcmUgd29ya2luZyBvbiBjb25zb2xlLCBpdCBqdXN0IGdl
dHMgaGFuZy4gVGhlcmUgaXMgbm8gcmVzcG9uc2UgdG8gdGhlIGtleWJvYXJkLiBIYXZlIGxvb2sg
YXQgdGhlIHJlc291cmNlIHVzYWdlIGR1cmluZyB0aGlzIHRpbWUsIENQVSBhbmQgUkFNIGlzIG5v
cm1hbC4KPsKgIAo+IFRoZSBjbGllbnRzIHVzZXMgdXNlciBwb3J0YWwgdG8gbGF1bmNoIHRoZSBW
TSBmcm9tIEZpcmVmb3guIFNwaWNlIGlzIHVzZWQgZm9yIHJlbW90ZSB2aWV3aW5nLgoKd2hhdCBz
cGljZSBjbGllbnQ/CgpUaGFua3MsCm1pY2hhbAoKPsKgIAo+IERvIGFueW9uZSBoYXZlIGNvbWUg
YWNyb3NzIHRoaXMgaXNzdWUgPyBMb29raW5nIGZvcndhcmQgZm9yIHlvdXIgaGVscC4KPiAKPiBS
ZWdhcmRzLAo+IFl1c3VmCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KPiBVc2VycyBtYWlsaW5nIGxpc3QKPiBVc2Vyc0BvdmlydC5vcmcKPiBodHRw
Oi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMKPiAKPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFVzZXJzIG1haWxpbmcgbGlz
dAo+IFVzZXJzQG92aXJ0Lm9yZwo+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0
aW5mby91c2VycwoK
----_com.android.email_1034179695696460
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5XaGljaCB3b3VsZG50IG1h
dHRlciB0aGUgbmV0d29yayBjb250ZW50aW9uIGFuZCBzbG93IGRpc2tzLCBvciB0aGUgbWFuYWdl
ciBob3N0aW5nIFZNcz88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxk
aXYgc3R5bGU9ImZvbnQtc2l6ZTo5cHg7Y29sb3I6IzU3NTc1NyI+U2VudCBmcm9tIG15IEdhbGF4
eSBTwq5JSUk8L2Rpdj48L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0t
LS0tLS08YnI+RnJvbTogTWljaGFsIFNrcml2YW5layA8bWljaGFsLnNrcml2YW5la0ByZWRoYXQu
Y29tPiA8YnI+RGF0ZTowNC8xNy8yMDE0ICA1OjUzIEFNICAoR01ULTA1OjAwKSA8YnI+VG86IFl1
c3VmaSBNIFIgPHl1c3VmQGdsb2JhbC1hbmFseXRpY3MuY29tPiA8YnI+Q2M6IHVzZXJzQG92aXJ0
Lm9yZyxNYXVyaWNlIEphbWVzIDxtamFtZXNAbWVkaWEtbm9kZS5jb20+IDxicj5TdWJqZWN0OiBS
ZTogW292aXJ0LXVzZXJzXSBWTXMgZ2V0IGhhbmcgPGJyPjxicj48YnI+T24gQXByIDE1LCAyMDE0
LCBhdCAxNDoxOCAsIE1hdXJpY2UgSmFtZXMgJmx0O21qYW1lc0BtZWRpYS1ub2RlLmNvbSZndDsg
d3JvdGU6PGJyPjxicj4mZ3Q7IEZyb20gbXkgZXhwZXJpZW5jZSBpdCBjb3VsZCBiZSB0aGUgZm9s
bG93aW5nLDxicj4mZ3Q7IDxicj4mZ3Q7IE5ldHdvcmsgY29udGVudGlvbjxicj4mZ3Q7IERpc2sg
bGF0ZW5jeSAoc2xvdyBkaXNrcyk8YnI+Jmd0OyA8YnI+Jmd0OyBJcyB0aGUgb3ZpcnQgbWFuYWdl
ciBhbHNvIGEgVk0gaG9zdD88YnI+PGJyPnRoYXQgd291bGRuJ3QgbWF0dGVyLCB0aGUgY29tbXVu
aWNhdGlvbiBpcyBiZXR3ZWVuIHRoZSBob3N0IGFuZCBTUElDRSBjbGllbnQgb25seSwgZW5naW5l
IGlzIG5vdCBpbnZvbHZlZC48YnI+PGJyPiZndDsgPGJyPiZndDsgRnJvbTogIll1c3VmaSBNIFIi
ICZsdDt5dXN1ZkBnbG9iYWwtYW5hbHl0aWNzLmNvbSZndDs8YnI+Jmd0OyBUbzogdXNlcnNAb3Zp
cnQub3JnPGJyPiZndDsgU2VudDogVHVlc2RheSwgQXByaWwgMTUsIDIwMTQgNjoxMjoyNCBBTTxi
cj4mZ3Q7IFN1YmplY3Q6IFtvdmlydC11c2Vyc10gVk1zIGdldCBoYW5nPGJyPiZndDsgPGJyPiZn
dDsgSGVsbG8gRXZlcnlvbmUsPGJyPiZndDsmbmJzcDsgPGJyPiZndDsgSSBoYXZlIG92aXJ0IDMu
MyBzZXR1cCB3aXRoIGFyb3VuZCAxNSBWTXMgY3JlYXRlZCBpbiBpdC4gV2UgaGF2ZSBDZW50T1M1
IG9uIHRoaXMgVk0uIFRoZSB1c2VycyBoYXZlIHByb2JsZW0gYWNjZXNzaW5nIHRoZSBWTXMgYXQg
dGltZXMuIFdoaWxlIHRoZXkgYXJlIHdvcmtpbmcgb24gY29uc29sZSwgaXQganVzdCBnZXRzIGhh
bmcuIFRoZXJlIGlzIG5vIHJlc3BvbnNlIHRvIHRoZSBrZXlib2FyZC4gSGF2ZSBsb29rIGF0IHRo
ZSByZXNvdXJjZSB1c2FnZSBkdXJpbmcgdGhpcyB0aW1lLCBDUFUgYW5kIFJBTSBpcyBub3JtYWwu
PGJyPiZndDsmbmJzcDsgPGJyPiZndDsgVGhlIGNsaWVudHMgdXNlcyB1c2VyIHBvcnRhbCB0byBs
YXVuY2ggdGhlIFZNIGZyb20gRmlyZWZveC4gU3BpY2UgaXMgdXNlZCBmb3IgcmVtb3RlIHZpZXdp
bmcuPGJyPjxicj53aGF0IHNwaWNlIGNsaWVudD88YnI+PGJyPlRoYW5rcyw8YnI+bWljaGFsPGJy
Pjxicj4mZ3Q7Jm5ic3A7IDxicj4mZ3Q7IERvIGFueW9uZSBoYXZlIGNvbWUgYWNyb3NzIHRoaXMg
aXNzdWUgPyBMb29raW5nIGZvcndhcmQgZm9yIHlvdXIgaGVscC48YnI+Jmd0OyA8YnI+Jmd0OyBS
ZWdhcmRzLDxicj4mZ3Q7IFl1c3VmPGJyPiZndDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8
YnI+Jmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+Jmd0OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21h
aWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+Jmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IFVzZXJzIG1haWxpbmcgbGlzdDxi
cj4mZ3Q7IFVzZXJzQG92aXJ0Lm9yZzxicj4mZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFp
bG1hbi9saXN0aW5mby91c2Vyczxicj48YnI+PC9ib2R5Pg==
----_com.android.email_1034179695696460--
10 years, 11 months
Repository ovirt-epel is listed more than once in the configuration
by Jorick Astrego
After upgrading to ovirt-release-11.2.0-1.noarch.rpm through yum, I see
the following message when I use yum update again:
Loaded plugins: fastestmirror, security, versionlock
Repository ovirt-epel is listed more than once in the
configuration
I see two entries referencing ovit-epel in the repos:
/etc/yum.repos.d/ovirt-epel.repo
/etc/yum.repos.d/ovirt-dependencies.repo
Shouldn't one of them get removed during the update?
Kind regards,
Jorick Astrego
Netbulae B.V.
10 years, 11 months
