Re: [libvirt] [PATCH 11/41] qemu: Separate guest CPU validation from command line creation

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > qemu_command.c should deal with translating our domain definition into a > QEMU command line and nothing else. > > Signed-off-by: Jiri Denemark > --- > src/qemu/qemu_command.c | 71 >

Re: [libvirt] [PATCH 20/41] domcaps: Add CPU usable flag

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > In case a hypervisor is able to tell us a list of supported CPU models > and whether each CPU models can be used on the current host, we can > propagate this to domain capabilities. This is a better alternative > to calling virConnectCompareCPU for

Re: [libvirt] [PATCH 15/41] qemu: Introduce virQEMUCapsGuestIsNative

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > To have a single place where we decide whether a guest can run natively > on a host. > > Signed-off-by: Jiri Denemark > --- > src/qemu/qemu_capabilities.c | 43 +++ > 1 file changed, 27

Re: [libvirt] [PATCH 17/41] cpu: Special case models == NULL in cpuGetModels

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > Some CPU drivers (such as arm) do not provide list of CPUs libvirt > supports and just pass any CPU model from domain XML directly to QEMU. > Such driver need to return models == NULL and success from cpuGetModels. > > Signed-off-by: Jiri Denemark

Re: [libvirt] [PATCH 16/41] qemu: Fill in CPU domain capabilities

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark > --- > src/qemu/qemu_capabilities.c | 24 +- > src/qemu/qemu_capabilities.h | 3 +- > src/qemu/qemu_driver.c | 7 +- >

Re: [libvirt] [PATCH V2] virpci: support driver_override sysfs interface

Hi Laine, Did you have a chance to look at V2 of this patch? As discussed in V1, I left the existing code untouched and added new functions for the driver_override interface. Thanks! Regards, Jim Jim Fehlig wrote: > libvirt uses the new_id PCI sysfs interface to bind a PCI stub driver > to a

Re: [libvirt] [PATCH 22/41] qemu: Propagate virCapsPtr to virQEMUCapsNewForBinaryInternal

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark > --- > src/qemu/qemu_capabilities.c | 25 +++-- > src/qemu/qemu_capabilities.h | 6 -- > src/qemu/qemu_capspriv.h | 3 ++- > src/qemu/qemu_domain.c | 13

Re: [libvirt] [PATCH v5 0/8] perf: add more perf events support

Hi John, How about this patch series? Thanks, Qiaowei > -Original Message- > From: John Ferlan [mailto:jfer...@redhat.com] > Sent: Thursday, August 4, 2016 6:31 AM > To: libvir-list@redhat.com > Cc: Ren, Qiaowei > Subject: [PATCH v5 0/8] perf: add more perf

Re: [libvirt] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

On 29/08/2016 08:57, Philipp Hahn wrote: > Hello, > > If my understanding of migration/snapshots is correct, the > target/loading VM must be a clone of the source/saving VM, that is have > the same devices, RAM/PCI layout, etc. In the past I have had several > issues with Qemu, when the

Re: [libvirt] qemu-guest-agent windows

