[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Libvirt] Impossible de restarter les VMs



Le 03/08/2013 13:52, daniel huhardeaux a écrit :
> Le 03/08/2013 13:28, Sandro CAZZANIGA a écrit :
>> Le 03/08/2013 13:25, Sandro CAZZANIGA a écrit :
>>> Le 03/08/2013 13:18, Christophe a écrit :
>>>> Sandro CAZZANIGA a écrit :
>>>>> La valeur du port VNC est à -1, voici le fichier XML si ça peut aider.
>>>>>
>>>>>
>>>>> Merci :)
>>>>>
>>>>>
>>>> Hello,
>>>>
>>>> Il me semble que ca veut dire port automatique. ça ne doit pas venir de
>>>> la donc ...
>>>>
>>>> Par contre, et ca rejoint le lien qu'a envoyé Daniel, sur la ligne
>>>>
>>>>      <type arch='x86_64' machine='pc-1.1'>hvm</type>
>>>>
>>>> Les miennes sont en machine='pc' (sans version , qui semble t'il change
>>>> en fonction des versions de libvirt/kvm).
>>>> Peut être une piste par la donc ;) .
>>>>
>>>> @+
>>>> Christophe.
>>>>
>>> J'essaye de changer ça. Sinon:
>>>
>>> % virsh dumpxml Bugzilla | grep emulator
>>>      <emulator>/usr/bin/kvm</emulator>
>>>
>>> Je vous tiens au courant pour le changement de "pc-1.1" à "pc" :)
>>>
>> J'ai changé la valeur pour "pc", tenter de démarré la VM, sans succès,
>> puis restarter le démon libvirt, et restarter la VM, mais sans succès.
>>
>> Je cherche encore, mais merci de votre aide :)
> 
> Comme dit dans mon premier message, fournir le xml de la machine aurait
> été d'une utilité indéniable. Voici ce que j'ai pour mes VM
> 
> <vcpu>2</vcpu>
> <os>
>     <type arch='x86_64' machine='pc0.12'>hvm</type>
>     <boot dev='hd'/>
> </os>
> <features>
> <acpi/>
> <apic/>
> <pae/>
> </features>
>   <cpu match='exact'>
> <model>Nehalem</model>
> <vendor>Intel</vendor>
>     <feature policy='require' name='tm2'/>
>     <feature policy='require' name='est'/>
>     <feature policy='require' name='monitor'/>
>     <feature policy='require' name='ss'/>
>     <feature policy='require' name='vme'/>
>     <feature policy='require' name='rdtscp'/>
>     <feature policy='require' name='ht'/>
>     <feature policy='require' name='ds'/>
>     <feature policy='require' name='pbe'/>
>     <feature policy='require' name='tm'/>
>     <feature policy='require' name='vmx'/>
>     <feature policy='require' name='ds_cpl'/>
>     <feature policy='require' name='xtpr'/>
>     <feature policy='require' name='acpi'/>
>     <feature policy='disable' name='sse4.1'/>
>     <feature policy='disable' name='sse4.2'/>
> </cpu>
> 
> Sachant que /proc/cpuinfo
> 
> processor       : 3
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 30
> model name      : Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz
> stepping        : 5
> microcode       : 0x4
> cpu MHz         : 2393.677
> cache size      : 8192 KB
> physical id     : 0
> siblings        : 4
> core id         : 3
> cpu cores       : 4
> apicid          : 6
> initial apicid  : 6
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 11
> wp              : yes
> flags           : 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 pni dtes64 monitor ds_cpl vmx smx est
> tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm
> tpr_shadow vnmi flexpriority ept vpid
> bogomips        : 4787.76
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:
> 
> virt-manager te permet d'obtenir les bonnes vvaleurs si tu ne les
> connais pas
> 

D'accord, mais pourquoi ça aurait marché pendant 4 mois et puis d'un
coup, du jour au lendemain, sans aucun reboot de la machine, ça ne
marche plus?

-- 
Sandro Cazzaniga
Jabber: kharec@jabber.fr
Twitter: @Kharec

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: