Re: [Users] Missing CPU features [CPU Name] [Wrong cpu identification]

[Martin Kletzander]

On 12/13/2012 01:14 PM, Pere G. Soria wrote:
> I added Host[gondor] to the oVirt Engine 3.1, after installing  all
> packages.
> Host gondor moved to Non-Operational state as host does not meet the
> cluster's minimum CPU level. Missing CPU features : model_Nehalem
> 
> This Box is a Intel(R) Xeon(TM) CPU 3.00GHz  - Intel Nehalem Family -
> so I modified/added the caps.py (/usr/share/vdsm).
> Line 107-->   def _getCompatibleCpuModels():
>   return ["model_Nehalem"] (this is what i added).
> 
> Now after restart de service the Host status remains UP.
> 
> Can you report it?? To fix this.
> 

Do you have everything enabled in BIOS for the processor (AES, NX)?  I
don't understand what the "Missing CPU features : model_Nehalem"  should
mean, but if you check what features you have in /proc/cpuinfo, most
probably there will be something missing.

Martin

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Missing CPU features [CPU Name] [Wrong cpu identification]

[Martin Kletzander]

On 12/13/2012 03:27 PM, Itamar Heim wrote:
> On 12/13/2012 02:55 PM, Martin Kletzander wrote:
>> On 12/13/2012 01:14 PM, Pere G. Soria wrote:
>>> I added Host[gondor] to the oVirt Engine 3.1, after installing  all
>>> packages.
>>> Host gondor moved to Non-Operational state as host does not meet the
>>> cluster's minimum CPU level. Missing CPU features : model_Nehalem
>>>
>>> This Box is a Intel(R) Xeon(TM) CPU 3.00GHz  - Intel Nehalem Family -
>>> so I modified/added the caps.py (/usr/share/vdsm).
>>> Line 107-->   def _getCompatibleCpuModels():
>>>return ["model_Nehalem"] (this is what i added).
>>>
>>> Now after restart de service the Host status remains UP.
>>>
>>> Can you report it?? To fix this.
>>>
>>
>> Do you have everything enabled in BIOS for the processor (AES, NX)?  I
>> don't understand what the "Missing CPU features : model_Nehalem"  should
>> mean, but if you check what features you have in /proc/cpuinfo, most
>> probably there will be something missing.
>>
> 
> martin - missing CPU feature: model_Nehalem means libvirt didn't report
> nehalem as a support cpu model for this machine.

Oh, OK, thanks for the info.  So I answered properly :)  Let's see if
we'll find out something from the /proc/cpuinfo.  It looks very similar
to those issues mentioned on the libvirt wiki [1] and others often
discussed, so I'm fairly sure that'll be the issue.

[1]
http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_different_model_from_the_hardware_documentation
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] VM migrations failing

[Martin Kletzander]

On 01/30/2013 08:40 PM, Dead Horse wrote:
> The nodes are EL6.3 based.
> 
> Currently installed libvirt packages:
> 
> libvirt-lock-sanlock-0.9.10-21.el6_3.8.x86_64
> libvirt-cim-0.6.1-3.el6.x86_64
> libvirt-0.9.10-21.el6_3.8.x86_64
> libvirt-python-0.9.10-21.el6_3.8.x86_64
> libvirt-client-0.9.10-21.el6_3.8.x86_64
> 
> and qemu packages:
> qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64
> qemu-kvm-tools-0.12.1.2-2.295.el6_3.10.x86_64
> qemu-img-0.12.1.2-2.295.el6_3.10.x86_64
> 
> Thus my presumption here given the above is that virDomainMigrateToURI2 has
> not yet been patched and/or back-ported into the EL6.x libvirt/qemu?
> 

virDomainMigrateToURI2 is supported since 0.9.2, but is there a
possibility the code is requesting direct migration?  That might explain
the message, which is then incorrect; this was fixed in [1].

Martin

[1]
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=3189dfb1636da22d426d2fc07cc9f60304b16c5c

> - DHC
> 
> 
> On Wed, Jan 30, 2013 at 1:28 PM, Dan Kenigsberg  wrote:
> 
>> On Wed, Jan 30, 2013 at 11:04:00AM -0600, Dead Horse wrote:
>>> Engine Build --> Commit: 82bdc46dfdb46b000f67f0cd4e51fc39665bf13b
>>> VDSM Build: --> Commit: da89a27492cc7d5a84e4bb87652569ca8e0fb20e + patch
>>> --> http://gerrit.ovirt.org/#/c/11492/
>>>
>>> Engine Side:
>>> 2013-01-30 10:56:38,439 ERROR
>>> [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo]
>>> (QuartzScheduler_Worker-70) Rerun vm
>> 887d764a-f835-4112-9eda-836a772ea5eb.
>>> Called from vds lostisles
>>> 2013-01-30 10:56:38,506 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand]
>>> (pool-3-thread-49) START, MigrateStatusVDSCommand(HostName = lostisles,
>>> HostId = e042b03b-dd4e-414c-be1a-b2c65ac000f5,
>>> vmId=887d764a-f835-4112-9eda-836a772ea5eb), log id: 6556e75b
>>> 2013-01-30 10:56:38,510 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand]
>>> (pool-3-thread-49) Failed in MigrateStatusVDS method
>>> 2013-01-30 10:56:38,510 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand]
>>> (pool-3-thread-49) Error code migrateErr and error message
>>> VDSGenericException: VDSErrorException: Failed to MigrateStatusVDS,
>> error =
>>> Fatal error during migration
>>> 2013-01-30 10:56:38,511 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand]
>>> (pool-3-thread-49) Command
>>> org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand return
>>> value
>>>  StatusOnlyReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=12,
>>> mMessage=Fatal error during migration]]
>>>
>>>
>>> VDSM Side:
>>> Thread-43670::ERROR::2013-01-30 10:56:37,052::vm::200::vm.Vm::(_recover)
>>> vmId=`887d764a-f835-4112-9eda-836a772ea5eb`::this function is not
>> supported
>>> by the connection driver: virDomainMigrateToURI2
>>> Thread-43670::ERROR::2013-01-30 10:56:37,513::vm::288::vm.Vm::(run)
>>> vmId=`887d764a-f835-4112-9eda-836a772ea5eb`::Failed to migrate
>>> Traceback (most recent call last):
>>>   File "/usr/share/vdsm/vm.py", line 273, in run
>>> self._startUnderlyingMigration()
>>>   File "/usr/share/vdsm/libvirtvm.py", line 504, in
>>> _startUnderlyingMigration
>>> None, maxBandwidth)
>>>   File "/usr/share/vdsm/libvirtvm.py", line 540, in f
>>> ret = attr(*args, **kwargs)
>>>   File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py",
>> line
>>> 111, in wrapper
>>> ret = f(*args, **kwargs)
>>>   File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1103, in
>>> migrateToURI2
>>> if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed',
>>> dom=self)
>>> libvirtError: this function is not supported by the connection driver:
>>> virDomainMigrateToURI2
>>
>> Could it be that you are using an ancient libvirt with no
>> virDomainMigrateToURI2? What are your libvirt and qemu-kvm versions (on
>> both machines)?
>>
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] VM migrations failing

[Martin Kletzander]

On 01/31/2013 10:25 AM, Dan Kenigsberg wrote:
> On Thu, Jan 31, 2013 at 09:43:44AM +0100, Martin Kletzander wrote:
>> On 01/30/2013 08:40 PM, Dead Horse wrote:
>>> The nodes are EL6.3 based.
>>>
>>> Currently installed libvirt packages:
>>>
>>> libvirt-lock-sanlock-0.9.10-21.el6_3.8.x86_64
>>> libvirt-cim-0.6.1-3.el6.x86_64
>>> libvirt-0.9.10-21.el6_3.8.x86_64
>>> libvirt-python-0.9.10-21.el6_3.8.x86_64
>>> libvirt-client-0.9.10-21.el6_3.8.x86_64
>>>
>>> and qemu packages:
>>> qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64
>>> qemu-kvm-tools-0.12.1.2-2.295.el6_3.10.x86_64
>>> qemu-img-0.12.1.2-2.295.el6_3.10.x86_64
>>>
>>> Thus my presumption here given the above is that virDomainMigrateToURI2 has
>>> not yet been patched and/or back-ported into the EL6.x libvirt/qemu?
>>>
>>
>> virDomainMigrateToURI2 is supported since 0.9.2, but is there a
>> possibility the code is requesting direct migration?  That might explain
>> the message, which is then incorrect; this was fixed in [1].
>>
>> Martin
>>
>> [1]
>> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=3189dfb1636da22d426d2fc07cc9f60304b16c5c
> 
> What is "direct migration" exactly, in the context of qemu-kvm?
> 
> We are using p2p migration
> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/libvirtvm.py;h=fe140ecbfac665248e2ad5c4bfaebaf54ab884cc;hb=18c24f7c7c27ac732c4a760caa9524e7319cd47e#l501
> 

OK, so that's not the issue, sorry for the confusion.  I was thinking it
would "somehow" get there.  Direct migration doesn't exist in QEMU at
all, so it seemed weird, but I can't seem to find any other reason for
this failure; will keep searching, though.

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] VM migrations failing

[Martin Kletzander]

On 01/31/2013 11:56 AM, Dan Kenigsberg wrote:
> On Thu, Jan 31, 2013 at 11:08:58AM +0100, Martin Kletzander wrote:
>> On 01/31/2013 10:25 AM, Dan Kenigsberg wrote:
>>> On Thu, Jan 31, 2013 at 09:43:44AM +0100, Martin Kletzander wrote:
>>>> On 01/30/2013 08:40 PM, Dead Horse wrote:
>>>>> The nodes are EL6.3 based.
>>>>>
>>>>> Currently installed libvirt packages:
>>>>>
>>>>> libvirt-lock-sanlock-0.9.10-21.el6_3.8.x86_64
>>>>> libvirt-cim-0.6.1-3.el6.x86_64
>>>>> libvirt-0.9.10-21.el6_3.8.x86_64
>>>>> libvirt-python-0.9.10-21.el6_3.8.x86_64
>>>>> libvirt-client-0.9.10-21.el6_3.8.x86_64
>>>>>
>>>>> and qemu packages:
>>>>> qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64
>>>>> qemu-kvm-tools-0.12.1.2-2.295.el6_3.10.x86_64
>>>>> qemu-img-0.12.1.2-2.295.el6_3.10.x86_64
>>>>>
>>>>> Thus my presumption here given the above is that virDomainMigrateToURI2 
>>>>> has
>>>>> not yet been patched and/or back-ported into the EL6.x libvirt/qemu?
>>>>>
>>>>
>>>> virDomainMigrateToURI2 is supported since 0.9.2, but is there a
>>>> possibility the code is requesting direct migration?  That might explain
>>>> the message, which is then incorrect; this was fixed in [1].
>>>>
>>>> Martin
>>>>
>>>> [1]
>>>> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=3189dfb1636da22d426d2fc07cc9f60304b16c5c
>>>
>>> What is "direct migration" exactly, in the context of qemu-kvm?
>>>
>>> We are using p2p migration
>>> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/libvirtvm.py;h=fe140ecbfac665248e2ad5c4bfaebaf54ab884cc;hb=18c24f7c7c27ac732c4a760caa9524e7319cd47e#l501
>>>
>>
>> OK, so that's not the issue, sorry for the confusion.  I was thinking it
>> would "somehow" get there.  Direct migration doesn't exist in QEMU at
>> all, so it seemed weird, but I can't seem to find any other reason for
>> this failure; will keep searching, though.
> 
> In this case, Dead Horse, would you try to migrate a VM (that you do not
> care much about) using
> virsh -c qemu+tls://hostname/system migrate --p2p dsthost?
> 
> I'd like to see that the problem reproduces this way, too. More of
> libvirtd.log may help. You may want to disable iptables for a moment,
> just to eliminate a common cause of failure.
> 