Hi Michal well no luck :( br. Umar On Mon, Aug 29, 2016 at 11:55 AM, Michal Privoznik wrote: > On 29.08.2016 08:32, Umar Draz wrote: > > Hi Michal > > > > Thanks for your reply, how I can upgrade my guest agent on windows? > > I think if you download msi corresponding to

Re: [libvirt] RFC: Limited dynamic ownership

On Tue, Aug 23, 2016 at 07:25:56PM -0400, Daniel P. Berrange wrote: On Tue, Aug 23, 2016 at 06:17:44PM -0400, Martin Kletzander wrote: On Tue, Aug 23, 2016 at 05:54:29PM -0400, Daniel P. Berrange wrote: > On Tue, Aug 23, 2016 at 05:06:20PM -0400, Martin Kletzander wrote: > > Hi everyone, > > >

Re: [libvirt] [PATCHv5 11/13] Add compatibility attribute to video

Hi Ján, I apply your patches of virtio compatibility attribute. And I find virtio video and input devices using virtio modern when set compatibility as legacy. The xml: Check virtio version in guest:

Re: [libvirt] [PATCH v2] tests: fix segfault in objecteventtest

On 25.08.2016 07:50, Roman Bogorodskiy wrote: > Test 12 from objecteventtest (createXML add event) segaults on FreeBSD > with bus error. > > At some point it calls testNodeDeviceDestroy() from the test driver. And > it fails when it tries to unlock the device in the "out:" label of this >

Re: [libvirt] [PATCH] bhyve: fix disks address allocation

Laine Stump wrote: > On 08/28/2016 08:45 AM, Roman Bogorodskiy wrote: > > As bhyve currently doesn't use controller addressing and simply > > uses 1 implicit controller for 1 disk device, the scheme looks the > > following: > > > > pci addrees -> (implicit controller) -> disk device > > > >

Re: [libvirt] qemu-guest-agent windows

On 28.08.2016 16:53, Umar Draz wrote: > Hello All, > > I have install qemu guest agent on windows 10, but unable to get the ip > address using this command > > virsh qemu-agent-command myvm '{ "execute": "guest-network-get-interfaces" > }' > > I am getting the following error on above command.

Re: [libvirt] qemu-guest-agent windows

On 29.08.2016 08:32, Umar Draz wrote: > Hi Michal > > Thanks for your reply, how I can upgrade my guest agent on windows? I think if you download msi corresponding to your architecture from here

[libvirt] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

Hello, If my understanding of migration/snapshots is correct, the target/loading VM must be a clone of the source/saving VM, that is have the same devices, RAM/PCI layout, etc. In the past I have had several issues with Qemu, when the distribution (Debian) updates their packaging of

Re: [libvirt] qemu-guest-agent windows

Hi Michal Thanks for your reply, how I can upgrade my guest agent on windows? right now this is running on windows ("version":"0.12.1") Br. Umar On Mon, Aug 29, 2016 at 11:22 AM, Michal Privoznik wrote: > On 28.08.2016 16:53, Umar Draz wrote: > > Hello All, > > > > I

Re: [libvirt] qemu-guest-agent windows

On 29.08.2016 11:48, Umar Draz wrote: > Hi Michal, > > well after the upgrade I am still getting the old version > >

Re: [libvirt] qemu-guest-agent windows

On 29.08.2016 12:11, Umar Draz wrote: > Ok then I will check that as well, > > Ok I have some FereeBSD vms as well, now I want qemu-guest-agent on them as > well, is it possible? > Yes. There are two implementations for qemu-ga: one for POSIX-like systems (where *BSD does belong to) and for

Re: [libvirt] qemu-guest-agent windows

Hi Michal, Thanks, I have installed qemu-ga on FreeBSD. Now I just need a help regarding what will be the xml for my this FreeBSD ? Br. Umar On Mon, Aug 29, 2016 at 3:30 PM, Michal Privoznik wrote: > On 29.08.2016 12:11, Umar Draz wrote: > > Ok then I will check that as

Re: [libvirt] qemu-guest-agent windows

Hi Michal, well after the upgrade I am still getting the old version

Re: [libvirt] [PATCH] Check for --live flag for postcopy-after-precopy migration

On 08/27/2016 02:21 AM, Jiri Denemark wrote: On Fri, Aug 26, 2016 at 21:41:31 +0200, Michal Privoznik wrote: On 26.08.2016 11:25, Kothapally Madhu Pavan wrote: Unlike postcopy migration there is no --live flag check for postcopy-after-precopy. Signed-off-by: Kothapally Madhu Pavan

Re: [libvirt] qemu-guest-agent windows

On 29.08.2016 10:27, Umar Draz wrote: > Hi Michal > > well no luck :( What do you mean? I need more info. The update was successful, but the qemu-ga is still not returning any IP addresses? What's the new version of qemu-ga then? What might work is to clone qemu.git and compile the qemu-ga from

Re: [libvirt] qemu-guest-agent windows

Ok then I will check that as well, Ok I have some FereeBSD vms as well, now I want qemu-guest-agent on them as well, is it possible? Br. Umar On Mon, Aug 29, 2016 at 2:54 PM, Michal Privoznik wrote: > On 29.08.2016 11:48, Umar Draz wrote: > > Hi Michal, > > > > well

Re: [libvirt] [PATCH v2] tests: fix segfault in objecteventtest

Michal Privoznik wrote: > On 25.08.2016 07:50, Roman Bogorodskiy wrote: > > Test 12 from objecteventtest (createXML add event) segaults on FreeBSD > > with bus error. > > > > At some point it calls testNodeDeviceDestroy() from the test driver. And > > it fails when it tries to unlock the

Re: [libvirt] qemu-guest-agent windows

Well here is the xml of my linux virtual machines for qemu-guest-agent now what will be for freebsd ? Br. Umar On Mon, Aug 29, 2016 at 6:06 PM, Michal Privoznik wrote: > On 29.08.2016 13:59, Umar Draz wrote: > > Hi Michal, > > > > Thanks, I have installed

Re: [libvirt] qemu-guest-agent windows

HI Thanks Got it. On Mon, Aug 29, 2016 at 6:36 PM, Vasiliy Tolstov wrote: > 2016-08-29 16:20 GMT+03:00 Umar Draz : > > Well here is the xml of my linux virtual machines for qemu-guest-agent > > > > > > > > > > > > now what will be for freebsd ? > >

Re: [libvirt] qemu-guest-agent windows

On 29.08.2016 13:59, Umar Draz wrote: > Hi Michal, > > Thanks, I have installed qemu-ga on FreeBSD. > > Now I just need a help regarding what will be the xml for my this FreeBSD ? What do you mean? Domain XML? Domain XML is guest OS agnostic. So whatever qemu-ga config you have in a domain that

[libvirt] [PATCH] libxl: advertise support for migration V3

The libxl driver has long supported migration V3 but has never indicated so in the connectSupportsFeature API. As a result, apps such as virt-manager that use the more generic virDomainMigrate API fail with libvirtError: this function is not supported by the connection driver: virDomainMigrate

Re: [libvirt] [PATCH 03/41] qemu: Use virDomainCapsCPUModels for cpuDefinitions

On 08/12/2016 09:32 AM, Jiri Denemark wrote: > The list of supported CPU models in domain capabilities is stored in > virDomainCapsCPUModels. Let's use the same object for storing CPU models > in QEMU capabilities. > > Signed-off-by: Jiri Denemark > --- >

Re: [libvirt] [PATCH 02/41] domcaps: Add support for listing supported CPU models

On 08/12/2016 09:32 AM, Jiri Denemark wrote: > The patch adds element to domain capabilities XML: > > > > > > Broadwell > Broadwell-noTSX > ... > > > > Applications can use it to inspect what CPU configuration

Re: [libvirt] [PATCH 10/41] testutilsqemu: Helpers for changing host CPU and arch

On 08/12/2016 09:33 AM, Jiri Denemark wrote: > Changing a host architecture or a CPU is not as easy as assigning a new > value to the appropriate element in virCaps since there is a relation > between the CPU and host architecture (we don't really want to test > anything on an AArch64 host with