September 2022 - Users - libvirt List Archives

Re: Help in porting smack related patches to meson build system
by Peter Krempa 20 Sep '22

20 Sep '22

On Mon, Sep 19, 2022 at 16:31:25 +0000, Vishal Gupta (vishagu2) wrote: > Hi Peter , Hi, I firstly want to ask you to avoid top-posting on technical mailing lists. > > > > Thanks for ur reply . > > > > Kirkstone is the latest release from Yocto foundation . details https://docs.yoctoproject.org/dev/migration-guides/migration-4.0.html > > > > Kirkstone support libvirt 8.10 https://layers.openembedded.org/layerindex/recipe/3052/ > > > > We are trying to port 2016 smack patch " https://listman.redhat.com/archives/libvir-list/2016-July/msg00456.html" for libvirt which is based on automake make file Okay so that is quite an old patch which was never finished and merged. > But above patch is incompatible with libvirt 8.10 .as libvirt 8.1 supports only meson > > > I was just wondering if above smack patch is already ported for meson based libvirt 8.10? > > We have issue in porting m4/virt-smack.m4 to meson.build file . virt-smack.m4 is define in 2016 smack patch No it is not ported. I want to warn you though that porting the build system part to meson will not be biggest of the problems. 1) The patch is more than 6 years old at this point There's quite a lot of change in libvirt during that time. Many helpers and internal APIs were refactored. The patch even once you port the build system will require *significant* rework to actually even compile. 2) libsmack (smack-utils) used by the new security module is not present in distros The library it requires doesn't seem to be adopted much: https://repology.org/project/smack-utils/versions Did you make sure that it's present in your environment? Additionally if you want to get the patch accepted upstream note that there were outstanding problems with the patch in the last version which is on the mailing list. I can see that there are definitely problems with coding style and the patch will need to be split to logical chunks as it's now just a big blob of code. Also given that the library is simply not present in distros it will require a justification why upstream should cary the patch. Carying code which is not compiled because of lack of dependencies is a burden to upstream and still can bitrot in the future. Even if you are not striving for upstreaming the patch, be prepared for more work than just porting the build system.

1 0

Help in porting smack related patches to meson build system
by Akash Bhaskaran (akabhask) 19 Sep '22

19 Sep '22

Hi, We are trying to port some patches pertaining to files like Makefile.am ,configure.ac and .m4’s to libvirt kirkstone release. We see that latest kirskstone now uses meson build architecture. We have difficulties in porting the changes in the above-mentioned files to meson. Is there any script or reference you can provide for helping us port these files to meson? Thanks, Akash

2 1

virt-manager alt-click passthrough?
by Alex 10 Sep '22

10 Sep '22

Hi, I'm using virt-manager to connect to a Windows 10 virtual machine, where I'm using photoshop. I need to send an alt-click key for some functions, but virt-manager is instead interpreting them. It isn't among the pre-configured options that can be sent. Is there a way to remap the alt key or alt-click combination so I can send it through to the virtual machine? I've also tried the RealVNC client/server trial, and I can't get that to connect at all. It does appear qemu/realvnc server is listening on 5900: tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN - qemu is also configured to listen (-spice port=5900,addr=127.0.0.1). I've also verified I can connect to port 5900 manually, so a Windows firewall is not the problem. Any ideas greatly appreciated.

1 0

[libvirt-users] [virtual interface] detach interface during boot succeed with no changes
by Yalan Zhang 08 Sep '22

08 Sep '22

Hi guys, when I detach an interface from vm during boot (vm boot not finished), it always fail. I'm not sure if there is an existing bug. I have confirmed with someone that for disk, there is similar behavior, if this is also acceptable? # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2; virsh detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh dumpxml rhel7.2 |grep /interface -B9 Domain rhel7.2 destroyed Domain rhel7.2 started Interface detached successfully <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </controller> <interface type='network'> <mac address='52:54:00:98:c4:a0'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> When I detach after the vm boot, expand the sleep time to 10, it will succeed. # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10; virsh detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh dumpxml rhel7.2 |grep /interface -B9 Domain rhel7.2 destroyed Domain rhel7.2 started Interface detached successfully ------- Best Regards, Yalan Zhang IRC: yalzhang Internal phone: 8389413

3 4

CPU features/flags - host vs. guest (Libvirt/QEMU/KVM)
by kAja Ziegler 07 Sep '22

07 Sep '22

Hello, does anyone know of any list/table (ideally as up-to-date as possible) with individual CPU features/flags for x86_64 (preferably Intel), which would state: - description of individual features/flags - dependencies between individual features/flags - e.g. avx on xsave - what features/flags are checked on the hypervisor (host), but are not propagated to the guest - e.g. acpi, ds, monitor, pbe, tm, etc. - some are masked/disabled [(not) supported] by Libvirt, others by KVM/QEMU - what features/flags active for/in the guest limit certain virtualization behavior/options such as live migration - e.g. invtsc, xsaves - so far I only found https://github.com/libvirt/libvirt/blob/master/src/cpu_map/x86_features.xml - features with migratable='no' I would like to tweak the CPU configuration for the virtual servers ie. choose the basic CPU model and turn on/off the necessary or appropriate features/flags while maintaining the possibility of live migration. But I miss the above-mentioned contexts, because not all the mentioned features within the cpu element in the VM definition (domains in Libvirt) are then visible inside the VM in /proc/cpuinfo. Of course, I know about other related commands, registers, etc. like "virsh capabilities|cpu-baseline|cpu-compare", MSR, fixes in CPU microcode, host-model or host-passthrough CPU... but I'm still not sure about setting the match, check and fallback attributes and the resulting behavior of Libvirt and QEMU/KVM. Many thanks in advance for any response K. Ziegler

1 0