The error message in this version of libvirt is emitted only in two
cases.  Either the QEMU driver doesn't support peer2peer migration
(which it does) or direct migration was requested (which wasn't) :)

So I agree with Dan, please try to reproduce this without ovirt/vdsm and
let us know (logs [1] will help a lot), because in case nobody fiddled
with anything, this sounds like a bug to me.

Martin

[1] http://libvirt.org/logging.html
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] VM migrations failing

[Martin Kletzander]

On 01/31/2013 07:07 PM, Dead Horse wrote:
> Here is the content exceprt from libvirtd.log for the command: virsh #
> migrate --p2p sl63 qemu+ssh://192.168.1.2/system
> 

Thanks for testing this.  However, this is another problem.  When
migrating p2p, the destination URI must be reachable from the source,
not the client.  That is probably what failed in first place.  Would you
mind trying migrating p2p (and specifying the destination URI that's
reachable from the source host)?  Thanks.

Also, on both hosts the version are the same?

> 2013-01-31 18:02:53.740+: 2832: debug : virDomainFree:2313 :
> dom=0x7f4f88000c80, (VM: name=sl63,
> uuid=887d764a-f835-4112-9eda-836a772ea5eb)
> 2013-01-31 18:02:53.743+: 2831: debug : virDomainLookupByName:2146 :
> conn=0x7f4f8c001d80, name=sl63
> 2013-01-31 18:02:53.743+: 2831: debug : virDomainFree:2313 :
> dom=0x7f4f84002150, (VM: name=sl63,
> uuid=887d764a-f835-4112-9eda-836a772ea5eb)
> 2013-01-31 18:02:53.747+: 2829: debug : virDrvSupportsFeature:1521 :
> conn=0x7f4f8c001d80, feature=4
> 2013-01-31 18:02:53.751+: 2826: debug : virDrvSupportsFeature:1521 :
> conn=0x7f4f8c001d80, feature=6
> 2013-01-31 18:02:53.754+: 2828: debug : virDomainMigratePerform3:6247 :
> dom=0x7f4f7c0d1430, (VM: name=sl63,
> uuid=887d764a-f835-4112-9eda-836a772ea5eb), xmlin=(null) cookiein=(nil),
> cookieinlen=0, cookieout=0x7f4f998cab30, cookieoutlen=0x7f4f998cab3c,
> dconnuri=qemu+ssh://192.168.1.2/system, uri=(null), flags=2, dname=(null),
> bandwidth=0
> 2013-01-31 18:02:53.755+: 2828: debug : qemuMigrationPerform:2821 :
> driver=0x7f4f8c0af820, conn=0x7f4f8c001d80, vm=0x7f4f7c0c7040,
> xmlin=(null), 
> dconnuri=qemu+ssh://192.168.1.2/system<http://3.57.111.32/system>,

Funny how mail clients try to make it "easier" for us and add a link
that makes sense (to them).

[...]

> 
> On Thu, Jan 31, 2013 at 11:27 AM, Dead Horse
> wrote:
> 
>> note ignore the IP diff in the ssh host auth --> copy/paste fail ;)
>> - DHC
>>
>>
>> On Thu, Jan 31, 2013 at 11:25 AM, Dead Horse <
>> deadhorseconsult...@gmail.com> wrote:
>>
>>> Doh, brain fart VDSM is not involved here for the purposed of the needed
>>> test.
>>> Here is my initial whack at it:
>>>
>>> Source Node:
>>>
>>> virsh # list
>>>  IdName   State
>>> 
>>>  1 sl63   running
>>>
>>> virsh # migrate --p2p sl63 qemu+ssh://192.168.1.2/system
>>> error: operation failed: Failed to connect to remote libvirt URI
>>> qemu+ssh://192.168.1.2/system <http://3.57.111.32/system>
>>>
>>> virsh # migrate --live sl63 qemu+ssh://192.168.1.2/system
>>> The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
>>> RSA key fingerprint is e5:1d:b3:e5:38:5f:e1:8b:73:26:9e:15:c8:0a:2d:ac.
>>> Are you sure you want to continue connecting (yes/no)? yes
>>> root@192.168.1.2's password:
>>> Please enter your authentication name: vdsm@ovirt
>>> Please enter your password:
>>>
>>> virsh #
>>>
>>>
>>> Dest Node After migrate --live:
>>> virsh # list
>>>  IdName   State
>>> 
>>>  2 sl63   running
>>>
>>> virsh #
>>>
>>>
>>>
>>> On Thu, Jan 31, 2013 at 10:38 AM, Dead Horse <
>>> deadhorseconsult...@gmail.com> wrote:
>>>
>>>> Shu,
>>>> I build oVirt Engine and vdsm from source myself. The commits I
>>>> indicated are what I built from.I run the engine under FC17 and my nodes
>>>> are running EL6.x respectively.
>>>>
>>>> Dan,
>>>> I reverted VDSM on my two test nodes to an earlier build of VDSM
>>>> (commit:
>>>> c343e1833f7b6e5428dd90f14f7807dca1baa0b4)
>>>> VDSM after the above commit is broken due to commit:
>>>> fc3a44f71d2ef202cff18d7203b9e4165b546621 however when I built and tested
>>>> from master yesterday I did apply a patch I tested for
>>>> ybronhei which fixed that issue.
>>>>
>>>> I will build VDSM from master, today w/ the supervdsm patch and try the
>>>> manual migration you indicated.
>>>>
>>>>  - DHC
>>>>
>>>>
>>>>
>>>> On Thu, Jan 31, 2013 at 4:56 AM, Dan Kenigsberg wrote:
>>>>
>>>>> On 

Re: [Users] VM migrations failing

[Martin Kletzander]

On 02/01/2013 09:29 PM, Dead Horse wrote:
> To test further I loaded up two more identical servers with EL 6.3 and the
> same package versions originally indicated. The difference here is that I
> did not turn these into ovirt nodes. EG: installing VDSM.
> 
> - All configurations were left at defaults on both servers
> - iptables and selinux disabled on both servers
> - verified full connectivty between both servers
> - setup ssh (/root/authorized keys) between the servers --> this turned out
> to be the key!
> 
> Then using syntax found here:
> http://libvirt.org/migration.html#flowpeer2peer
> EG: From the source server I issued the following:
>

So your client equals to the source server, that makes us sure that the
connection is made on the same network for p2p and non-p2p migration.

> virsh migrate --p2p sl63 qemu+ssh://192.168.1.2/system
> 

You're using ssh transport here, but isn't vdsm using tcp or tls?
According to the config file tcp transport is enabled with no
authentication whatsoever...

> It fails in exactly the same way as previously indicated when the
> destination server does not have an ssh rsa pub ID from the source system
> in it's /root/.ssh/authorized_keys file.
> However once the ssh rsa pub ID is in place on the destination system all
> is well and migrations work as expected.
> 

..., which would mean you need no ssh keys when migrating using tcp
transport instead.

Also during p2p migration the source libvirt daemon can't ask you for
the password, but when not using p2p the client is connecting to the
destination, thus being able to ask for the password and/or use
different ssh keys.

But it looks like none of this has anything to do with the problem as:

 1) as you found out, changing vdsm versions makes the problem go
away/appear and

 2) IIUC the first error was "function is not supported by the
connection driver: virDomainMigrateToURI2", but the second one was
"error: operation failed: Failed to connect to remote libvirt URI".

Since I tried finding out why the first error appeared, I probably
misunderstood somewhere in the middle of this thread and am useless
here.  However if I can help from the libvirt POV, I'll follow up this
thread and will see whether there's anything related.

Good luck,
Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] VM migrations failing

[Martin Kletzander]

On 02/03/2013 08:40 AM, Dan Kenigsberg wrote:
> On Fri, Feb 01, 2013 at 11:44:08PM +0100, Martin Kletzander wrote:
>> On 02/01/2013 09:29 PM, Dead Horse wrote:
>>> To test further I loaded up two more identical servers with EL 6.3 and the
>>> same package versions originally indicated. The difference here is that I
>>> did not turn these into ovirt nodes. EG: installing VDSM.
>>>
>>> - All configurations were left at defaults on both servers
>>> - iptables and selinux disabled on both servers
>>> - verified full connectivty between both servers
>>> - setup ssh (/root/authorized keys) between the servers --> this turned out
>>> to be the key!
>>>
>>> Then using syntax found here:
>>> http://libvirt.org/migration.html#flowpeer2peer
>>> EG: From the source server I issued the following:
>>>
>>
>> So your client equals to the source server, that makes us sure that the
>> connection is made on the same network for p2p and non-p2p migration.
>>
>>> virsh migrate --p2p sl63 qemu+ssh://192.168.1.2/system
>>>
>>
>> You're using ssh transport here, but isn't vdsm using tcp or tls?
> 
> It is!
> 

So then testing it with '+ssh' does not help much.  But at least we know
the addresses are reachable.

>> According to the config file tcp transport is enabled with no
>> authentication whatsoever...
>>
>>> It fails in exactly the same way as previously indicated when the
>>> destination server does not have an ssh rsa pub ID from the source system
>>> in it's /root/.ssh/authorized_keys file.
>>> However once the ssh rsa pub ID is in place on the destination system all
>>> is well and migrations work as expected.
>>>
>>
>> ..., which would mean you need no ssh keys when migrating using tcp
>> transport instead.
>>
>> Also during p2p migration the source libvirt daemon can't ask you for
>> the password, but when not using p2p the client is connecting to the
>> destination, thus being able to ask for the password and/or use
>> different ssh keys.
>>
>> But it looks like none of this has anything to do with the problem as:
>>
>>  1) as you found out, changing vdsm versions makes the problem go
>> away/appear and
> 
> I've missed this point. Which version of vdsm makes it go away?
> 

Sorry, I've got it stuck in my head that part of the thread was about
it, but when going through the mail now it makes less sense than before.
 I probably understood that from [1] and maybe some other sentence that
mixed in my head, but was related to the ssh migration.

Sorry for that,
Martin

[1] http://www.mail-archive.com/users@ovirt.org/msg06105.html
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] ovirt reporting wrong cpu family

[Martin Kletzander]

On 02/16/2013 10:02 PM, Itamar Heim wrote:
> On 16/02/2013 22:46, Adrian Gibanel wrote:
>> Yes, I know. I meant a workaround where the processor is detected as
>> SandyBridge.
> 
> Adrian - please provide libvirt version.
> Martin - can you please take a look?

I'm not sure what kind of help I can give here, but let me see.

> Adrian - can you later please wikify this recurring question?
> 

