e actual
patch mails:
https://listman.redhat.com/archives/libvir-list/2022-March/229089.html
Anyone else who responds to any of the mail on this thread should fix
the qemu-devel address accordingly.
On 3/8/22 10:33 AM, Laine Stump wrote:
On 3/8/22 1:39 AM, Ani Sinha wrote:
Changelog:
v2 - re
On 9/30/21 1:09 PM, Laurent Vivier wrote:
If we want to save a snapshot of a VM to a file, we used to follow the
following steps:
1- stop the VM:
(qemu) stop
2- migrate the VM to a file:
(qemu) migrate "exec:cat > snapshot"
3- resume the VM:
(qemu) cont
After that we can restore t
On 3/11/21 8:19 PM, David Gibson wrote:
On Thu, Mar 11, 2021 at 05:50:42PM -0300, Daniel Henrique Barboza wrote:
On 3/9/21 3:22 AM, Markus Armbruster wrote:
Cc: Paolo and Julia in addition to Igor, because the thread is wandering
towards DeviceState member pending_deleted_event.
Cc: Laine fo
On 5/21/20 9:23 AM, Igor Mammedov wrote:
On Thu, 21 May 2020 06:07:25 -0400
"Michael S. Tsirkin" wrote:
On Thu, May 21, 2020 at 09:32:17AM +0200, Igor Mammedow wrote:
On Wed, 20 May 2020 12:13:35 -0400
"Michael S. Tsirkin" wrote:
On Wed, May 20, 2020 at 02:20:12PM +0200, Igor Mammedow w
On 4/17/20 12:35 PM, Ani Sinha wrote:
+Laine
On Apr 17, 2020, at 9:39 PM, Michael S. Tsirkin wrote:
Problem is, I think this is not something we can support with pcie or shpc.
I'm reluctant to add features that only ACPI can support,
we are trying to phase that out.
Hmm. I see. We use conve
On 2/19/20 9:55 AM, Julia Suvorova wrote:
Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt
manage it and restrict unplug for the whole machine. This is going to
prevent user-initiated unplug in guests (Windows mostly).
Hotplug is enabled by default.
Usage:
-device pcie-r
On 2/18/20 1:40 PM, Julia Suvorova wrote:
On Tue, Feb 18, 2020 at 6:18 PM Laine Stump wrote:
On 2/18/20 11:17 AM, Julia Suvorova wrote:
Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt
to manage it and restrict unplug for the entire machine. This is going
to prevent user
On 2/18/20 11:17 AM, Julia Suvorova wrote:
Make hot-plug/hot-unplug on PCIe Root Ports optional to allow libvirt
to manage it and restrict unplug for the entire machine. This is going
to prevent user-initiated unplug in guests (Windows mostly).
Usage:
-device pcie-root-port,disable-hotplug=t
On 2/4/20 1:43 PM, Daniel P. Berrangé wrote:
On Mon, Feb 03, 2020 at 05:19:51PM -0500, Laine Stump wrote:
Although I've never experienced it, due to not running Windows guests, I've
recently learned that a Windows guest permits a user (hopefully only one
with local admin privileges??
Although I've never experienced it, due to not running Windows guests,
I've recently learned that a Windows guest permits a user (hopefully
only one with local admin privileges??!) to "hot-unplug" any PCI device.
I've also learned that some hypervisor admins don't want to permit
admins of the v
On 11/4/19 4:21 PM, Parav Pandit wrote:
Patches are great to see failover capability enabled on the netdevice.
However it's very difficult to test it without having libvirt support.
Can we please have the necessary libvirt enhancements?
I'm working on libvirt support, and will make sure to C
On 10/23/19 5:15 PM, Alex Williamson wrote:
On Wed, 23 Oct 2019 22:31:37 +0200
Jens Freimann wrote:
On Wed, Oct 23, 2019 at 02:02:11PM -0600, Alex Williamson wrote:
On Wed, 23 Oct 2019 21:30:35 +0200
Jens Freimann wrote:
On Wed, Oct 23, 2019 at 12:06:48PM -0600, Alex Williamson wrote:
O
On 6/12/19 7:59 AM, Jens Freimann wrote:
On Wed, Jun 12, 2019 at 11:11:23AM +0200, Daniel P. Berrangé wrote:
On Tue, Jun 11, 2019 at 11:42:54AM -0400, Laine Stump wrote:
On 5/17/19 8:58 AM, Jens Freimann wrote:
>
> Command line example:
>
> qemu-system-x86_64 -enable-kvm -m
On 6/11/19 11:51 AM, Michael S. Tsirkin wrote:
On Tue, Jun 11, 2019 at 11:42:54AM -0400, Laine Stump wrote:
On 5/17/19 8:58 AM, Jens Freimann wrote:
This is another attempt at implementing the host side of the
net_failover concept
(https://www.kernel.org/doc/html/latest/networking
On 5/17/19 8:58 AM, Jens Freimann wrote:
This is another attempt at implementing the host side of the
net_failover concept
(https://www.kernel.org/doc/html/latest/networking/net_failover.html)
Changes since last RFC:
- work around circular dependency of commandline options. Just add
failover=
On 6/4/19 9:43 AM, Jens Freimann wrote:
On Mon, Jun 03, 2019 at 04:36:48PM -0300, Eduardo Habkost wrote:
On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote:
On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:
> On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrot
On 6/3/19 2:12 PM, Michael S. Tsirkin wrote:
On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote:
On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:
On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:
On 5/21/2019 11:49 AM, Jens Freimann wrote:
On Tue, May 21, 2019 at 07:37
On 6/3/19 4:24 AM, Jens Freimann wrote:
On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:
On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan
On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:
On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:
On 5/21/2019 11:49 AM, Jens Freimann wrote:
On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote:
On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote:
On Mon, M
On 5/23/19 10:58 AM, Dr. David Alan Gilbert (git) wrote:
From: "Dr. David Alan Gilbert"
Laine asked for some extra features on the network announce support;
this is the first one of them.
It allows you to send an announce on a subset of the interfaces.
Note since we've still only got one timer
On 10/16/2018 01:02 PM, Daniel P. Berrangé wrote:
> On Mon, Oct 15, 2018 at 03:14:04PM -0300, Eduardo Habkost wrote:
>> On Sun, Oct 14, 2018 at 05:35:12PM -0400, Michael S. Tsirkin wrote:
>>> On Fri, Oct 12, 2018 at 11:54:35PM -0300, Eduardo Habkost wrote:
The current virtio-*-pci device types
ed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote:
>>>>> On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote:
>>>>>> On 08/17/2018 06:35 AM, Andrea Bolognani wrote:
>>>>>>> If we decide we want to explicitly spell out the option
On 08/17/2018 06:35 AM, Andrea Bolognani wrote:
> On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
>> On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
>>> 5) Some guest OSes that we still want to support (and which would
>>> otherwise work ok
(Several of us started an offline discussion on this topic, and it
quickly became complicated, so we decided it should continue upstream.
Here is a synopsis of the discussion so far (as *I've* interpreted it,
so corrections are welcome and apologies in advance for anything I got
wrong!) Some of the
On 08/03/2017 06:29 AM, Marcel Apfelbaum wrote:
> On 03/08/2017 5:41, Laine Stump wrote:
>> On 08/02/2017 01:58 PM, Marcel Apfelbaum wrote:
>>> On 02/08/2017 19:26, Michael S. Tsirkin wrote:
>>>> On Wed, Aug 02, 2017 at 06:36:29PM +0300, Marcel Apfelbaum wrote:
>&
On 08/02/2017 01:58 PM, Marcel Apfelbaum wrote:
> On 02/08/2017 19:26, Michael S. Tsirkin wrote:
>> On Wed, Aug 02, 2017 at 06:36:29PM +0300, Marcel Apfelbaum wrote:
Can dmi-pci support shpc? why doesn't it? For compatibility?
>>>
>>> I don't know why, but the fact that it doesn't
On 06/29/2017 03:44 PM, Alex Williamson wrote:
> On Thu, 29 Jun 2017 14:50:15 -0400
> Laine Stump wrote:
>
>> On 06/28/2017 08:24 PM, Michael Roth wrote:
>>> Hi everyone. Hoping to get some feedback on this approach, or some
>>> alternatives propo
On 06/28/2017 08:24 PM, Michael Roth wrote:
> Hi everyone. Hoping to get some feedback on this approach, or some
> alternatives proposed below, to the following issue:
>
> Currently libvirt immediately attempts to rebind a managed device back to the
> host driver when it receives a DEVICE_DELETED
On 01/12/2017 11:35 AM, Michael Roth wrote:
Quoting Laine Stump (2017-01-12 08:52:10)
On 01/12/2017 05:31 AM, Andrea Bolognani wrote:
On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote:
* To allow for hotplugged devices, libvirt should also add a number
of additional, empty vPHBs
On 01/12/2017 05:31 AM, Andrea Bolognani wrote:
On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote:
* To allow for hotplugged devices, libvirt should also add a number
of additional, empty vPHBs (the PAPR spec allows for hotplug of
PHBs, but this is not yet implemented in qemu
On 12/15/2016 05:12 AM, Marcel Apfelbaum wrote:
On 12/14/2016 10:10 PM, Laine Stump wrote:
On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:
Be aware that 1 slot doesn't necessarily refer to only one device,
we can have a multi-function device.
Is that a fixed thing? I mean, is it a
On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:
On 12/13/2016 06:00 PM, Eduardo Habkost wrote:
On Tue, Dec 13, 2016 at 04:15:18PM +0200, Marcel Apfelbaum wrote:
On 12/13/2016 02:42 PM, Eduardo Habkost wrote:
On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
Quick interface re
(Sorry for any duplicates. I sent it from the wrong address the first time)
On 12/01/2016 11:18 PM, David Gibson wrote:
On Fri, Nov 25, 2016 at 02:46:21PM +0100, Andrea Bolognani wrote:
On Wed, 2016-11-23 at 16:00 +1100, David Gibson wrote:
Existing libvirt versions assume that pseries guests
On 12/01/2016 11:18 PM, David Gibson wrote:
On Fri, Nov 25, 2016 at 02:46:21PM +0100, Andrea Bolognani wrote:
On Wed, 2016-11-23 at 16:00 +1100, David Gibson wrote:
Existing libvirt versions assume that pseries guests have
a legacy PCI root bus, and will base their PCI address
allocation / PCI
On 11/03/2016 07:08 AM, Marcel Apfelbaum wrote:
On 11/02/2016 06:01 PM, Laine Stump wrote:
On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote:
The shpc component is optional while ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc by default will make slot
On 11/02/2016 11:16 AM, Marcel Apfelbaum wrote:
The shpc component is optional while ACPI hotplug is used
for hot-plugging PCI devices into a PCI-PCI bridge.
Disabling the shpc by default will make slot 0 usable at boot time
and not only for hot-plug, without loosing any functionality.
Older mac
On 10/31/2016 12:18 PM, Marcel Apfelbaum wrote:
+
+2.2.1 Plugging a PCI Express device into a PCI Express Root Port:
+ -device
ioh3420,id=root_port1,slot=x[,chassis=y][,bus=pcie.0][,addr=z] \
+ -device ,bus=root_port1
+ Note that (slot, chassis) pair is mandatory and mus
On 10/28/2016 07:28 AM, Henning Schild wrote:
Hey,
i am running an unusual setup where i assign pci devices behind the
back of libvirt. I have two options to do that:
1. a wrapper script for qemu that takes care of suid-root and appends
arguments for pci-assign
2. virsh qemu-monitor-command ...
On 10/04/2016 12:43 PM, Laszlo Ersek wrote:
On 10/04/16 18:10, Laine Stump wrote:
On 10/04/2016 11:40 AM, Laszlo Ersek wrote:
On 10/04/16 16:59, Daniel P. Berrange wrote:
On Mon, Sep 05, 2016 at 06:24:48PM +0200, Laszlo Ersek wrote:
All valid *high-level* topology goals should be permitted
On 10/04/2016 12:10 PM, Laine Stump wrote:
On 10/04/2016 11:40 AM, Laszlo Ersek wrote:
Small correction to your wording though: you don't want to attach the
DMI-PCI bridge to the PXB device, but to the extra root bus provided by
the PXB.
This made me realize something - the root bus
On 10/04/2016 11:45 AM, Alex Williamson wrote:
On Tue, 4 Oct 2016 15:59:11 +0100
"Daniel P. Berrange" wrote:
On Mon, Sep 05, 2016 at 06:24:48PM +0200, Laszlo Ersek wrote:
On 09/01/16 15:22, Marcel Apfelbaum wrote:
+2.3 PCI only hierarchy
+==
+Legacy PCI devices can be plu
On 10/04/2016 11:40 AM, Laszlo Ersek wrote:
On 10/04/16 16:59, Daniel P. Berrange wrote:
On Mon, Sep 05, 2016 at 06:24:48PM +0200, Laszlo Ersek wrote:
On 09/01/16 15:22, Marcel Apfelbaum wrote:
+2.3 PCI only hierarchy
+==
+Legacy PCI devices can be plugged into pcie.0 as In
On 09/28/2016 03:59 PM, Neo Jia wrote:
On Wed, Sep 28, 2016 at 07:45:38PM +, Tian, Kevin wrote:
From: Neo Jia [mailto:c...@nvidia.com]
Sent: Thursday, September 29, 2016 3:23 AM
On Thu, Sep 22, 2016 at 03:26:38PM +0100, Daniel P. Berrange wrote:
On Thu, Sep 22, 2016 at 08:19:21AM -0600, Al
On 09/07/2016 03:39 PM, Marcel Apfelbaum wrote:
On 09/07/2016 08:55 PM, Laine Stump wrote:
On 09/07/2016 04:06 AM, Marcel Apfelbaum wrote:
On 09/07/2016 09:21 AM, Gerd Hoffmann wrote:
Hi,
ports, if that's allowed). For example:
- 1-32 ports needed: use root ports only
- 33-64
On 09/07/2016 03:04 AM, Gerd Hoffmann wrote:
Hi,
Side note for usb: In practice you don't want to use the tons of
uhci/ehci controllers present in the original q35 but plug xhci into one
of the pcie root ports instead (unless your guest doesn't support xhci).
I've wondered about that recent
On 09/07/2016 04:06 AM, Marcel Apfelbaum wrote:
On 09/07/2016 09:21 AM, Gerd Hoffmann wrote:
Hi,
ports, if that's allowed). For example:
- 1-32 ports needed: use root ports only
- 33-64 ports needed: use 31 root ports, and one switch with 2-32
downstream ports
I expect you rarely need a
On 09/05/2016 10:18 PM, Alex Williamson wrote:
On Mon, 5 Sep 2016 11:36:55 +0200
Paolo Bonzini wrote:
On 05/09/2016 11:23, Markus Armbruster wrote:
On the other hand, it is clearly documented that the DEVICE_DELETED
event is sent as soon as guest acknowledges completion of device
removal. So
On 09/06/2016 07:35 AM, Gerd Hoffmann wrote:
While talking about integrated devices: There is docs/q35-chipset.cfg,
which documents how to mimic q35 with integrated devices as close and
complete as possible.
Usage:
qemu-system-x86_64 -M q35 -readconfig docs/q35-chipset.cfg $args
Side note fo
On 09/05/2016 05:36 AM, Paolo Bonzini wrote:
On 05/09/2016 11:23, Markus Armbruster wrote:
On the other hand, it is clearly documented that the DEVICE_DELETED
event is sent as soon as guest acknowledges completion of device
removal. So libvirt's buggy if we'd follow documentation strictly. But
On 09/02/2016 05:44 PM, Paolo Bonzini wrote:
On 02/09/2016 22:19, John Ferlan wrote:
We don't have such a pool for GPU's (yet) - although I suppose they
could just become a class of storage pools.
The issue being nodedev device objects are not saved between reboots.
They are generated on the
On 09/01/2016 12:59 PM, Alex Williamson wrote:
On Thu, 1 Sep 2016 18:47:06 +0200
Michal Privoznik wrote:
On 31.08.2016 08:12, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, August 31, 2016 12:17 AM
Hi folks,
At KVM Forum we had a BoF session pr
On 08/24/2016 06:29 PM, Daniel P. Berrange wrote:
On Thu, Aug 18, 2016 at 09:41:59AM -0700, Neo Jia wrote:
Hi libvirt experts,
I am starting this email thread to discuss the potential solution / proposal of
integrating vGPU support into libvirt for QEMU.
Some quick background, NVIDIA is implem
On 08/18/2016 12:41 PM, Neo Jia wrote:
Hi libvirt experts,
I am starting this email thread to discuss the potential solution / proposal of
integrating vGPU support into libvirt for QEMU.
Thanks for the detailed description. This is very helpful.
Some quick background, NVIDIA is implementin
On 08/19/2016 11:43 AM, Andrea Bolognani wrote:
On Thu, 2016-08-18 at 08:38 +0200, Andrew Jones wrote:
Finally, FWIW, with a guest kernel of 4.6.4-301.fc24.aarch64. The
following qemu command line works for me.
(notice the use of PCIe), and my network interface gets labeled enp0s1.
$QEMU -ma
On 08/18/2016 08:43 AM, Kevin Zhao wrote:
Hi Laine,
Thanks :-) I also has a little questions below.
On 18 August 2016 at 01:00, Laine Stump wrote:
On 08/17/2016 12:13 PM, Andrew Jones wrote:
On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote:
Hi all,
Now I&#
On 08/18/2016 08:10 AM, Marcel Apfelbaum wrote:
On 08/17/2016 08:00 PM, Laine Stump wrote:
What I'm not sure about is whether we should always auto-add an extra
pcie-*-root to be sure a device can be hotplugged, or if we should admit
that 1
available slot isn't good enou
On 08/18/2016 03:41 AM, Andrew Jones wrote:
On Wed, Aug 17, 2016 at 01:00:05PM -0400, Laine Stump wrote:
On 08/17/2016 12:13 PM, Andrew Jones wrote:
On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote:
Hi all,
Now I'm investigating net device hot plug and disk hotplug for
AA
On 08/17/2016 12:13 PM, Andrew Jones wrote:
On Wed, Aug 17, 2016 at 08:08:11PM +0800, Kevin Zhao wrote:
Hi all,
Now I'm investigating net device hot plug and disk hotplug for
AArch64. For virtio , the default address is virtio-mmio. After Libvirt
1.3.5, user can explicitly specify the addr
On 11/16/2015 05:37 AM, Michael S. Tsirkin wrote:
On Mon, Nov 16, 2015 at 12:34:11PM +0200, Marcel Apfelbaum wrote:
On 11/16/2015 12:11 PM, Paolo Bonzini wrote:
On 16/11/2015 11:10, Marcel Apfelbaum wrote:
What would you lose? Hotplug?
Without the bridge? Yes. However the user can add it
For a long time, libvirt assumed by default that all types of virtual
machines had an integrated IDE controller named "ide" that wasn't
specified on the qemu commandline. Since that caused problems
specifically for the Q35 machine type (which has an *ahci* controller
that it perplexingly calls
On 05/19/2015 05:07 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 22, 2015 at 10:23:04AM +0100, Daniel P. Berrange wrote:
>> On Fri, Apr 17, 2015 at 04:53:02PM +0800, Chen Fan wrote:
>>> backgrond:
>>> Live migration is one of the most important features of virtualization
>>> technology.
>>> With re
On 04/22/2015 01:20 PM, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> On Wed, Apr 22, 2015 at 06:12:25PM +0100, Dr. David Alan Gilbert wrote:
>>> * Daniel P. Berrange (berra...@redhat.com) wrote:
On Wed, Apr 22, 2015 at 06:01:56PM +0100, Dr. David Alan Gi
On 04/23/2015 04:34 AM, Chen Fan wrote:
>
> On 04/20/2015 06:29 AM, Laine Stump wrote:
>> On 04/17/2015 04:53 AM, Chen Fan wrote:
>>> - on destination side, check whether need to hotplug new NIC
>>> according to specified XML.
>>> usually, we use migrat
On 04/22/2015 12:22 AM, Chen Fan wrote:
> Hi Laine,
>
> Thanks for your review for my patches.
>
> and do you know that solarflare's patches have made some update version
> since
>
> https://www.redhat.com/archives/libvir-list/2012-November/msg01324.html
>
> ?
>
> if not, I hope to go on to complet
On 04/17/2015 04:53 AM, Chen Fan wrote:
> backgrond:
> Live migration is one of the most important features of virtualization
> technology.
> With regard to recent virtualization techniques, performance of network I/O
> is critical.
> Current network I/O virtualization (e.g. Para-virtualized I/O,
On 01/13/2015 05:01 PM, Gerhard Wiesinger wrote:
> On 13.01.2015 22:16, Paolo Bonzini wrote:
>>
>> On 13/01/2015 22:14, Gerhard Wiesinger wrote:
>>> I also had a look at the kernel code again:
>>> http://lxr.free-electrons.com/source/kernel/time/timekeeping.c?v=3.17#L493
>>>
>>> 499 do {
>>
On 05/23/2014 05:54 PM, Eric Blake wrote:
> On 05/23/2014 04:19 AM, Laine Stump wrote:
>> On 05/23/2014 12:17 PM, Laine Stump wrote:
>>> *However*, this discussion forced me to investigate some of the basic
>>> assumptions that I'd been making when coming in to fix
On 05/23/2014 06:50 AM, Marcelo Tosatti wrote:
> On Thu, May 22, 2014 at 01:33:14PM -0600, Eric Blake wrote:
>> [Adding qemu]
>>
>> On 05/22/2014 05:07 AM, Laine Stump wrote:
>>> commit e31b5cf393857 attempted to fix libvirt's
>>> VIR_DOMAIN_EVENT_ID
On 05/23/2014 12:17 PM, Laine Stump wrote:
> *However*, this discussion forced me to investigate some of the basic
> assumptions that I'd been making when coming in to fix this bug. In
> particular, my assumption was that the value of "adjustment" that was
> set in th
On 09/30/2013 05:55 AM, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>> I never heard of a pci/pci express
>> one but it's not impossible I think.
> PCI on one side of the card, PCIe on the other, and a switchable
> backplate? Weird :)
>
> Again, I can't see why we'd want to model this
On 09/25/2013 06:00 AM, Michael S. Tsirkin wrote:
> On Wed, Sep 25, 2013 at 05:39:37AM -0400, Laine Stump wrote:
>> However it is done, each controller will need to have two sets of flags
>> - one for what it can plug into, and one for what can be plugged into it.
> Not just int
On 09/25/2013 04:48 AM, Marcel Apfelbaum wrote:
> On Wed, 2013-09-25 at 10:01 +0300, Michael S. Tsirkin wrote:
>> On Tue, Sep 24, 2013 at 06:01:02AM -0400, Laine Stump wrote:
>>> When I added support for the Q35-based machinetypes to libvirt, I
>>> specifically prohibite
When I added support for the Q35-based machinetypes to libvirt, I
specifically prohibited attaching any PCI devices (with the exception of
graphics controllers) to the PCIe root complex, and had planned to
prevent attaching them to PCIe root ports (ioh3420 device) and PCIe
downstream switch ports (
On 08/02/2013 02:49 AM, Gerd Hoffmann wrote:
> Hi,
>
>> qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server
>> -vnc :15 -vga std -usb
>>
>> Then ran "query-pci" in the qmp monitor and found that the vga device is
>> put at slot 1 instead of slot 2.
>>
>> My questions:
>>
>> 1) I
On 08/02/2013 03:23 AM, Markus Armbruster wrote:
> Gerd Hoffmann writes:
>
>> Hi,
>>
>>> qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server
>>> -vnc :15 -vga std -usb
>>>
>>> Then ran "query-pci" in the qmp monitor and found that the vga device is
>>> put at slot 1 instead of
libvirt makes an assumption that if you specify "-vga qxl" instead of
"-device qxl-vga,...", the vga device will be connected to slot 2. I
learned this in a recent discussion about a bug caused by switching over
to using the former syntax (in order to support multiheaded QXL):
https://bugzilla.r
I was just talking to Michael Tsirkin on IRC about determining which
devices accepted a "bus" option, and asked why this option doesn't show
up in the output of "qemu -device $devname,?" (as happens for addr,
etc). He said this is an old bug, and asked that I send mail to the list
as a reminder tha
On 02/06/2013 02:13 PM, Laine Stump wrote:
> Now that qemu is getting the q35 machine type, libvirt needs to support it.
In an attempt to make sure that libvirt actually does something useful
with qemu's new machine type, I'm revisiting this topic and trying to
get a more thorough
Now that qemu is getting the q35 machine type, libvirt needs to support it.
As far as I understand, from libvirt's point of view, q35 is just another
x86_64 system, but with a different set of implicit devices, and possibly some
extra rules limiting which devices can be plugged into which bus/sl
On 01/09/2013 10:22 AM, Daniel P. Berrange wrote:
> On Wed, Jan 09, 2013 at 08:14:07AM -0700, Eric Blake wrote:
>> On 01/09/2013 01:39 AM, Amos Kong wrote:
>>> Current seabios will try to boot from selected devices first,
>>> if they are all failed, seabios will also try to boot from
>>> un-selecte
On 10/15/2012 05:25 AM, Daniel P. Berrange wrote:
> On Mon, Oct 15, 2012 at 10:30:07AM +0200, Stefan Hajnoczi wrote:
>> On Sat, Oct 13, 2012 at 04:47:14PM -0400, Laine Stump wrote:
>>> Here is the sequence sent to disconnect only the host side, then
>>> reconne
On 10/13/2012 04:47 PM, Laine Stump wrote:
> I am attempting to enhance libvirt's virDomainUpdateDeviceFlags() API to
> support changing "just about anything" about the host side of a PCI
> network device without actually detaching the PCI device from the guest.
> He
I am attempting to enhance libvirt's virDomainUpdateDeviceFlags() API to
support changing "just about anything" about the host side of a PCI
network device without actually detaching the PCI device from the guest.
Here is a patch I sent to the libvirt mailing list that I had thought
would accomplis
On 03/09/2012 09:16 AM, Jiri Denemark wrote:
> Hi.
>
> On Fri, Mar 09, 2012 at 11:32:47 +, Stefan Hajnoczi wrote:
> ...
>> static __inline__ int platform_test_xfs_fd(int fd)
>> {
>> struct statfs buf;
>> if (fstatfs(fd, &buf) < 0)
>> return 0;
>> return (
On 03/02/2012 05:35 AM, Kevin Wolf wrote:
> Am 02.03.2012 10:58, schrieb Amos Kong:
>> On 02/03/12 11:38, Amos Kong wrote:
> --- a/net.c
> +++ b/net.c
> @@ -84,7 +84,7 @@ static int get_str_sep(char *buf, int buf_size,
> const char **pp, int sep)
> const char *p, *p1;
On 07/26/2010 10:23 AM, Luiz Capitulino wrote:
On Sat, 24 Jul 2010 13:01:24 +0530
Amit Shah wrote:
On (Fri) Jul 23 2010 [15:08:18], Luiz Capitulino wrote:
diff --git a/monitor.c b/monitor.c
index 45fd482..d12a7b5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1056,6 +1056,10 @@ static int do_con
Bug description: As reported here:
http://www.redhat.com/archives/libvir-list/2009-December/msg00203.html
"virsh save" is very slow - it writes the image at around 1MB/sec on
my test system. (I think I saw a bug report for this issue on Fedora's
bugzilla, but I can't find it now...)
Here's
On 04/09/2010 12:03 PM, Laine Stump wrote:
(Please forgive (and correct!) any inaccuracies in my description of
qemu's workings - I've only recently started looking at it directly,
rather than through the lens of libvirt)
libvirt implements a "domain restore" operation
(Please forgive (and correct!) any inaccuracies in my description of
qemu's workings - I've only recently started looking at it directly,
rather than through the lens of libvirt)
libvirt implements a "domain restore" operation by:
0) start with a previously saved domain image in a file
1) ope
89 matches
Mail list logo
