Re: [Users] Auto-start vms on boot?

2012-12-09 Thread Alexandre Santos
Hi,
I'm not involved on the ovirt development, but here are my thoughts:
1. oVirt makes sense on a datacenter scenario, where there is always a HA
management server that takes care of everything, including the management
of all VMs state.
2. If you want such a tight relation between the host and the VMs running
on it, you don't need oVirt, just plain host virtualization, like the one
that comes on every linux distro with virt-manager.There you can install
and manage the VMs on a single host, forcing them to stop or start on host
shutdown or boot.
3. This is what I've been doing myself. Virt-manager can manage all hosts
running kvm/qemu but don't have this datacenter approach, where you store
your VMs on a SAN/iSCSI and you run you VMs on diskless hosts and can
migrate them as you which, for instance.

If the oVirt developers think that i?m missing something or that I'm wrong,
please come and correct me :-)

Alex

2012/12/9 Itamar Heim ih...@redhat.com

 On 12/09/2012 02:55 PM, Adrian Gibanel wrote:

 This is how I see it:

 Engine should have an offline database of its assigned hosts and their
 state (With state I mean properties. One of these properties would be
 the auto-start one).
 So when a host starts the engine starts and then loops assigned virtual
 machines. While looping the virtual machines checs its auto-start
 property. If it's set to true it starts the virtual machine.

 Not sure if what I am describing has an easy implementation with current
 oVirt architecture. Any comments from people who might understand better
 oVirt architecture on this use-case?

 I think the hosts should rely the least possible on the management server.


 my concern is how to make sure engine only starts VMs it should in this
 case.


 --**--**
 

 *De: *Itamar Heim ih...@redhat.com
 *Para: *Adrian Gibanel adrian.giba...@btactic.com
 *CC: *users users@ovirt.org
 *Enviados: *Viernes, 7 de Diciembre 2012 19:39:26
 *Asunto: *Re: [Users] Auto-start vms on boot?


 On 12/07/2012 06:23 PM, Adrian Gibanel wrote:
   My use case is that I just don't want to start manually the
 virtual machines when the host starts and, also, if the host is
 shutdown it should guest-shutdown the virtual machines.
  
   Any doc on that pin option? How one is supposed to pin a virtual
 machine to a host?

 just to be clear, we still don't have the behavior i described. I just
 stated the only use case i'm familiar for a similar requirement.
 (pinning a VM to host is done via the edit vm dialog).

 question on your use case - how would the engine know if the admin
 just
 shutdown a VM manually from a VM which should be auto started
 (should we
 add such a checkbox).
 in the use case i described, we would be adding a 'start/stop VM with
 host' for a VM pinned to a host.

  
   Thank you.
  
   - Mensaje original -
  
   On 12/06/2012 10:34 PM, Adrian Gibanel wrote:
   It would seem that oVirt does not provide an standard way of
   forcing boot of virtual machines at boot.
  
   Pools can have pre-started vms as stated here:
  
 https://access.redhat.com/**knowledge/docs/en-US/Red_Hat_**
 Enterprise_Virtualization/3.1/**html/Administration_Guide/**
 Prestarting_Virtual_Machines_**in_a_Pool.htmlhttps://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/Prestarting_Virtual_Machines_in_a_Pool.html
   but pools imply state-less virtual machines and I am talking more
   about normal virtual machines.
  
   I've found this script:
  
   https://github.com/iranzo/**rhevm-utils/blob/master/rhev-**
 vm-start.pyhttps://github.com/iranzo/rhevm-utils/blob/master/rhev-vm-start.py
  
   which could do to the trick if run at host boot.
  
   I've also thought (but not tried) to mark a virtual machine as
   Highly Available even if I have only one host (I mean, usually
   HA only makes sense when you have two hosts).
  
   Marking a VM as H.A. would do the trick?
   Any special reason why there isn't and standard way of marking
   which vms should be auto-started at boot?
  
   Just wanted to hear your thoughts before filling an RFE.
  
  
   Thank you.
  
   what exactly is your use case?
   the one i'm familiar with is to tie the VM life cycle to a
 specific
   host, so a VM which is pinned to a specific host for a certain
 task
   (say, IDS), is always starting when the host starts, and will be
   automatically shutdown when host is moved to maintenance.
   so only relevant for VMs which are pinned to a host.

 --
 http://www.btactic.com/***Adrián Gibanel*

 I.T. Manager

 +34 675 683 301
 www.btactic.com http://btactic.com/



 *
 Ens podeu seguir a/Nos podeis seguir en:

 

[Users] Cannot find suitable CPU model for given data

2012-12-09 Thread Cristian Falcas
Hi,

I get this error with the nightly builds when I start a VM:

libvirtError: internal error Cannot find suitable CPU model for given data


Log data:
Thread-654::DEBUG::2012-12-09 17:14:18,120::libvirtvm::1485::vm.Vm::(_run)
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::?xml version=1.0
encoding=utf-8?
domain type=kvm
nameq/name
uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/uuid
memory524288/memory
currentMemory524288/currentMemory
vcpu2/vcpu
devices
channel type=unix
target name=com.redhat.rhevm.vdsm type=virtio/
source mode=bind
path=/var/lib/libvirt/qemu/channels/q.com.redhat.rhevm.vdsm/
/channel
channel type=unix
target name=org.qemu.guest_agent.0
type=virtio/
source mode=bind
path=/var/lib/libvirt/qemu/channels/q.org.qemu.guest_agent.0/
/channel
input bus=ps2 type=mouse/
channel type=spicevmc
target name=com.redhat.spice.0 type=virtio/
/channel
graphics autoport=yes keymap=en-us listen=0
passwd=* passwdValidTo=1970-01-01T00:00:01 port=-1 tlsPort=-1
type=spice
channel mode=secure name=main/
channel mode=secure name=inputs/
channel mode=secure name=cursor/
channel mode=secure name=playback/
channel mode=secure name=record/
channel mode=secure name=display/
channel mode=secure name=usbredir/
channel mode=secure name=smartcard/
/graphics
console type=pty
target port=0 type=virtio/
/console
sound model=ac97/
video
model heads=1 type=qxl vram=65536/
/video
interface type=bridge
mac address=00:1a:4a:6f:6f:f4/
model type=virtio/
source bridge=ovirtmgmt/
filterref filter=vdsm-no-mac-spoofing/
/interface
memballoon model=virtio/
disk device=cdrom snapshot=no type=file
source
file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/4f6a2b90-9c70-45e5-8b17-5274ee97ce73/images/----/CentOS-6.3-x86_64-bin-DVD1.iso
startupPolicy=optional/
target bus=ide dev=hdc/
readonly/
serial/serial
boot order=1/
/disk
disk device=disk snapshot=no type=file
source
file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/81361e6d-2b58-4781-80c2-d908a0fe91cd/images/ffa8728f-6f0c-4b59-99ac-5bef0bd7634e/80a8701a-bf07-4d8a-8d02-8f98e6bb46a1/
target bus=virtio dev=vda/

serialffa8728f-6f0c-4b59-99ac-5bef0bd7634e/serial
driver cache=none error_policy=stop
io=threads name=qemu type=raw/
/disk
/devices
os
type arch=x86_64 machine=pc-0.14hvm/type
smbios mode=sysinfo/
/os
sysinfo type=smbios
system
entry name=manufactureroVirt/entry
entry name=productoVirt Node/entry
entry name=version17-1/entry
entry
name=serial30303146-4430-3946-3139-3938/entry
entry
name=uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/entry
/system
/sysinfo
clock adjustment=-43200 offset=variable
timer name=rtc tickpolicy=catchup/
/clock
features
acpi/
/features
cpu match=exact
modelOpteron_G3/model
topology cores=1 sockets=2 threads=1/
/cpu
/domain

Thread-654::DEBUG::2012-12-09
17:14:18,152::vm::672::vm.Vm::(_startUnderlyingVm)
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::_ongoingCreations released
Thread-654::ERROR::2012-12-09
17:14:18,152::vm::696::vm.Vm::(_startUnderlyingVm)
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::The vm start process failed
Traceback (most recent call last):
  File /usr/share/vdsm/vm.py, line 658, in _startUnderlyingVm
self._run()
  File /usr/share/vdsm/libvirtvm.py, line 1511, in _run
self._connection.createXML(domxml, flags),
  File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py, line
111, in wrapper
ret = f(*args, **kwargs)
  File /usr/lib64/python2.7/site-packages/libvirt.py, line 2633, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirtError: internal error Cannot find suitable CPU 

Re: [Users] Cannot find suitable CPU model for given data

2012-12-09 Thread Oved Ourfalli


- Original Message -
 From: Cristian Falcas cristi.fal...@gmail.com
 To: users@ovirt.org
 Sent: Sunday, December 9, 2012 5:17:01 PM
 Subject: [Users] Cannot find suitable CPU model for given data
 
 
 Hi,
 
 I get this error with the nightly builds when I start a VM:
 
 libvirtError: internal error Cannot find suitable CPU model for given
 data
 
 
 Log data:
 Thread-654::DEBUG::2012-12-09
 17:14:18,120::libvirtvm::1485::vm.Vm::(_run)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::?xml version=1.0
 encoding=utf-8?
 domain type=kvm
 nameq/name
 uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/uuid
 memory524288/memory
 currentMemory524288/currentMemory
 vcpu2/vcpu
 devices
 channel type=unix
 target name=com.redhat.rhevm.vdsm type=virtio/
 source mode=bind
 path=/var/lib/libvirt/qemu/channels/q.com.redhat.rhevm.vdsm/
 /channel
 channel type=unix
 target name=org.qemu.guest_agent.0 type=virtio/
 source mode=bind
 path=/var/lib/libvirt/qemu/channels/q.org.qemu.guest_agent.0/
 /channel
 input bus=ps2 type=mouse/
 channel type=spicevmc
 target name=com.redhat.spice.0 type=virtio/
 /channel
 graphics autoport=yes keymap=en-us listen=0 passwd=*
 passwdValidTo=1970-01-01T00:00:01 port=-1 tlsPort=-1
 type=spice
 channel mode=secure name=main/
 channel mode=secure name=inputs/
 channel mode=secure name=cursor/
 channel mode=secure name=playback/
 channel mode=secure name=record/
 channel mode=secure name=display/
 channel mode=secure name=usbredir/
 channel mode=secure name=smartcard/
 /graphics
 console type=pty
 target port=0 type=virtio/
 /console
 sound model=ac97/
 video
 model heads=1 type=qxl vram=65536/
 /video
 interface type=bridge
 mac address=00:1a:4a:6f:6f:f4/
 model type=virtio/
 source bridge=ovirtmgmt/
 filterref filter=vdsm-no-mac-spoofing/
 /interface
 memballoon model=virtio/
 disk device=cdrom snapshot=no type=file
 source
 file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/4f6a2b90-9c70-45e5-8b17-5274ee97ce73/images/----/CentOS-6.3-x86_64-bin-DVD1.iso
 startupPolicy=optional/
 target bus=ide dev=hdc/
 readonly/
 serial/serial
 boot order=1/
 /disk
 disk device=disk snapshot=no type=file
 source
 file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/81361e6d-2b58-4781-80c2-d908a0fe91cd/images/ffa8728f-6f0c-4b59-99ac-5bef0bd7634e/80a8701a-bf07-4d8a-8d02-8f98e6bb46a1/
 target bus=virtio dev=vda/
 serialffa8728f-6f0c-4b59-99ac-5bef0bd7634e/serial
 driver cache=none error_policy=stop io=threads name=qemu
 type=raw/
 /disk
 /devices
 os
 type arch=x86_64 machine=pc-0.14hvm/type
 smbios mode=sysinfo/
 /os
 sysinfo type=smbios
 system
 entry name=manufactureroVirt/entry
 entry name=productoVirt Node/entry
 entry name=version17-1/entry
 entry name=serial30303146-4430-3946-3139-3938/entry
 entry name=uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/entry
 /system
 /sysinfo
 clock adjustment=-43200 offset=variable
 timer name=rtc tickpolicy=catchup/
 /clock
 features
 acpi/
 /features
 cpu match=exact
 modelOpteron_G3/model
 topology cores=1 sockets=2 threads=1/
 /cpu
 /domain
 
 Thread-654::DEBUG::2012-12-09
 17:14:18,152::vm::672::vm.Vm::(_startUnderlyingVm)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::_ongoingCreations
 released
 Thread-654::ERROR::2012-12-09
 17:14:18,152::vm::696::vm.Vm::(_startUnderlyingVm)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::The vm start process
 failed
 Traceback (most recent call last):
 File /usr/share/vdsm/vm.py, line 658, in _startUnderlyingVm
 self._run()
 File /usr/share/vdsm/libvirtvm.py, line 1511, in _run
 self._connection.createXML(domxml, flags),
 File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py,
 line 111, in wrapper
 ret = f(*args, **kwargs)
 File /usr/lib64/python2.7/site-packages/libvirt.py, line 2633, in
 createXML
 if ret is None:raise libvirtError('virDomainCreateXML() failed',
 conn=self)
 libvirtError: internal error Cannot find suitable CPU model for given
 data
 Thread-654::DEBUG::2012-12-09
 17:14:18,156::vm::1045::vm.Vm::(setDownStatus)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::Changed state to Down:
 internal error Cannot find suitable CPU model for given data
 
 
Not sure I'm pointing you at the right direction, but perhaps reading the 
following link will help:
http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_different_model_from_the_hardware_documentation
(especially the last section).

Oved
 ___
 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] Cannot find suitable CPU model for given data

2012-12-09 Thread Roy Golan

On 12/09/2012 05:17 PM, Cristian Falcas wrote:

Hi,

I get this error with the nightly builds when I start a VM:


 please paste the output of the following command to see if Opteron_G3 
is really supported:

  vdsClient 0 -s getVdsCaps


libvirtError: internal error Cannot find suitable CPU model for given data


Log data:
Thread-654::DEBUG::2012-12-09 
17:14:18,120::libvirtvm::1485::vm.Vm::(_run) 
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::?xml version=1.0 
encoding=utf-8?

domain type=kvm
nameq/name
uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/uuid
memory524288/memory
currentMemory524288/currentMemory
vcpu2/vcpu
devices
channel type=unix
target name=com.redhat.rhevm.vdsm 
type=virtio/
source mode=bind 
path=/var/lib/libvirt/qemu/channels/q.com.redhat.rhevm.vdsm/

/channel
channel type=unix
target name=org.qemu.guest_agent.0 
type=virtio/
source mode=bind 
path=/var/lib/libvirt/qemu/channels/q.org.qemu.guest_agent.0/

/channel
input bus=ps2 type=mouse/
channel type=spicevmc
target name=com.redhat.spice.0 type=virtio/
/channel
graphics autoport=yes keymap=en-us listen=0 
passwd=* passwdValidTo=1970-01-01T00:00:01 port=-1 
tlsPort=-1 type=spice

channel mode=secure name=main/
channel mode=secure name=inputs/
channel mode=secure name=cursor/
channel mode=secure name=playback/
channel mode=secure name=record/
channel mode=secure name=display/
channel mode=secure name=usbredir/
channel mode=secure name=smartcard/
/graphics
console type=pty
target port=0 type=virtio/
/console
sound model=ac97/
video
model heads=1 type=qxl vram=65536/
/video
interface type=bridge
mac address=00:1a:4a:6f:6f:f4/
model type=virtio/
source bridge=ovirtmgmt/
filterref filter=vdsm-no-mac-spoofing/
/interface
memballoon model=virtio/
disk device=cdrom snapshot=no type=file
source 
file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/4f6a2b90-9c70-45e5-8b17-5274ee97ce73/images/----/CentOS-6.3-x86_64-bin-DVD1.iso 
startupPolicy=optional/

target bus=ide dev=hdc/
readonly/
serial/serial
boot order=1/
/disk
disk device=disk snapshot=no type=file
source 
file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/81361e6d-2b58-4781-80c2-d908a0fe91cd/images/ffa8728f-6f0c-4b59-99ac-5bef0bd7634e/80a8701a-bf07-4d8a-8d02-8f98e6bb46a1/

target bus=virtio dev=vda/
serialffa8728f-6f0c-4b59-99ac-5bef0bd7634e/serial
driver cache=none error_policy=stop 
io=threads name=qemu type=raw/

/disk
/devices
os
type arch=x86_64 machine=pc-0.14hvm/type
smbios mode=sysinfo/
/os
sysinfo type=smbios
system
entry name=manufactureroVirt/entry
entry name=productoVirt Node/entry
entry name=version17-1/entry
entry 
name=serial30303146-4430-3946-3139-3938/entry
entry 
name=uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/entry

/system
/sysinfo
clock adjustment=-43200 offset=variable
timer name=rtc tickpolicy=catchup/
/clock
features
acpi/
/features
cpu match=exact
modelOpteron_G3/model
topology cores=1 sockets=2 threads=1/
/cpu
/domain

Thread-654::DEBUG::2012-12-09 
17:14:18,152::vm::672::vm.Vm::(_startUnderlyingVm) 
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::_ongoingCreations released
Thread-654::ERROR::2012-12-09 
17:14:18,152::vm::696::vm.Vm::(_startUnderlyingVm) 
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::The vm start process failed

Traceback (most recent call last):
  File /usr/share/vdsm/vm.py, line 658, in _startUnderlyingVm
self._run()
  File /usr/share/vdsm/libvirtvm.py, line 1511, in _run
self._connection.createXML(domxml, flags),
  File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py, 
line 111, in wrapper

ret = f(*args, **kwargs)
  File 

Re: [Users] Auto-start vms on boot?

2012-12-09 Thread Itamar Heim

On 12/09/2012 05:11 PM, Alexandre Santos wrote:

Hi,
I'm not involved on the ovirt development, but here are my thoughts:
1. oVirt makes sense on a datacenter scenario, where there is always a
HA management server that takes care of everything, including the
management of all VMs state.
2. If you want such a tight relation between the host and the VMs
running on it, you don't need oVirt, just plain host virtualization,
like the one that comes on every linux distro with virt-manager.There
you can install and manage the VMs on a single host, forcing them to
stop or start on host shutdown or boot.


the 'tight' relation in the use case i mentioned is only for some of the 
VMs which serve a specific purpose on each host (say, an IDS virtual 
appliance for all traffic on a specific host).

the rest of the VMs would be 'normal'.


3. This is what I've been doing myself. Virt-manager can manage all
hosts running kvm/qemu but don't have this datacenter approach, where
you store your VMs on a SAN/iSCSI and you run you VMs on diskless hosts
and can migrate them as you which, for instance.

If the oVirt developers think that i?m missing something or that I'm
wrong, please come and correct me :-)


I'm just trying to understand your use case to see how it can be resolved.
(btw, you can probably easily script this via the api/sdk/cli with a 
small script checking a list of VMs are always up. I just wonder how 
you'll know they aren't meant to be down by admin)
would the admin have to disable the 'auto start' config before shutting 
down the VM, or else the engine will auto-start it again?




Alex

2012/12/9 Itamar Heim ih...@redhat.com mailto:ih...@redhat.com

On 12/09/2012 02:55 PM, Adrian Gibanel wrote:

This is how I see it:

Engine should have an offline database of its assigned hosts and
their
state (With state I mean properties. One of these properties
would be
the auto-start one).
So when a host starts the engine starts and then loops assigned
virtual
machines. While looping the virtual machines checs its auto-start
property. If it's set to true it starts the virtual machine.

Not sure if what I am describing has an easy implementation with
current
oVirt architecture. Any comments from people who might
understand better
oVirt architecture on this use-case?

I think the hosts should rely the least possible on the
management server.


my concern is how to make sure engine only starts VMs it should in
this case.



--__--__

 *De: *Itamar Heim ih...@redhat.com
mailto:ih...@redhat.com
 *Para: *Adrian Gibanel adrian.giba...@btactic.com
mailto:adrian.giba...@btactic.com
 *CC: *users users@ovirt.org mailto:users@ovirt.org
 *Enviados: *Viernes, 7 de Diciembre 2012 19:39:26
 *Asunto: *Re: [Users] Auto-start vms on boot?


 On 12/07/2012 06:23 PM, Adrian Gibanel wrote:
   My use case is that I just don't want to start manually the
 virtual machines when the host starts and, also, if the host is
 shutdown it should guest-shutdown the virtual machines.
  
   Any doc on that pin option? How one is supposed to pin a
virtual
 machine to a host?

 just to be clear, we still don't have the behavior i
described. I just
 stated the only use case i'm familiar for a similar
requirement.
 (pinning a VM to host is done via the edit vm dialog).

 question on your use case - how would the engine know if
the admin just
 shutdown a VM manually from a VM which should be auto started
 (should we
 add such a checkbox).
 in the use case i described, we would be adding a
'start/stop VM with
 host' for a VM pinned to a host.

  
   Thank you.
  
   - Mensaje original -
  
   On 12/06/2012 10:34 PM, Adrian Gibanel wrote:
   It would seem that oVirt does not provide an standard
way of
   forcing boot of virtual machines at boot.
  
   Pools can have pre-started vms as stated here:
  

https://access.redhat.com/__knowledge/docs/en-US/Red_Hat___Enterprise_Virtualization/3.1/__html/Administration_Guide/__Prestarting_Virtual_Machines___in_a_Pool.html

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/Prestarting_Virtual_Machines_in_a_Pool.html
   but pools imply state-less virtual machines and I am
talking more
   about normal virtual machines.
  
   

Re: [Users] template source always Blank

2012-12-09 Thread Itamar Heim

On 12/09/2012 07:28 PM, Jim Kinney wrote:

Greetings,

I've built several new templates from the blank template and a ISO
install of various OS's. However, when I built a new VM using the new
template(s), the new VM still says it's based from the blank template. I
expected it to say it was from the template-foo U specified. The VM is
correctly built from the template so I think it's a generation/database
issue.



I'm guessing you used 'clone' (default for new server) rather than 
'thinly provisioned' (default for new desktop).
clone means the template disk is copied/cloned for better performance, 
rather than COW (less space).
when the disk is cloned, there is no longer a relation to the original 
template at storage level.




--
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What
you gain at one end you lose at the other. It's like feeding a dog on
his own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://electjimkinney.org
http://heretothereideas.blogspot.com/



___
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] mislabelled template source

2012-12-09 Thread Jim Kinney
Greetings,

I've built several new templates from the blank template and a ISO install
of various OS's. However, when I built a new VM using the new template(s),
the new VM still says it's based from the blank template. I expected it to
say it was from the template-foo U specified. The VM is correctly built
from the template so I think it's a generation/database issue.

-- 
-- 
James P. Kinney III
*
*Every time you stop a school, you will have to build a jail. What you gain
at one end you lose at the other. It's like feeding a dog on his own tail.
It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
*
http://electjimkinney.org
http://heretothereideas.blogspot.com/
*
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Cannot find suitable CPU model for given data

2012-12-09 Thread Cristian Falcas
On Sun, Dec 9, 2012 at 5:37 PM, Roy Golan rgo...@redhat.com wrote:

  On 12/09/2012 05:17 PM, Cristian Falcas wrote:

 Hi,

 I get this error with the nightly builds when I start a VM:


  please paste the output of the following command to see if Opteron_G3 is
 really supported:
   vdsClient 0 -s getVdsCaps


 libvirtError: internal error Cannot find suitable CPU model for given data


 Log data:
 Thread-654::DEBUG::2012-12-09 17:14:18,120::libvirtvm::1485::vm.Vm::(_run)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::?xml version=1.0
 encoding=utf-8?
 domain type=kvm
 nameq/name
 uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/uuid
 memory524288/memory
 currentMemory524288/currentMemory
 vcpu2/vcpu
 devices
 channel type=unix
 target name=com.redhat.rhevm.vdsm
 type=virtio/
 source mode=bind
 path=/var/lib/libvirt/qemu/channels/q.com.redhat.rhevm.vdsm/
 /channel
 channel type=unix
 target name=org.qemu.guest_agent.0
 type=virtio/
 source mode=bind
 path=/var/lib/libvirt/qemu/channels/q.org.qemu.guest_agent.0/
 /channel
 input bus=ps2 type=mouse/
 channel type=spicevmc
 target name=com.redhat.spice.0 type=virtio/
 /channel
 graphics autoport=yes keymap=en-us listen=0
 passwd=* passwdValidTo=1970-01-01T00:00:01 port=-1 tlsPort=-1
 type=spice
 channel mode=secure name=main/
 channel mode=secure name=inputs/
 channel mode=secure name=cursor/
 channel mode=secure name=playback/
 channel mode=secure name=record/
 channel mode=secure name=display/
 channel mode=secure name=usbredir/
 channel mode=secure name=smartcard/
 /graphics
 console type=pty
 target port=0 type=virtio/
 /console
 sound model=ac97/
 video
 model heads=1 type=qxl vram=65536/
 /video
 interface type=bridge
 mac address=00:1a:4a:6f:6f:f4/
 model type=virtio/
 source bridge=ovirtmgmt/
 filterref filter=vdsm-no-mac-spoofing/
 /interface
 memballoon model=virtio/
 disk device=cdrom snapshot=no type=file
 source
 file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/4f6a2b90-9c70-45e5-8b17-5274ee97ce73/images/----/CentOS-6.3-x86_64-bin-DVD1.iso
 startupPolicy=optional/
 target bus=ide dev=hdc/
 readonly/
 serial/serial
 boot order=1/
 /disk
 disk device=disk snapshot=no type=file
 source
 file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/81361e6d-2b58-4781-80c2-d908a0fe91cd/images/ffa8728f-6f0c-4b59-99ac-5bef0bd7634e/80a8701a-bf07-4d8a-8d02-8f98e6bb46a1/
 target bus=virtio dev=vda/

 serialffa8728f-6f0c-4b59-99ac-5bef0bd7634e/serial
 driver cache=none error_policy=stop
 io=threads name=qemu type=raw/
 /disk
 /devices
 os
 type arch=x86_64 machine=pc-0.14hvm/type
 smbios mode=sysinfo/
 /os
 sysinfo type=smbios
 system
 entry name=manufactureroVirt/entry
 entry name=productoVirt Node/entry
 entry name=version17-1/entry
 entry
 name=serial30303146-4430-3946-3139-3938/entry
 entry
 name=uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/entry
 /system
 /sysinfo
 clock adjustment=-43200 offset=variable
 timer name=rtc tickpolicy=catchup/
 /clock
 features
 acpi/
 /features
 cpu match=exact
 modelOpteron_G3/model
 topology cores=1 sockets=2 threads=1/
 /cpu
 /domain

 Thread-654::DEBUG::2012-12-09
 17:14:18,152::vm::672::vm.Vm::(_startUnderlyingVm)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::_ongoingCreations released
 Thread-654::ERROR::2012-12-09
 17:14:18,152::vm::696::vm.Vm::(_startUnderlyingVm)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::The vm start process failed
 Traceback (most recent call last):
   File /usr/share/vdsm/vm.py, line 658, in _startUnderlyingVm
 self._run()
   File /usr/share/vdsm/libvirtvm.py, line 1511, in _run
 

Re: [Users] Cannot find suitable CPU model for given data

2012-12-09 Thread Cristian Falcas
On Sun, Dec 9, 2012 at 5:37 PM, Roy Golan rgo...@redhat.com wrote:

  On 12/09/2012 05:17 PM, Cristian Falcas wrote:

 Hi,

 I get this error with the nightly builds when I start a VM:


  please paste the output of the following command to see if Opteron_G3 is
 really supported:
   vdsClient 0 -s getVdsCaps


 libvirtError: internal error Cannot find suitable CPU model for given data


 Log data:
 Thread-654::DEBUG::2012-12-09 17:14:18,120::libvirtvm::1485::vm.Vm::(_run)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::?xml version=1.0
 encoding=utf-8?
 domain type=kvm
 nameq/name
 uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/uuid
 memory524288/memory
 currentMemory524288/currentMemory
 vcpu2/vcpu
 devices
 channel type=unix
 target name=com.redhat.rhevm.vdsm
 type=virtio/
 source mode=bind
 path=/var/lib/libvirt/qemu/channels/q.com.redhat.rhevm.vdsm/
 /channel
 channel type=unix
 target name=org.qemu.guest_agent.0
 type=virtio/
 source mode=bind
 path=/var/lib/libvirt/qemu/channels/q.org.qemu.guest_agent.0/
 /channel
 input bus=ps2 type=mouse/
 channel type=spicevmc
 target name=com.redhat.spice.0 type=virtio/
 /channel
 graphics autoport=yes keymap=en-us listen=0
 passwd=* passwdValidTo=1970-01-01T00:00:01 port=-1 tlsPort=-1
 type=spice
 channel mode=secure name=main/
 channel mode=secure name=inputs/
 channel mode=secure name=cursor/
 channel mode=secure name=playback/
 channel mode=secure name=record/
 channel mode=secure name=display/
 channel mode=secure name=usbredir/
 channel mode=secure name=smartcard/
 /graphics
 console type=pty
 target port=0 type=virtio/
 /console
 sound model=ac97/
 video
 model heads=1 type=qxl vram=65536/
 /video
 interface type=bridge
 mac address=00:1a:4a:6f:6f:f4/
 model type=virtio/
 source bridge=ovirtmgmt/
 filterref filter=vdsm-no-mac-spoofing/
 /interface
 memballoon model=virtio/
 disk device=cdrom snapshot=no type=file
 source
 file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/4f6a2b90-9c70-45e5-8b17-5274ee97ce73/images/----/CentOS-6.3-x86_64-bin-DVD1.iso
 startupPolicy=optional/
 target bus=ide dev=hdc/
 readonly/
 serial/serial
 boot order=1/
 /disk
 disk device=disk snapshot=no type=file
 source
 file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/81361e6d-2b58-4781-80c2-d908a0fe91cd/images/ffa8728f-6f0c-4b59-99ac-5bef0bd7634e/80a8701a-bf07-4d8a-8d02-8f98e6bb46a1/
 target bus=virtio dev=vda/

 serialffa8728f-6f0c-4b59-99ac-5bef0bd7634e/serial
 driver cache=none error_policy=stop
 io=threads name=qemu type=raw/
 /disk
 /devices
 os
 type arch=x86_64 machine=pc-0.14hvm/type
 smbios mode=sysinfo/
 /os
 sysinfo type=smbios
 system
 entry name=manufactureroVirt/entry
 entry name=productoVirt Node/entry
 entry name=version17-1/entry
 entry
 name=serial30303146-4430-3946-3139-3938/entry
 entry
 name=uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/entry
 /system
 /sysinfo
 clock adjustment=-43200 offset=variable
 timer name=rtc tickpolicy=catchup/
 /clock
 features
 acpi/
 /features
 cpu match=exact
 modelOpteron_G3/model
 topology cores=1 sockets=2 threads=1/
 /cpu
 /domain

 Thread-654::DEBUG::2012-12-09
 17:14:18,152::vm::672::vm.Vm::(_startUnderlyingVm)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::_ongoingCreations released
 Thread-654::ERROR::2012-12-09
 17:14:18,152::vm::696::vm.Vm::(_startUnderlyingVm)
 vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::The vm start process failed
 Traceback (most recent call last):
   File /usr/share/vdsm/vm.py, line 658, in _startUnderlyingVm
 self._run()
   File /usr/share/vdsm/libvirtvm.py, line 1511, in _run
 

Re: [Users] template source always Blank

2012-12-09 Thread Jim Kinney
That _is_ what I did!

Hmm. Makes it an external process to track VM lineage without that data.

So use the thin-provision only to allow this tracking. And this works with
windows VMs? will test shortly.

On Sun, Dec 9, 2012 at 12:41 PM, Itamar Heim ih...@redhat.com wrote:

 On 12/09/2012 07:28 PM, Jim Kinney wrote:

 Greetings,

 I've built several new templates from the blank template and a ISO
 install of various OS's. However, when I built a new VM using the new
 template(s), the new VM still says it's based from the blank template. I
 expected it to say it was from the template-foo U specified. The VM is
 correctly built from the template so I think it's a generation/database
 issue.


 I'm guessing you used 'clone' (default for new server) rather than 'thinly
 provisioned' (default for new desktop).
 clone means the template disk is copied/cloned for better performance,
 rather than COW (less space).
 when the disk is cloned, there is no longer a relation to the original
 template at storage level.


 --
 --
 James P. Kinney III
 
 Every time you stop a school, you will have to build a jail. What

 you gain at one end you lose at the other. It's like feeding a dog on
 his own tail. It won't fatten the dog.
 - Speech 11/23/1900 Mark Twain
 
 http://electjimkinney.org
 http://heretothereideas.**blogspot.com/http://heretothereideas.blogspot.com/
 


 __**_
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/**mailman/listinfo/usershttp://lists.ovirt.org/mailman/listinfo/users






-- 
-- 
James P. Kinney III
*
*Every time you stop a school, you will have to build a jail. What you gain
at one end you lose at the other. It's like feeding a dog on his own tail.
It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
*
http://electjimkinney.org
http://heretothereideas.blogspot.com/
*
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Cannot find suitable CPU model for given data

2012-12-09 Thread Itamar Heim

On 12/09/2012 11:22 PM, Cristian Falcas wrote:




On Sun, Dec 9, 2012 at 5:37 PM, Roy Golan rgo...@redhat.com
mailto:rgo...@redhat.com wrote:

On 12/09/2012 05:17 PM, Cristian Falcas wrote:

Hi,

I get this error with the nightly builds when I start a VM:


  please paste the output of the following command to see if
Opteron_G3 is really supported:
   vdsClient 0 -s getVdsCaps


libvirtError: internal error Cannot find suitable CPU model for
given data


Log data:
Thread-654::DEBUG::2012-12-09
17:14:18,120::libvirtvm::1485::vm.Vm::(_run)
vmId=`a4a8f349-7fdf-42f4-873e-e70f692c6ca2`::?xml version=1.0
encoding=utf-8?
domain type=kvm
nameq/name
uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/uuid
memory524288/memory
currentMemory524288/currentMemory
vcpu2/vcpu
devices
channel type=unix
target name=com.redhat.rhevm.vdsm
type=virtio/
source mode=bind
path=/var/lib/libvirt/qemu/channels/q.com.redhat.rhevm.vdsm/
/channel
channel type=unix
target name=org.qemu.guest_agent.0
type=virtio/
source mode=bind
path=/var/lib/libvirt/qemu/channels/q.org.qemu.guest_agent.0/
/channel
input bus=ps2 type=mouse/
channel type=spicevmc
target name=com.redhat.spice.0
type=virtio/
/channel
graphics autoport=yes keymap=en-us listen=0
passwd=* passwdValidTo=1970-01-01T00:00:01 port=-1
tlsPort=-1 type=spice
channel mode=secure name=main/
channel mode=secure name=inputs/
channel mode=secure name=cursor/
channel mode=secure name=playback/
channel mode=secure name=record/
channel mode=secure name=display/
channel mode=secure name=usbredir/
channel mode=secure name=smartcard/
/graphics
console type=pty
target port=0 type=virtio/
/console
sound model=ac97/
video
model heads=1 type=qxl vram=65536/
/video
interface type=bridge
mac address=00:1a:4a:6f:6f:f4/
model type=virtio/
source bridge=ovirtmgmt/
filterref filter=vdsm-no-mac-spoofing/
/interface
memballoon model=virtio/
disk device=cdrom snapshot=no type=file
source

file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/4f6a2b90-9c70-45e5-8b17-5274ee97ce73/images/----/CentOS-6.3-x86_64-bin-DVD1.iso
startupPolicy=optional/
target bus=ide dev=hdc/
readonly/
serial/serial
boot order=1/
/disk
disk device=disk snapshot=no type=file
source

file=/rhev/data-center/21ddcd50-aba8-461a-9ecf-c5762af89355/81361e6d-2b58-4781-80c2-d908a0fe91cd/images/ffa8728f-6f0c-4b59-99ac-5bef0bd7634e/80a8701a-bf07-4d8a-8d02-8f98e6bb46a1/
target bus=virtio dev=vda/
serialffa8728f-6f0c-4b59-99ac-5bef0bd7634e/serial
driver cache=none error_policy=stop
io=threads name=qemu type=raw/
/disk
/devices
os
type arch=x86_64 machine=pc-0.14hvm/type
smbios mode=sysinfo/
/os
sysinfo type=smbios
system
entry name=manufactureroVirt/entry
entry name=productoVirt Node/entry
entry name=version17-1/entry
entry
name=serial30303146-4430-3946-3139-3938/entry
entry
name=uuida4a8f349-7fdf-42f4-873e-e70f692c6ca2/entry
/system
/sysinfo
clock adjustment=-43200 offset=variable
timer name=rtc tickpolicy=catchup/
/clock
features
acpi/
/features
cpu match=exact
modelOpteron_G3/model
topology cores=1 sockets=2 threads=1/
/cpu
/domain

Thread-654::DEBUG::2012-12-09
17:14:18,152::vm::672::vm.Vm::(_startUnderlyingVm)