If this is related to libvirt detecting the wrong CPU, we have a short
wiki page [1] for that either, you can link to that in yours (or maybe
it'll help you write it).

[...]
>> On 16/02/2013 18:56, Adrian Gibanel wrote:
>>> I happen to have the same problem in oVirt 3.1 on Fedora.
>>> Any workaround?
>>>
>>> $ sudo vdsClient -s 0 getVdsCaps | grep -i flags ; echo -e -n "\n" ;cat 
>>> /proc/cpuinfo | grep "model name" | head -n 1
>>> cpuFlags = 
>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,popcnt,tsc_deadline_timer,xsave,avx,lahf_lm,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
>>>

At first, let me say that this is very weird CPU detection as according
to these flags, the processor described in here should be "Nehalem".
Could you try running 'virsh -r capabilities' on the host to check what
libvirt reports?

There might be a possible workaround if you want your CPU to be
identified as different model, most probably by editing
'/usr/share/libvirt/cpu_map.xml', but that should be omitted since it
may lead to problems.

[...]
>>> model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz
>>>

And as I see the CPU is SandyBridge, so this should be solved properly
(probably a bug somewhere or very low-level misconfiguration).  Check
[1], maybe some features can get enabled.

Martin

[1]
http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_different_model_from_the_hardware_documentation
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] ovirt reporting wrong cpu family (2nd server)

[Martin Kletzander]

On 03/02/2013 08:46 PM, Itamar Heim wrote:
> On 02/03/2013 18:39, Adrian Gibanel wrote:
>> I've read again the wiki page and as you might ask for it here's the
>> cpuinfo flags output:
>>
>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
>> pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>> xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
>> ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
>> x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb
>> xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
>>
>> If we check the mentioned cpu_max.xml file we find :
>>
>>  
>>
>>
>>
>>
>>
>>
>>
>>  
>>
>> So I suppose that pclmuldq is expected in the flags but it's not
>> there. Isn't it?
> 
> well, it kind of looks like a bug, since you have pclmulqdq (additional
> 'q' in the middle').
> martin?
> 

Hi, this is expected.  While working on these features, the names
sometime change and in this case pclmulqdq is the same as pclmuldq.
Mostly it is referred to it as pclmulqdq, but when this feature was
added in qemu, the name was without the 'q', alias was added later on:

http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02376.html

>> # virsh -r capabilities
>> 
>> 
>> 
>>   
>> ----002590a41888
>> 
>>   x86_64
>>   SandyBridge

But from this output (which I pasted from the older mail, so the
indentation may not fit), I see libvirt is detecting the CPU perfectly
in this case.

>>
>> So I need to add my specific model at hand and trying to infer which
>> are the specific flags for it?
>> Or maybe that needs something more to be hacked in the libvirt code...
>> and thus I should wait for libvirt people to add it? Well, I mean,
>> going to their ML and asking there?
>>
>> Or isn't there any hope for my particular sandbridge cpu?
>>

There definitely is, as mentioned above.  There almost always is, I
remember only one CPU without a chance and that was because the HW
itself really didn't know the function.  Unfortunately, sometimes
(HW-dependant) it really has to be set in BIOS/UEFI.  For some changes
there are utilities, so you don't have to have physical access to the
machine, but as seen from the capabilities, this is not your case.

>> Thank you.
>>
>> - Mensaje original -
>>
>>> De: "Adrian Gibanel" 
>>> Para: users@ovirt.org
>>> CC: "Itamar Heim" , "Jithin Raju"
>>> ,
>>> "Martin Kletzander" 
>>> Enviados: Sábado, 2 de Marzo 2013 17:21:43
>>> Asunto: Re: [Users] ovirt reporting wrong cpu family (2nd server)
>>
>>> This is another server which I have also problems with. I cannot select
>>> SandyBridge as the cpu type.
>>> Still oVirt 3.1 in Fedora 17.
>>
>>> * Tecnology : Sandy Bridge E
>>> * CPU : Intel Xeon E5-1620
>>> * Cores / Threads : 4 / 8
>>> * Frecuency : 3.6GHz / 3.8GHz Turbo Boost
>>
>>> #cpuinfo:
>>> Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
>>
>>> # rpm -qa | grep -E 'vdsm|libvirt' | sort
>>> libvirt-0.9.11.9-1.fc17.x86_64
>>> libvirt-client-0.9.11.9-1.fc17.x86_64
>>> libvirt-daemon-0.9.11.9-1.fc17.x86_64
>>> libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64
>>> libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64
>>> libvirt-lock-sanlock-0.9.11.9-1.fc17.x86_64
>>> libvirt-python-0.9.11.9-1.fc17.x86_64
>>> vdsm-4.10.0-10.fc17.x86_64
>>> vdsm-cli-4.10.0-10.fc17.noarch
>>> vdsm-python-4.10.0-10.fc17.x86_64
>>> vdsm-xmlrpc-4.10.0-10.fc17.noarch
>>
>>> # virsh -r capabilities
>>
>>> 
>>> [...]
>>
>>> - Mensaje original -
>>
>>>> At first, let me say that this is very weird CPU detection as according
>>>> to these flags, the processor described in here should be "Nehalem".
>>>> Could you try running 'virsh -r capabilities' on the host to check what
>>>> libvirt reports?
>>
>>> -- 
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] ovirt reporting wrong cpu family

[Martin Kletzander]

On 03/02/2013 05:07 PM, Adrian Gibanel wrote:
> Sorry for the late answer. I was kind of busy. I reply inline below.
> 
> - Mensaje original - 
> 
>> De: "Martin Kletzander" 
>> Para: "Itamar Heim" 
>> CC: "Adrian Gibanel" , users@ovirt.org, "Jithin
>> Raju" 
>> Enviados: Martes, 19 de Febrero 2013 15:11:05
>> Asunto: Re: [Users] ovirt reporting wrong cpu family
> 
>> On 02/16/2013 10:02 PM, Itamar Heim wrote:
>>> Adrian - can you later please wikify this recurring question?
>>>
> 
>> If this is related to libvirt detecting the wrong CPU, we have a short
>> wiki page [1] for that either, you can link to that in yours (or maybe
>> it'll help you write it).
> Thank you. I'll take a look. More below.
> 
>> [...]
>>>> On 16/02/2013 18:56, Adrian Gibanel wrote:
>>>>> I happen to have the same problem in oVirt 3.1 on Fedora.
>>>>> Any workaround?
>>>>>
>>>>> $ sudo vdsClient -s 0 getVdsCaps | grep -i flags ; echo -e -n "\n" ;cat
>>>>> /proc/cpuinfo | grep "model name" | head -n 1
>>>>> cpuFlags =
>>>>> fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,popcnt,tsc_deadline_timer,xsave,avx,lahf_lm,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,model_coreduo,model_Conroe
>>>>>
> 
>> At first, let me say that this is very weird CPU detection as according
>> to these flags, the processor described in here should be "Nehalem".
>> Could you try running 'virsh -r capabilities' on the host to check what
>> libvirt reports?
> 
> Here you are:
> 
> 
> 
>   
> c090c38a-5202-e211-bbb4-4c72b97c99ed
> 
>   x86_64
>   Nehalem

And it is really Nehalem, so my manual cpu flags hunt was right.  But
this means there is a problem lower than in libvirt.  I'm afraid that
the sentence about the BIOS/UEFI not being your case which I wrote in
http://lists.ovirt.org/pipermail/users/2013-March/012908.html is no
longer true for this server.  The only solution I can come up with right
now is what already once helped for resolving Nehalem-related detection
and it's the link from the wiki page (that was outdated, so I updated it):

http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=TOOL-ASU

but that's applicable for BladeCenters only.  If this is not suitable
for you, I'm afraid you'll have to contact your HW vendor in order to
resolve the CPU issue.

Hope it helps and please keep me posted, I'd like to summarize all the
related info on one place and resolve related bugs (if there are any) so
similar issues go away, because they seem to be appearing more and more
frequently.

Have a nice day,
Martin

[...]
> 
> 
> 
>> There might be a possible workaround if you want your CPU to be
>> identified as different model, most probably by editing
>> '/usr/share/libvirt/cpu_map.xml', but that should be omitted since it
>> may lead to problems.
> Non applicable workaround then. I should have expected it. Ok, I prefer not 
> having additional problems.
> 
>> [...]
>>>>> model name : Intel(R) Core(TM) i3-2130 CPU @ 3.40GHz
>>>>>
> 
>> And as I see the CPU is SandyBridge, so this should be solved properly
>> (probably a bug somewhere or very low-level misconfiguration). Check
>> [1], maybe some features can get enabled.
> 
> The machine is in a datacentre so I doubt I can change any BIOS or UEFI 
> settings.
> 
>> Martin
> 
>> [1]
>> http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_different_model_from_the_hardware_documentation
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] ovirt 3.2 all-in-one setup always fails

[Martin Kletzander]

On 03/12/2013 06:39 PM, Alex Lourie wrote:
> Hi Alex
> 
> On Sun, Mar 10, 2013 at 4:26 PM, Alex Leonhardt 
> wrote:
>> Hi Alex,
>>
>> Regarding the dependencies - libvirtd would not start w/o having
>> messagebus / avahi-daemon installed & running, however, it doesnt seem
>> to come up as an dependency when installing libvirtd (otherwise it
>> would have been installed previously) ?
> 
> wow, that's strange. I haven't seen this before. I suggest opening a bug
> on libvirt anyway.
> 

Do that so we can keep track of that and feel free to let us (me) know
about the bz number.
I know of libvirt having problems to start when compiled with firewalld
and unavailable system dbus.  This was solved by requiring dbus on
fedora-based systems in both rpm's specfile and systemd's init script.
There should be no problem with avahi by default (it is commented in the
config file).  What's the info in libvirtd.log?

