missing disk after storage domain expansion
by Andrea Ghelardi
Hi gentlemen,
I recently found an error on 1 of my storages: it was complaining about no
free space but the VM was running and disk operational.
Since I needed to perform some maintenance on the VM, I shut it down and at
restart VM couldn’t boot up properly.
Checked VM via console and a disk was missing. Edited fstab (luckily this
disk was not root but heck! It had a Sybase DB on it!) and restarted VM
this time ok.
Since the disk resides on the dstore with no space, I expanded the iSCSI
LUN, then refreshed multipath on hosts, then resized PVs and now ovirt is
showing the correct size (logs do not complain anymore on no free space).
BUUUT
Now disk is missing. It is not shown anymore on Disks tab nor anywhere else.
Problem is that storage shows 214GB occupancy (size of the missing disk) so
data is there but cannot find it anymore.
Logs show original disk creation, errors from the lack of space, refresh of
the storage size and then.... no more references on the disk.
What can I do to find those missing ~210GBs?
Cheers
Andrea Ghelardi
10 years
oVirt newbie
by Fábio Coelho
------=_Part_1122235_111346377.1431721634636
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SGkgRXZlcnlvbmUsIAoKbCdtIGEgU3lzQWRtaW4sIG9sZCB2bXdhcmUgdXNlciwgd2lsbGluZyB0
byBhZHZhbmNlIGluIG9wZW4gc291cmNlIGFsdGVybmF0aXZlcy4gSSBob3BlIEkgY2FuIGhlbHAg
YW5kIGJlIGhlbHBlZCBmb3IgaGVyZSA6RC4gCgpDdXJyZW50bHksIEknbSB0ZXN0aW5nIGEgc2V0
dXAgd2l0aCBvdmlydC1ub2RlLWVsNyBhbmQgYSBjZW50b3M2IGVuZ2luZS1zZXJ2ZXIsIGFuZCBh
dCB0aGUgbW9tZW50LCBhbGwgaXMgZ29pbmcgZmluZSEgCgpDaGVlcnMsIAoKRsOhYmlvIENvZWxo
byAKCgpBdmlzbyBMZWdhbAoKQSBpbmZvcm1hw6fDo28gY29udGlkYSBuZXN0ZSBlLW1haWwgZSBl
bSBzZXVzIGFuZXhvcyBwb2RlIHNlciByZXN0cml0YSwgc2VuZG8gbyBlbWl0ZW50ZSBkZXN0ZSBy
ZXNwb25zw6F2ZWwgcG9yIHNldSBjb250ZcO6ZG8gZSBlbmRlcmXDp2FtZW50by4gU2Ugdm9jw6og
bsOjbyBmb3IgYSBwZXNzb2EgYXV0b3JpemFkYSBhIHJlY2ViZXIgZXN0YSBtZW5zYWdlbSBlIHRl
bmRvIHJlY2ViaWRvIGEgbWVzbWEgcG9yIGVuZ2FubywgZmF2b3IgYXBhZ8OhLWxhIGltZWRpYXRh
bWVudGUuIEEgSkZTQyBjb25zaWRlcmEgb3BpbmnDtWVzLCBjb25jbHVzw7VlcyBlIG91dHJhcyBp
bmZvcm1hw6fDtWVzIG7Do28gb2ZpY2lhaXMgZGUgcmVzcG9uc2FiaWxpZGFkZSBkbyB1c3XDoXJp
byBkZXN0ZSBzZXJ2acOnby4K
------=_Part_1122235_111346377.1431721634636
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWw+PGJvZHk+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMt
c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXYgZGF0YS1tYXJrZXI9
Il9fUVVPVEVEX1RFWFRfXyI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xl
LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1z
dHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog
MTJwdDsgY29sb3I6ICMwMDAwMDA7Ij48ZGl2PkhpIEV2ZXJ5b25lLDxicj48L2Rpdj48YnI+PGRp
dj5sJ20mbmJzcDsgYSBTeXNBZG1pbiwgb2xkIHZtd2FyZSB1c2VyLCB3aWxsaW5nIHRvIGFkdmFu
Y2UgaW4gb3BlbiBzb3VyY2UgYWx0ZXJuYXRpdmVzLiBJIGhvcGUgSSBjYW4gaGVscCBhbmQgYmUg
aGVscGVkIGZvciBoZXJlIDpELjxicj48L2Rpdj48YnI+PGRpdj5DdXJyZW50bHksIEknbSB0ZXN0
aW5nIGEgc2V0dXAgd2l0aCBvdmlydC1ub2RlLWVsNyBhbmQgYSBjZW50b3M2IGVuZ2luZS1zZXJ2
ZXIsIGFuZCBhdCB0aGUgbW9tZW50LCBhbGwgaXMgZ29pbmcgZmluZSE8YnI+PC9kaXY+PGJyPjxk
aXY+Q2hlZXJzLDxicj48L2Rpdj48YnI+PGRpdj5Gw6FiaW8gQ29lbGhvPC9kaXY+PC9kaXY+PC9k
aXY+PGJyPjwvZGl2PjxwPjxicj4KQXZpc28gTGVnYWw8L3A+Cgo8cD5BIGluZm9ybWHDp8OjbyBj
b250aWRhIG5lc3RlIGUtbWFpbCBlIGVtIHNldXMgYW5leG9zIHBvZGUgc2VyIHJlc3RyaXRhLCBz
ZW5kbyBvIGVtaXRlbnRlIGRlc3RlIHJlc3BvbnPDoXZlbCBwb3Igc2V1IGNvbnRlw7pkbyBlIGVu
ZGVyZcOnYW1lbnRvLiBTZSB2b2PDqiBuw6NvIGZvciBhIHBlc3NvYSBhdXRvcml6YWRhIGEgcmVj
ZWJlciBlc3RhIG1lbnNhZ2VtIGUgdGVuZG8gcmVjZWJpZG8gYSBtZXNtYSBwb3IgZW5nYW5vLCBm
YXZvciBhcGFnw6EtbGEgaW1lZGlhdGFtZW50ZS4gQSBKRlNDIGNvbnNpZGVyYSBvcGluacO1ZXMs
IGNvbmNsdXPDtWVzIGUgb3V0cmFzIGluZm9ybWHDp8O1ZXMgbsOjbyBvZmljaWFpcyBkZSByZXNw
b25zYWJpbGlkYWRlIGRvIHVzdcOhcmlvIGRlc3RlIHNlcnZpw6dvLjwvcD48L2JvZHk+PC9odG1s
Pg==
------=_Part_1122235_111346377.1431721634636--
10 years
oVirt Test Day next week on May 27th
by Sandro Bonazzola
Hi,
Just a reminder that next week we're going to have a Test Day on May 27 (postponed 1 day due to collision with 3.5.3 RC2 release).
Maintainers: please update the test day page[1]
Testers: be sure to get your systems ready!
[1] http://www.ovirt.org/OVirt_3.6_Test_Day
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
Possible SELinux problems with ovirt syncronizing networks
by Jeremy Utley
Hello all!
Running ovirt 3.5 on CentOS 7 currently, and running into a little
problem. All my nodes are currently showing the ovirtmgmt network as
unsyncronized. When I try to force them to sync, it fails. Looking at the
/var/log/vdsm/supervdsm.log file on one of the nodes, it looks like it has
to do with SELinux. See:
http://pastebin.com/NX7yetVW
Which contains a dump of the supervdsm.log file when I tried to force
syncronization. Judging from what I'm seeing, after VDSM writes the new
network configuration files to /etc/sysconfig/network-scripts/ifcfg-*, it
attempts to run a selinux.restorecon function against those files. Since
we disable SELinux by default on all our servers, this action is failing
with Errno 61 (see lines 66-71 and 86-91 in the above-mentioned pastebin).
Is this normal? Is ovirt expecting to run with SELinux enabled? Or am I
mis-interpreting this log output?
Thanks for any help or advice you can give me!
Jeremy
10 years
My feedback on network setting after installing OVirt
by John Joseph
Hi All,
Like to give my feedback about how the network interface behaved after OVirt
I have used
CentOS 6.6 64 bit, updated
Ovirt stable from the repo
Now after the installation, and configuration you get "ovirtmgmt" interface and "ovirtmgmt" interface gets the IP address and everything is fine . Now reboot it
result is that when you give ifconfig , eth0 is not displayed and "ovirtmgmt" do not have IP address
This stage solved by giving ifconfig eth0 up
and restarting the network, it will give "ovirtmgmt" an IP now
I tested it using different installation, with DHCP or manual configuration for eth0 , in both the case the same experience
Giving my feedback,
thanks
10 years
ovirt-agent: is it possible to run specific actions when taking snapshots?
by Ernest Beinrohr
This is a multi-part message in MIME format.
--------------000401040808070400080406
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
It would be nice, if ovirt snapshots were more safe. When a VM has the
ovirt-agent installed, ovirt could tell the agent to run site-speficic
actions. What I have in mind is:
linux vms:
- sync
- echo 3 > /proc/sys/vm/drop_caches
- zerofill empty space (this takes long but saves precious backup space)
databases:
- prepare databases for snapshot (flush,write-lock)
- send snapshot-complete and unlock
--
Ernest Beinrohr, AXON PRO
Ing <http://www.beinrohr.sk/ing.php>, RHCE
<http://www.beinrohr.sk/rhce.php>, RHCVA
<http://www.beinrohr.sk/rhce.php>, LPIC
<http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>,
+421-2-62410360 +421-903-482603
--------------000401040808070400080406
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
It would be nice, if ovirt snapshots were more safe. When a VM has
the ovirt-agent installed, ovirt could tell the agent to run
site-speficic actions. What I have in mind is:<br>
<br>
linux vms:<br>
- sync<br>
- echo 3 > /proc/sys/vm/drop_caches<br>
- zerofill empty space (this takes long but saves precious backup
space)<br>
<br>
databases:<br>
- prepare databases for snapshot (flush,write-lock)<br>
- send snapshot-complete and unlock<br>
<br>
<br>
<div class="moz-signature">-- <br>
<div id="oernii_footer" style="color: gray;">
<span style="font-family: Lucida Console, Luxi Mono, Courier,
monospace; font-size: 90%;">
Ernest Beinrohr, AXON PRO<br>
<a style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/ing.php">Ing</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/vca.php">VCA</a>, <br>
+421-2-62410360 +421-903-482603
<br>
</span> </div>
<img
src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk"
moz-do-not-send="true" border="0" height="1" width="1">
</div>
</body>
</html>
--------------000401040808070400080406--
10 years
Live migration qemu 2.1.2 -> 2.1.3: Unknown savevm section
by Markus Stockhausen
------=_NextPartTM-000-9231d65f-462b-4e82-9556-148b260cc199
Content-Type: multipart/alternative;
boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_"
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
don't know what will be the best place for the following question.
So starting with the OVirt mailing list.
We are using OVirt with FC20 nodes with enabled virt-preview.
Thus we are running qemu 2.1.2. Everything is working smoothly
including live merge.
For testing purposes we compiled qemu 2.1.3 from Fedora koji
and updated one of the hosts. Trying to migrate a running VM to
the new host fails with the message
Unknown savevm section or instance 'kvm-tpr-opt' 0
I guess some incompatibility between the versions. But qemu git
history between 2.1.2 and 2.1.3 gives no hints about the reason.
Any ideas - or is that migration scenario not supported at all?
Markus
P.S. start parameters are:
LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AU=
DIO_DRV=3Dspice SPICE_DEBUG_ALLOW_MC=3D1 /usr/bin/qemu-kvm -name vm60 -S -m=
achine pc-1.0,accel=3Dkvm,usb=3Doff
-cpu Nehalem,hv_relaxed -m 4096 -realtime mlock=3Doff -smp 2,maxcpus=3D160,=
sockets=3D160,cores=3D1,threads=3D1 -uuid d2d8bdfd-99a6-41c0-84e7-26e1d6a60=
57b -smbios type=3D1,manufacturer=3DoVirt,product=3DoVirt Node,version=3D20=
-3,serial=3D49434D53-0200-48D6-3000-D6483000EEC8,uuid=3Dd2d8bdfd-99a6-41c0-=
84e7-26e1d6a6057b -no-user-config -nodefaults -chardev socket,id=3Dcharmoni=
tor,path=3D/var/lib/libvirt/qemu/vm60.monitor,server,nowait -mon chardev=3D=
charmonitor,id=3Dmonitor,mode=3Dcontrol -rtc base=3D2014-12-11T16:09:44,dri=
ftfix=3Dslew -global kvm-pit.lost_tick_policy=3Ddiscard -no-shutdown -boot =
strict=3Don -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -dev=
ice virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x5 -device virtio-serial=
-pci,id=3Dvirtio-serial0,bus=3Dpci.0,addr=3D0x6 -drive if=3Dnone,id=3Ddrive=
-ide0-1-0,readonly=3Don,format=3Draw,serial=3D -device ide-cd,bus=3Dide.1,u=
nit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive file=3D/rhev/data-cente=
r/94ed7a19-fade-4bd6-83f2-2cbb2f730b95/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545=
/images/422a4486-6642-41ae-bb1d-b6a955550689/26b4c1e3-faf8-4fb3-b662-da6a55=
a3d8f2,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Draw,serial=3D422a4486-664=
2-41ae-bb1d-b6a955550689,cache=3Dnone,werror=3Dstop,rerror=3Dstop,aio=3Dthr=
eads -device virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x7,drive=3Ddrive=
-virtio-disk0,id=3Dvirtio-disk0,bootindex=3D1 -netdev tap,fd=3D29,id=3Dhost=
net0,vhost=3Don,vhostfd=3D30 -device virtio-net-pci,netdev=3Dhostnet0,id=3D=
net0,mac=3D00:0c:29:7a:94:f1,bus=3Dpci.0,addr=3D0x3,bootindex=3D2 -chardev =
socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/d2d8bdfd-99a=
6-41c0-84e7-26e1d6a6057b.com.redhat.rhevm.vdsm,server,nowait -device virtse=
rialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dchannel0=
,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dcharchannel1,path=3D/var=
/lib/libvirt/qemu/channels/d2d8bdfd-99a6-41c0-84e7-26e1d6a6057b.org.qemu.gu=
est_agent.0,server,nowait -device virtserialport,bus=3Dvirtio-serial0.0,nr=
=3D2,chardev=3Dcharchannel1,id=3Dchannel1,name=3Dorg.qemu.guest_agent.0 -ch=
ardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -device virtserialport,bus=
=3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id=3Dchannel2,name=3Dcom.=
redhat.spice.0 -spice tls-port=3D5901,addr=3DA.B.C.D,x509-dir=3D/etc/pki/vd=
sm/libvirt-spice,tls-channel=3Dmain,tls-channel=3Ddisplay,tls-channel=3Dinp=
uts,tls-channel=3Dcursor,tls-channel=3Dplayback,tls-channel=3Drecord,tls-ch=
annel=3Dsmartcard,tls-channel=3Dusbredir,seamless-migration=3Don -k de -dev=
ice qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,bus=3Dpci.=
0,addr=3D0x2 -device intel-hda,id=3Dsound0,bus=3Dpci.0,addr=3D0x4 -device h=
da-duplex,id=3Dsound0-codec0,bus=3Dsound0.0,cad=3D0 -incoming tcp:[::]:4915=
2 -msg timestamp=3Don
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_
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 type=3D"text/css" id=3D"owaParaStyle"></style>
</head>
<body fpstyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">Hi,
<div><br>
</div>
<div>don't know what will be the best place for the following question.&nbs=
p;</div>
<div>So starting with the OVirt mailing list. </div>
<div><br>
</div>
<div>We are using OVirt with FC20 nodes with enabled virt-preview.</div>
<div><span style=3D"font-size: 10pt;">Thus we are running qemu 2.1.2. =
</span><span style=3D"font-size: 13.3333330154419px;">Everything is working=
smoothly </span></div>
<div><span style=3D"font-size: 13.3333330154419px;">including live merge. &=
nbsp;</span></div>
<div><span style=3D"font-size: 10pt;"><br>
</span></div>
<div><span style=3D"font-size: 10pt;">For testing purposes we compiled =
;</span><span style=3D"font-size: 10pt;">qemu 2.1.3 from Fedora koji</span>=
</div>
<div><span style=3D"font-size: 10pt;">and updated one of the hosts. Trying =
to migrate a running VM to</span></div>
<div><span style=3D"font-size: 10pt;">the new host fails with the message</=
span></div>
<div><span style=3D"font-size: 10pt;"><br>
</span></div>
<div>
<div>Unknown savevm section or instance 'kvm-tpr-opt' 0</div>
<div style=3D"font-size: 10pt;"><br>
</div>
</div>
<div style=3D"font-size: 10pt;">I guess some incompatibility between the ve=
rsions. But qemu git</div>
<div style=3D"font-size: 10pt;">history between 2.1.2 and 2.1.3 gives no hi=
nts about the reason.</div>
<div style=3D"font-size: 10pt;"><br>
</div>
<div style=3D"font-size: 10pt;">Any ideas - or is that migration scenario n=
ot supported at all?</div>
<div style=3D"font-size: 10pt;"><br>
</div>
<div style=3D"font-size: 10pt;">Markus</div>
<div style=3D"font-size: 10pt;"><br>
</div>
<div style=3D"font-size: 10pt;">P.S. start parameters are:</div>
<div style=3D"font-size: 10pt;"><br>
</div>
<div style=3D"font-size: 10pt;">
<div style=3D"font-size: 10pt;">LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/loca=
l/bin:/usr/sbin:/usr/bin <span style=3D"font-size: 10pt;">QEMU_AUDIO_D=
RV=3Dspice SPICE_DEBUG_ALLOW_MC=3D1 </span><span style=3D"font-size: 1=
0pt;">/usr/bin/qemu-kvm -name vm60 -S -machine pc-1.0,accel=3Dkvm,usb=3Doff=
</span></div>
<div style=3D"font-size: 10pt;">-cpu Nehalem,hv_relaxed -m 4096 -realtime m=
lock=3Doff <span style=3D"font-size: 10pt;">-smp 2,maxcpus=3D160,socke=
ts=3D160,cores=3D1,threads=3D1 </span><span style=3D"font-size: 10pt;"=
>-uuid d2d8bdfd-99a6-41c0-84e7-26e1d6a6057b </span><span style=3D"font=
-size: 10pt;">-smbios
type=3D1,manufacturer=3DoVirt,product=3DoVirt Node,</span><span style=3D"f=
ont-size: 10pt;">version=3D20-3,serial=3D49434D53-0200-48D6-3000-D6483000EE=
C8,uuid=3Dd2d8bdfd-99a6-41c0-84e7-26e1d6a6057b -no-user-config -nodefaults =
-chardev socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/vm60.monitor,=
server,nowait
-mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc base=3D2014-12=
-11T16:09:44,driftfix=3Dslew -global kvm-pit.lost_tick_policy=3Ddiscard -no=
-shutdown -boot strict=3Don -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,add=
r=3D0x1.0x2 -device virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x5
-device virtio-serial-pci,id=3Dvirtio-serial0,bus=3Dpci.0,addr=3D0x6 -driv=
e if=3Dnone,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw,serial=3D -devic=
e ide-cd,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive f=
ile=3D/rhev/data-center/94ed7a19-fade-4bd6-83f2-2cbb2f730b95/965ca3b6-4f9c-=
4e81-b6e8-5ed4a9e58545/images/422a4486-6642-41ae-bb1d-b6a955550689/26b4c1e3=
-faf8-4fb3-b662-da6a55a3d8f2,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Draw=
,serial=3D422a4486-6642-41ae-bb1d-b6a955550689,cache=3Dnone,werror=3Dstop,r=
error=3Dstop,aio=3Dthreads
-device virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x7,drive=3Ddrive-vir=
tio-disk0,id=3Dvirtio-disk0,bootindex=3D1 -netdev tap,fd=3D29,id=3Dhostnet0=
,vhost=3Don,vhostfd=3D30 -device virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0=
,mac=3D00:0c:29:7a:94:f1,bus=3Dpci.0,addr=3D0x3,bootindex=3D2 -chardev
socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/d2d8bdfd-99=
a6-41c0-84e7-26e1d6a6057b.com.redhat.rhevm.vdsm,server,nowait -device virts=
erialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dchannel=
0,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dcharchannel1,path=3D/va=
r/lib/libvirt/qemu/channels/d2d8bdfd-99a6-41c0-84e7-26e1d6a6057b.org.qemu.g=
uest_agent.0,server,nowait
-device virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel=
1,id=3Dchannel1,name=3Dorg.qemu.guest_agent.0 -chardev spicevmc,id=3Dcharch=
annel2,name=3Dvdagent -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,=
chardev=3Dcharchannel2,id=3Dchannel2,name=3Dcom.redhat.spice.0
-spice tls-port=3D5901,addr=3DA.B.C.D,x509-dir=3D/etc/pki/vdsm/libvirt-spi=
ce,tls-channel=3Dmain,tls-channel=3Ddisplay,tls-channel=3Dinputs,tls-channe=
l=3Dcursor,tls-channel=3Dplayback,tls-channel=3Drecord,tls-channel=3Dsmartc=
ard,tls-channel=3Dusbredir,seamless-migration=3Don -k de
-device qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,bus=
=3Dpci.0,addr=3D0x2 -device intel-hda,id=3Dsound0,bus=3Dpci.0,addr=3D0x4 -d=
evice hda-duplex,id=3Dsound0-codec0,bus=3Dsound0.0,cad=3D0 -incoming tcp:[:=
:]:49152 -msg timestamp=3Don</span></div>
<div><br>
</div>
</div>
</div>
</body>
</html>
--_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_--
------=_NextPartTM-000-9231d65f-462b-4e82-9556-148b260cc199
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-9231d65f-462b-4e82-9556-148b260cc199--
10 years
status of ovirt 3.5.1 with centos 7.1
by Jason Keltz
Hi.
I wanted to check on the status of ovirt 3.5.1 with CentOS 7.1. I'm
pretty sure the current 3.5.1 engine has problems with CentOS 7.1 (?),
but not sure about vdsm? I know that 3.5.2 will resolve issues with
engine...
(I'm asking because I've kickstarted CentOS 7.1 as a host, and am having
a few problems (eg. unable to talk to power management) and want to
avoid debugging if it's already known to be broken... :)
Thanks!
Jason.
10 years
