search for: rodrigosiqueira

...someone could help us. Follows: 1) Import our QEMU images with virsh Currently, we import the QEMU VMs with virt-install. Is it possible to automatically discover the distro variant of a QEMU image in order to use it in the “--os-variant” option? Here is how we register a VM: https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113 2) The requirement of sudo to create a network When we register our VM, we want to keep the ssh working well. However, every time we register a VM we create a new network bridge as a result it requires sudo. Is it possible to avoid...

...r you). Yes, I did it last week. I'm doing the following steps: 1. I mount the disk image using libguestfs 2. Print the value MOUNT_PATH_DISK/etc/*-release 3. Take the distro and version Do you know a straightforward path? > > Here is how we register a VM: > > https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113 > > > > 2) The requirement of sudo to create a network > > > > When we register our VM, we want to keep the ssh working well. However, > > every time we register a VM we create a new network bridge as...

...> >Is it possible to automatically discover the distro variant of a QEMU >image in order to use it in the “--os-variant” option? > You might be able to get that info using libguestfs (virt-v2v should be able to do that for you). >Here is how we register a VM: >https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113 > >2) The requirement of sudo to create a network > >When we register our VM, we want to keep the ssh working well. However, >every time we register a VM we create a new network bridge as a result >it requires sudo....

Hi, Thanks for the patch, I reviewed and tested it. Everything looks fine for VKMS. Reviewed-by: Rodrigo Siqueira <rodrigosiqueira at gmail.com> Tested-by: Rodrigo Siqueira <rodrigosiqueira at gmail.com> On 01/15, Thomas Zimmermann wrote: > VBLANK callbacks in struct drm_driver are deprecated in favor of > their equivalents in struct drm_crtc_funcs. Convert vkms over. > > Signed-off-by: Thomas Zimmermann...

VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert vkms over. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++++++--- drivers/gpu/drm/vkms/vkms_drv.c | 1 - drivers/gpu/drm/vkms/vkms_drv.h | 4 ---- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git

VBLANK handlers in struct drm_driver are deprecated. Only legacy, non-KMS drivers are supposed to used them. DRM drivers with kernel modesetting are supposed to use VBLANK callbacks of the CRTC infrastructure. This patchset converts all DRM drivers to CRTC VBLANK callbacks and cleans up struct drm_driver. The remaining VBLANK callbacks in struct drm_driver are only used by legacy drivers. Patch

VBLANK handlers in struct drm_driver are deprecated. Only legacy, non-KMS drivers are supposed to used them. DRM drivers with kernel modesetting are supposed to use VBLANK callbacks of the CRTC infrastructure. This patchset converts all DRM drivers to CRTC VBLANK callbacks and cleans up struct drm_driver. The remaining VBLANK callbacks in struct drm_driver are only used by legacy drivers.

VBLANK handlers in struct drm_driver are deprecated. Only legacy, non-KMS drivers are supposed to used them. DRM drivers with kernel modesetting are supposed to use VBLANK callbacks of the CRTC infrastructure. This patchset converts all DRM drivers to CRTC VBLANK callbacks and cleans up struct drm_driver. The remaining VBLANK callbacks in struct drm_driver are only used by legacy drivers. Patch