>>
>> I read this "solution" on some blog page, and based on that installed
>> avahi-daemon & messagebus + started them, only then libvirtd started
>> up. vdsmd wont tell you it's waiting for libvirtd to start on the
>> console, it'll mention in the log that "it's waiting for libvirtd" and
>> eventually will time out.
> 
> Granted, if these are the required dependencies, then definitely they
> should be installed.
> 
> I will look into this and try to understand what is it about.
> 
>>
>> Thanks,
>> Alex
>>
>> On 03/10/2013 10:19 AM, Alex Lourie wrote: On Fri 08 Mar 2013
>> 04:33:53 PM IST, Alex Leonhardt wrote:

 Also, the there seem to be missing some dependencies for
 - messagebus (service not enabled/started/installed) - avahi-daemon
 (wasnt installed, had to install and start / enable)
 else
 libvirtd   will not start and the setup will fail.



 On 8 March 2013 14:30, Alex Leonhardt >>> > wrote:
 And here from when I tried to use "localhost" as the host / fqdn :

 Installing: AIO: Validating CPU Compatibility... [ DONE
 ] AIO: Adding firewall rules... [ DONE ] Configuring
 oVirt Engine... [ DONE ] Configuring JVM... [ DONE ]
 Creating CA... [ DONE ] Updating ovirt-engine service...
 [ DONE ] Setting Database Configuration... [ DONE ]
 Setting Database Security... [ DONE ] Creating Database...
 [ DONE ] Updating the Default Data Center Storage Type...
 [ DONE ] Editing oVirt Engine Configuration... [ DONE ]
 Editing Postgresql Configuration... [ DONE ] Configuring
 the Default ISO Domain... [ DONE ] Configuring Firewall...
 [ DONE ] Starting ovirt-engine Service... [ DONE ]
 Configuring HTTPD... [ DONE ] AIO: Creating storage
 directory... [ DONE ] AIO: Adding Local Datacenter and
 cluster... [ DONE ] AIO: Adding Local host (This may take
 several minutes)...  [ ERROR ] Error: Host was found in
 a 'Failed' state. Please check engine and bootstrap installation
 logs. Please check log file
 /var/log/ovirt-engine/engine-setup_2013_03_08_14_10_56.log for
 more information Exception in thread libvirtEventLoop (most
 likely raised during interpreter shutdown)
 #

 2013-03-08 14:13:33::DEBUG::setup_sequences::59::root:: running
 _loadFilesToIsoDomain 2013-03-08
 14:13:33::ERROR::engine-setup::1838::root:: Traceback
 (most recent call last):   File "/usr/bin/engine-setup",
 line 1835, in _loadFilesToIsoDomain utils.copyFile(filename,
 targetPath, basedefs.CONST_VDSM_UID, basedefs.CONST_KVM_GID)
   File "/usr/share/ovirt-engine/scripts/common_utils.py", line
 706, in copyFile shutil.copy2(fileSrc, destination)
   File "/usr/lib64/python2.6/shutil.py", line 95, in copy2
 copyfile(src, dst)   File
 "/usr/lib64/python2.6/shutil.py", line 50, in copyfile with
 open(src, 'rb') as fsrc: IOError: [Errno 2] No such file or
 directory: '/usr/share/virtio-win/virtio-win.vfd'
 2013-03-08 14:13:33::ERROR::engine-setup::1839::root:: Failed to
 copy files to iso domain

 [snip]
 2013-03-08 14:14:14::DEBUG::setup_sequences::59::root:: running
 waitForHostUp 2013-03-08
 14:14:14::DEBUG::all_in_one_100::303::root:: Waiting for host to
 become operational 2013-03-08
 14:14:14::DEBUG::all_in_one_100::306::root:: current host status
 is: installing 2013-03-08
 14:14:14::DEBUG::all_in_one_100::317::root:: Traceback (most
 recent call last):
   File
 "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line
 314, in isHostUp raise
 Exception(INFO_CREATE_HOST_WAITING_UP) Exception: Waiting for
 the host t

Re: [Users] save to restart libvirtd ?

[Martin Kletzander]

On 04/15/2013 03:39 PM, Alex Leonhardt wrote:
> Hi,
> 
> I believe it's save, but just wanted to re-check, is it save to restart
> libvirtd on a HV running ~40 VMs ?
> 

Hi,

for libvirt questions, I'd rather use libvirt-us...@redhat.com, but for
this particular one, I can confirm that libvirt is written in a way that
enables it to be restarted without any impact on the machines which are
being ran.

Of course I can't say "nothing will happen" due to the fact that every
single time something can happen, but nothing _should_ happen to any of
your machines.

Have a nice day,
Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] save to restart libvirtd ?

[Martin Kletzander]

On 04/16/2013 12:21 AM, Alex Leonhardt wrote:
> Thanks Martin,
> 
> I tested on a "almost" empty host I had to play with, and it seemed all
> went well, so will hopefully be able to regain ~11 GB of memory after
> restarting libvirtd :) ..
> 
> I'll sign up to the other mailing list to find out why / how it could
> have grown this big :\
> 

There might be some memleaks, especially in older version.  For this
kind of stuff, I'd maybe use the libvir-list [1]

Martin

[1] http://www.redhat.com/mailman/listinfo/libvir-list

> Thanks
> Alex
> 
> 
> On 04/15/2013 04:12 PM, Martin Kletzander wrote:
>> On 04/15/2013 03:39 PM, Alex Leonhardt wrote:
>>> Hi,
>>>
>>> I believe it's save, but just wanted to re-check, is it save to restart
>>> libvirtd on a HV running ~40 VMs ?
>>>
>> Hi,
>>
>> for libvirt questions, I'd rather use libvirt-us...@redhat.com, but for
>> this particular one, I can confirm that libvirt is written in a way that
>> enables it to be restarted without any impact on the machines which are
>> being ran.
>>
>> Of course I can't say "nothing will happen" due to the fact that every
>> single time something can happen, but nothing _should_ happen to any of
>> your machines.
>>
>> Have a nice day,
>> Martin
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] too much debugging in ovirt-node

[Martin Kletzander]

On 06/26/2013 07:47 PM, Winfried de Heiden wrote:
> Hi all,
> 
> Using ovirt-node-iso-2.6.1-20120228.fc18.iso (2012 seems to be a typo,
> must be 2013?) is logging with too much debugging.
> 
> Changing all the"DEBUG" to "WARNOMG" in /etc/vdsm/logger.conf and
> "persist /etc/vdsm/logger.conf" solved it for /var/log/vdsm/vdsm.log.
> 
> However, /var/log/libvirtd.log also shows tons of debug messages. The
> file /etc/libvirt/libvirtd.conf shows:
> 
> listen_addr="0.0.0.0"
> unix_sock_group="kvm"
> unix_sock_rw_perms="0770"
> auth_unix_rw="sasl"
> host_uuid="06304eff-1c91-4e1e-86e2-d773621dcab3"
> log_outputs="1:file:/var/log/libvirtd.log"
> ca_file="/etc/pki/vdsm/certs/cacert.pem"
> cert_file="/etc/pki/vdsm/certs/vdsmcert.pem"
> key_file="/etc/pki/vdsm/keys/vdsmkey.pem"
> 
> Changing log_outputs="1:file:/var/log/libvirtd.log" to 
> "log_outputs="3:file:/var/log/libvirtd.log"
> 
> with persist (or unpersist first, thn persist) doesn't help. After a
> reboot log_outputs="1:file:/var/log/libvirtd.log" will appear again.
> 
> How to decrease the log level for libvirtd?
> 

Check also log_level and log_filter properties.  You can cut down the
logs a lot, but beware that in case something happens...  You probably
know.  The advantage with using something on top of libvirt (oVirt for
example) is that you will be probably able to reproduce libvirt problems
in case there will be any and then you can switch the debugging back.

For full options on logging, see http://libvirt.org/logging.html

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] too much debugging in ovirt-node

[Martin Kletzander]

On 06/28/2013 12:49 PM, Matt . wrote:
> I have also libvirt logs with about 10GB of space, annoying, needs to be
> fixed.
> 

Please don't top-post on technical lists.

However, same reply applies to you.  Check your log_level and
log_filters settings.  I just installed fresh server and looking at the
libvirtd.conf, VDSM properly configured it to have also:

log_filters="1:libvirt 3:event 3:json 1:util 1:qemu"

where "3:event 3:json" gets rid of a lot unnecessary messages (but
beware, it depends on the order in which those directives are
specified).  You can also have a look at what we discussed about in Bug
920614 [1], where you might find interesting settings for that as well.
 There is also link to the Gerrit tracker, where the issue is tracked
[2] as well.

Logs should also be rotated.  In case there is no logrotate daemon or no
rules for it, that may be another point of failure.

Martin

[1] https://bugzilla.redhat.com/920614
[2] http://gerrit.ovirt.org/#/c/13642/

> 
> 2013/6/28 Martin Kletzander 
> 
>> On 06/26/2013 07:47 PM, Winfried de Heiden wrote:
>>> Hi all,
>>>
>>> Using ovirt-node-iso-2.6.1-20120228.fc18.iso (2012 seems to be a typo,
>>> must be 2013?) is logging with too much debugging.
>>>
>>> Changing all the"DEBUG" to "WARNOMG" in /etc/vdsm/logger.conf and
>>> "persist /etc/vdsm/logger.conf" solved it for /var/log/vdsm/vdsm.log.
>>>
>>> However, /var/log/libvirtd.log also shows tons of debug messages. The
>>> file /etc/libvirt/libvirtd.conf shows:
>>>
>>> listen_addr="0.0.0.0"
>>> unix_sock_group="kvm"
>>> unix_sock_rw_perms="0770"
>>> auth_unix_rw="sasl"
>>> host_uuid="06304eff-1c91-4e1e-86e2-d773621dcab3"
>>> log_outputs="1:file:/var/log/libvirtd.log"
>>> ca_file="/etc/pki/vdsm/certs/cacert.pem"
>>> cert_file="/etc/pki/vdsm/certs/vdsmcert.pem"
>>> key_file="/etc/pki/vdsm/keys/vdsmkey.pem"
>>>
>>> Changing log_outputs="1:file:/var/log/libvirtd.log" to
>>> "log_outputs="3:file:/var/log/libvirtd.log"
>>>
>>> with persist (or unpersist first, thn persist) doesn't help. After a
>>> reboot log_outputs="1:file:/var/log/libvirtd.log" will appear again.
>>>
>>> How to decrease the log level for libvirtd?
>>>
>>
>> Check also log_level and log_filter properties.  You can cut down the
>> logs a lot, but beware that in case something happens...  You probably
>> know.  The advantage with using something on top of libvirt (oVirt for
>> example) is that you will be probably able to reproduce libvirt problems
>> in case there will be any and then you can switch the debugging back.
>>
>> For full options on logging, see http://libvirt.org/logging.html
>>
>> Martin
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr

[Martin Kletzander]

On 07/27/2013 09:50 PM, Dan Kenigsberg wrote:
> On Fri, Jul 26, 2013 at 02:03:28PM -0400, Nicholas Kesick wrote:
>>> Date: Fri, 26 Jul 2013 05:52:44 +0300
>>> From: ih...@redhat.com
>>> To: cybertimber2...@hotmail.com
>>> CC: dan...@redhat.com; users@ovirt.org
>>> Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr
>>>
>>> On 07/26/2013 05:40 AM, Nicholas Kesick wrote:

 Replies inline.
  > Date: Thu, 25 Jul 2013 22:27:17 +0300
  > From: dan...@redhat.com
  > To: cybertimber2...@hotmail.com
  > CC: users@ovirt.org
  > Subject: Re: [Users] oVirt 3.2 - Migration failed due to error:
 migrateerr
  >
  > On Thu, Jul 25, 2013 at 11:54:40AM -0400, Nicholas Kesick wrote:
  > > When I try to migrate a VM, any VM, between my two hosts, I receive
 an error that says Migration failed due to error: migrateerr. Looking in
 the log I don't see any thing that jumps out other than the final message
  > >
  > > VDSGenericException: VDSErrorException: Failed to MigrateStatusVDS,
 error = Fatal error during migration
  > >
  > > Ovirt-engine is version 3.2.2-1.1.fc18.noarch, firewalld is
 disabled, and selinux is permissive.
  >
  > Please do not say this in public, you're hurting Dan Walsh's feelings 
 ;-)
  >
 I recall seeing his blog posts, and I agree. Not sure when I set it to
 permissive... maybe to get the 3.2 install w/ Firewalld setup to
 complete? I remember that was fixed in 3.2.1. I'll set it back to 
 enforcing.
  > >
  > > ovirt-node version is 2.6.1 on both hosts.
  > >
  > > Any suggestions would be welcome!
  > >
  >
  > I'd love to see /etc/vdsm/vdsm.log from source and destination. The
  > intersting parts start with vmMigrate at the source and with
  > vmMigrationCreate at the destination.
 Hmm, I probably should have pulled that sooner. So, I cleared the active
 VDSM (while nothing was running) and libvirtd.log, booted one vm, and
 tried to migrate it. Attached are the logs. It looks like it boils down
 to (from the source):
 Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 271, in run
