LVM structure
by Nicolas Ecarnot
Hello,
I'm still coping with my qemu image corruption, and I'm following some
Redhat guidelines that explains the way to go :
- Start the VM
- Identify the host
- On this host, run the ps command to identify the disk image location :
# ps ax|grep qemu-kvm|grep vm_name
- Look for "-drive
file=/rhev/data-center/00000001-0001-0001-0001-00000000033e/b72773dc-c99c-472a-9548-503c122baa0b/images/91bfb2b4-5194-4ab3-90c8-3c172959f712/e7174214-3c2b-4353-98fd-2e504de72c75"
(YMMV)
- Resolve this symbolic link
# ls -la
/rhev/data-center/00000001-0001-0001-0001-00000000033e/b72773dc-c99c-472a-9548-503c122baa0b/images/91bfb2b4-5194-4ab3-90c8-3c172959f712/e7174214-3c2b-4353-98fd-2e504de72c75
lrwxrwxrwx 1 vdsm kvm 78 3 oct. 2016
/rhev/data-center/00000001-0001-0001-0001-00000000033e/b72773dc-c99c-472a-9548-503c122baa0b/images/91bfb2b4-5194-4ab3-90c8-3c172959f712/e7174214-3c2b-4353-98fd-2e504de72c75
->
/dev/b72773dc-c99c-472a-9548-503c122baa0b/e7174214-3c2b-4353-98fd-2e504de72c75
- Shutdown the VM
- On the SPM, activate the logical volume :
# lvchange -ay
/dev/b72773dc-c99c-472a-9548-503c122baa0b/e7174214-3c2b-4353-98fd-2e504de72c75
- Verify the state of the qemu image :
# qemu-img check
/dev/b72773dc-c99c-472a-9548-503c122baa0b/e7174214-3c2b-4353-98fd-2e504de72c75
- If needed, attempt a repair :
# qemu-img check -r all /dev/...
- In any case, deactivate the LV :
# lvchange -an /dev/...
I followed this steps tens of times, and finding the LV and activating
it was obvious and successful.
Since yesterday, I'm finding some VMs one which these steps are not
working : I can identify the symbolic link, but the SPM neither the host
are able to find the LV device, thus can not LV-activate it :
# lvchange -ay
/dev/de2fdaa0-6e09-4dd2-beeb-1812318eb893/ce13d349-151e-4631-b600-c42b82106a8d
Failed to find logical volume
"de2fdaa0-6e09-4dd2-beeb-1812318eb893/ce13d349-151e-4631-b600-c42b82106a8d"
Either I need two more coffees, either I may be missing a step or
something to check.
Looking at the SPM /dev/disk/* structure, it looks like very sound (I
can see my three storage domains dm-name-* series of links).
As the VM can nicely be ran and stopped, does the host activates
something more before being launched?
--
Nicolas ECARNOT
7 years, 1 month
ovirt-node iso installs non-bootable OS
by Guillaume
----=_RainLoop_127_572554114.1507153165
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hello,=0A=0AI'm new to ovirt, I try it for the first time.=0AI downloaded=
the iso ovirt-node-ng-installer-ovirt-4.1-2017100406.iso (http://jenkins=
.ovirt.org/job/ovirt-node-ng_ovirt-4.1_build-artifacts-el7-x86_64/lastSuc=
cessfulBuild/artifact/exported-artifacts/ovirt-node-ng-installer-ovirt-4.=
1-2017100406.iso)=0A=0AI installed it twice, but each time I have the sam=
e problem.=0AWhen I reboot the PC after the install I can't start the OS,=
I have the following error:=0A=0AFailed to open EFIcentosgrubx64.efi - N=
ot Found=0AFailed to load image EFIcentosgrubx64.efi: Not Found=0Astart_i=
mage() returned Not Found=0A=0AAm I the only one to have this error ?=0A=
=0AIs there a way to solve this issue with the rescue iso choice ? or can=
I download an older iso ?=0A=0AThanks,=0A=0AGuillaume
----=_RainLoop_127_572554114.1507153165
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html; charset=3Dutf-8" /></head><body><div data-html-editor-font-wrap=
per=3D"true" style=3D"font-family: arial, sans-serif; font-size: 13px;"><=
div><div><div style=3D"font-family: arial, sans-serif;font-size: 13px">He=
llo,<br><br>I'm new to ovirt, I try it for the first time.<br>I downloade=
d the iso <a href=3D"http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.1=
_build-artifacts-el7-x86_64/lastSuccessfulBuild/artifact/exported-artifac=
ts/ovirt-node-ng-installer-ovirt-4.1-2017100406.iso">ovirt-node-ng-instal=
ler-ovirt-4.1-2017100406.iso</a><br><br>I installed it twice, but each ti=
me I have the same problem.<br>When I reboot the PC after the install I c=
an't start the OS, I have the following error:<br><br>Failed to open \EFI=
\centos\grubx64.efi - Not Found<br>Failed to load image \EFI\centos\grubx=
64.efi: Not Found<br>start_image() returned Not Found<br><br>Am I the onl=
y one to have this error ?<br><br>Is there a way to solve this issue with=
the rescue iso choice ? or can I download an older iso ?<br><br>Thanks,<=
br><br>Guillaume<br><signature></signature> </div></div></div></div></bod=
y></html>
----=_RainLoop_127_572554114.1507153165--
7 years, 1 month
Gluster Performance
by Bryan Sockel
Is there any performance loss from your if your gluster replica 3 servers
are not all the same configuration?
Server 1 - Primary
16 X 1.2 TB 10k Drives - Raid 10 - Stripe 256k (2.5 Drives)
1 CPU - Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz
64 GB Memory
Server 2 - Replica
8 X 6 TB 7.5 RPM Drives - Raid 10 - Trip 512 (3.5)
1 CPU - Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz
16 GB Memory
Server 3 - Arbiter (Also Virtual machine node)
2 X 1.2 TB 10k Drives Raid 10
2 CPU - Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
192 GB Memory
Thanks
7 years, 1 month
Ovirt causing strange network issues?
by Derek Atkins
Hi,
I'm at my wits end so I'm tossing this here in the hopes that SOMEONE
will be able to help me.
tl;dr: Ovirt is doing something on my network that is causing my fiber
modem to go from 3-5ms to 300-1000+ms round trip times. I know it's
ovirt because when I unplug ovirt from my network the issue goes away;
when I plug it back in, the issue recurs.
Long version:
I've been running Ovirt 4.0.6 happily on CentOS 7.3 for several months
on a single host machine. Indeed, the host had an uptime of 200+ days
and was working great until approximately midnight, September 21/22
(just over a week ago). I was on an airplane halfway across the
Atlantic at that time, so it wasn't anything I did.
My network is configured as:
fiber modem <-> edgerouter <-> switch <-> everything else
ovirt is living in the "everything else" area.
When I sit with a laptop connected to either the everything else range
or even directly connected to the fiber modem, I run 'mtr' and see
network times (starting at the fiber modem) that bounce all over the
place. When I unplug ovirt I see consistent 3-5ms times. Plug it back
in, voom, back up to badness.
I've spent several hours plugging and unplugging different devices
trying to isolate the issue. The only "device" that has any effect is
my ovirt box.
I have tried to debug this in several ways, but really the only thing
that seems to have helped at all is shutting down all the VMs and the
hosted engine. Once nothing else is running (but the host itself), only
then does the network seem to return to normal.
I'm really at my wits end on this; I have no idea what is causing this
or what might have changed to cause the issue right at that time. I
also can't imagine what ovirt is doing over the network that could cause
the modem, two physical hops away, to lose its mind in this way. But my
experiementation is definitely showing a direct correlation.
Help!!
-derek
--
Derek Atkins 617-623-3745
derek(a)ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
7 years, 1 month
Question about cold start
by Chris Adams
I have an oVirt cluster that was hard shutdown last night (fire is bad,
and firemen killed the generators for their safety). When it came back
up, it did not start any VMs other than the hosted engine.
Is that expected? I know this is not a normal use case, but is there a
way to set VMs to start on cluster boot?
--
Chris Adams <cma(a)cmadams.net>
7 years, 1 month
Re: [ovirt-users] Ovirt 4.0 and EL 7.4
by Sandro Bonazzola
Il 04 Ott 2017 15:51, "Alan Griffiths" <apgriffiths79(a)gmail.com> ha scritto:
Hi,
Is 4.0 supported/known to work on CentOS 7.4?
I've just tried to upgrade one of the hosts in my lab from 7.3 to 7.4
and now vdsm-network fails to start with
vdsm-tool: libvirt: XML-RPC error : authentication failed: authentication
failed
To even get this far I had to exclude gluster packages as 7.4
introduces 3.8 but ovirt 4.0 repo is still on 3.7.
So, more generally. If I'm on ovirt 4.0, gluster 3.7 and EL 7.3. What
is the best ordering for getting to ovirt 4.1 and EL 7.4?
I would suggest to first upgrade to oVirt 4.1 and then complete the update
to CentOS 7.4
Thanks,
Alan
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7 years, 1 month
Re: [ovirt-users] How to import a qcow2 disk into ovirt
by Martín Follonier
Hi,
I've done all the recommendations in this thread, and I'm still getting the
"Paused by System" message just after the transfer starts.
Honestly I don't know were else to look at, cause I don't find any log
entry or packet capture that give me a hint about what is happening.
I'll appreciate any help! Thank you in advance!
Regards
Martin
On Thu, Sep 1, 2016 at 5:01 PM, Amit Aviram <aavi...(a)redhat.com> wrote:
> You can do both,
> Through the database, the table is "vdc_options". change "option_value"
> where "option_name" = 'ImageProxyAddress' .
>
> On Thu, Sep 1, 2016 at 4:56 PM, Gianluca Cecchi <gianluca.cec...(a)gmail.com
> > wrote:
>
>> On Thu, Sep 1, 2016 at 3:53 PM, Amit Aviram <aavi...(a)redhat.com> wrote:
>>
>>> You can just replace this value in the DB and change it to the right
>>> FQDN, it is a config value named "ImageProxyAddress". replace "localhost"
>>> with the right address (notice that the port is there too).
>>>
>>> If this will keep happen after users will have the latest version, we
>>> will have to open a bug and fix whatever causes the URL to be "localhost".
>>>
>>>
>> Do you mean through "engine-config" or directly into database?
>> In this second case which is the table involved?
>>
>> Gianluca
>>
>
>
[root@ractorshe bin]# systemctl stop ovirt-imageio-proxy
engine=# select * from vdc_options where option_name='ImageProxyAddress';
option_id | option_name | option_value | version
-----------+-------------------+-----------------+---------
950 | ImageProxyAddress | localhost:54323 | general
(1 row)
engine=# update vdc_options set option_value='ractorshe.mydomain:54323'
where option_name='ImageProxyAddress';
UPDATE 1
engine=# select * from vdc_options where option_name='ImageProxyAddress';
option_id | option_name | option_value |
version
-----------+-------------------+--------------------------------------+---------
950 | ImageProxyAddress | ractorshe.mydomain:54323 | general
(1 row)
engine=#
engine=# select * from vdc_options where option_name='ImageProxyAddress';
option_id | option_name | option_value |
version
-----------+-------------------+--------------------------------------+---------
950 | ImageProxyAddress | ractorshe.mydomain:54323 | general
(1 row)
systemctl stop ovirt-engine
(otherwise it remained localhost)
systemctl start ovirt-engine
systemctl start ovirt-imageio-proxy
Now transfer is ok.
I tried a qcow2 disck configured as 40Gb but containing about 1.6Gb of data.
I'm going to connect it to a VM and see if all is ok also from a contents
point of view.
Gianluca
_______________________________________________
Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
7 years, 1 month
oVirt Hosted Engine Backup and Restore guide
by Alexander Vrublevskiy
----ALT--yzweeHoec3G1pTHJaNdlhSvadlSkYjRQ1507035192
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
CkhlbGxvIENvbW11bml0eSEKCkknbSBsb29raW5nIGZvciBpbmZvcm1hdGlvbiBhYm91dCBIb3N0
ZWQgRW5naW5lIGJhY2t1cCBhbmQgcmVzdG9yZSBwcm9jZWR1cmVzLiBUaGVyZSdzIEhFIGhvdy10
byB3aGljaCByZWZlcnMgdG8gb1ZpcnQgSG9zdGVkIEVuZ2luZSBCYWNrdXAgYW5kIFJlc3RvcmUg
Z3VpZGU6Cmh0dHBzOi8vd3d3Lm92aXJ0Lm9yZy9kb2N1bWVudGF0aW9uL2hvdy10by9ob3N0ZWQt
ZW5naW5lLyNob3N0ZWQtZW5naW5lLWJhY2t1cC1hbmQtcmVzdG9yZSDCoAoKYnV0IHRoZSBsaW5r
IGxlYWRzIHRvIDQwNCBlcnJvci4KCkNvdWxkIGFueW9uZSBwcm92aWRlIHdvcmtpbmcgbGluayB0
byB0aGUgZG9jdW1lbnQsIHBsZWFzZT8KCkFuZCB0aGUgbWFpbiBwb2ludCB3aHkgSSdtIGxvb2tp
bmcgZm9yIGl0IGlzIEhFIG1pZ3JhdGlvbjogd2UgbmVlZCB0byBtb3ZlIEhFIHRvIGFub3RoZXIg
ZGF0YSBjZW50ZXIuIEl0J2QgYmUgYXdlc29tZSBpZiBzb21lb25lIGNvdWxkIHNoYXJlIGV4cGVy
aWVuY2Ugb2Ygc3VjaCBtaWdyYXRpb24gb3IgYXQgbGVhc3QgcG9pbnQgdGhlIGRpcmVjdGlvbiB0
byBleHBsb3JlLgoKVGhhbmtzIGluIGFkdmFuY2UhClJlZ2FyZHMKQWxleAo=
----ALT--yzweeHoec3G1pTHJaNdlhSvadlSkYjRQ1507035192
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
CjxIVE1MPjxCT0RZPjxwPkhlbGxvIENvbW11bml0eSE8YnI+PGJyPkknbSBsb29raW5nIGZvciBp
bmZvcm1hdGlvbiBhYm91dCBIb3N0ZWQgRW5naW5lIGJhY2t1cCBhbmQgcmVzdG9yZSBwcm9jZWR1
cmVzLiBUaGVyZSdzIEhFIGhvdy10byB3aGljaCByZWZlcnMgdG8gb1ZpcnQgSG9zdGVkIEVuZ2lu
ZSBCYWNrdXAgYW5kIFJlc3RvcmUgZ3VpZGU6PGJyIGRhdGEtbWNlLWJvZ3VzPSIxIj48L3A+PHA+
PGEgaHJlZj0iaHR0cHM6Ly93d3cub3ZpcnQub3JnL2RvY3VtZW50YXRpb24vaG93LXRvL2hvc3Rl
ZC1lbmdpbmUvI2hvc3RlZC1lbmdpbmUtYmFja3VwLWFuZC1yZXN0b3JlIj5odHRwczovL3d3dy5v
dmlydC5vcmcvZG9jdW1lbnRhdGlvbi9ob3ctdG8vaG9zdGVkLWVuZ2luZS8jaG9zdGVkLWVuZ2lu
ZS1iYWNrdXAtYW5kLXJlc3RvcmU8L2E+Jm5ic3A7PGJyPjxicj5idXQgdGhlIGxpbmsgbGVhZHMg
dG8gNDA0IGVycm9yLjxicj48YnI+Q291bGQgYW55b25lIHByb3ZpZGUgd29ya2luZyBsaW5rIHRv
IHRoZSBkb2N1bWVudCwgcGxlYXNlPzxicj48YnI+QW5kIHRoZSBtYWluIHBvaW50IHdoeSBJJ20g
bG9va2luZyBmb3IgaXQgaXMgSEUgbWlncmF0aW9uOiB3ZSBuZWVkIHRvIG1vdmUgSEUgdG8gYW5v
dGhlciBkYXRhIGNlbnRlci4gSXQnZCBiZSBhd2Vzb21lIGlmIHNvbWVvbmUgY291bGQgc2hhcmUg
ZXhwZXJpZW5jZSBvZiBzdWNoIG1pZ3JhdGlvbiBvciBhdCBsZWFzdCBwb2ludCB0aGUgZGlyZWN0
aW9uIHRvIGV4cGxvcmUuPGJyPjxicj5UaGFua3MgaW4gYWR2YW5jZSE8YnI+PC9wPjxwPlJlZ2Fy
ZHM8YnI+QWxleDxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9wPjwvQk9EWT48L0hUTUw+Cg==
----ALT--yzweeHoec3G1pTHJaNdlhSvadlSkYjRQ1507035192--
7 years, 1 month
