- Users - libvirt List Archives

Static DHCP lease never distributed
by Brooks Swinnerton 11 Feb '21

11 Feb '21

Hi there, I have a libvirt network defined as so: <network> <name>customers</name> <bridge name='customers' macTableManager='libvirt' /> <port isolated='yes' /> <dns enable='no' /> <ip address='10.0.0.1' prefix='24'> <dhcp> <host mac='02:99:92:43:eb:b8' name='dhcp-test' ip='10.0.0.10' /> </dhcp> </ip> </network> And that network is attached to a virtual machine: <interface type='network'> <mac address='02:99:92:43:eb:b8'/> <source network='customers'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> But for some reason when the domain starts, it never gets an address. If I tcpdump the bridge that was created by the network I can see it sending out discover packets, but dnsmasq never seems to respond: 01:26:25.039987 02:99:92:43:eb:b8 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:99:92:43:eb:b8, length 300, xid 0xc7283f76, secs 228, Flags [none] Client-Ethernet-Address 02:99:92:43:eb:b8 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 02:99:92:43:eb:b8 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP Vendor-Class Option 60, length 3: "d-i" Despite that appearing to be the correct mac address. Looking in /var/lib/libvirt/dnsmasq/customers.hostsfile, it's returning what I would expect to be there: 02:99:92:43:eb:b8,10.0.0.10,dhcp-test If I add a <range> stanza to the configuration, that does appear to work, so it seems this is only related to static addresses. This is libvirtd 5.8.0.

2 1

Re: [ovirt-devel] Issue: Device path changed after adding disks to guest VM
by Nir Soffer 02 Feb '21

02 Feb '21