File "/usr/share/vdsm/libvirtvm.py", line 505, in
 _startUnderlyingMigration
File "/usr/share/vdsm/libvirtvm.py", line 541, in f
File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
 line 111, in wrapper
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1178, in
 migrateToURI2
 libvirtError: internal error Attempt to migrate guest to the same host
 localhost
 Does this mean my UUIDs are the same?
 http://vaunaspada.babel.it/blog/?p=613
 As far as the destination, I'm really not understanding what's going on
 on the destination between "Destination VM creation succeeded" and
 ":destroy Called" that would lead to it failing, except for what's after
 the traceback:
 Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 696, in _startUnderlyingVm
File "/usr/share/vdsm/libvirtvm.py", line 1907, in
 _waitForIncomingMigrationFinish
File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
 line 111, in wrapper
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2822, in
 lookupByUUIDString
 libvirtError: Domain not found: no domain with matching uuid
 '50171e1b-cf21-41d8-80f3-88ab1b980091'
 But that is the ID of the VM by the looks of it.
 Sorry Itamar, nothing was written to libvirtd.log after I cleared it.
> 
> It could be that libvirtd is still writing to the files that you removed
> from the filesystem. To make sure libvirtd writes to your new file,
> restart the service. There may be clues there on why libvirt thinks that
> the source and destination are one and the same.
> 

When clearing the logs, it should be enough to do '>
/path/to/libvirtd.log' (in bash).

>>>
>>> Thread-800::ERROR::2013-07-26 01:57:16,198::vm::198::vm.Vm::(_recover) 
>>> vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::internal error Attempt to 
>>> migrate guest to the same host localhost
>>> Thread-800::ERROR::2013-07-26 01:57:16,377::vm::286::vm.Vm::(run) 
>>> vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::Failed to migrate
>>> Traceback (most recent call last):
>>>File "/usr/share/vdsm/vm.py", line 271, in run
>>>File "/usr/share/vdsm/libvirtvm.py", line 505, in 
>>> _startUnderlyingMigration
>>>File "/usr/share/vdsm/libvirtvm.py", line 541, in f
>>>File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", 
>>> line 111, in wrapper
>>>File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1178, in 
>>> migrateToURI2
>>> libvirtError: internal error Attempt to migrate guest to the same host 
>>> localhost
>>>
>>> what are your hostnames?
>>
>> "host001" on 192.168.0.103 and "host002" on 192.168.0.104
>> Even trie

Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr

[Martin Kletzander]

On 07/29/2013 06:06 PM, Nicholas Kesick wrote:
> 
>  
>> Date: Mon, 29 Jul 2013 09:56:30 +0200
>> From: mklet...@redhat.com
>> To: dan...@redhat.com
>> CC: cybertimber2...@hotmail.com; users@ovirt.org
>> Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr
>>
>> On 07/27/2013 09:50 PM, Dan Kenigsberg wrote:
>>> On Fri, Jul 26, 2013 at 02:03:28PM -0400, Nicholas Kesick wrote:
> Date: Fri, 26 Jul 2013 05:52:44 +0300
> From: ih...@redhat.com
> To: cybertimber2...@hotmail.com
> CC: dan...@redhat.com; users@ovirt.org
> Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr
>
> On 07/26/2013 05:40 AM, Nicholas Kesick wrote:
>>
>> Replies inline.
>>  > Date: Thu, 25 Jul 2013 22:27:17 +0300
>>  > From: dan...@redhat.com
>>  > To: cybertimber2...@hotmail.com
>>  > CC: users@ovirt.org
>>  > Subject: Re: [Users] oVirt 3.2 - Migration failed due to error:
>> migrateerr
>>  >
>>  > On Thu, Jul 25, 2013 at 11:54:40AM -0400, Nicholas Kesick wrote:
>>  > > When I try to migrate a VM, any VM, between my two hosts, I receive
>> an error that says Migration failed due to error: migrateerr. Looking in
>> the log I don't see any thing that jumps out other than the final message
>>  > >
>>  > > VDSGenericException: VDSErrorException: Failed to MigrateStatusVDS,
>> error = Fatal error during migration
>>  > >
>>  > > Ovirt-engine is version 3.2.2-1.1.fc18.noarch, firewalld is
>> disabled, and selinux is permissive.
>>  >
>>  > Please do not say this in public, you're hurting Dan Walsh's feelings 
>> ;-)
>>  >
>> I recall seeing his blog posts, and I agree. Not sure when I set it to
>> permissive... maybe to get the 3.2 install w/ Firewalld setup to
>> complete? I remember that was fixed in 3.2.1. I'll set it back to 
>> enforcing.
>>  > >
>>  > > ovirt-node version is 2.6.1 on both hosts.
>>  > >
>>  > > Any suggestions would be welcome!
>>  > >
>>  >
>>  > I'd love to see /etc/vdsm/vdsm.log from source and destination. The
>>  > intersting parts start with vmMigrate at the source and with
>>  > vmMigrationCreate at the destination.
>> Hmm, I probably should have pulled that sooner. So, I cleared the active
>> VDSM (while nothing was running) and libvirtd.log, booted one vm, and
>> tried to migrate it. Attached are the logs. It looks like it boils down
>> to (from the source):
>> Traceback (most recent call last):
>>File "/usr/share/vdsm/vm.py", line 271, in run
>>File "/usr/share/vdsm/libvirtvm.py", line 505, in
>> _startUnderlyingMigration
>>File "/usr/share/vdsm/libvirtvm.py", line 541, in f
>>File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
>> line 111, in wrapper
>>File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1178, in
>> migrateToURI2
>> libvirtError: internal error Attempt to migrate guest to the same host
>> localhost
>> Does this mean my UUIDs are the same?
>> http://vaunaspada.babel.it/blog/?p=613
>> As far as the destination, I'm really not understanding what's going on
>> on the destination between "Destination VM creation succeeded" and
>> ":destroy Called" that would lead to it failing, except for what's after
>> the traceback:
>> Traceback (most recent call last):
>>File "/usr/share/vdsm/vm.py", line 696, in _startUnderlyingVm
>>File "/usr/share/vdsm/libvirtvm.py", line 1907, in
>> _waitForIncomingMigrationFinish
>>File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
>> line 111, in wrapper
>>File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2822, in
>> lookupByUUIDString
>> libvirtError: Domain not found: no domain with matching uuid
>> '50171e1b-cf21-41d8-80f3-88ab1b980091'
>> But that is the ID of the VM by the looks of it.
>> Sorry Itamar, nothing was written to libvirtd.log after I cleared it.
>>>
>>> It could be that libvirtd is still writing to the files that you removed
>>> from the filesystem. To make sure libvirtd writes to your new file,
>>> restart the service. There may be clues there on why libvirt thinks that
>>> the source and destination are one and the same.
>>>
>>
>> When clearing the logs, it should be enough to do '>
>> /path/to/libvirtd.log' (in bash).
>> Just checked and it seems some things were logged in there during my testing 
>> on Friday. I'll attach those.
>
> Thread-800::ERROR::2013-07-26 01:57:16,198::vm::198::vm.Vm::(_recover) 
> vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::internal error Attempt to 
> migrate guest to the same host localhost
> Thread-800::ERROR::2013-07-26 01:57:16,377::vm::286::vm.Vm::(run) 
> vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::Failed to migrate
> Traceback (most recent call last):
>Fil

Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr

[Martin Kletzander]

On 07/29/2013 06:06 PM, Nicholas Kesick wrote:
> 
>  
>> Date: Mon, 29 Jul 2013 09:56:30 +0200
>> From: mklet...@redhat.com
>> To: dan...@redhat.com
>> CC: cybertimber2...@hotmail.com; users@ovirt.org
>> Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr
>>
>> On 07/27/2013 09:50 PM, Dan Kenigsberg wrote:
>>> On Fri, Jul 26, 2013 at 02:03:28PM -0400, Nicholas Kesick wrote:
> Date: Fri, 26 Jul 2013 05:52:44 +0300
> From: ih...@redhat.com
> To: cybertimber2...@hotmail.com
> CC: dan...@redhat.com; users@ovirt.org
> Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr
>
> On 07/26/2013 05:40 AM, Nicholas Kesick wrote:
>>
>> Replies inline.
>>  > Date: Thu, 25 Jul 2013 22:27:17 +0300
>>  > From: dan...@redhat.com
>>  > To: cybertimber2...@hotmail.com
>>  > CC: users@ovirt.org
>>  > Subject: Re: [Users] oVirt 3.2 - Migration failed due to error:
>> migrateerr
>>  >
>>  > On Thu, Jul 25, 2013 at 11:54:40AM -0400, Nicholas Kesick wrote:
>>  > > When I try to migrate a VM, any VM, between my two hosts, I receive
>> an error that says Migration failed due to error: migrateerr. Looking in
>> the log I don't see any thing that jumps out other than the final message
>>  > >
>>  > > VDSGenericException: VDSErrorException: Failed to MigrateStatusVDS,
>> error = Fatal error during migration
>>  > >
>>  > > Ovirt-engine is version 3.2.2-1.1.fc18.noarch, firewalld is
>> disabled, and selinux is permissive.
>>  >
>>  > Please do not say this in public, you're hurting Dan Walsh's feelings 
>> ;-)
>>  >
>> I recall seeing his blog posts, and I agree. Not sure when I set it to
>> permissive... maybe to get the 3.2 install w/ Firewalld setup to
>> complete? I remember that was fixed in 3.2.1. I'll set it back to 
>> enforcing.
>>  > >
>>  > > ovirt-node version is 2.6.1 on both hosts.
>>  > >
>>  > > Any suggestions would be welcome!
>>  > >
>>  >
>>  > I'd love to see /etc/vdsm/vdsm.log from source and destination. The
>>  > intersting parts start with vmMigrate at the source and with
>>  > vmMigrationCreate at the destination.
>> Hmm, I probably should have pulled that sooner. So, I cleared the active
>> VDSM (while nothing was running) and libvirtd.log, booted one vm, and
>> tried to migrate it. Attached are the logs. It looks like it boils down
>> to (from the source):
>> Traceback (most recent call last):
>>File "/usr/share/vdsm/vm.py", line 271, in run
>>File "/usr/share/vdsm/libvirtvm.py", line 505, in
>> _startUnderlyingMigration
>>File "/usr/share/vdsm/libvirtvm.py", line 541, in f
>>File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
>> line 111, in wrapper
>>File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1178, in
>> migrateToURI2
>> libvirtError: internal error Attempt to migrate guest to the same host
>> localhost
>> Does this mean my UUIDs are the same?
>> http://vaunaspada.babel.it/blog/?p=613
>> As far as the destination, I'm really not understanding what's going on
>> on the destination between "Destination VM creation succeeded" and
>> ":destroy Called" that would lead to it failing, except for what's after
>> the traceback:
>> Traceback (most recent call last):
>>File "/usr/share/vdsm/vm.py", line 696, in _startUnderlyingVm
>>File "/usr/share/vdsm/libvirtvm.py", line 1907, in
>> _waitForIncomingMigrationFinish
>>File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
>> line 111, in wrapper
>>File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2822, in
>> lookupByUUIDString
>> libvirtError: Domain not found: no domain with matching uuid
>> '50171e1b-cf21-41d8-80f3-88ab1b980091'
>> But that is the ID of the VM by the looks of it.
>> Sorry Itamar, nothing was written to libvirtd.log after I cleared it.
>>>
>>> It could be that libvirtd is still writing to the files that you removed
>>> from the filesystem. To make sure libvirtd writes to your new file,
>>> restart the service. There may be clues there on why libvirt thinks that
>>> the source and destination are one and the same.
>>>
>>
>> When clearing the logs, it should be enough to do '>
>> /path/to/libvirtd.log' (in bash).
>> Just checked and it seems some things were logged in there during my testing 
>> on Friday. I'll attach those.
>
> Thread-800::ERROR::2013-07-26 01:57:16,198::vm::198::vm.Vm::(_recover) 
> vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::internal error Attempt to 
> migrate guest to the same host localhost
> Thread-800::ERROR::2013-07-26 01:57:16,377::vm::286::vm.Vm::(run) 
> vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::Failed to migrate
> Traceback (most recent call last):
>Fil

