Re: [libvirt] Preferred CPU model not allowed by hypervisor
- Original Message - From: Jared list-v...@legroom.net To: libvir-list@redhat.com Sent: Saturday, July 21, 2012 5:46:18 AM Subject: [libvirt] Preferred CPU model not allowed by hypervisor Hi. I'm having a weird problem where libvirt/qemu/kvm won't let me use the model processor I have defined in my domain's config file. Instead, I get the error message in libvirtd.log that: warning : x86Decode:1346 : Preferred CPU model Nehalem not allowed by hypervisor; closest supported model will be used If I review the qemu log for that particular domain, I see that my CPU has been changed to this: -cpu kvm64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3 (in other places, I see it set to core2duo rather than kvm64) However, it *should* be Nehalem. For some background, I'm running lvm on a westmere proc, which is the successor to Nehalem. I'm specifying Nehalem as the target platform, though, to make it easier to migrate to another server if necessary. I do have this same problem if I set this to Westmere, though, so it's not unique to Nehalem. As for support and capabilities, libvirt correctly detects my host CPU as Westmere: $ virsh capabilities | grep model modelWestmere/model qemu-kvm does (as far as I can tell) support Nehalem: $ qemu-kvm -cpu ?model | grep Nehalem x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) Nehalem is defined in qmeu's target-x86_64.conf: grep Nehalem /etc/qemu/target-x86_64.conf name = Nehalem model_id = Intel Core i7 9xx (Nehalem Class Core i7) And if I run a cpu check on the processor, it seems to work fine: $ qemu-kvm -cpu Nehalem,check VNC server running on `127.0.0.1:5900' So, I I'm creating the new domain as a virt-install with the qemu-kvm backend as follows: virt-install --name=test --ram=1024 --arch=x86_64 --vcpus=2 --cpu=Nehalem --virt-type=kvm SNIP This results in the following cpu configuration: cpu mode='custom' match='exact' model fallback='allow'Nehalem/model /cpu But then, when I start this domain, I get the error message posted above. Any ideas what's going on here? I'm at a loss, and unfortunately I don't have much experience with kvm/libvirt just yet so I don't know what I should be focusing on for troubleshooting. Would appreciate any suggestions or guidance. Have a look here https://bugzilla.redhat.com/show_bug.cgi?id=804224 Thanks. -- Jared -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
- Original Message - From: Anthony Liguori anth...@codemonkey.ws To: Daniel P. Berrange berra...@redhat.com, libvir-list@redhat.com, qemu-de...@nongnu.org, Gleb Natapov g...@redhat.com, Jiri Denemark jdene...@redhat.com, Avi Kivity a...@redhat.com, a...@ovirt.org Sent: Saturday, March 10, 2012 1:24:47 PM Subject: Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt On 03/10/2012 09:58 AM, Eduardo Habkost wrote: On Sat, Mar 10, 2012 at 12:42:46PM +, Daniel P. Berrange wrote: I could have sworn we had this discussion a year ago or so, and had decided that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf would be solely for end user configuration changes, not for QEMU builtin defaults. But looking at the code in QEMU, it doesn't seem we ever implemented this ? Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but, contrary to our normal RHEL development practice, it was not based on a cherry-pick of an upstream patch :-( For sake of reference, I'm attaching the two patches from the RHEL6 source RPM that do what I'm describing NB, I'm not neccessarily advocating these patches for upstream. I still maintain that libvirt should write out a config file containing the exact CPU model description it desires and specify that with -readconfig. The end result would be identical from QEMU's POV and it would avoid playing games with QEMU's config loading code. I agree that libvirt should just write the config somewhere. The problem here is to define: 1) what information should be mandatory on that config data; 2) who should be responsible to test and maintain sane defaults (and where should they be maintained). The current cpudef definitions are simply too low-level to require it to be written from scratch. Lots of testing have to be done to make sure we have working combinations of CPUID bits defined, so they can be used as defaults or templates. Not facilitating reuse of those tested defauls/templates by libvirt is duplication of efforts. Really, if we expect libvirt to define all the CPU bits from scratch on a config file, we could as well just expect libvirt to open /dev/kvm itself and call the all CPUID setup ioctl()s itself. That's how low-level some of the cpudef bits are. Let's step back here. Why are you writing these patches? It's probably not because you have a desire to say -cpu Westmere when you run QEMU on your laptop. I'd wager to say that no human has ever done that or that if they had, they did so by accident because they read documentation and thought they had to. Humans probably do one of two things: 1) no cpu option or 2) -cpu host. So then why are you introducing -cpu Westmere? Because ovirt-engine has a concept of datacenters and the entire datacenter has to use a compatible CPU model to allow migration compatibility. Today, the interface that ovirt-engine exposes is based on CPU codenames. Presumably ovirt-engine wants to add a Westmere CPU group and as such have levied a requirement down the stack to QEMU. But there's no intrinsic reason why it uses CPU model names. VMware doesn't do this. It has a concept of compatibility groups[1]. s/has/had That was back in the 3.5 days and it was hit and miss, it relied on a user putting the same kind of machines in the resource groups and often caused issues. Now they've moved up to a model very similar to what we're using: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1003212 oVirt could just as well define compatibility groups like GroupA, GroupB, GroupC, etc. and then the -cpu option we would be discussing would be -cpu GroupA. This is why it's a configuration option and not builtin to QEMU. It's a user interface as as such, should be defined at a higher level. Perhaps it really should be VDSM that is providing the model info to libvirt? Then they can add whatever groups then want whenever they want as long as we have the appropriate feature bits. I think the real (model specific) names are the best place to start. But if a user wants to override those with their own specific types then it should be allowed P.S. I spent 30 minutes the other day helping a user who was attempting to figure out whether his processor was a Conroe, Penryn, etc. Making this determination is fairly difficult and it makes me wonder whether having CPU code names is even the best interface for oVirt.. I think that was more about a bad choice in UI than a bad choice in the architecture. It should be made clear to a user what kind of machine they have and what it's capabilities are This bug was borne out of that issue
Re: [libvirt] KVM Windows guest: add hard drive
- Original Message - From: Mihamina Rakotomandimby miham...@gulfsat.mg To: virt-tools-l...@redhat.com, Libvirt Developers Mailing List libvir-list@redhat.com Sent: Tuesday, October 12, 2010 2:17:49 PM Subject: [libvirt] KVM Windows guest: add hard drive Manao ahoana, Hello, Bonjour, I installed a Windows (XP and 2003) guest using one partition as hard drive. I used: sudo virt-install --connect qemu:///system \ --name win2003-01 \ --ram 1024 \ --keymap=fr \ --disk path=/dev/lvm0/win2003-01 \ --cdrom=/home/mihamina/Windows_2003_Server.iso \ --os-type windows \ --os-variant=win2k3 \ --noapic \ --noacpi \ --network=bridge:br0 \ --accelerate \ --vnc \ --force And this works fine. Really fine. The disk section in the definition: disk type='block' device='disk' source dev='/dev/lvm0/win2003-01'/ target dev='hda' bus='ide'/ /disk After installation, people asked me to add another hard drive to this installation, and then, I added another disk in the definition: disk type='block' device='disk' source dev='/dev/lvm0/win2003-01'/ target dev='hda' bus='ide'/ /disk disk type='block' device='disk' source dev='/dev/lvm0/win2003-01-a'/ target dev='hdb' bus='ide'/ /disk I destroyed + undefined + defined + started the VM and the definition is OK (dumpxml), but the Windows guest doesnt see any new hard drive. I already tried with replacing ide with virtio, no new hard drive yet. This is my configuration: miham...@kvm-lxc-02:~$ dpkg -l | grep virt ii kvm 72+dfsg-5~lenny5 Full virtualization on x86 hardware ii libvirt-bin 0.4.6-10 the programs for the libvirt library ii libvirt0 0.4.6-10 library for interfacing with different virtualization systems ii python-libvirt 0.4.6-10 libvirt Python bindings ii virt-manager 0.6.0-6 desktop application for managing virtual machines ii virt-viewer 0.0.3-2 Displaying the graphical console of a virtual machine ii virtinst 0.400.0-7 Programs to create and clone virtual machines How to make, with this, new hard drive recognized by the Windows guest? Are you looking for a new driver to appear in 'my computer', because it wouldn't appear there until you format it. Does it show up in device manager? Misaotra, Thanks, Merci. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche Developpement +261 34 56 000 19 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] SVG sources for the libvirt wiki images is online
do you have the libvirt logo as svg? - Justin Clift jcl...@redhat.com wrote: From: Justin Clift jcl...@redhat.com To: Libvirt Developers Mailing List libvir-list@redhat.com Sent: Thursday, September 9, 2010 9:56:48 AM GMT -05:00 US/Canada Eastern Subject: [libvirt] SVG sources for the libvirt wiki images is online Hi all, The SVG sources for the images used in the libvirt wiki docs are online: http://wiki.libvirt.org/page/SVGImages That's a browsable list, still fairly disorganised (!), but contains a visual list of the images on the wiki so far, with the link to their SVG source. They're all licensed under the Creative Commons Attribution–Share Alike 3.0 Unported license (CC-BY-SA): http://creativecommons.org/licenses/by-sa/3.0/ Feel welcome to use them in your wiki's, improve them, and so on. Updates, ideas, and contributions welcome too of course. :) Regards and best wishes, Justin Clift -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] using sync_manager with libvirt
- Perry Myers pmy...@redhat.com wrote: From: Perry Myers pmy...@redhat.com To: David Teigland teigl...@redhat.com Cc: libvir-list@redhat.com Sent: Sunday, August 22, 2010 12:13:16 PM GMT -05:00 US/Canada Eastern Subject: Re: [libvirt] using sync_manager with libvirt On 08/19/2010 01:23 PM, David Teigland wrote: On Thu, Aug 19, 2010 at 11:12:25AM -0400, David Teigland wrote: I'm only aware of one goal, and the current plan is to implement it correctly and completely. That goal is to lock vm images so if the vm happens to run on two hosts, only one instance can access the image. Ok. So for the first implementation of sync_manager it will still be possible for someone to corrupt data by configuring two separate vms to accidentally use the same storage volumes. That's fine for the first pass, just something to keep in mind for later. Presumably it'll use support the shareable/ flag for shared disks. (That's slightly misleading; technically, the lock prevents a second qemu process from even being started.) ack Perry -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] iptables rules for a vm
On Tue, 2008-12-09 at 17:30 -0500, Karl Wirth wrote: Hello, I have kicked around an idea before with some of you about iptables...basically being able to have iptables rules that are associated with the metadata around a particular vm, then apply those to the host iptables when the vm is spun up or migrated to that host. Especially the interesting issues around taking the nf/ip_conntrack data and making sure that state information is correctly migrated. I emailed with James he thinks the pieces are there but integration work is needed (as well as the central management). Would someone be willing to help me understand what major pieces of work would be needed to make this possible? Regards, Karl -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt_low_level_storage_api
return: success/failure removeLV(VG,LV): params: VG - Volume Group UUID LV - Logical Volume UUID description: return: snapshotLV(VG, LV, size): params: VG - Volume Group UUID LV - Logical Volume UUID size - Initial size of snapshot volume description: creeates a snapshot of LV return: UUID of snapshot -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list Andrew Cathrow Red Hat, Inc. (678) 733 0452 - Mobile (978) 392-2482 - Office [EMAIL PROTECTED] -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] breaking out of virsh console?
On Thu, 2008-08-14 at 11:23 -0700, Schroeder, Paul wrote: Hello all... In my VM's inittab, I set agetty to run on ttyS0 so I could do virsh console myvm and log in from the host machine's command line. It works perfectly. Trouble is, I don't know how to break out of it to get back to the command line on my host. I've only been able to do so by killing the virsh process. There's gotta be a better way.. Right? ctrl + ] Thanks...Paul... -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Reusing dumpxml output
On Thu, 2008-08-14 at 10:12 +0100, Daniel P. Berrange wrote: There is also the option to request the 'inactive' XML dump for a running domain which removes any auto-allocated params. This is just a convenience though, and not required for re-creating the VM later. What version is this in I don't see this in the F9 virsh (libvir 0.4.4) or is it just not documented. Daniel -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Adding devices to a vm using virsh
On Mon, 2008-04-21 at 10:59 +0100, Richard W.M. Jones wrote: Unfortunately I'm pretty sure we don't support adding arbitrary devices (ie. PCI pass-thru). Rich, is this on our roadmap? If not do I need to BZ this? Aic You should be able to do this by starting the domain using an ordinary Xen configuration file. Rich. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
