June 2016 - Users - libvirt List Archives

[libvirt-users] Adding a channel device within an Openstack Fedora Instance ..
by Jean-Pierre Ribeauville 06 Jun '16

06 Jun '16

Hi, I'm trying to add a channel on a Openstack instance via this command : # virsh attach-device instance-00000005 test.xml that returns this error error: Failed to attach device from test.xml error: internal error: no virtio-serial controllers are available # # cat test.xml : <channel type='unix'> <source mode='bind' path='//var/lib/libvirt/qemu/instance-00000005.agent'/> <target type='virtio' name='instance-00000005.agent'/> </channel> #virsh dumpxml instance-00000005 <domain type='kvm' id='8'> <name>instance-00000005</name> <uuid>f85ea8a4-0159-417c-bef5-5b4e908ea2a0</uuid> <metadata> <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> <nova:package version="12.0.1-1.el7"/> <nova:name>Fedora-Cloud-23-2015-1</nova:name> <nova:creationTime>2016-06-06 08:22:34</nova:creationTime> <nova:flavor name="m1.small"> <nova:memory>2048</nova:memory> <nova:disk>20</nova:disk> <nova:swap>0</nova:swap> <nova:ephemeral>0</nova:ephemeral> <nova:vcpus>1</nova:vcpus> </nova:flavor> <nova:owner> <nova:user uuid="da49c3189eaf40b28893b422b60cc73e">demo</nova:user> <nova:project uuid="ef3ecf8618e24130b2cd8adab8e17310">demo</nova:project> </nova:owner> <nova:root type="image" uuid="a22e881e-dd17-4795-a118-67f9ec90a768"/> </nova:instance> </metadata> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>1</vcpu> <cputune> <shares>1024</shares> </cputune> <resource> <partition>/machine</partition> </resource> <sysinfo type='smbios'> <system> <entry name='manufacturer'>Fedora Project</entry> <entry name='product'>OpenStack Nova</entry> <entry name='version'>12.0.1-1.el7</entry> <entry name='serial'>8cd9a34f-a760-4c53-9420-a3a22a484bb2</entry> <entry name='uuid'>f85ea8a4-0159-417c-bef5-5b4e908ea2a0</entry> <entry name='family'>Virtual Machine</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-model'> <model fallback='allow'/> <topology sockets='1' cores='1' threads='1'/> </cpu> <clock offset='utc'> <timer name='pit' tickpolicy='delay'/> <timer name='rtc' tickpolicy='catchup'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/f85ea8a4-0159-417c-bef5-5b4e908ea2a0/disk'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/nova/instances/_base/5773dfb9c65f9640334bf9b3101ac8a2f485ee83'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <interface type='bridge'> <mac address='fa:16:3e:ad:2d:51'/> <source bridge='qbr9ece405a-26'/> <target dev='tap9ece405a-26'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='file'> <source path='/var/lib/nova/instances/f85ea8a4-0159-417c-bef5-5b4e908ea2a0/console.log'/> <target port='0'/> <alias name='serial0'/> </serial> <serial type='pty'> <source path='/dev/pts/4'/> <target port='1'/> <alias name='serial1'/> </serial> <console type='file'> <source path='/var/lib/nova/instances/f85ea8a4-0159-417c-bef5-5b4e908ea2a0/console.log'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <input type='tablet' bus='usb'> <alias name='input0'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='5901' autoport='yes' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <stats period='10'/> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c699,c952</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c699,c952</imagelabel> </seclabel> </domain> How may I add this controller ( before adding the channel device) ? Thanks for help. Regards, Jean-Pierre RIBEAUVILLE +33 1 4717 2049 [axway_logo_tagline_87px]

1 0

[libvirt-users] Get information during live migration
by 鍾致曜 05 Jun '16

05 Jun '16

Hello, I'm a student, and I have a question when using libvirt. Is there any way to use the libvirt API to know the VM is migrated from what IP address during live migration? Or, could I use the API to monitor where the VM is migrated to? Thanks! And sorry for my poor english John

1 0

[libvirt-users] Migration problem - takes 5 minutes to start moving the memory
by Marc-Aurèle Brothier - Exoscale 02 Jun '16

02 Jun '16