Re: [Users] [libvirt] Host local_host running without virtualization hardware acceleration

[Martin Kletzander]

On Tue, Nov 05, 2013 at 09:08:33AM +0100, Sandro Bonazzola wrote:
> Hi,
> I had to reinstall ovirt yesterday and now it seems that it doesn't work 
> anymore.
> I'm running nightly on Fedora 18.
>  kernel-3.11.4-101.fc18.x86_64
>  sanlock-2.8-1.fc18.x86_64
>  libvirt-1.1.4-1.fc18.x86_64
>  qemu-1.5.1-1.fc18.x86_64
>  vdsm-4.13.0-93.gitea8c8f0.fc18.x86_64
>  ovirt-engine-3.4.0-0.2.master.20131104192919.git3b65870.fc18.noarch
> 
> engine-setup with all-in-one detects hardware virtualization and allow me to 
> configure the system.
> (it fails detecting engine health status due probably to recent changes in 
> its URL, I'm already looking into it)
> 
> Once added localhost to the engine, it has been moved to non operational mode 
> saying
> I don't have virtualization hardware acceleration anymore.
> 
> I've found that:
> 
> # modinfo kvm
> filename:   /lib/modules/3.11.4-101.fc18.x86_64/kernel/arch/x86/kvm/kvm.ko
> license:GPL
> author: Qumranet
> depends:
> intree: Y
> vermagic:   3.11.4-101.fc18.x86_64 SMP mod_unload
> parm:   min_timer_period_us:uint
> parm:   ignore_msrs:bool
> parm:   tsc_tolerance_ppm:uint
> parm:   allow_unsafe_assigned_interrupts:Enable device assignment on 
> platforms without interrupt remapping support. (bool)
> 

This is good, but AFAIK this module is not what provides /dev/kvm.
Depending on the processor you're using, try checking 'kvm_intel' or
'kvm_amd'.  Also make sure both are loaded.

> # /usr/bin/qemu-kvm
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
> 
> looking at strace:
> open("/dev/kvm", O_RDWR|O_CLOEXEC)  = -1 ENOENT (No such file or 
> directory)
> 

What does ls -lZ /dev/kvm tell you?

> Any clue on what may be happened?
> 

No idea, but I'm basing everything on the fact that it worked before
the re-install, am I right?

Martin


signature.asc
Description: Digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] json parsing error when live migrating

[Martin Kletzander]

On 07/02/2012 05:03 PM, Nathanaël Blanchet wrote:
> hello,
> 
> I have this error very often when live migrating from host A -> host B
> 
> libvirtError: erreur interne Unexpected JSON reply '{"error": {"class":
> "JSONParsing", "desc": "Invalid JSON syntax", "data": {}}}'
> 
> 
> I'm using stable 4.9.3 vdsm with ovirt 3.0.
> 
> Has anybody ever got this error?
> 

Hello,

this looks like it could be our (libvirt's) error. Do you have any logs
that could help me go through this more closely?

I'm in a process of setting up a "lab" with ovirt to help in exactly
these kind of situations, but unfortunately it's not working yet.

Have a nice day,
Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] json parsing error when live migrating

[Martin Kletzander]

Thank you as well. Even though you managed to fix that (and I'm glad for
that), this shouldn't happen or at least there should be a better error
message. I'll have a look at it to make sure we'll do something about that.

@Dave: do you think it would be good to turn this into BZ even before I
make sure this is our error?

Martin

On 07/03/2012 12:40 PM, Nathanaël Blanchet wrote:
> Hello,
> 
> thanks for your answer, I found the error : it was from vm which I
> imported from libvirt/kvm with virtv2v. These vms were created by
> virt-manager  and were running default cirrus xorg driver, while ovirt
> creates qxl one as default. I've changed this on each concerned vms. Now
> live migration successes everytime.
> Hope it will be useful for people who will be in the same case.
> 
> Le 03/07/2012 10:36, Martin Kletzander a écrit :
>> On 07/02/2012 05:03 PM, Nathanaël Blanchet wrote:
>>> hello,
>>>
>>> I have this error very often when live migrating from host A -> host B
>>>
>>> libvirtError: erreur interne Unexpected JSON reply '{"error": {"class":
>>> "JSONParsing", "desc": "Invalid JSON syntax", "data": {}}}'
>>>
>>>
>>> I'm using stable 4.9.3 vdsm with ovirt 3.0.
>>>
>>> Has anybody ever got this error?
>>>
>> Hello,
>>
>> this looks like it could be our (libvirt's) error. Do you have any logs
>> that could help me go through this more closely?
>>
>> I'm in a process of setting up a "lab" with ovirt to help in exactly
>> these kind of situations, but unfortunately it's not working yet.
>>
>> Have a nice day,
>> Martin
> 


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[Users] Setting up test nodes

[Martin Kletzander]

Hi everyone,

TL;DR: how do I setup a software node (faqemu) with apps from source?

I'm new to the oVirt world and coming from the lower layer, I must admin
I feel kind of confused.

I'm trying to create a "lab" with ovirt-engine (up and running), some
ovirt-node (with sw qemu) and ovirt-node with all the stack running on
git sources (qemu, libvirt, vdsm and ovirt-node). The problem is that I
only tried this before with ovirt-node ISO image and I don't know how
can I step in there and work with the system underneath.

The whole point of this is to help speed up problem-solving in the
future for problems related to mostly libvirt. Having this available
should help us a lot.

My main question is: What is the proper way to setup a node from
standard fedora installation (not ISO) and having software-emulated qemu
machine there?

Thanks in advance for any tips and have a nice day,
Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Unable to run VM with "Unable to create cgroup" error message

[Martin Kletzander]

Hi,

the only problem I could imagine is that there is really some directory
missing, but you said it is there. Fromt his point I see two things you
can try:
 1) run libvirt with debugging output enabled [1]
 2) try to create the directories manually

Hopefully it'll give us more information on what's wrong.

Martin

On 07/03/2012 11:55 AM, xuejie chen wrote:
> Hi everyone,
> 
> I created a Desktop VM1 with all default settings and added a 2G Disk
> to the VM1 in WebAdmin.
> But when I run the vm, it returns failure with the follow error
> message in WebAdmin.
> "VM VM1 is down. Exit message: Unable to create cgroup for VM1"
> 
> My DateCenter contains one host(with OS is CentOS 6, VDSM version is
> 4.9.6 and libvirt version is 0.9.4) and one NFS domain.
> And The cgroup Directory have already exits on the host.
> But why cannot I run the VM1?
> 
> There are some error message in VDSM log
> 
> File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2087, in createXML
>if ret is None: raise libvirtError('virDomainCreateXML() failed', 
> conn=self)
> libvirtError: Unable to create cgroup for VM1: No such file or directory
> --
> 
> There are some error message in libvirt log
> -
> error : virNetClientProgramDispatchError:170 : Unable to create cgroup
> for VM1: No such file or directory"
> -
> 
> There are log files in attachment
> 
> 
> Best wishes,
> Xuejie Chen
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Unable to run VM with "Unable to create cgroup" error message

[Martin Kletzander]

Sorry, I almost always forget the links :)

[1] http://libvirt.org/logging.html

Martin

P.S.: don't hesitate to send other info and ask, I'd be happy to help,
although I'm going away for week and a half.


On 07/04/2012 10:12 AM, Martin Kletzander wrote:
> Hi,
> 
> the only problem I could imagine is that there is really some directory
> missing, but you said it is there. Fromt his point I see two things you
> can try:
>  1) run libvirt with debugging output enabled [1]
>  2) try to create the directories manually
> 
> Hopefully it'll give us more information on what's wrong.
> 
> Martin
> 
> On 07/03/2012 11:55 AM, xuejie chen wrote:
>> Hi everyone,
>>
>> I created a Desktop VM1 with all default settings and added a 2G Disk
>> to the VM1 in WebAdmin.
>> But when I run the vm, it returns failure with the follow error
>> message in WebAdmin.
>> "VM VM1 is down. Exit message: Unable to create cgroup for VM1"
>>
>> My DateCenter contains one host(with OS is CentOS 6, VDSM version is
>> 4.9.6 and libvirt version is 0.9.4) and one NFS domain.
>> And The cgroup Directory have already exits on the host.
>> But why cannot I run the VM1?
>>
>> There are some error message in VDSM log
>> 
>> File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2087, in createXML
>>if ret is None: raise libvirtError('virDomainCreateXML() failed', 
>> conn=self)
>> libvirtError: Unable to create cgroup for VM1: No such file or directory
>> --
>>
>> There are some error message in libvirt log
>> -
>> error : virNetClientProgramDispatchError:170 : Unable to create cgroup
>> for VM1: No such file or directory"
>> -
>>
>> There are log files in attachment
>>
>>
>> Best wishes,
>> Xuejie Chen
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Setting up test nodes

[Martin Kletzander]

On 07/04/2012 10:46 AM, Doron Fediuck wrote:
> On 03/07/12 21:27, Itamar Heim wrote:
>> On 07/03/2012 03:48 PM, Martin Kletzander wrote:
>>> Hi everyone,
>>>
>>> TL;DR: how do I setup a software node (faqemu) with apps from source?
>>
>> - do you wnat to setup an ovirt-node, or just install vdsm on plain fedora 
>> 17?
>> sounds like the latter, but if you want to use fake-qemu, ovirt-node is much 
>> harder than just using a fedora 17.
>>

Frankly, I don't see the difference in there that much. The basic point
in this is -- have a visible node in ovirt-engine on which I can
experiment with (mainly) libvirt.

At first I though I need to have the 'ovirt-node' package installed but
it doesn't seem it's needed now. I searched through the documentation
but I haven't found a lot related to this particular use case.

>>>
>>> I'm new to the oVirt world and coming from the lower layer, I must admin
>>> I feel kind of confused.
>>>
>>> I'm trying to create a "lab" with ovirt-engine (up and running), some
>>> ovirt-node (with sw qemu) and ovirt-node with all the stack running on
>>> git sources (qemu, libvirt, vdsm and ovirt-node). The problem is that I
>>> only tried this before with ovirt-node ISO image and I don't know how
>>> can I step in there and work with the system underneath.
>>>
>>> The whole point of this is to help speed up problem-solving in the
>>> future for problems related to mostly libvirt. Having this available
>>> should help us a lot.
>>>
>>> My main question is: What is the proper way to setup a node from
>>> standard fedora installation (not ISO) and having software-emulated qemu
>>> machine there?
>>
>>
>> for using plain fedora 17 as a guest, you just need to:
>> option 1:
>> - yum install vdsm vdsdsm-hook-faqemu
>> - vi /etc/vdsm/vdsm.conf and set vars.fake_kvm_support=True
>> - now simply add the host from web admin (hosts-->add host)
>> note: you may need this patch if not in your version of vdsm already:
>> http://gerrit.ovirt.org/#/c/5611/
>>

