- Users - libvirt List Archives

[libvirt-users] error: internal error: Failed to reserve port 5908
by Bill Kenworthy 21 Sep '15

21 Sep '15

After saving a particular VM running WinXP, any attempt to resume it (even when no other VM's are running) generates the following error: olympus ~ # virsh restore /var/lib/libvirt/qemu/save/WinXP.save error: Failed to restore domain from /var/lib/libvirt/qemu/save/WinXP.save error: internal error: Failed to reserve port 5908 This started sometimes towards the end of last year with only the WinXP VM. libvirt is supporting a number of windows versions and a heap of linux VM's but its only WinXP that does this. Can someone give a hint as to what is causing it? BillK olympus ~ # virsh dumpxml WinXP <domain type='kvm'> <name>WinXP</name> <uuid>a9ddf88e-9ff4-46d0-9661-a5ccfacd104f</uuid> <memory unit='KiB'>4096000</memory> <currentMemory unit='KiB'>4096000</currentMemory> <vcpu placement='static'>2</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='i686' machine='pc-1.2'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='custom' match='exact'> <model fallback='allow'>Penryn</model> <vendor>Intel</vendor> <feature policy='require' name='tm2'/> <feature policy='require' name='est'/> <feature policy='require' name='monitor'/> <feature policy='require' name='ds'/> <feature policy='require' name='ss'/> <feature policy='require' name='vme'/> <feature policy='require' name='dtes64'/> <feature policy='require' name='ht'/> <feature policy='require' name='dca'/> <feature policy='require' name='pbe'/> <feature policy='require' name='tm'/> <feature policy='require' name='pdcm'/> <feature policy='require' name='vmx'/> <feature policy='require' name='ds_cpl'/> <feature policy='require' name='xtpr'/> <feature policy='require' name='acpi'/> </cpu> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup' track='guest'> <catchup threshold='123' slew='120'/> </timer> <timer name='pit' tickpolicy='delay'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/mnt/vm/WinXP/WinXP_disk1.qcow2'/> <target dev='hda' bus='ide'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <interface type='bridge'> <mac address='00:00:00:00:00:18'/> <source bridge='fbr49'/> <virtualport type='openvswitch'> <parameters interfaceid='aa19a961-60ac-4c0b-8cca-adf102b47c83'/> </virtualport> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='spice' port='-1' autoport='no' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='8192' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </memballoon> </devices> <seclabel type='none' model='none'/> </domain> olympus ~ #

3 2

[libvirt-users] virt-install and kickstart networking
by Alex 21 Sep '15

21 Sep '15

Hi, I have a fedora22 host and trying to use virt-install to install a fedora22 guest. The host is configured with bridge networking, using eth0 as its local interface. It appears the guest is communicating on vnet0 instead of eth0, so it can never reach the outside to download the install files. Where is vnet0 configured? Is it set by default when a bridge is created? I have one other guest on this host, but it was created manually with virt-manager and doesn't have the same problem. I have the following virt-install command for installing: virt-install --name testme --hvm --memory 1024 --virt-type kvm \ --disk path=/var/lib/libvirt/images/testme.qcow2,size=16 \ --network bridge=br0:eth0,mac=52:54:00:35:dd:67 \ --os-variant=fedora22 \ --location http://192.168.1.7/~alex/fedora22/ \ --initrd-inject anaconda-setup.cfg --extra-args "inst.ks=file:/anaconda-setup.cfg" \ --graphics vnc,password=foobar,listen=192.168.1.1,port=5910 I have a bridge set up as br0 with eth0 as the network interface. virbr0 is the 192.168.122.0 network, with vnet0 and vnet1 apparently the interfaces for that network. Is the br0 specified in the --network command line the actual br0 or, what looks to be more likely, the virbr0 interface? If so, how do I configure it to instead use the real br0, so it can communicate with the rest of the hosts on the local network? Can someone also explain to me the relationship between the mac address that I set here with the virt-install command and the network line in the anaconda-setup.cfg file? Thanks, Alex

1 0

[libvirt-users] failure when trying to add a channel device via virsh attach-device
by Jean-Pierre Ribeauville 21 Sep '15

21 Sep '15

Hi, On a KVM host installed with following packages versions : [root@rhel6-roadster test_channels_OK]# rpm -qa | grep libvirt libvirt-devel-0.10.2-29.el6.x86_64 libvirt-0.10.2-29.el6.x86_64 libvirt-client-0.10.2-29.el6.x86_64 libvirt-java-0.4.9-1.el6.noarch libvirt-java-devel-0.4.9-1.el6.noarch libvirt-python-0.10.2-29.el6.x86_64 [root@rhel6-roadster test_channels_OK]# rpm -qa | grep qemu qemu-kvm-0.12.1.2-2.415.el6.x86_64 gpxe-roms-qemu-0.9.7-6.10.el6.noarch qemu-img-0.12.1.2-2.415.el6.x86_64 [root@rhel6-roadster test_channels_OK]# virsh --version 0.10.2 [root@rhel6-roadster test_channels_OK]# When trying to add a channel device via virsh attach-device , I got following errors : <channel type='unix'> <source mode='bind' path='//var/lib/libvirt/qemu/omnivision_123456.agent'/> <target type='virtio' name='omnivision_123456.agent' state='disconnected'/> <alias name='channel_OmniVision'/> <address type='virtio-serial' controller='0' bus='0' port='30'/> </channel> Guest is off : [root@rhel6-roadster test_channels_OK]# virsh attach-device Linux_2 add_channel_device.xml error: Failed to attach device from add_channel_device.xml error: Requested operation is not valid: cannot do live update a device on inactive domain [root@rhel6-roadster test_channels_OK]# Guest is running : [root@rhel6-roadster test_channels_OK]# virsh attach-device Linux_2 add_channel_device.xml error: Failed to update device from add_channel_device.xml error: XML error: unknown device type [root@rhel6-roadster test_channels_OK] Did I miss something ? Thanks for help. J.P. Ribeauville P: +33.(0).1.47.17.27.87 Puteaux 3 Etage 5 Bureau 4 jpribeauville(a)axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez à l'environnement avant d'imprimer.

2 2

[libvirt-users] Guest agent is not responding
by Marko Weber | 8000 18 Sep '15

18 Sep '15

hello, in my windows vm i installed qemu-guest-agent and rebootet the vm. In the settings for the vm i set via virt-manager a new channel "unix socket" "org.qemu.guest_agent.0" "virtio". when i try to do a snapshot via shell i get: virsh snapshot-create-as --domain win7new win7new-snap1 --disk-only --atomic --quiesce error: Guest agent is not responding: Guest agent not available for now I use gentoo on the Host. qemu is built with useflags: aio alsa caps curl fdt filecaps gtk iscsi jpeg lzo ncurses nls numa pin-upstream-blobs png python sdl seccomp smartcard ssh threads tls usb usbredir uuid vde vhost-net virtfs vnc xattr xfs libvirt: audit caps fuse iscsi libvirtd lvm lxc macvtap nls numa parted pcap policykit qemu udev vepa virt-network thanks for any tipps and hints. -- zbfmail - Mittendrin statt nur Datei!

2 3

[libvirt-users] hvm on x86_64 on binutils i386
by Bhasker C V 17 Sep '15

17 Sep '15

Hi, I have this setup kernel: x86_64 version 4.2.0 operating system (rootfs binutils etc.,) : i386 (ELF-32-bit) qemu-system : version 2.4.0 qemu-system-x86_64 (i386 binary) libvirt: 1.2.19 (i386 ) When I run the qemu-system-x86_64 binary with --enable-kvm, the guest machine is working properly as hvm. So QEMU can run x86_64 OS as hvm when I install using virt-install virt-install --name debian --cdrom ./debian-stretch-DI-a1-amd64-netinst.iso --disk /STOR/DEBIAN,bus=sata --ram 1024 --graphics vnc I expect the 64-bit kernel to load and start install in the guest but i get a complaint that the guest cannot boot since the cpu is not 64-bit capable (please use a kernel appropriate for your CPU) I tried adding the machine option to virt-install virt-install --name debian --cdrom ./debian-stretch-DI-a1-amd64-netinst.iso --disk /STOR/DEBIAN,bus=sata --ram 1024 --graphics vnc --machine pc-i440fx-2.0 No joy Tried changing the machine as hvm and also added --arch x86_64 none of them help ! Can someone tell me how to do this ? Just because the binutils and the OS is 32-bit I think libvirt must not refuse to hvm a x86_64 guest since the kernel is still x86_64 kernel and so so the kvm (module) I am guessing I am missing some option passed to virt-install or this is a limitation purely on libvirt (not qemu or kvm) Moreover QEMU is able to run a hvm guest x86_64 and manually running qemu does bootup the 64-bit kernel guests.

2 3

[libvirt-users] vport0p devices no suitable drver found ..
by Jean-Pierre Ribeauville 17 Sep '15

17 Sep '15

Hi, By using virtio-win-0.1.109.iso , it looks like vport0p devices are not configured (on a Windows 2008 R2 guest) due to no suitable driver found ( below setupapi.dev.log): [Boot Session: 2015/09/16 17:29:32.375] >>> [Device Install (Hardware initiated) - {6fde7547-1b65-48ae-b628-80be62016026}\vioserialport\4&7e8053e&1&03] >>> Section start 2015/09/16 17:29:56.046 ump: Creating Install Process: DrvInst.exe 17:29:56.109 ndv: Retrieving device info... ndv: Setting device parameters... ndv: Searching Driver Store and Device Path... dvi: {Build Driver List} 17:29:56.328 dvi: Searching for hardware ID(s): dvi: {6fde7547-1b65-48ae-b628-80be62016026}\vioserialport cpy: Policy is set to make all digital signatures equal. dvi: Enumerating INFs from path list 'C:\Windows\inf' inf: Searched 0 potential matches in published INF directory inf: Searched 36 INFs in directory: 'C:\Windows\inf' dvi: {Build Driver List - exit(0x00000000)} 17:29:59.000 ndv: Selecting best match from Driver Store (including Device Path)... dvi: {DIF_SELECTBESTCOMPATDRV} 17:29:59.000 dvi: No class installer for 'vport0p3' dvi: No CoInstallers found dvi: Default installer: Enter 17:29:59.015 dvi: {Select Best Driver} ! dvi: Selecting driver failed(0xe0000228) dvi: {Select Best Driver - exit(0xe0000228)} ! dvi: Default installer: failed! ! dvi: Error 0xe0000228: There are no compatible drivers for this device. dvi: {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 17:29:59.062 ndv: {Core Device Install} 17:29:59.062 ! ndv: Installing NULL driver! dvi: Set selected driver complete. dvi: {DIF_ALLOW_INSTALL} 17:29:59.687 dvi: No class installer for 'vport0p3' dvi: Default installer: Enter 17:29:59.687 dvi: Default installer: Exit dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 17:29:59.687 dvi: {DIF_INSTALLDEVICE} 17:29:59.687 dvi: No class installer for 'vport0p3' dvi: Default installer: Enter 17:29:59.687 ! dvi: Installing NULL driver! dvi: Writing common driver property settings. dvi: {Restarting Devices} 17:30:00.093 dvi: Restart: {6FDE7547-1B65-48AE-B628-80BE62016026}\VIOSERIALPORT\4&7E8053E&1&03 dvi: Restart complete. dvi: {Restarting Devices exit} 17:30:00.187 dvi: Default installer: Exit dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 17:30:00.187 ndv: Device install status=0xe0000203 ndv: Performing device install final cleanup... ! ndv: Queueing up error report since device installation failed... ndv: {Core Device Install - exit(0xe0000203)} 17:30:00.187 ump: Server install process exited with code 0xe0000203 17:30:00.203 <<< Section end 2015/09/16 17:30:00.203 <<< [Exit status: FAILURE(0xe0000203)] Is there something I miss ? Thanks for help. J.P. Ribeauville P: +33.(0).1.47.17.27.87 Puteaux 3 Etage 5 Bureau 4 jpribeauville(a)axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez à l'environnement avant d'imprimer.

1 0

[libvirt-users] how to use {6FDE7547-1B65-48ae-B628-80BE62016026}\VIOSerialPort ?
by Jean-Pierre Ribeauville 16 Sep '15

16 Sep '15

Hi, When adding a channel device on a Win2008R2 Guest, I got this new thing within registry : Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\{6FDE7547-1B65-48ae-B628-80BE62016026}\VIOSerialPort\4&7e8053e&0&02 Class Name: <NO CLASS> Last Write Time: 9/16/2015 - 4:09 PM Value 0 Name: DeviceDesc Type: REG_SZ Data: vport0p2 Value 1 Name: Capabilities Type: REG_DWORD Data: 0xe6 Value 2 Name: UINumber Type: REG_DWORD Data: 0x2 Value 3 Name: ConfigFlags Type: REG_DWORD Data: 0 Value 4 Name: HardwareID Type: REG_MULTI_SZ Data: {6FDE7547-1B65-48ae-B628-80BE62016026}\VIOSerialPort Value 5 Name: CompatibleIDs Type: REG_MULTI_SZ Data: Value 6 Name: ContainerID Type: REG_SZ Data: {90e92d57-5573-11e5-9d8e-806e6f6e6963} Value 7 Name: LocationInformation Type: REG_SZ Data: RedHat VIOSerial Port Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\{6FDE7547-1B65-48ae-B628-80BE62016026}\VIOSerialPort\4&7e8053e&0&02\LogConf Class Name: <NO CLASS> Last Write Time: 9/16/2015 - 4:10 AM Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\{6FDE7547-1B65-48ae-B628-80BE62016026}\VIOSerialPort\4&7e8053e&0&02\Control Class Name: <NO CLASS> Last Write Time: 9/16/2015 - 4:09 PM How may I use theses infos to get/send datas to the host via this channel ? Thanks for help. Regards, J.P. Ribeauville P: +33.(0).1.47.17.27.87 Puteaux 3 Etage 5 Bureau 4 jpribeauville(a)axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez à l'environnement avant d'imprimer.

1 0

[libvirt-users] cpu frequency
by Paul Apostolescu 16 Sep '15

16 Sep '15

Is it possible to set the CPU frequency exposed to the guest operating system for a kvm-enabled virtual machine ? The documentation does not mention anything about it. Thanks.

2 1

[libvirt-users] VM in a VM on kvm/qemu
by Digimer 13 Sep '15

13 Sep '15

Hi all, For development reasons, I've setup a pair of VMs (host is Fedora 22) running EL6 as an HA cluster. On these two nodes, I host a 3rd VM (so Fedora 22 -> 2x EL 6.7 -> El 6.7). Currently, 'EL' == CentOS, but I can switch to RHEL proper if need be. To my happy surprise, it actually works! Of course, the two-deep EL6 guest is slow as molasses. I don't really care about making it usably fast because this setup is purely to dev/test the HA cluster VMs. That said, a minimal EL6 install currently takes about 2 hours. So testing deleting/creating guests is very slow. So my question is; Understanding it will never be good performance, is there anything I can do to make the VM-in-a-VM faster? I tried looking for docs on this, looking for ways to tune, CPU/BIOS options to set, etc, without much luck. Most google results are about vmware and other hypervisors. Any pointers/tips/clue-sticks will be much appreciated! -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?

2 1

[libvirt-users] Backup a VM (using live external snapshot and blockcommit)
by Jérôme 11 Sep '15

11 Sep '15

Hi. I'm following here a conversation that was initiated on Kashyap's website [1]. We have a server we use as a host for virtual machines using KVM (virt-manager used for VM creation) and we would like to setup VM backups. Basically, we're thinking of a backup schedule like "keep 7 daily and 4 weekly backups". We'd rather not shutdown the VM every day so live backups would be nice. I've been doing my best with documentation found on the Internet. It is likely that the path I chose was not the best, so feel free to tell me if I'm asking the wrong questions and I should be proceeding totally differently. AFAIU, backups can be done at filesystem level (using LVM) and at virtualization level (using libvirt). We chose the libvirt way. AFAIU, live backups using libvirt may be done thanks to blockcommit as explained here on the wiki [2]. -> Considering our use case, is this the recommended way? Assuming yes, here is the plan. I wrote a script that does # Create snapshot virsh snapshot-create-as --domain $VM_NAME snap --diskspec vda,file=$VM_DIR/"$VM_NAME"-snap.qcow2 --disk-only --atomic --no-metadata --quiesce # Copy frozen backing file cp $VM_DIR/"$VM_NAME".qcow2 $SNAP_FILEPATH # Blockcommit snapshot back into backing file virsh blockcommit $VM_NAME vda --active --pivot # Remove snapshot file rm $VM_DIR/"$VM_NAME"-snap.qcow2 Variables should be self-explanatory: - VM_DIR is the directory where the VM are stored - VM_NAME is the name of the VM, and its qcow2 file is called VM_NAME.qcow2 - SNAP_FILEPATH is the full path (including name) where the backup should be created Using this scheme, we only keep snapshots for the time of the VM file copy, which is less than a minute. The backing chain is at most 'back <- snap', and most of the time just 'back'. If something ever happens to the VM (human error while being logged as root, attack from the internet,...), we'll turn off the VM, replace its qcow2 file and turn it back on. I understand that this method only saves disk states, so the VM will be started as if it had been powered-off suddenly while running (not quite: thanks to the '--quiesce' option, at least the disks are in a sane state). Not perfect but better than nothing. Those backups are meant to be used only when all else failed, anyway, it's not daily use. -> Does this make sense? Am I missing a feature or even a different approach that would make things simpler or more secure? Am I using libvirt snapshots for what they're not meant to? -> Anything wrong about my snapshot-create-as and blockcommit command lines? May I remove the snapshot with only a rm command? Now, a few side questions, as I might have messed up with the VM I was experimenting with. I used the same command lines as described above, except I didn't pass the '--no-metadata' option. Once the backing file was copied, I deleted the snapshot qcow2 file and thought I was done with it, until I realized the snapshot was still listed by virsh snapshot-list. And I couldn't find a way to delete it. (For the record, I asked on serverfault about that [3].) Ultimately, I found the snapshot's .xml descriptor and deleted it (in fact, moved it) while libvirtd was down. Now, the snapshot is not listed anymore. -> Am I getting away with it? Are there still some traces about that snapshot? Is my VM in an unsafe state? Anything I should do about it? -> What would be the proper way of dropping an external snapshot that was created without the '--no-metadata' option, then blockcommitted? I understand libvirt doesn't do it yet. Thanks for any hint. I naively thought our use case was pretty usual, and I must admit I didn't think I'd have to dive into this complexity, which is why I'm thinking there might be a more "common" way... [1] http://kashyapc.com/2014/10/07/libvirt-blockcommit-shorten-disk-image-chain… [2] http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit [3] http://serverfault.com/questions/721216/delete-orphan-libvirt-snapshot -- Jérôme

3 5