Hi, I'm facing a strange issue while doing a migration from an hypervisor to another one. The migration takes for ever to start moving the memory. The VM had no workload what so ever, just a basic ubuntu image. The versions on the hypervisors are: libvirt 1.2.21, qemu 1.2.3 Command to launche the migration: virsh migrate --verbose --live --abort-on-error --tunnelled --p2p --auto-converge --copy-storage-inc --xml vm-6160.xml 6160 qemu+tls://<destination_hypervisor>/system Here is the log output, look at the time elapsed: root@virt-hv009:~# virsh domjobinfo 6160 Job type: Unbounded Time elapsed: 27518 ms Data processed: 21.506 GiB Data remaining: 29.003 GiB Data total: 50.509 GiB Memory processed: 0.000 B Memory remaining: 520.820 MiB Memory total: 520.820 MiB File processed: 21.506 GiB File remaining: 28.494 GiB File total: 50.000 GiB Constant pages: 0 Normal pages: 0 Normal data: 0.000 B Expected downtime: 300 ms Setup time: 6 ms root@virt-hv009:~# virsh domjobinfo 6160 Job type: Unbounded Time elapsed: 32331 ms Data processed: 25.475 GiB Data remaining: 25.034 GiB Data total: 50.509 GiB Memory processed: 0.000 B Memory remaining: 520.820 MiB Memory total: 520.820 MiB File processed: 25.475 GiB File remaining: 24.525 GiB File total: 50.000 GiB Constant pages: 0 Normal pages: 0 Normal data: 0.000 B Expected downtime: 300 ms Setup time: 6 ms root@virt-hv009:~# virsh domjobinfo 6160 Job type: Unbounded Time elapsed: 49543 ms Data processed: 50.000 GiB Data remaining: 520.820 MiB Data total: 50.509 GiB Memory processed: 0.000 B Memory remaining: 520.820 MiB Memory total: 520.820 MiB File processed: 50.000 GiB File remaining: 0.000 B File total: 50.000 GiB Constant pages: 0 Normal pages: 0 Normal data: 0.000 B Expected downtime: 300 ms Setup time: 6 ms ^^^^ Here after 49 sec, the disk has been process, but the memory hasn't started I skip the logs, but below is the output 5minutes & 56 seconds later, still nothing: root@virt-hv009:~# virsh domjobinfo 6160 Job type: Unbounded Time elapsed: 356919 ms Data processed: 50.000 GiB Data remaining: 520.820 MiB Data total: 50.509 GiB Memory processed: 0.000 B Memory remaining: 520.820 MiB Memory total: 520.820 MiB File processed: 50.000 GiB File remaining: 0.000 B File total: 50.000 GiB Constant pages: 0 Normal pages: 0 Normal data: 0.000 B Expected downtime: 300 ms Setup time: 6 ms Just after it started to move the memory, but 6 minutes later! root@virt-hv009:~# virsh domjobinfo 6160 Job type: Unbounded Time elapsed: 360092 ms Data processed: 50.052 GiB Data remaining: 453.895 MiB Data total: 50.509 GiB Memory processed: 53.224 MiB Memory remaining: 453.895 MiB Memory total: 520.820 MiB Memory bandwidth: 98.172 MiB/s File processed: 50.000 GiB File remaining: 0.000 B File total: 50.000 GiB Constant pages: 3541 Normal pages: 13591 Normal data: 53.090 MiB Expected downtime: 300 ms Setup time: 6 ms root@virt-hv009:~# virsh domjobinfo 6160 error: failed to get domain '6160' error: Domain not found: no domain with matching name '6160' Here the migration is done. But what made it wait more than 5 minutes to start moving the memory? Does anyone knows? Or have any idea what could produce this latency. - Marco

3 4

Re: [libvirt-users] virsh for VMWare
by Richard W.M. Jones 01 Jun '16

01 Jun '16

[libvirt-users should be able to help out] On Wed, Jun 01, 2016 at 01:58:09PM +0000, John L. Magee wrote: > Rich- do you know a way we could use virsh in scripts without > manually entering the username/password creds for every invocation? > Or could you point me to a source who may be able to help? We need > to be able to set Linux VM memory and cpu configurations from a > linux monitoring system and, if the cred entry could be overcome, > virsh would be so much simpler than conventional VMWare > alternatives. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

3 2

[libvirt-users] unhelpful error message on failed "virsh migrate"
by Andreas Buschmann 01 Jun '16

01 Jun '16

Hello, I have two servers where I can push VMs from one to the other by issuing the command virsh migrate --live --persistent --copy-storage-all --verbose \ test6 qemu+ssh://kvmhost2/system on kvmhost1. I can get the VM back by issuing the equivalent command on kvmhost2: virsh migrate --live --persistent --copy-storage-all --verbose \ test6 qemu+ssh://kvmhost1/system After an update (on behalf of the glibc bug) it only works for some VMs and fails for others. The error message is unhelpful: virsh --debug 4 migrate --live --persistent --copy-storage-all --verbose \ vmware-mgmt qemu+ssh://kvmhost1/system error: internal error: info migration reply was missing return status Is there a way to get a more helpful error message? migrating VMs only works for a very limited subset of the VMs on the system in the direction kvmhost2 --> kvmhost2 Stopping the VMs, copying them over to kvmhost1 and restarting still works, and I can even migrate them back. How do I debug this problem? One possible way would be to stop all VMs on kvmhost2, manually copy them to kvmhost1 and start them and afterwards reinstall all packages (or the whole Server if that doesn't help) But that would be a workaround, and I still would not know what the problem is. The system is CentOS 7.2 now and was CentOS 7.1 before the upgrade, with the qemu-kvm-rhev repo added for qemu. Mit freundlichen Gruessen Andreas Buschmann -- Andreas Buschmann [Senior Systems Engineer] net.DE AG

1 1