I'll try this after resolving few other errors unrelated to oVirt. I
though there is some more complicated way through swamps and dragon lair
=) Thanks for showing me the right way!

>> option 2: if your host is fedora 16 and above, just use nested 
>> virtualization, and your virtual host would behave like a normal one (i 
>> still need to try this one out)
>> i.e., just add the virtual host from web admin (hosts-->add host)
>>

I wouldn't want to try that, kvm is still not that stable, people say
the guests get stuck after some time and I don't really need anything
running in these machines.

In case you'll try that, good luck.

>> I assume another step would be needed here (at least configuring the guest 
>> in libvirt to have nested virtualization), but i haven't tried this one yet 
>> to know what it is.
>>
> 
> Once successful, it would be great if you could document your process
> in oVirt's wiki, sharing your experience with other users ;)
> 

I'll try to summarize that in case I'll succeed, but now everything
seems very new to me (I mean I don't even know where to click in the
engine's administration portal).

>>>
>>> Thanks in advance for any tips and have a nice day,
>>> Martin
> 
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Unable to run VM with "Unable to create cgroup" error message

[Martin Kletzander]

On 07/04/2012 02:36 PM, Andrew Cathrow wrote:
> 
> 
> - Original Message -
>> From: "Martin Kletzander" 
>> To: "xuejie chen" 
>> Cc: users@ovirt.org
>> Sent: Wednesday, July 4, 2012 4:12:07 AM
>> Subject: Re: [Users] Unable to run VM with "Unable to create cgroup" error 
>> message
>>
>> Hi,
>>
>> the only problem I could imagine is that there is really some
>> directory
>> missing, but you said it is there. Fromt his point I see two things
>> you
>> can try:
>>  1) run libvirt with debugging output enabled [1]
>>  2) try to create the directories manually
> 
> Is the cgroupfs mounted?
> 

I checked and libvirt should complain if it is not mounted. But to be
sure, is it?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Unable to run VM with ”opening backend ‘pyt’ failed”

[Martin Kletzander]

On 07/17/2012 02:41 AM, Mark Wu wrote:
> On 07/16/2012 09:46 AM, xuejie chen wrote:
>>  > file="/rhev/data-center/2d7df94d-738d-4d7d-97a4-dd5027a4bf25/d3267b58-cbbd-4e6e-8685-8acd152d49a1/images/7e1011e0-d0ac-4c1f-bd09-a19e450c3259
> Please upgrade vdsm to 4.10.0 as Dan suggested above.  If the problem
> still exists, please:
> 
> check the owner and permission of that image file:
> 
> ls -l 
> /rhev/data-center/2d7df94d-738d-4d7d-97a4-dd5027a4bf25/d3267b58-cbbd-4e6e-8685-8acd152d49a1/images/7e1011e0-d0ac-4c1f-bd09-a19e450c3259/9c728c1d-762e-4670-9076-9ca5a37b6354
> 
> Run "setenforce 0" to disable selinux and see if it helps:
> 

As Mark pointed out, checking the permissions should be enough, so
"ls -lZ" will do. I don't know if "Local on host" means exactly what I
think, but in case it's not managed using vdsm, that directory may need
to me mounted from somewhere, libvirt itself doesn't do that (unless
it's in network filesystem pool).

In case this goes down to a problem in libvirt, feel free to say what's
wrong and I'll see what I can do about it.

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Unable to run VM with ”opening backend ‘pyt’ failed”

[Martin Kletzander]

On 07/20/2012 10:20 AM, xuejie chen wrote:
> 2012/7/17 Martin Kletzander :
>> On 07/17/2012 02:41 AM, Mark Wu wrote:
>>> On 07/16/2012 09:46 AM, xuejie chen wrote:
>>>>  >>> file="/rhev/data-center/2d7df94d-738d-4d7d-97a4-dd5027a4bf25/d3267b58-cbbd-4e6e-8685-8acd152d49a1/images/7e1011e0-d0ac-4c1f-bd09-a19e450c3259
>>> Please upgrade vdsm to 4.10.0 as Dan suggested above.  If the problem
>>> still exists, please:
>>>
>>> check the owner and permission of that image file:
>>>
>>> ls -l 
>>> /rhev/data-center/2d7df94d-738d-4d7d-97a4-dd5027a4bf25/d3267b58-cbbd-4e6e-8685-8acd152d49a1/images/7e1011e0-d0ac-4c1f-bd09-a19e450c3259/9c728c1d-762e-4670-9076-9ca5a37b6354
>>>
>>> Run "setenforce 0" to disable selinux and see if it helps:
>>>
>>
>> As Mark pointed out, checking the permissions should be enough, so
>> "ls -lZ" will do. I don't know if "Local on host" means exactly what I
>> think, but in case it's not managed using vdsm, that directory may need
>> to me mounted from somewhere, libvirt itself doesn't do that (unless
>> it's in network filesystem pool).
> 
> I checked the owner of that image file is vdsm.
> But I found the user of qemu-kvm is root.
> So I modified the qemu.conf and set user to qemu.

This modification shouldn't be necessary as the binary packages are
compiled with this setting usually. However, in case you used some
yourself-built package, that might have caused the config change
(happens to me with compiled packages from repo.

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] [User] why VM image owner change to root after stop the vm

[Martin Kletzander]

On 07/25/2012 10:36 AM, T-Sinjon wrote:
> 
> Dear everyone:
> 
> Description
> When i create a vm , the vm owner is vdsm:kvm(36:36)
> 
> when i start a vm , the vm owner change to qemu:qemu(107:107)
> -rw-rw. 1 qemu qemu 107374182400 Jul 25  2012 
> d1e6b671-6b48-4964-9c56-22847e9b83df
> -rw-r--r--. 1 vdsm kvm   269 Jul 25  2012 
> d1e6b671-6b48-4964-9c56-22847e9b83df.meta
> 
> then i stop the vm , the vm owner change to root:root
> -rw-rw. 1 root root 107374182400 Jul 25  2012 
> d1e6b671-6b48-4964-9c56-22847e9b83df
> -rw-r--r--. 1 vdsm kvm   269 Jul 25  2012 
> d1e6b671-6b48-4964-9c56-22847e9b83df.meta
> 
> then , i cannot start the vm , on the web logs event:
> 

Just out of curiosity (it won't probably won't be the cause of the
problem), do you have dynamic_ownership=0 in /etc/libvirt/qemu.conf ?

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] [User] why VM image owner change to root after stop the vm

[Martin Kletzander]

Thanks, I just wanted to make sure it's not libvirt that does this.

On 07/25/2012 04:44 PM, T-Sinjon wrote:
> both engine and node dynamic_ownership are 0
> 
> On 25 Jul, 2012, at 5:56 PM, Martin Kletzander wrote:
> 
>> On 07/25/2012 10:36 AM, T-Sinjon wrote:
>>>
>>> Dear everyone:
>>>
>>> Description
>>> When i create a vm , the vm owner is vdsm:kvm(36:36)
>>>
>>> when i start a vm , the vm owner change to qemu:qemu(107:107)
>>> -rw-rw. 1 qemu qemu 107374182400 Jul 25  2012 
>>> d1e6b671-6b48-4964-9c56-22847e9b83df
>>> -rw-r--r--. 1 vdsm kvm   269 Jul 25  2012 
>>> d1e6b671-6b48-4964-9c56-22847e9b83df.meta
>>>
>>> then i stop the vm , the vm owner change to root:root
>>> -rw-rw. 1 root root 107374182400 Jul 25  2012 
>>> d1e6b671-6b48-4964-9c56-22847e9b83df
>>> -rw-r--r--. 1 vdsm kvm   269 Jul 25  2012 
>>> d1e6b671-6b48-4964-9c56-22847e9b83df.meta
>>>
>>> then , i cannot start the vm , on the web logs event:
>>>
>>
>> Just out of curiosity (it won't probably won't be the cause of the
>> problem), do you have dynamic_ownership=0 in /etc/libvirt/qemu.conf ?
>>
>> Martin
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] [User] why VM image owner change to root after stop the vm

[Martin Kletzander]

On 07/26/2012 02:30 PM, Dan Kenigsberg wrote:
> On Thu, Jul 26, 2012 at 11:05:21AM +0800, T-Sinjon wrote:
>> maybe it's a libvirt problem  , since my nodes have used oVirt Node 
>> Hypervisor 2.2.2-2.2.fc16
>>
>> engine:
>> libvirt-0.9.11.4-3.fc17.x86_64
> This one is unused.
> 
>>
>> node:
>> libvirt-0.9.6-4.fc16.x86_64
>>
>> storage:
>> No local fs, I have two Domain , one is using NFS fs, the other is GlusterFS 
>> mount by NFS.
>> Both have the problem
>>
>> [root@ovirt-node-sun-1 ~]# strace -p 1209 -e chown -ff
>> Process 1209 attached with 11 threads - interrupt to quit
>>
>> After start vm:
>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19068, 
>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19069, 
>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19071, 
>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19072, 
>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19074, 
>> si_status=0, si_utime=1, si_stime=0} (Child exited) ---
>> [pid  1209] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19080, 
>> si_status=0, si_utime=0, si_stime=0} (Child exited) ---
>> [pid  1518] 
>> chown("/rhev/data-center/3bdc6f14-bb92-4b0e-8db2-d0ba4c34f61d/b5078b10-a044-42c5-b270-8b81cd51ce35/images/979c2849-2587-4015-bad5-53159a11b6ed/38648b73-b0d4-4f2a-9f46-5b20613abb7a",
>>  107, 107) = 0  
>>
>> After stop vm:
>> [pid  1209] 
>> chown("/rhev/data-center/3bdc6f14-bb92-4b0e-8db2-d0ba4c34f61d/b5078b10-a044-42c5-b270-8b81cd51ce35/images/979c2849-2587-4015-bad5-53159a11b6ed/38648b73-b0d4-4f2a-9f46-5b20613abb7a",
>>  0, 0) = 0
> 
> 
> Why are you are teasing us? ;-) who was pid 1209, vdsm or libvirtd?
> 

=)

Unfortunately, you might be right, Dan. I think maybe it is libvirt and
it is hitting a bug, but the bug I know about does this only with
dynamic_ownership=1 (that's why I asked at first).

To be sure, let's wait till we know who was 1518. Until then I'll try to
investigate ;)

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] [User] why VM image owner change to root after stop the vm

[Martin Kletzander]

OK, so it is done by libvirt. However, I was trying to reproduce this
and I was looking in the code and it looks like your config file
settings are not reflected in libvirt (does the ownership change also
after libvirt restart?). There is no chown called when dynamic ownership
is turned off. The only thing I haven't tried is checking older versions
of libvirt, but this code haven't changed that much.