On Wed, Dec 2, 2020 at 4:57 PM Joy Li <joooy.li(a)gmail.com> wrote: > > Thanks a lot Nir! Good to know that oVirt cannot guarantee the disk names so that I don't need to spend more time trying to enable such a feature. > > I can always reproduce the problem via my application, basically, the procedure is as following: > > 1. create a VM Which guest OS? Can you share the guest disk image or ISO image used to instal it? > 2. add disks to the VM (e.g.: disk names: disk1, disk3) > 3. check the disk mappings via `virsh domblklist ` Please shared the libvirt domain xml (virsh dumpxml vm-name) > 4. add another disk (let's say, disk2, give a name alphabetically before some existing disks) Add disk while the vm is running (hotplug)? > 5. shutdown the VM via hypervisor and start it again (reboot won't work) What do you mean by "reboot does not work?" > 6. `virsh domblklist` again, then you might see the problem I mentioned before Mapping is different compared with state before the reboot? > There are no virtio devices inside /dev/disk/by-id/xxx of my guest VM. Maybe you don't have systemd-udev installed? The links in /dev/disk/... are created by udev during startup, and when detecting a new disk. > And I just noticed that the disks mapping information given by hypervisor (from VM configuration or virsh command) is different from the reality inside the VM. The disk name inside the VM was actually not changed. > > So now my issue is that given a disk name (/dev/vdb) of a VM, how can I get its wwid? Before I got it from the hypervisor, but now the hypervisor's information is not reliable, and since the disk is unformatted, I cannot use UUID. You can use: # udevadm info /dev/vda P: /devices/pci0000:00/0000:00:02.5/0000:06:00.0/virtio4/block/vda N: vda L: 0 S: disk/by-path/pci-0000:06:00.0 S: disk/by-id/virtio-b97e68b2-87ea-45ca-9 S: disk/by-path/virtio-pci-0000:06:00.0 E: DEVPATH=/devices/pci0000:00/0000:00:02.5/0000:06:00.0/virtio4/block/vda E: DEVNAME=/dev/vda E: DEVTYPE=disk E: MAJOR=252 E: MINOR=0 E: SUBSYSTEM=block E: USEC_INITIALIZED=10518442 E: ID_SERIAL=b97e68b2-87ea-45ca-9 E: ID_PATH=pci-0000:06:00.0 E: ID_PATH_TAG=pci-0000_06_00_0 E: DEVLINKS=/dev/disk/by-path/pci-0000:06:00.0 /dev/disk/by-id/virtio-b97e68b2-87ea-45ca-9 /dev/disk/by-path/virtio-pci-0000:06:00.0 E: TAGS=:systemd: I tried to reproduce you issue 4.4.5 development build: Starting vm with 2 direct LUN disks: # virsh -r dumpxml disk-mapping ... <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='native' discard='unmap'/> <source dev='/rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5' index='3'> <seclabel model='dac' relabel='no'/> </source> <backingStore type='block' index='5'> <format type='qcow2'/> <source dev='/rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/ad891316-b80a-4ab5-895b-400108bd0ca1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> </backingStore> <target dev='sda' bus='scsi'/> <serial>40018b33-2b11-4d10-82e4-604a5b135fb2</serial> <boot order='1'/> <alias name='ua-40018b33-2b11-4d10-82e4-604a5b135fb2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/3600140594af345ed76d42058f2b1a454' index='2'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vda' bus='virtio'/> <serial>b97e68b2-87ea-45ca-94fb-277d5b30baa2</serial> <alias name='ua-b97e68b2-87ea-45ca-94fb-277d5b30baa2'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5' index='1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vdb' bus='virtio'/> <serial>d9a29187-f492-4a0d-aea2-7d5216c957d7</serial> <alias name='ua-d9a29187-f492-4a0d-aea2-7d5216c957d7'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </disk> ... # virsh -r domblklist disk-mapping Target Source --------------------------------------------------------------------------------------------------------------------------------------------------------------- sdc - sda /rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5 vda /dev/mapper/3600140594af345ed76d42058f2b1a454 vdb /dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5 In guest: # ls -lh /dev/disk/by-id/virtio-* lrwxrwxrwx. 1 root root 9 Jan 6 09:42 /dev/disk/by-id/virtio-b97e68b2-87ea-45ca-9 -> ../../vda lrwxrwxrwx. 1 root root 9 Jan 6 09:42 /dev/disk/by-id/virtio-d9a29187-f492-4a0d-a -> ../../vdb NOTE: "d9a29187-f492-4a0d-a" are the first characters of the disk id: "d9a29187-f492-4a0d-aea2-7d5216c957d7" seen in oVirt: https://my-engine/ovirt-engine/webadmin/?locale=en_US#disks-general;id=d9a2… Adding another disk in sorted in the middle (while the vm is running): # virsh -r dumpxml disk-mapping ... <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='native' discard='unmap'/> <source dev='/rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5' index='3'> <seclabel model='dac' relabel='no'/> </source> <backingStore type='block' index='5'> <format type='qcow2'/> <source dev='/rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/ad891316-b80a-4ab5-895b-400108bd0ca1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> </backingStore> <target dev='sda' bus='scsi'/> <serial>40018b33-2b11-4d10-82e4-604a5b135fb2</serial> <boot order='1'/> <alias name='ua-40018b33-2b11-4d10-82e4-604a5b135fb2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/3600140594af345ed76d42058f2b1a454' index='2'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vda' bus='virtio'/> <serial>b97e68b2-87ea-45ca-94fb-277d5b30baa2</serial> <alias name='ua-b97e68b2-87ea-45ca-94fb-277d5b30baa2'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5' index='1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vdb' bus='virtio'/> <serial>d9a29187-f492-4a0d-aea2-7d5216c957d7</serial> <alias name='ua-d9a29187-f492-4a0d-aea2-7d5216c957d7'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/36001405b4d0c0b7544d47438b21296ef' index='7'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vdc' bus='virtio'/> <serial>e801c2e4-dc2e-4c53-b17b-bf6de99f16ed</serial> <alias name='ua-e801c2e4-dc2e-4c53-b17b-bf6de99f16ed'/> <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </disk> ... # virsh -r domblklist disk-mapping Target Source --------------------------------------------------------------------------------------------------------------------------------------------------------------- sdc - sda /rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5 vda /dev/mapper/3600140594af345ed76d42058f2b1a454 vdb /dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5 vdc /dev/mapper/36001405b4d0c0b7544d47438b21296ef In the guest: # ls -lh /dev/disk/by-id/virtio-* lrwxrwxrwx. 1 root root 9 Jan 6 09:42 /dev/disk/by-id/virtio-b97e68b2-87ea-45ca-9 -> ../../vda lrwxrwxrwx. 1 root root 9 Jan 6 09:42 /dev/disk/by-id/virtio-d9a29187-f492-4a0d-a -> ../../vdb lrwxrwxrwx. 1 root root 9 Jan 6 09:51 /dev/disk/by-id/virtio-e801c2e4-dc2e-4c53-b -> ../../vdc Shutdown VM and start it again # virsh -r dumpxml disk-mapping ... <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='native' discard='unmap'/> <source dev='/rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5' index='4'> <seclabel model='dac' relabel='no'/> </source> <backingStore type='block' index='6'> <format type='qcow2'/> <source dev='/rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/ad891316-b80a-4ab5-895b-400108bd0ca1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> </backingStore> <target dev='sda' bus='scsi'/> <serial>40018b33-2b11-4d10-82e4-604a5b135fb2</serial> <boot order='1'/> <alias name='ua-40018b33-2b11-4d10-82e4-604a5b135fb2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/3600140594af345ed76d42058f2b1a454' index='3'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vda' bus='virtio'/> <serial>b97e68b2-87ea-45ca-94fb-277d5b30baa2</serial> <alias name='ua-b97e68b2-87ea-45ca-94fb-277d5b30baa2'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/36001405b4d0c0b7544d47438b21296ef' index='2'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vdb' bus='virtio'/> <serial>e801c2e4-dc2e-4c53-b17b-bf6de99f16ed</serial> <alias name='ua-e801c2e4-dc2e-4c53-b17b-bf6de99f16ed'/> <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </disk> <disk type='block' device='disk' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' iothread='1'/> <source dev='/dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5' index='1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='vdc' bus='virtio'/> <serial>d9a29187-f492-4a0d-aea2-7d5216c957d7</serial> <alias name='ua-d9a29187-f492-4a0d-aea2-7d5216c957d7'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </disk> ... # virsh -r domblklist disk-mapping Target Source --------------------------------------------------------------------------------------------------------------------------------------------------------------- sdc - sda /rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5 vda /dev/mapper/3600140594af345ed76d42058f2b1a454 vdb /dev/mapper/36001405b4d0c0b7544d47438b21296ef vdc /dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5 In the guest: # ls -lh /dev/disk/by-id/virtio-* lrwxrwxrwx. 1 root root 9 Jan 6 09:55 /dev/disk/by-id/virtio-b97e68b2-87ea-45ca-9 -> ../../vda lrwxrwxrwx. 1 root root 9 Jan 6 09:55 /dev/disk/by-id/virtio-d9a29187-f492-4a0d-a -> ../../vdb lrwxrwxrwx. 1 root root 9 Jan 6 09:55 /dev/disk/by-id/virtio-e801c2e4-dc2e-4c53-b -> ../../vdc Comparing to state before reboot: # virsh -r domblklist disk-mapping Target Source --------------------------------------------------------------------------------------------------------------------------------------------------------------- sdc - sda /rhev/data-center/mnt/blockSD/84dc4e3c-00fd-4263-84e8-fc246eeee6e9/images/40018b33-2b11-4d10-82e4-604a5b135fb2/40f455c4-8c92-4f8f-91c2-991b0ddfc2f5 vda /dev/mapper/3600140594af345ed76d42058f2b1a454 vdb /dev/mapper/360014050058f2f8a0474dc7a8a7cc6a5 vdc /dev/mapper/36001405b4d0c0b7544d47438b21296ef # ls -lh /dev/disk/by-id/virtio-* lrwxrwxrwx. 1 root root 9 Jan 6 09:42 /dev/disk/by-id/virtio-b97e68b2-87ea-45ca-9 -> ../../vda lrwxrwxrwx. 1 root root 9 Jan 6 09:42 /dev/disk/by-id/virtio-d9a29187-f492-4a0d-a -> ../../vdb lrwxrwxrwx. 1 root root 9 Jan 6 09:51 /dev/disk/by-id/virtio-e801c2e4-dc2e-4c53-b -> ../../vdc In the guest disks are mapped to the same device name. It looks like libivrt domblklist is not correct - vdb and vdc are switched. Peter, this expected? Nir > > Joy > > On Wed, Dec 2, 2020 at 1:28 PM Nir Soffer <nsoffer(a)redhat.com> wrote: >> >> On Wed, Dec 2, 2020 at 10:27 AM Joy Li <joooy.li(a)gmail.com> wrote: >> > >> > Hi All, >> > >> > I'm facing the problem that after adding disks to guest VM, the device target path changed (My ovirt version is 4.3). For example: >> > >> > Before adding a disk: >> > >> > virsh # domblklist <vmname> >> > Target Source >> > --------------------------------------------------------- >> > hdc - >> > vda /dev/mapper/3600a09803830386546244a546d494f53 >> > vdb /dev/mapper/3600a09803830386546244a546d494f54 >> > vdc /dev/mapper/3600a09803830386546244a546d494f55 >> > vdd /dev/mapper/3600a09803830386546244a546d494f56 >> > vde /dev/mapper/3600a09803830386546244a546d494f57 >> > vdf /dev/mapper/3600a09803830386546244a546d494f58 >> > >> > After adding a disk, and then shutdown and start the VM: >> > >> > virsh # domblklist <vmname> >> > Target Source >> > --------------------------------------------------------- >> > hdc - >> > vda /dev/mapper/3600a09803830386546244a546d494f53 >> > vdb /dev/mapper/3600a09803830386546244a546d494f54 >> > vdc /dev/mapper/3600a09803830386546244a546d494f6c >> > vdd /dev/mapper/3600a09803830386546244a546d494f55 >> > vde /dev/mapper/3600a09803830386546244a546d494f56 >> > vdf /dev/mapper/3600a09803830386546244a546d494f57 >> > vdg /dev/mapper/3600a09803830386546244a546d494f58 >> > >> > The devices' multipath doesn't map to the same target path as before, so in my VM the /dev/vdc doesn't point to the old /dev/mapper/3600a09803830386546244a546d494f55 anymore. >> > >> > Anybody knows how can I make the device path mapping fixed without being changed after adding or removing disks. >> >> Device nodes are not stable, and oVirt cannot guarantee that you will >> get the same >> node in the guest in all runs. >> >> You should use /dev/disk/by-id/xxx links to located devices, and blkid to create >> fstab mounts that do not depend on node names. >> >> Regardless, oVirt try to keep devices stable as possible. Do you know >> how to reproduce >> this issue reliably? >> >> Nir >>

6 6

Fwd: virsh backup-begin problem
by Andrey Fokin 21 Jan '21

21 Jan '21

Ok. Sorry. On Thu, Jan 21, 2021 at 3:38 PM Peter Krempa <pkrempa(a)redhat.com> wrote: > On Thu, Jan 21, 2021 at 15:16:44 +0300, Andrey Fokin wrote: > > Yes, there is an error message. > > sudo virsh backup-begin lubuntu2 ./backup.xml > > error: XML document failed to validate against schema: Unable to validate > > doc against /usr/share/libvirt/schemas/domainbackup.rng > > Element domainbackup has extra content: disk > > As I've noted in the exact mail you are replying to, I will not offer > any further assistance unless you post the question also on > libvirt-users(a)redhat.com list as you did with your original question. > This is to archive any discussions for future reference. > > > On Thu, Jan 21, 2021 at 2:40 PM Peter Krempa <pkrempa(a)redhat.com> wrote: > > > > > On Thu, Jan 21, 2021 at 12:34:43 +0100, Peter Krempa wrote: > > > > On Thu, Jan 21, 2021 at 14:31:18 +0300, Andrey Fokin wrote: > > > > > Peter, thanks. I understood you message about additional > configuration > > > in > > > > > domen settings. It's really interesting, and I'll going to test it > as > > > well. > > > > > But could you please advise how change backup-begin command XML > > > parameters > > > > > file to start full backup process? What is wrong in my case and > how to > > > fix > > > > > it? My config below. > > > > > Thanks a lot! > > > > > <domainbackup> > > > > > <disk name='/var/lib/libvirt/images/lubuntu2.qcow2' > type='file'> > > > > > <target file='$PWD/scratch1.img'/> > > > > > <driver type='raw'/> > > > > > </disk> > > > > > <disk name='/var/lib/libvirt/images/lubuntu2-1.qcow2' > type='file'> > > > > > <target file='$PWD/scratch2.img'/> > > > > > <driver type='raw'/> > > > > > </disk> > > > > > </domainbackup> > > > > > > > > Could you please describe what the problem is? You are getting an > error? > > > > If so why didn't you paste it? > > > > > > > > I'm not going to setup a backup just to try your configuration. > Please > > > > provide all information you have and describe the problem as best as > > > > possible. > > Here: > > > > > > > Oh, and don't drop libvirt-users from the CC-list! That way my advice > > > would not be recorded in the mailing list archives and browsable by > > > others with a possibly same problem. > > > > > > Please Re-post your query to the list AND include any information you > > > have to get a reply from me. > > > > > > > > > > -- > > BRG, > > Andrey > > -- BRG, Andrey

2 5

virsh backup-begin problem
by Andrey Fokin 21 Jan '21

21 Jan '21

Colleagues, could you please advise what a problem could be in XML file in case of: virsh backup-begin lubuntu2 ./backup.xml where backup.xml - <domainbackup> <disk name='/var/lib/libvirt/images/lubuntu2.qcow2' type='file'> <target file='$PWD/scratch1.img'/> <driver type='raw'/> </disk> <disk name='/var/lib/libvirt/images/lubuntu2-1.qcow2' type='file'> <target file='$PWD/scratch2.img'/> <driver type='raw'/> </disk> </domainbackup> and domain config is- <domain type="kvm"> <name>lubuntu2</name> <uuid>c466086e-4570-4fb5-8cb6-bfe104791381</uuid> <memory unit="KiB">1048576</memory> <currentMemory unit="KiB">1048576</currentMemory> <vcpu placement="static">1</vcpu> <os> <type arch="x86_64" machine="pc-i440fx-focal">hvm</type> <boot dev="hd"/> </os> <features> <acpi/> <apic/> <vmport state="off"/> </features> <cpu mode="host-model" check="partial"/> <clock offset="utc"> <timer name="rtc" tickpolicy="catchup"/> <timer name="pit" tickpolicy="delay"/> <timer name="hpet" present="no"/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <pm> <suspend-to-mem enabled="no"/> <suspend-to-disk enabled="no"/> </pm> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type="file" device="disk"> <driver name="qemu" type="qcow2"/> <source file="/var/lib/libvirt/images/lubuntu2.qcow2"/> <target dev="hda" bus="ide"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> <disk type="file" device="cdrom"> <driver name="qemu" type="raw"/> <target dev="hdb" bus="ide"/> <readonly/> <address type="drive" controller="0" bus="0" target="0" unit="1"/> </disk> <disk type="file" device="disk"> <driver name="qemu" type="qcow2"/> <source file="/var/lib/libvirt/images/lubuntu2-1.qcow2"/> <target dev="hdc" bus="ide"/> <address type="drive" controller="0" bus="1" target="0" unit="0"/> </disk> <controller type="usb" index="0" model="ich9-ehci1"> <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x7"/> </controller> <controller type="usb" index="0" model="ich9-uhci1"> <master startport="0"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0" multifunction="on"/> </controller> <controller type="usb" index="0" model="ich9-uhci2"> <master startport="2"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x1"/> </controller> <controller type="usb" index="0" model="ich9-uhci3"> <master startport="4"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x2"/> </controller> <controller type="pci" index="0" model="pci-root"/> <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="0x06" function="0x0"/> </controller> <interface type="network"> <mac address="52:54:00:90:d7:29"/> <source network="default"/> <model type="e1000"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/> </interface> <serial type="pty"> <target type="isa-serial" port="0"> <model name="isa-serial"/> </target> </serial> <console type="pty"> <target type="serial" port="0"/> </console> <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"> <address type="usb" bus="0" port="1"/> </input> <input type="mouse" bus="ps2"/> <input type="keyboard" bus="ps2"/> <graphics type="spice" autoport="yes"> <listen type="address"/> <image compression="off"/> </graphics> <sound model="ich6"> <address type="pci" domain="0x0000" bus="0x00" slot="0x04" function="0x0"/> </sound> <video> <model type="qxl" ram="65536" vram="65536" vgamem="16384" heads="1" primary="yes"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/> </video> <redirdev bus="usb" type="spicevmc"> <address type="usb" bus="0" port="2"/> </redirdev> <redirdev bus="usb" type="spicevmc"> <address type="usb" bus="0" port="3"/> </redirdev> <memballoon model="virtio"> <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> </memballoon> </devices> </domain> -- BRG, Andrey

2 3

How to enable libvirtd auth just like oVirt ?
by tommy 18 Jan '21

18 Jan '21

Hi everyone: In my libvirtd test env, there's no auth when using virsh: root@ubts2:~# virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # virsh # virsh # list Id Name State -------------------------- 26 3.ohost1 running 27 3.ohost2 running 28 3.ohost3 running virsh # virsh # virsh # virsh # But, in oVirt env, there's auth when using virsh: [root@ohost1 ~]# virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # virsh # virsh # virsh # virsh # list Please enter your authentication name: How can I enable auth in my libvirtd env just like oVirt ? Thanks.

2 1

I would like to contribute to libvirt
by PRAJWAL BENEDICT A 13 Jan '21

13 Jan '21

2 1

Get Host Capabilities failed: Internal JSON-RPC error: {'reason': 'internal error: Duplicate key'}
by tommy 13 Jan '21

13 Jan '21

Hi,everyone: I got this error in my ovirt env: VDSM ooengh1.tltd.com command Get Host Capabilities failed: Internal JSON-RPC error: {'reason': 'internal error: Duplicate key'} Systemctl message is: Dec 23 20:48:48 ooengh1.tltd.com vdsm[2431]: ERROR Internal server error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 345, in _handle_request res = method(**params) File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 198, in _dynamicMethod result = fn(*methodArgs) File "<string>", line 2, in getCapabilities File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1371, in getCapabilities c = caps.get() File "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 93, in get machinetype.compatible_cpu_models()) File "/usr/lib/python2.7/site-packages/vdsm/common/cache.py", line 43, in __call__ value = self.func(*args) File "/usr/lib/python2.7/site-packages/vdsm/machinetype.py", line 142, in compatible_cpu_models all_models = domain_cpu_models(c, arch, cpu_mode) File "/usr/lib/python2.7/site-packages/vdsm/machinetype.py", line 97, in domain_cpu_models domcaps = conn.getDomainCapabilities(None, arch, None, virt_type, 0) File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 131, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 94, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3844, in getDomainCapabilities if ret is None: raise libvirtError ('virConnectGetDomainCapabilities() failed', conn=self) libvirtError: internal error: Duplicate key AnyOne can help me ? Thanks!

2 4

[resent] virt-manager connection fails with 'qemu unexpectedly closed the monitor'
by John Paul Adrian Glaubitz 12 Jan '21

12 Jan '21

Hi! I recently ran into a problem when connecting to libvirtd 6.9.0 on Debian unstable and trying to import an existing image with Windows 7. Upon finishing the wizard and starting the instance, the import process fails with the following error message: Unable to complete install: 'internal error: qemu unexpectedly closed the monitor' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install installer.start_install(guest, meter=meter) File "/usr/share/virt-manager/virtinst/install/installer.py", line 731, in start_install domain = self._create_guest( File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4366, in createXML raise libvirtError('virDomainCreateXML() failed') libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor Since this error message is rather generic, I don't know where to start debugging. Does anyone know how to increase verbosity here to get an error message that might be more helpful? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz(a)debian.org `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2 4

Problem with xen hvm DomU
by Christoph 08 Jan '21

08 Jan '21

Hi can someone say me whats wrong in this config: <domain type='xen'> <name>fenrir.chao5.int</name> <uuid>7aedcd03-54e8-4055-8d1b-37dd34194859</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>2</vcpu> <os> <type arch='x86_64' machine='xenfv'>hvm</type> <loader type='rom'>/usr/lib/xen/boot/hvmloader</loader> <kernel>/usr/lib64/xen/boot/hvmloader</kernel> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='variable' adjustment='0' basis='localtime'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/vg_astarte/lv_fenrir_root'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/vg_astarte/lv_fenrir_swap'/> <target dev='hdb' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='xenbus' index='0'/> <controller type='ide' index='0'/> <interface type='bridge'> <mac address='00:16:3e:05:30:04'/> <source bridge='xenbr5'/> <script path='vif-bridge'/> <model type='netfront'/> </interface> <interface type='bridge'> <mac address='00:16:3e:04:30:04'/> <source bridge='xenbr4'/> <script path='vif-bridge'/> <model type='netfront'/> </interface> <interface type='bridge'> <mac address='00:16:3e:15:30:04'/> <source bridge='xenbr15'/> <script path='vif-bridge'/> <model type='netfront'/> </interface> <interface type='bridge'> <mac address='00:16:3e:14:30:04'/> <source bridge='xenbr14'/> <script path='vif-bridge'/> <model type='netfront'/> </interface> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='6000' autoport='no' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='cirrus' vram='8192' heads='1' primary='yes'/> </video> <memballoon model='xen'/> </devices> </domain> If I try to start it with virsh create... then I see only: error: Failed to create domain from /etc/libvirt/libxl/fenrir.chao5.int.xml error: internal error: libxenlight failed to create new domain 'fenrir.chao5.int' ------ Greetz

2 6

Migration via qemu+ssh using a given private ssh key possible ?
by Oliver Dzombic 06 Jan '21

06 Jan '21

Hi, happy new year! Is there a way to tell libvirt to migrate an instance via qemu+ssh using a specific ssh key ? It seems libvirt will always try to use the .ssh/id_rsa private key. But i would like to somehow tell libvirt to use a specific private ssh key. ( At best via command line argument ). Is that possible somehow ? Or something else similar ? Thank you! -- Mit freundlichen Gruessen / Best regards Oliver Dzombic Layer7 Networks mailto:info@layer7.net Anschrift: Layer7 Networks GmbH Zum Sonnenberg 1-3 63571 Gelnhausen HRB 96293 beim Amtsgericht Hanau Geschäftsführung: Oliver Dzombic UST ID: DE259845632

3 4

about the script /etc/qemu-ifup with nmcli command
by Yalan Zhang 05 Jan '21

05 Jan '21

Hi, I have tried the qemu-ifup script as below with nmcli command as brctl is deprecated on rhel8, but the guest network can not work. I think the script needs update. Could you please help to have a look? Thank you in advance. 1. prepare a linux bridge on the host named br0; 2. prepare the qemu-ifup script as below: # cat /etc/qemu-ifup #!/bin/bash # A br0 bridge should be already set up. # Compare with: # http://en.wikibooks.org/wiki/QEMU/Networking#qemu-ifup # # For the bridge setup, see: # http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging # http://gist.github.com/393525 ip link set "$1" up nmcli c add type bridge-slave ifname $1 con-name $1 master br0 autoconnect yes 3. start vm with below interface setting: # virsh dumpxml rh | grep /interface -B5 <interface type='ethernet'> <mac address='52:54:00:79:ba:dd'/> <script path='/etc/qemu-ifup'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </interface> # virsh start rh Domain rh started 4.check on guest, the interface can not get dhcp ip address; 5. check on host, # nmcli con NAME UUID TYPE DEVICE br0 f68f73c7-10ee-40c1-bb09-3366d11ac896 bridge br0 ... vnet0 90a48d77-dccc-4b59-98f5-09f8cbd62458 ethernet -- # nmcli dev DEVICE TYPE STATE CONNECTION br0 bridge connected br0 ... vnet0 tun unmanaged -- 6. hotplug a bridge type interface and compare the tap devices: # virsh attach-interface rh bridge br0 --model virtio Interface attached successfully # nmcli con NAME UUID TYPE DEVICE br0 f68f73c7-10ee-40c1-bb09-3366d11ac896 bridge br0 vnet1 07c2a1f8-396f-4d5f-b61f-ef2ddb42ed93 tun vnet1 --->the hot-plugged one ... vnet0 90a48d77-dccc-4b59-98f5-09f8cbd62458 ethernet -- ----> the ethernet one # nmcli dev DEVICE TYPE STATE CONNECTION vnet1 tun connected (externally) vnet1 --->the hot-plugged one vnet0 tun unmanaged -- ----> the ethernet one ... 7. from the outputs above, the back-end tun device for ethernet type interface is unmanaged. I don't know how to update the script to fix it. Could you please help? ------- Best Regards, Yalan Zhang IRC: yalzhang

2 2

virt-manager connection fails with 'qemu unexpectedly closed the monitor'
by John Paul Adrian Glaubitz 04 Jan '21

04 Jan '21

Hi! I recently ran into a problem when connecting to libvirtd 6.9.0 on Debian unstable and trying to import an existing image with Windows 7. Upon finishing the wizard and starting the instance, the import process fails with the following error message: Unable to complete install: 'internal error: qemu unexpectedly closed the monitor' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install installer.start_install(guest, meter=meter) File "/usr/share/virt-manager/virtinst/install/installer.py", line 731, in start_install domain = self._create_guest( File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4366, in createXML raise libvirtError('virDomainCreateXML() failed') libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor Since this error message is rather generic, I don't know where to start debugging. Does anyone know how to increase verbosity here to get an error message that might be more helpful? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz(a)debian.org `. `' Freie Universitaet Berlin - glaubitz(a)physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2 1

Unexplicable permission error when trying to read a qemu firmware file
by Emmanuel Kasper 04 Jan '21

04 Jan '21

Hi I want to create a CoreOS VM following the steps mentioned at https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started, using a Debian 11 (bullseye) system. I am thus creating a VM with the following virt-install command: virt-install --connect="qemu:///system" --name=coreos \ --vcpus=2 --memory=2048 \ --os-variant=fedora29 --import --graphics=none \ --disk="size=10,backing_store=$PWD/fedora-coreos-33.20201201.3.0-qemu.x86_64.qcow2" \ --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=/tmp/example.ign" which spits some warnings and this mysterious error 2020-12-29T16:52:03.858938Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] 2020-12-29T16:52:03.858941Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] 2020-12-29T16:52:03.864778Z qemu-system-x86_64: -fw_cfg name=opt/com.coreos/config,file=/tmp/example.ign: can't load /tmp/example.ign: Failed to open file “/tmp/example.ign”: Permission denied the file /tmp/example.ign is perfectly world readable, -rw-rw-rw- 1 manu manu 1130 Dec 29 17:23 /tmp/example.ign so I am puzzled at what could cause this permission error. on a RHEL8 system, I had the same error, and was able to fix by setting a security context on the firmware file: sudo semanage fcontext --add --type virt_content_t /tmp/example.ign restorecon /tmp/example.ign now this Debian system does not selinux installed at all. ls -dZ / ? / I could also read the qemu firmware file when using the qemu:///session connection any pointers where to look for ? Emmanuel

2 1

Isolated bridge does not bridge
by Paul van der Vlis 04 Jan '21

04 Jan '21

Hello, I want to do some testing and I have removed two VM's from the bridge what connects them to internet, and added them to another isolated bridge what's not connected to internet. Problem is that I cannot reach the other host in the isolated network. Something like this: virsh shutdown kvm66 virsh shutdown kvm68 brctl delif br0 vnet10 vnet6 # the interfaces of kvm66 and kvm68 brctl addbr br1 brctl addif br1 vnet10 vnet6 Then I've replaced br0 to br1 in the XML of both VM's with "virsh edit". Then I did start the VM's using the serial console (no network): virsh start --console kvm66 virsh start --console kvm68 I cannot ping from one machine to the other. Why?? With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/

4 5

How to open listener of Libvirt ?
by tommy 04 Jan '21

04 Jan '21

Hi,every one: My Ubuntu is : 20.04 LTS, and I using libvirtd on it to manage KVM vm, but now I can not open listener function of the libvirtd. SYSTEM SOCKET ACTIVATION The libvirtd daemon is capable of starting in two modes. In the traditional mode, it will create and listen on UNIX sockets itself. If the --listen parameter is given, it will also listen on TCP/IP socket(s), according to the listen_tcp and listen_tls options in /etc/libvirt/libvirtd.conf In socket activation mode, it will rely on systemd to create and listen on the UNIX, and optionally TCP/IP, sockets and pass them as pre-opened file de� scriptors. In this mode, it is not permitted to pass the --listen parameter, and most of the socket related config options in /etc/libvirt/libvirtd.conf will no longer have any effect. To enable TCP or TLS sockets use either $ systemctl start libvirtd-tls.socket Or $ systemctl start libvirtd-tcp.socket But, on my system, there are no such service like libvirtd-tls.socket or libvirtd-tcp.socket. root@ubts1:~# systemctl | grep libvirt libvirt-guests.service loaded active exited Suspend/Resume Running libvirt Guests libvirtd.service loaded active running Virtualization daemon libvirtd-admin.socket loaded active running Libvirt admin socket libvirtd-ro.socket loaded active running Libvirt local read-only socket libvirtd.socket loaded active running Libvirt local socket How can I open the listener ? Thanks！

2 3

cannot get Libvirt/qemu to use secure boot
by Felix Rubio Dalmau 29 Dec '20

29 Dec '20

Hi everybody, I am having serious trouble enabling secure boot via virt-install... and I do not see clearly even where to look for help :-/. Maybe somebody can point me on the right direction? I am running: arch linux edk2-ovmf 202011-1 libvirt 6.5 virt-install 3.2 qemu 5.2 I am creating the domain with virt-install, and the parameters --features smm.state=on --boot loader=/usr/share/ovmf/x64/OVMF_CODE.secboot.fd,nvram.template=/usr/share/ovmf/x64/OVMF_VARS.fd,loader.readonly=yes,loader.type=pflash,loader_secure=yes If I boot into the UEFI I can see there is the menu for the OVMF and Secure Boot available, but when I get into the Secure Boot entry, I only see it is "disabled" and I cannot tick the "Attempt secure boot" box. As far as I understand, by using OVMF_CODE.secboot.f I should already get the default keys working, so I should be good to go to test this setup, but... to no success. Does anybody have any idea on what might be wrong/where can I get help (should this not be the place?) Thank you! Felix

1 1

Manage libvirt actions through netgroups and PolKit
by Gi Actor 26 Dec '20

26 Dec '20

1 0

libvirt-lxc: Permission issue of /proc/net
by John Hurnett 24 Dec '20

24 Dec '20

Hi, I've encountered a problem that some of /proc/net/ files can't be accessed in unprivileged containers, because it is owned by nobody:nogroup (-1:-1) and have 440 permissions. This exact issue was solved in LXC project by unsharing netns: https://github.com/lxc/lxc/commit/5b1e83cbc498cd3edeaf13afa987d530299a35a7 . Maybe it could be similarly fixed on libvirt-lxc? BR, John H.

2 2

AppArmor issue when using gluster storage pool
by Max Schettler 16 Dec '20

16 Dec '20

Hi, I'm trying to run a VM image that's stored on a gluster storage pool which I added to libvirt (5.0.0) on a Debian 10 installation. Whenever I try to boot a gluster-based VM, I get an error message about a missing AppArmor profile. In fact, the corresponding files (/etc/apparmor.d/libvirt/libvirt-{,.files}) are missing. After some tinkering I noticed that the profile for the VM are in fact missing iff there is a gluster-based disk attached to the VM in question. Whenever I remove the disk, the profile files reappear, and when I add it again, they are not present. I am wondering what might cause this, and how I could fix, or work around it, other than outright disabling AppArmor altogether. Thanks and best regards, Max Schettler -- Max Schettler, M.Sc. TKN, TU Berlin, Germany http://www.ccs-labs.org/team/schettler/

1 0

SASL(-1): generic failure: All-whitespace username - from HA/pacemaker
by lejeczek 15 Dec '20

15 Dec '20

Hi guys, I have a HA/pacemaker cluster with VirtualDomain and it all seems to work fine, VMs start & stop, except for live migration. So I thought I'd start here with errors I see, from 'pacemaker': ... All-whitespace username. notice: vpn1_migrate_to_0[977276] error output [ error: authentication failed: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: All-whitespace username.) ] notice: vpn1_migrate_to_0[977276] error output [ ocf-exit-reason:vpn1: live migration to dzien failed: 1 ] notice: Result of migrate_to operation for vpn1 on swir: error notice: swir-vpn1_migrate_to_0:189 [ error: authentication failed: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: All-whitespace username.)\nocf-exit-reason:vpn1: live migration to dzien failed: 1\n ] notice: Result of stop operation for vpn1 on swir: ok Can you shed more light on what virsh/libvirt says there? many thanks, L.

1 0

live migration with authentication - how?
by lejeczek 15 Dec '20

15 Dec '20

Hi guys. I'm trying I assumed something very crude, logic suggested I should try it first: $ virsh migrate reactos qemu+ssh://dzien/system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf Please enter your authentication name: vdsm@ovirt Please enter your password: As you can see I still get asked for credentials. Is it possible to live migrate that(or some) way, without being asked for those? many thanks, L.

2 2

Libvirt-lxc: iptables not working in containers
by John Hurnett 15 Dec '20

15 Dec '20

Hi, I can't get iptables to work in libvirt-lxc containers. "iptables -L" command shows empty chains. However I tested the same scenario with pure lxc and iptables works as it should. Has anyone experienced that? It seems like a bug, but maybe there is some libvirt xml parameter I am missing? BR

2 1

Installing Kali Linux as Guest OS in KVM Hypervisor
by Kaushal Shriyan 11 Dec '20

11 Dec '20

Hi, I have run the below command to install Kali Linux using linux-2020.4-installer-amd64.iso from https://www.kali.org/downloads/ #virt-install --name kalilinux --memory 4096 --vcpus=2 --location=/linuxkvmaddgbdisk/kali-linux-2020.4-installer-amd64.iso,kernel=install.amd/gtk/vmlinuz,initrd=install.amd/gtk/initrd.gz --network=bridge:br0 --os-type=linux --os-variant=debian9 --graphics=none --extra-args "console=ttyS0" -v --disk path=/linuxkvmaddgbdisk/kalilinux.img,size=50 I am not able to get the root login prompt when I run the below command to set IP and hostname for the guest OS. Am I missing any parameters from the above virt-install command to install Kali Linux as Guest OS in KVM Hypervisor? #virsh console kalilinux Connected to domain kalilinux Escape character is ^] Any help will be highly appreciated. I look forward to hearing from you. Thanks in Advance. Best Regards, Kaushal

4 6

[CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski 11 Dec '20

11 Dec '20

We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2021, to be hosted virtually on February 6th 2021. This year will mark FOSDEM’s 21th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. Due to Covid-19, FOSDEM will be held virtually this year on February 6th & 7th, 2021. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at users or developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 20th of December Acceptance notifications: 25th of December Final schedule announcement: 31st of December Recorded presentations upload deadline: 15th of January Devroom: 6th February 2021 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will need to be pre-recorded and put into our system at least a couple of weeks before the event. The presentations should be uploaded by 15th of January and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend the virtual FOSDEM event for the Q&A. We will not consider proposals from prospective speakers who are unsure whether they will be able to attend the FOSDEM virtual event. If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance with helping speakers to record the presentation as well as helping with streaming and chat moderation for the devroom. Please contact devroom mailing list [2] for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17>https://penta.fosdem .org/submission/FOSDEM21 [2] iaas-virt-devroom at lists.fosdem.org

1 1

Cannot passthrough usb with bus number and device number
by YaoHua Wu 08 Dec '20

08 Dec '20

Sometimes, qemu cannot find correct usb device number Reproduce steps: 1、lsusb Bus 001 Device 011: ID 090c:1000 1、prepare usb device attach xml <hostdev managed="yes" mode="subsystem" type="usb"> <source> <vendor id="0x090c" /> <product id="0x1000" /> <address bus='001' device='011'/> </source><address bus="1" port="1" type="usb" /> </hostdev> 2、virsh attach-device vm usb.xml error: internal error: Did not find USB device 090c:1000 bus:1 device 9 Question: why the device number returned in qemu's error report is not what I wrote in xml， what I mean is that if my dev number is really wrong, the returned error should also be the number I wrote， commonly when using dongle Look forward to your reply yaohua.wu

2 3