On 07/26/2012 05:28 PM, T-Sinjon wrote:
> sorry for my careless , they all libvirtd
> 
> [root@ovirt-node-sun-1 ~]# top -b -n 2 -H -p 1209
> top - 15:25:08 up 3 days,  9:11,  3 users,  load average: 0.06, 0.49, 0.39
> Tasks:  11 total,   0 running,  11 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.7%us,  1.3%sy,  0.0%ni, 97.7%id,  0.0%wa,  0.1%hi,  0.1%si,  0.0%st
> Mem:  16436060k total,  7349120k used,  9086940k free,69100k buffers
> Swap:0k total,0k used,0k free,  2239792k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND  
>   
>  1209 root  20   0  909m  17m 7164 S  0.0  0.1   1:33.10 libvirtd 
>   
>  1515 root  20   0  909m  17m 7164 S  0.0  0.1   0:07.56 libvirtd 
>   
>  1516 root  20   0  909m  17m 7164 S  0.0  0.1   0:07.81 libvirtd 
>   
>  1517 root  20   0  909m  17m 7164 S  0.0  0.1   0:07.78 libvirtd 
>   
>  1518 root  20   0  909m  17m 7164 S  0.0  0.1   0:07.55 libvirtd 
>   
>  1519 root  20   0  909m  17m 7164 S  0.0  0.1   0:07.46 libvirtd 
>   
>  1520 root  20   0  909m  17m 7164 S  0.0  0.1   0:01.35 libvirtd 
>   
>  1521 root  20   0  909m  17m 7164 S  0.0  0.1   0:01.36 libvirtd 
>   
>  1522 root  20   0  909m  17m 7164 S  0.0  0.1   0:01.37 libvirtd 
>   
>  1523 root  20   0  909m  17m 7164 S  0.0  0.1   0:01.34 libvirtd 
>   
>  1524 root  20   0  909m  17m 7164 S  0.0  0.1   0:01.30 libvirtd
> 
> On 26 Jul, 2012, at 8:51 PM, Martin Kletzander wrote:
> 
>> On 07/26/2012 02:30 PM, Dan Kenigsberg wrote:
>>> On Thu, Jul 26, 2012 at 11:05:21AM +0800, T-Sinjon wrote:
>>>> maybe it's a libvirt problem  , since my nodes have used oVirt Node 
>>>> Hypervisor 2.2.2-2.2.fc16
>>>>
>>>> engine:
>>>> libvirt-0.9.11.4-3.fc17.x86_64
>>> This one is unused.
>>>
>>>>
>>>> node:
>>>> libvirt-0.9.6-4.fc16.x86_64
>>>>
>>>> storage:
>>>> No local fs, I have two Domain , one is using NFS fs, the other is 
>>>> GlusterFS mount by NFS.
>>>> Both have the problem
>>>>
>>>> [root@ovirt-node-sun-1 ~]# strace -p 1209 -e chown -ff
>>>> Process 1209 attached with 11 threads - interrupt to quit
>>>>
>>>> After start vm:
>>>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19068, 
>>>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>>>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19069, 
>>>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>>>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19071, 
>>>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>>>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19072, 
>>>> si_status=0, si_utime=1, si_stime=1} (Child exited) ---
>>>> [pid  1518] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19074, 
>>>> si_status=0, si_utime=1, si_stime=0} (Child exited) ---
>>>> [pid  1209] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=19080, 
>>>> si_status=0, si_utime=0, si_stime=0} (Child exited) ---
>>>> [pid  1518] 
>>>> chown("/rhev/data-center/3bdc6f14-bb92-4b0e-8db2-d0ba4c34f61d/b5078b10-a044-42c5-b270-8b81cd51ce35/images/979c2849-2587-4015-bad5-53159a11b6ed/38648b73-b0d4-4f2a-9f46-5b20613abb7a",
>>>>  107, 107) = 0  
>>>>
>>>> After stop vm:
>>>> [pid  1209] 
>>>> chown("/rhev/data-center/3bdc6f14-bb92-4b0e-8db2-d0ba4c34f61d/b5078b10-a044-42c5-b270-8b81cd51ce35/images/979c2849-2587-4015-bad5-53159a11b6ed/38648b73-b0d4-4f2a-9f46-5b20613abb7a",
>>>>  0, 0) = 0
>>>
>>>
>>> Why are you are teasing us? ;-) who was pid 1209, vdsm or libvirtd?
>>>
>>
>> =)
>>
>> Unfortunately, you might be right, Dan. I think maybe it is libvirt and
>> it is hitting a bug, but the bug I know about does this only with
>> dynamic_ownership=1 (that's why I asked at first).
>>
>> To be sure, let's wait till we know who was 1518. Until then I'll try to
>> investigate ;)
>>
>> Martin
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] [User] why VM image owner change to root after stop the vm

[Martin Kletzander]

It looks like this exactly could be the problem. I don't know how the
node installation works, but when you install normal system it shouldn't
start any services until you specify that. Of course this is another
story when installing one-purpose system, so I won't be able to tell you
exactly, but vdsm should definitely make sure libvirtd loads its config
(re/starts *after* the config is modified)

I'm glad it works for you now.

Martin

On 07/31/2012 01:42 PM, T-Sinjon wrote:
> yeah, everything went ok after restart libvirtd
> 
> I have do a test :
> Install a new node, the problem always there (any possible  that 
> "dynamic_ownership=0 # by vdsm"  has done after libvirtd starting??)
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification

[Martin Kletzander]

Oh, sorry to hear that, that doesn't sound good.

What did change on the server with reboot? I wonder how this is possible.

Martin

On 08/01/2012 06:32 PM, Ricardo Esteves wrote:
> And now, after reboot of the node, i get this:
> 
> [root@blade4  ~]# virsh capabilities
> Segmentation fault
> 
> -
> Original Message-
> *From*: Ricardo Esteves  >
> *To*: Itamar Heim  >
> *Cc*: users@ovirt.org 
> *Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
> *Date*: Wed, 01 Aug 2012 16:52:11 +0100
> 
> 
> I didn't disabled anything, but after installing the node when i
> configure the option "oVirt Engine" it gives an error saying it can't
> download the certificate, but i had this error with previous versions of
> the node, and it detected ok the CPU family.
> 
> This is the output after a fresh install of the node:
> 
> [root@blade4  ~]# vdsClient -s 0 getVdsCaps | grep
> -i flags
> Traceback (most recent call last):
>   File "/usr/share/vdsm/vdsClient.py", line 2275, in 
>   File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
>   File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders
>   File "/usr/lib64/python2.7/httplib.py", line 814, in _send_output
>   File "/usr/lib64/python2.7/httplib.py", line 776, in send
>   File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
> line 91, in connect
>   File "/usr/lib64/python2.7/socket.py", line 553, in create_connection
> gaierror: [Errno -2] Name or service not known
> 
> 
> [root@blade4  ~]# virsh capabilities
> 
> 
>   
> 35303737-3830-435a-4a30-30333035455a
> 
>   x86_64
>   Nehalem
>   Intel
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> 
> 
>   
>   
> tcp
>   
> 
> 
>   
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
>   
> 
> 
>   selinux
>   0
> 
>   
> 
>   
> hvm
> 
>   32
>   /usr/bin/qemu-system-x86_64
>   pc-0.15
>   pc-1.0
>   pc
>   pc-0.14
>   pc-0.13
>   pc-0.12
>   pc-0.11
>   pc-0.10
>   isapc
>   
>   
>   
> /usr/bin/qemu-kvm
> pc-0.15
> pc-1.0
> pc
> pc-0.14
> pc-0.13
> pc-0.12
> pc-0.11
> pc-0.10
> isapc
>   
> 
> 
>   
>   
>   
>   
>   
>   
> 
>   
> 
>   
> hvm
> 
>   64
>   /usr/bin/qemu-system-x86_64
>   pc-0.15
>   pc-1.0
>   pc
>   pc-0.14
>   pc-0.13
>   pc-0.12
>   pc-0.11
>   pc-0.10
>   isapc
>   
>   
>   
> /usr/bin/qemu-kvm
> pc-0.15
> pc-1.0
> pc
> pc-0.14
> pc-0.13
> pc-0.12
> pc-0.11
> pc-0.10
> isapc
>   
> 
> 
>   
>   
>   
>   
> 
>   
> 
> 
> 
> When i add the host to oVirt i get this message:
> 
> Host blade4.vi.pt moved to Non-Operational state as host does not meet
> the cluster's minimum CPU level. Missing CPU features : model_Nehalem
> 
> Best regards,
> Ricardo Esteves.
> 
> -Original Message-
> *From*: Itamar Heim  >
> *To*: Ricardo Esteves  >
> *Cc*: users@ovirt.org 
> *Subject*: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
> *Date*: Wed, 01 Aug 2012 15:43:22 +0300
> 
> On 08/01/2012 02:28 PM, Ricardo Esteves wrote:
>>
>> [root@blade4  ~]# vdsClient -s 0 getVdsCaps | grep
>> -i flags
>> Traceback (most recent call last):
>>File "/usr/share/vdsm/vdsClient.py", line 2275, in 
>>File "/usr/share/vdsm/vdsClient.py", line 403, in do_getCap
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1292, in single_request
>>File "/usr/lib64/python2.7/xmlrpclib.py", line 1439, in send_content
>>File "/usr/lib64/python2.7/httplib.py", line 954, in endheaders

Re: [Users] Failure to migrate from one host out of four

[Martin Kletzander]

Hi,

Thanks for reporting this, I've found now where the problem is and it is
in libvirt. However this issue is not easy to fix as it reveals more
than just this one problem. The format for outputting floating point
numbers into JSON string seems to be locale-dependent. Could you send me
what locale are you having? I guess you could migrate the guest by
starting libvirt with "LC_ALL=C" set.

Martin

On 08/02/2012 02:01 PM, Karli Sjöberg wrote:
> Hi,
> 
> Wondering if anyone has encountered the same issue as me. On one host in
> my cluster, if I migrate in a guest, I cannot migrate it out to another
> host?  The get "stuck" there, so to speak. Same when a guest is started
> on that particular host, it is impossible to migrate them out again.
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Failure to migrate from one host out of four

[Martin Kletzander]

On 08/02/2012 03:10 PM, Karli Sjöberg wrote:
> 
> 2 aug 2012 kl. 15.05 skrev Martin Kletzander:
> 
>> Hi,
>>
>> Thanks for reporting this, I've found now where the problem is and it is
>> in libvirt. However this issue is not easy to fix as it reveals more
>> than just this one problem. The format for outputting floating point
>> numbers into JSON string seems to be locale-dependent. Could you send me
>> what locale are you having? I guess you could migrate the guest by
>> starting libvirt with "LC_ALL=C" set.
> 
> OK, wow, awesome! Sorry, I´m not too familiar with Fedora, more of a
> BSD-guy, in learning:) How do you change Locale to something more
> appropriate? And what does it like?
> 

If you want to set it for the whole system, I think it is in
/etc/sysconfig/i18n but I've never did that in Fedora and I bet there is
some GUI or at least a TUI interface for that (system-config-language
maybe?). Changing it might require you to reboot or re-login, but if you
don't want to do that or even if you don't want to change your locale
system-wide, just tell me, I'll help you figure out a procedure to start
libvirt without changing any of that.

However, this is really a bug in our code, so you shouldn't be pushed to
do that. I'm looking into that right now. Feel free to create a bug on
libvirt with the first log saying that our JSON is locale-dependant.

Martin
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users