Re: [libvirt] [GSOC] project libvirt fuzzing

[D L]

On Thu, Mar 16, 2017 at 1:03 PM, Michal Privoznik 
wrote:

> On 03/16/2017 09:08 AM, D L wrote:
>
>> On Tue, Mar 7, 2017 at 4:08 AM, Michal Privoznik 
>> wrote:
>>
>>
> The file has to be stored locally. Libvirt doesn't have an
>>> 'url-grabber'. In fact, our APIs expect XML document passed as string
>>> (not a filename where it is stored). It's just virsh that allows users
>>> to point it to a file which is read and passed to the define API.
>>>
>>> Oh, my bad. The typing was somehow translated into an url in my browser.
>> But it is an interesting idea to have config files requested via http.
>>
>
> I'm not so sure. This looks like something for tools working on the top of
> libvirt, e.g. virt-install. If we were to have everything in libvirt, it
> would become unmanageable.
>
>
>>
>>> I took a deeper look at the domain_conf.c and network_conf.c. It is just
>> so
>> amazing to see a single file having 26 K lines of code. I first thought it
>> must
>> be generated automatically, then I found there are ~1640 commit for that
>> single file over 8 years.
>> Yes, ctags is very very helpful!
>>
>
> Yeah, it is our biggest file. The next one is src/qemu/qemu_driver.c. But
> ctags are useful not because of big files, but because our code is
> scattered into a lot of files. But that's not important now.
>
>
>>
>>
>> Now that we have parsed the domain XML into internal representation
>>> (virDomainDef), we can look into qemu command line generation. I think
>>> the whole process is best visible in qemuDomainCreateXML() (e.g. "vim -t
>>> qemuDomainCreateXML" ;-)). This is qemu driver implementation of public
>>> API virDomainCreateXML(). It allows users to create so called transient
>>> domains. Long story short: "here, I have domain XML, start it up for me,
>>> will you?". Therefore at the beginning the domain XML is parsed (using
>>> the function described above), several not-important-right-now functions
>>> are called and then qemuProcessStart() is called which calls
>>> qemuProcessLaunch() which calls qemuBuildCommandLine(). Finally, this is
>>> the function that takes the virDomainDef (among other arguments) and
>>> produces yet another internal representation of qemu command line
>>> (virCommandPtr). This command line is then executed later in the process.
>>>
>>> Here I traced through the invocations starting from qemuDomainCreateXML.
>>>
>> Indeed, eventually, it returned a _virCommand struct with some process
>> information, like file descriptors, pid, uid, gid etc. And for different
>> purposes,
>> it is being passed as an argument  in about 200 places, such as
>> in ./src/qemu/qemu_command.c, there are
>>   qemuBuildMasterKeyCommandLine(), and
>>   qemuBuildNVRAMCommandLine(),
>>
>
> The virCommand type is for generic command execution. Not just qemu. For
> instance, when creating new storage volumes, libvirt spawns qemu-img tool.
> That's why you can find some virCommand occurrences all over the place
> (e.g. in storage_util.c).
> Moreover, some functions take existing virCommand object and just add
> something to it - just like qemuBuildMasterKeyCommandLine() is doing.
> This way, the build process of command line is split into many functions.
> The main reason to do so is better maintainability. Just like you'd use
> functions in regular code to semantically divide code into parts.
> What's important here is qemuBuildCommandLine() which takes domain
> definition (well, pointer to it), and constructs correspoding qemu command
> line (represented as a pointer to virCommand which is returned) by calling
> several functions - each one constructing some part of the command line.
>
> Now the GSoC idea could be to test this qemuBuildCommandLine() function. A
> fuzzer would create the virDomainDef object, we would run
> qemuBuildCommandLine() over it and see if it crashed or not, whether a sane
> output was generated or not.
> Then to take this one level up, virDomainDef is produced by
> virDomainDefParse() which takes a string (read XML document) and parses it.
> At this point, the fuzzer does not need to care about virDomainDef at all,
> it can just create all possible XML documents and call virDomainDefParse()
> over them, and then qemuBuildCommandLine() over the result of parser.
> Therefore I think this is what we should aim at.
>
> in /src/util/vircommand.c: there are
>>   virCommandSetWorkingDirectory(), and
>>   virCommandProcessIO()
>> in /src/rpc/virnetsocket.c, there is
>>   virNetSocketNewConnectCommand().
>> in /src/storage/storage_util.c, there is
>>   storageBackendCreateQemuImgSetOptions(). etc
>>
>> 3. And libvirt also is compiled with libxml2.
>>>
>>> Yes. This has strong historical background (hint: look who started
>>> libvirt and who wrote libxml2 ;-)). Frankly, I don't think we've ever
>>> considered a different xml parsing library.
>>>
>>> Oh yeah, just for curiosity, I git cloned libxml2, and find the name of
>> Daniel
>> Veillard, then found 

Re: [libvirt] [GSOC] project libvirt fuzzing

[D L]

On Thu, Mar 16, 2017 at 1:29 PM, Daniel P. Berrange 
wrote:

> On Tue, Mar 07, 2017 at 12:27:58AM -0500, D L wrote:
> > On Sun, Mar 5, 2017 at 2:47 AM, Michal Privoznik 
> wrote:
> > Regarding fuzzing, I think we can try several fuzzing tools to run in
> > parallel, as different
> >  fuzzers tend to find different kinds of bugs. Thus, AFL (American Fuzz
> > Lop) [1],
> > which is a coverage-guided mutation-based fuzzer with genetic algorithm,
> > can
> > take hand-crafted xml seed to fuzz our libvert target. Alternatively, we
> > could
> > develop generation-based grammar module in AFL (which is definitely
> > non-trivial);
> > so far I have not seen active development in AFL community on xml format
> > grammar generation. Another option could be clang-libfuzzer [2].
> >
> > Several related articles show examples of fuzzing are using AFL to
> generate
> > SQL [3], llvm-afl [4], and hexml fuzzing with AFL [5]. In combination
> with
> > lcov, we
> >  could compare different fuzzers and guide our fuzzing tuning.
>
> FYI, I would very much like to see it use a fuzzer that is open source,
> because
> I'd like the end result of the project to ideally produce some test suite
> or
> test framework that we can put in to our CI system and run daily to
> validate
> future changes.
>
>
> Hi Daniel,

Yes, I am definitely focusing on open source fuzzers.

I have been having a question for quite a while. I thought mostly behind
the scenes
of each established open sources projects should have a security team
working
on security testing on a regular basis. Accordingly they also have the tool
chains
and standardized procedures to find, report and fix security
vulnerabilities. They may
or may not work with or collaborate with the Developer teams.

It is also possible that some of those exploitable bugs were purely
discovered just by
interested individuals as their side project/work. And some of them got CVE
assigned
eventually. I was hoping to find some record
 of how such bugs were discovered; i.e., there'd be some tutorial-like
documentations
describing how to work on a large scale industrial fuzzing project. I
primarily got
most of the impressions from the following links about libxml2 AFL fuzzing
bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=744980
https://bugzilla.gnome.org/show_bug.cgi?id=756263
https://bugzilla.gnome.org/show_bug.cgi?id=759020
https://bugzilla.gnome.org/show_bug.cgi?id=759671
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7115
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7116

Not only at libvirt community, is libxml2's situations also similar to
other major open
source projects?

Dan

Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/
> :|
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] news: Document "Enforce guest CPU specification" series

[Jiri Denemark]

Signed-off-by: Jiri Denemark 
---
 docs/news.xml | 13 +
 1 file changed, 13 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 3501f89ab..f1bfeda55 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -39,6 +39,19 @@
   the QEMU binary supports it.
 
   
+  
+
+  qemu: Add support for checking guest CPU ABI compatibility
+
+
+  When migrating a domain to a different host, restoring a domain from
+  a file or reverting a snapshot libvirt will make sure the guest CPU
+  QEMU presents to the guest OS exactly matches the one provided on
+  the source host (or before the domain's state was saved). This
+  enhanced check may also be requested when starting a new domain to
+  ensure the virtual CPU exactly matches the one specified in the XML.
+
+  
 
 
   
-- 
2.12.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/2] bhyve: helper function to probe hypervisor caps

[Roman Bogorodskiy]

There are a number of functions in bhyve_capabilities.c that probe
hypervisor capabilities by executing the bhyve(1) binary with the
specific device arugment, checking error message (if any) and setting
proper capability bit. As those are extremely similar, move this logic
into a helper function and convert existing functions to use that.
---
 src/bhyve/bhyve_capabilities.c | 122 +
 1 file changed, 49 insertions(+), 73 deletions(-)

diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index 4bf1d84fa..f72fdea41 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve/bhyve_capabilities.c
@@ -193,121 +193,97 @@ virBhyveProbeGrubCaps(virBhyveGrubCapsFlags *caps)
 }
 
 static int
-bhyveProbeCapsRTC_UTC(unsigned int *caps, char *binary)
+bhyveProbeCapsDeviceHelper(unsigned int *caps,
+   char *binary,
+   const char *bus,
+   const char *device,
+   const char *errormsg,
+   unsigned int flag)
 {
-char *help;
+char *error;
 virCommandPtr cmd = NULL;
-int ret = 0, exit;
+int ret = -1, exit;
 
 cmd = virCommandNew(binary);
-virCommandAddArg(cmd, "-h");
-virCommandSetErrorBuffer(cmd, );
-if (virCommandRun(cmd, ) < 0) {
-ret = -1;
-goto out;
-}
+virCommandAddArgList(cmd, bus, device, NULL);
+virCommandSetErrorBuffer(cmd, );
+if (virCommandRun(cmd, ) < 0)
+goto cleanup;
 
-if (strstr(help, "-u:") != NULL)
-*caps |= BHYVE_CAP_RTC_UTC;
+if (strstr(error, errormsg) == NULL)
+*caps |= flag;
 
- out:
-VIR_FREE(help);
+ret = 0;
+ cleanup:
+VIR_FREE(error);
 virCommandFree(cmd);
 return ret;
 }
 
 static int
-bhyveProbeCapsAHCI32Slot(unsigned int *caps, char *binary)
+bhyveProbeCapsRTC_UTC(unsigned int *caps, char *binary)
 {
-char *error;
+char *help;
 virCommandPtr cmd = NULL;
 int ret = 0, exit;
 
 cmd = virCommandNew(binary);
-virCommandAddArgList(cmd, "-s", "0,ahci", NULL);
-virCommandSetErrorBuffer(cmd, );
+virCommandAddArg(cmd, "-h");
+virCommandSetErrorBuffer(cmd, );
 if (virCommandRun(cmd, ) < 0) {
 ret = -1;
 goto out;
 }
 
-if (strstr(error, "pci slot 0:0: unknown device \"ahci\"") == NULL)
-*caps |= BHYVE_CAP_AHCI32SLOT;
+if (strstr(help, "-u:") != NULL)
+*caps |= BHYVE_CAP_RTC_UTC;
 
  out:
-VIR_FREE(error);
+VIR_FREE(help);
 virCommandFree(cmd);
 return ret;
 }
 
 static int
-bhyveProbeCapsNetE1000(unsigned int *caps, char *binary)
+bhyveProbeCapsAHCI32Slot(unsigned int *caps, char *binary)
 {
-char *error;
-virCommandPtr cmd = NULL;
-int ret = -1, exit;
-
-cmd = virCommandNew(binary);
-virCommandAddArgList(cmd, "-s", "0,e1000", NULL);
-virCommandSetErrorBuffer(cmd, );
-if (virCommandRun(cmd, ) < 0)
-goto cleanup;
+return bhyveProbeCapsDeviceHelper(caps, binary,
+  "-s",
+  "0,ahci",
+  "pci slot 0:0: unknown device \"ahci\"",
+  BHYVE_CAP_AHCI32SLOT);
+}
 
-if (strstr(error, "pci slot 0:0: unknown device \"e1000\"") == NULL)
-*caps |= BHYVE_CAP_NET_E1000;
 
-ret = 0;
- cleanup:
-VIR_FREE(error);
-virCommandFree(cmd);
-return ret;
+static int
+bhyveProbeCapsNetE1000(unsigned int *caps, char *binary)
+{
+return bhyveProbeCapsDeviceHelper(caps, binary,
+  "-s",
+  "0,e1000",
+  "pci slot 0:0: unknown device \"e1000\"",
+  BHYVE_CAP_NET_E1000);
 }
 
 static int
 bhyveProbeCapsLPC_Bootrom(unsigned int *caps, char *binary)
 {
-char *error;
-virCommandPtr cmd = NULL;
-int ret = -1, exit;
-
-cmd = virCommandNew(binary);
-virCommandAddArgList(cmd, "-l", "bootrom", NULL);
-virCommandSetErrorBuffer(cmd, );
-if (virCommandRun(cmd, ) < 0)
-goto cleanup;
-
-if (strstr(error, "bhyve: invalid lpc device configuration 'bootrom'") == 
NULL)
-*caps |= BHYVE_CAP_LPC_BOOTROM;
-
-ret = 0;
- cleanup:
-VIR_FREE(error);
-virCommandFree(cmd);
-return ret;
+return bhyveProbeCapsDeviceHelper(caps, binary,
+  "-l",
+  "bootrom",
+  "bhyve: invalid lpc device configuration 
'bootrom'",
+  BHYVE_CAP_LPC_BOOTROM);
 }
 
 
 static int
 bhyveProbeCapsFramebuffer(unsigned int *caps, char *binary)
 {
-char *error;
-virCommandPtr cmd = NULL;
-int ret = -1, exit;
-
-cmd = virCommandNew(binary);
-virCommandAddArgList(cmd, "-s", "0,fbuf", NULL);
-

[libvirt] [PATCH 2/2] bhyve: add xhci tablet support

[Roman Bogorodskiy]

Along with video and VNC support, bhyve has introduced USB tablet
support as an input device. This tablet is exposed to a guest
as a device on an XHCI controller.

At present, tablet is the only supported device on the XHCI controller
in bhyve, so to make things simple, it's allowed to only have a
single XHCI controller with a single tablet device.

In detail, this commit:

 - Introduce a new capability bit for XHCI support in bhyve
 - Add an XHCI controller and tabled support with 1:1 mapping
   between them
 - Add a couple of unit tests
---
 src/bhyve/bhyve_capabilities.c | 15 +++
 src/bhyve/bhyve_capabilities.h |  1 +
 src/bhyve/bhyve_command.c  | 50 ++
 src/bhyve/bhyve_device.c   |  4 +-
 .../bhyvexml2argv-input-xhci-tablet.args   |  9 
 .../bhyvexml2argv-input-xhci-tablet.ldargs |  3 ++
 .../bhyvexml2argv-input-xhci-tablet.xml| 18 
 .../bhyvexml2argv-xhci-multiple-controllers.xml| 19 
 .../bhyvexml2argv-xhci-multiple-devs.xml   | 19 
 .../bhyvexml2argv-xhci-no-devs.xml | 17 
 tests/bhyvexml2argvtest.c  | 10 -
 .../bhyvexml2xmlout-input-xhci-tablet.xml  | 31 ++
 tests/bhyvexml2xmltest.c   |  3 ++
 13 files changed, 197 insertions(+), 2 deletions(-)
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-input-xhci-tablet.args
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-input-xhci-tablet.ldargs
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-input-xhci-tablet.xml
 create mode 100644 
tests/bhyvexml2argvdata/bhyvexml2argv-xhci-multiple-controllers.xml
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-xhci-multiple-devs.xml
 create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-xhci-no-devs.xml
 create mode 100644 
tests/bhyvexml2xmloutdata/bhyvexml2xmlout-input-xhci-tablet.xml

diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index f72fdea41..a34c596f0 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve/bhyve_capabilities.c
@@ -286,6 +286,18 @@ bhyveProbeCapsFramebuffer(unsigned int *caps, char *binary)
   BHYVE_CAP_FBUF);
 }
 
+
+static int
+bhyveProbeCapsXHCIController(unsigned int *caps, char *binary)
+{
+return bhyveProbeCapsDeviceHelper(caps, binary,
+  "-s",
+  "0,xhci",
+  "pci slot 0:0: unknown device \"xhci\"",
+  BHYVE_CAP_FBUF);
+}
+
+
 int
 virBhyveProbeCaps(unsigned int *caps)
 {
@@ -313,6 +325,9 @@ virBhyveProbeCaps(unsigned int *caps)
 if ((ret = bhyveProbeCapsFramebuffer(caps, binary)))
 goto out;
 
+if ((ret = bhyveProbeCapsXHCIController(caps, binary)))
+goto out;
+
  out:
 VIR_FREE(binary);
 return ret;
diff --git a/src/bhyve/bhyve_capabilities.h b/src/bhyve/bhyve_capabilities.h
index 3db4f1b88..3db51af02 100644
--- a/src/bhyve/bhyve_capabilities.h
+++ b/src/bhyve/bhyve_capabilities.h
@@ -45,6 +45,7 @@ typedef enum {
 BHYVE_CAP_NET_E1000 = 1 << 2,
 BHYVE_CAP_LPC_BOOTROM = 1 << 3,
 BHYVE_CAP_FBUF = 1 << 4,
+BHYVE_CAP_XHCI = 1 << 5,
 } virBhyveCapsFlags;
 
 int virBhyveProbeGrubCaps(virBhyveGrubCapsFlags *caps);
diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
index ec7a71572..e0528ed77 100644
--- a/src/bhyve/bhyve_command.c
+++ b/src/bhyve/bhyve_command.c
@@ -249,6 +249,45 @@ bhyveBuildAHCIControllerArgStr(const virDomainDef *def,
 }
 
 static int
+bhyveBuildUSBControllerArgStr(const virDomainDef *def,
+  virDomainControllerDefPtr controller,
+  virCommandPtr cmd)
+{
+size_t i;
+int ndevices = 0;
+
+for (i = 0; i < def->ninputs; i++) {
+virDomainInputDefPtr input = def->inputs[i];
+
+if (input->bus != VIR_DOMAIN_INPUT_BUS_USB) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("only USB input devices are supported"));
+return -1;
+}
+
+if (input->type != VIR_DOMAIN_INPUT_TYPE_TABLET) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("only tablet input devices are supported"));
+return -1;
+}
+ndevices++;
+}
+
+if (ndevices != 1) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("only single input device is supported"));
+return -1;
+}
+
+virCommandAddArg(cmd, "-s");
+virCommandAddArgFormat(cmd, "%d:%d,xhci,tablet",
+   controller->info.addr.pci.slot,
+   controller->info.addr.pci.function);
+
+return 0;
+}
+
+static int
 bhyveBuildVirtIODiskArgStr(const 

Re: [libvirt] [PATCH 00/11] storage: modularize the storage driver backends

[Daniel P. Berrange]

On Wed, Feb 08, 2017 at 05:27:00PM +0100, Peter Krempa wrote:
> Split up the storage driver backends into loadable modules so that
> binary distributions don't have to compromise on shipping the storage
> driver with all backends which may pull in too many dependencies.

BTW, it has been 9 years since we enabled dlopen for the main drivers.

Initially it was tedious to use when running from non-installed git
build dir, but we fixed that in 2014 with virFileFindResource, so that
it "just works".

The only bug we ever hit was when we initially tried to modularize
even the non-daemon drivers, and it broke usage from language bindings.

Every platform we care about, including Windows, has dlopen() or
equivalent functionality.

So perhaps it is time to *drop* support for building without modules.

It will simplify our makefiles quite a bit to be able to assume everything
is always dlopen'd modules, and will slightly simplify the code, and most
importantly ensure a single codepath, so we know the behaviour is always
the same.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-block] [RFC] finegrained disk driver options control

[Alberto Garcia]

On Sat 18 Mar 2017 10:54:16 AM CET, Daniel P. Berrange wrote:
>> If you don't care about that at all, the optimal configuration in
>> terms of performance is to give qemu a cache large enough that the
>> metadata of the whole image fits in it. When setting
>> cache-clean-interval, this could actually be reasonable even for
>> large images because the memory wouldn't be used forever but just as
>> long as the guest is submitting the problematic I/O patterns - but it
>> still means that temporarily qemu could really use all of this
>> memory.
>
> Is there some easy algorithm that libvirt can use to determine the
> size of the L2 tables, and thus report what the maximum useful cache
> size would be ?

Yes, the disk size that can be covered with a certain L2 cache is:

   disk_size = l2_cache_size * cluster_size / 8

(all sizes in bytes)

Note that increasing the L2 cache size also increases the refcount
cache, which you might want to keep small.

It's all explained in detail here:

  https://github.com/qemu/qemu/blob/master/docs/qcow2-cache.txt
  
https://blogs.igalia.com/berto/2015/12/17/improving-disk-io-performance-in-qemu-2-5-with-the-qcow2-l2-cache/

Berto

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: Don't try to update undefined guest CPU

[Laine Stump]

On 03/20/2017 04:12 AM, Jiri Denemark wrote:
> Calling virCPUUpdateLive on a domain with no guest CPU configuration
> does not make sense. Especially when doing so would crash libvirtd.
> 
> Signed-off-by: Jiri Denemark 
> ---
>  src/qemu/qemu_process.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)

ACK. This fixed the crash for me.
> 
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 780f9587a..ec0e36d2e 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -3815,11 +3815,6 @@ qemuProcessVerifyCPUFeatures(virDomainDefPtr def,
>  {
>  int rc;
>  
> -if (!def->cpu ||
> -(def->cpu->mode == VIR_CPU_MODE_CUSTOM &&
> - !def->cpu->model))
> -return 0;
> -
>  rc = virCPUCheckFeature(def->os.arch, def->cpu, "invtsc");
>  
>  if (rc < 0) {
> @@ -3870,6 +3865,13 @@ qemuProcessUpdateLiveGuestCPU(virQEMUDriverPtr driver,
>  qemuProcessVerifyHypervFeatures(def, cpu) < 0)
>  goto cleanup;
>  
> +if (!def->cpu ||
> +(def->cpu->mode == VIR_CPU_MODE_CUSTOM &&
> + !def->cpu->model)) {
> +ret = 0;
> +goto cleanup;
> +}
> +
>  if (qemuProcessVerifyCPUFeatures(def, cpu) < 0)
>  goto cleanup;
>  
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH v2 REBASE 00/18] Introduce vGPU mdev framework to libvirt

[Erik Skultety]

On Mon, Mar 20, 2017 at 11:03:40AM +0100, Erik Skultety wrote:
> On Mon, Mar 20, 2017 at 03:27:19PM +0800, yonglihe wrote:
> > 
> > tested v3, on the mdev-next branch:
> > 
> > none-root:
> > ==
> > 1. hacker the privilege operations
> > sudo sh -c "ulimit -l 3074424832 && exec su $LOGNAME"
> > sudo chown ubuntu:ubuntu /dev/vfio/0
> > 
> >  RFC: i don't know the correct way to do such thing while build it from
> > sources. updated me, thanks.
> 
> I'm not sure what you're referring to, so could you be more specific, so we 
> can
> work from there and find the right solution?
> 
> [...]
> 
> > rooted mode
> > 
> > 
> > 
> > start libvirt-d trace:
> > --
> > 
> > this trace shows occasionally while starting the libvirt-d, not every time.
> > 
> > 2017-03-19 19:22:45.559+: 13104: info : libvirt version: 3.2.0
> > 2017-03-19 19:22:45.559+: 13104: info : hostname: z-nuc-11.maas
> > 2017-03-19 19:22:45.559+: 13104: error : qemuMonitorOpenUnix:367 :
> > failed to connect to monitor socket: No such process
> > 2017-03-19 19:22:45.562+: 13000: info : libvirt version: 3.2.0
> > 2017-03-19 19:22:45.562+: 13000: info : hostname: z-nuc-11.maas
> > 2017-03-19 19:22:45.562+: 13000: error : virNetSocketReadWire:1800 : End
> > of file while reading data: Input/output error
> 
> Hmm, the virNetSocketReadWire might go away with the recent libvirt patches (I
> rebased my branch onto current master) if you're using either virtlogd (which
> is the default in qemu.conf on RHEL if I'm not mistaken) or virtlockd, so try

^^The fix I mentioned would only make difference if all the daemons would log
into the same file or to journal, but the log format above is different from
what you'd see in the journal and I assume there is a dedicated log file for
each daemon, so please ignore my post above. I'll still need complete logs and
the configs though.

Erik

> with the rebased branch. But I doubt the qemuMonitorOpenUnix bit would
> disappear with the mentioned libvirt fix. But I will need a fresh and complete
> daemon log to investigate further, as well as libvirtd.conf and qemu.conf 
> (just
> in case), so that I can compare to my environment, since I'm not able to
> reproduce this.
> 
> [...]
> 
> > NOTES:
> >there is no traces under none root mode, though i don't think the trace
> > is related to user privilege. fix me.
> 
> It's indeed odd that you don't see the same behaviour when running qemu as
> root. As I said, I will need the daemon log and preferably the configs as well
> to investigate further.
> 
> Thanks,
> Erik
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 5/5] network: check accept_ra before enabling ipv6 forwarding

[Cedric Bosdonnat]

On Thu, 2017-03-16 at 21:12 -0400, Laine Stump wrote:
> On 03/15/2017 10:45 AM, Cédric Bosdonnat wrote:
> > When enabling IPv6 on all interfaces, we may get the host Router
> > Advertisement routes discarded. To avoid this, the user needs to set
> > accept_ra to 2 for the interfaces with such routes.
> > 
> > See https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
> > on this topic.
> > 
> > To avoid user mistakenly losing routes on their hosts, check
> > accept_ra values before enabling IPv6 forwarding. If a RA route is
> > detected, but neither the corresponding device nor global accept_ra
> > is set to 2, the network will fail to start.
> 
> Since I already asked the question and didn't hear a positive response,
> I'm guessing "no news is bad news", i.e. there isn't a reliable way to
> fix this problem automatically. Assuming that, reporting the problem and
> failing seems like the next best (least worse) thing...

The only automatic thing that we could do is remember the RA routes that
are set before enabling ipv6 forwarding and reset them after having lost them.

IMHO automatically changing the accept_ra parameter for the user could lead to
unknown (possibly buggy) cases. Before this patch, the network is started, but
the host may loose routes (the default one in my case). After, it keeps the
host routes, fails to start the network and tells the user to fix his host
network config.


--
Cedric

> 
> > ---
> >  src/libvirt_private.syms|   1 +
> >  src/network/bridge_driver.c |  16 +++--
> >  src/util/virnetdevip.c  | 158 
> > 
> >  src/util/virnetdevip.h  |   1 +
> >  4 files changed, 171 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> > index 0fe88c3fa..ec6553520 100644
> > --- a/src/libvirt_private.syms
> > +++ b/src/libvirt_private.syms
> > @@ -2056,6 +2056,7 @@ virNetDevBridgeSetVlanFiltering;
> >  virNetDevIPAddrAdd;
> >  virNetDevIPAddrDel;
> >  virNetDevIPAddrGet;
> > +virNetDevIPCheckIPv6Forwarding;
> >  virNetDevIPInfoAddToDev;
> >  virNetDevIPInfoClear;
> >  virNetDevIPRouteAdd;
> > diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
> > index 3f6561055..d02cd19f9 100644
> > --- a/src/network/bridge_driver.c
> > +++ b/src/network/bridge_driver.c
> > @@ -61,6 +61,7 @@
> >  #include "virlog.h"
> >  #include "virdnsmasq.h"
> >  #include "configmake.h"
> > +#include "virnetlink.h"
> >  #include "virnetdev.h"
> >  #include "virnetdevip.h"
> >  #include "virnetdevbridge.h"
> > @@ -2377,11 +2378,16 @@ networkStartNetworkVirtual(virNetworkDriverStatePtr 
> > driver,
> >  }
> >  
> >  /* If forward.type != NONE, turn on global IP forwarding */
> > -if (network->def->forward.type != VIR_NETWORK_FORWARD_NONE &&
> > -networkEnableIPForwarding(v4present, v6present) < 0) {
> > -virReportSystemError(errno, "%s",
> > - _("failed to enable IP forwarding"));
> > -goto err3;
> > +if (network->def->forward.type != VIR_NETWORK_FORWARD_NONE) {
> > +if (!virNetDevIPCheckIPv6Forwarding())
> > +goto err3; /* Precise error message already provided */
> > +
> > +
> > +if (networkEnableIPForwarding(v4present, v6present) < 0) {
> > +virReportSystemError(errno, "%s",
> > + _("failed to enable IP forwarding"));
> > +goto err3;
> > +}
> >  }
> >  
> >  
> > diff --git a/src/util/virnetdevip.c b/src/util/virnetdevip.c
> > index 42fbba1eb..a4d382427 100644
> > --- a/src/util/virnetdevip.c
> > +++ b/src/util/virnetdevip.c
> > @@ -508,6 +508,158 @@ virNetDevIPWaitDadFinish(virSocketAddrPtr *addrs, 
> > size_t count)
> >  return ret;
> >  }
> >  
> > +static int
> > +virNetDevIPGetAcceptRA(const char *ifname)
> > +{
> > +char *path = NULL;
> > +char *buf = NULL;
> > +char *suffix;
> > +int accept_ra = -1;
> > +
> > +if (virAsprintf(, "/proc/sys/net/ipv6/conf/%s/accept_ra",
> > +ifname ? ifname : "all") < 0)
> > +goto cleanup;
> > +
> > +if ((virFileReadAll(path, 512, ) < 0) ||
> > +(virStrToLong_i(buf, , 10, _ra) < 0))
> > +goto cleanup;
> > +
> > + cleanup:
> > +VIR_FREE(path);
> > +VIR_FREE(buf);
> > +
> > +return accept_ra;
> > +}
> > +
> > +struct virNetDevIPCheckIPv6ForwardingData {
> > +bool hasRARoutes;
> > +
> > +/* Devices with conflicting accept_ra */
> > +char **devices;
> > +size_t ndevices;
> > +};
> > +
> > +static int
> > +virNetDevIPCheckIPv6ForwardingCallback(const struct nlmsghdr *resp,
> > +   void *opaque)
> > +{
> > +struct rtmsg *rtmsg = NLMSG_DATA(resp);
> > +int accept_ra = -1;
> > +struct rtattr *rta;
> > +char *ifname = NULL;
> > +struct virNetDevIPCheckIPv6ForwardingData *data = opaque;
> > +int ret = 0;
> > +int len = 

Re: [libvirt] [RFC PATCH v2 REBASE 00/18] Introduce vGPU mdev framework to libvirt

[Erik Skultety]

On Mon, Mar 20, 2017 at 03:27:19PM +0800, yonglihe wrote:
> 
> tested v3, on the mdev-next branch:
> 
> none-root:
> ==
> 1. hacker the privilege operations
> sudo sh -c "ulimit -l 3074424832 && exec su $LOGNAME"
> sudo chown ubuntu:ubuntu /dev/vfio/0
> 
>  RFC: i don't know the correct way to do such thing while build it from
> sources. updated me, thanks.

I'm not sure what you're referring to, so could you be more specific, so we can
work from there and find the right solution?

[...]

> rooted mode
> 
> 
> 
> start libvirt-d trace:
> --
> 
> this trace shows occasionally while starting the libvirt-d, not every time.
> 
> 2017-03-19 19:22:45.559+: 13104: info : libvirt version: 3.2.0
> 2017-03-19 19:22:45.559+: 13104: info : hostname: z-nuc-11.maas
> 2017-03-19 19:22:45.559+: 13104: error : qemuMonitorOpenUnix:367 :
> failed to connect to monitor socket: No such process
> 2017-03-19 19:22:45.562+: 13000: info : libvirt version: 3.2.0
> 2017-03-19 19:22:45.562+: 13000: info : hostname: z-nuc-11.maas
> 2017-03-19 19:22:45.562+: 13000: error : virNetSocketReadWire:1800 : End
> of file while reading data: Input/output error

Hmm, the virNetSocketReadWire might go away with the recent libvirt patches (I
rebased my branch onto current master) if you're using either virtlogd (which
is the default in qemu.conf on RHEL if I'm not mistaken) or virtlockd, so try
with the rebased branch. But I doubt the qemuMonitorOpenUnix bit would
disappear with the mentioned libvirt fix. But I will need a fresh and complete
daemon log to investigate further, as well as libvirtd.conf and qemu.conf (just
in case), so that I can compare to my environment, since I'm not able to
reproduce this.

[...]

> NOTES:
>there is no traces under none root mode, though i don't think the trace
> is related to user privilege. fix me.

It's indeed odd that you don't see the same behaviour when running qemu as
root. As I said, I will need the daemon log and preferably the configs as well
to investigate further.

Thanks,
Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC] finegrained disk driver options control

[Daniel P. Berrange]

On Mon, Mar 20, 2017 at 11:11:42AM +0300, Denis V. Lunev wrote:
> On 03/18/2017 12:59 PM, Daniel P. Berrange wrote:
> > On Thu, Mar 16, 2017 at 08:31:08PM +0300, Denis V. Lunev wrote:
> >> On 03/16/2017 05:45 PM, Daniel P. Berrange wrote:
> >>> On Thu, Mar 16, 2017 at 05:08:57PM +0300, Denis V. Lunev wrote:
>  Hello, All!
> 
>  There is a problem in the current libvirt implementation. domain.xml
>  allows to specify only basic set of options, especially in the case
>  of QEMU, when there are really a lot of tweaks in format drivers.
>  Most likely these options will never be supported in a good way
>  in libvirt as recognizable entities.
> 
>  Right now in order to debug libvirt QEMU VM in production I am using
>  very strange approach:
>  - disk section of domain XML is removed
>  - exact command line options to start the disk are specified at the end
>    of domain.xml whithin  as described by Stefan
>   
>  http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html
> 
>  The problem is that when debug is finished and viable combinations of
>  options is found I can not drop VM in such state in the production. This
>  is the pain and problem. For example, I have spend 3 days with the
>  VM of one customer which blames us for slow IO in the guest. I have
>  found very good combination of non-standard options which increases
>  disk performance 5 times (not 5%). Currently I can not put this 
>  combination
>  in the production as libvirt does not see the disk.
> 
>  I propose to do very simple thing, may be I am not the first one here,
>  but it would be nice to allow to pass arbitrary option to the QEMU
>  command line. This could be done in a very generic way if we will
>  allow to specify additional options inside  section like this:
> 
>  
>  iothread='1'>
>    
>    
>    
>    
>    
>  
> 
>  and so on. The meaning (at least for QEMU) is quite simple -
>  these options will just be added to the end of the -drive command
>  line. The meaning for other drivers should be the same and I
>  think that there are ways to pass generic options in them.
> >>> It is a general policy that we do *not* do generic option passthrough
> >>> in this kind of manner. We always want to represent concepts explicitly
> >>> with named attributes, so that if 2 hypervisors support the same concept
> >>> we can map it the same way in the XML
> >>>
> >> In general this policy means that the management software which
> >> wants to implement some differentiation in between VMs f.e.
> >> in disk tuning is forced to use qemu:commandline backdoor.
> >> That is a pity. Exactly like in the case with additional logs.
> >>
> >> Thank you for the discussion. At least I have found new way
> >> to perform some fine tuning.
> > Ignoring the question of generic option passthrough, I think we can model
> > the cache settings in libvirt XML explicitly. Other types of disk besides
> > qcow2 can have a cache concept, so I think we could create something like
> > this:
> >
> >
> >
> >   
> >   
> >   
> >
> >
> >
> > The "bank" element would be permitted to be repeated multiple times if a
> > particular diskk driver had multiple caches it needed.
> >
> > In the storage vol XML, we would want a way top report what the size of
> > the L2 and refcount tables are when reporting qcow2 volumes, so apps
> > know the maximum sensible size to use for cache.
> >
> For cache and anything which could be bound as cache this is not that
> difficult. But are you going to limit possible bank names? Without
> the limit this would work exactly the same as I have proposed.
> With the limit, i.e. understanding of  allowed banks on a format
> basis, we will stuck in a really LOT of details.

It would certainly validate the cache names matched those supported by
the image format, as well as validating the values are in integer format.
As mentioned, the storage volume XML would also report the cache supported
by each storage volume in a storage pool, providing applications the way
to learn what caches are available for the format. This is very different
to just providing blind passthrough of any qcow option.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: Don't try to update undefined guest CPU

[Jiri Denemark]

Calling virCPUUpdateLive on a domain with no guest CPU configuration
does not make sense. Especially when doing so would crash libvirtd.

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_process.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 780f9587a..ec0e36d2e 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3815,11 +3815,6 @@ qemuProcessVerifyCPUFeatures(virDomainDefPtr def,
 {
 int rc;
 
-if (!def->cpu ||
-(def->cpu->mode == VIR_CPU_MODE_CUSTOM &&
- !def->cpu->model))
-return 0;
-
 rc = virCPUCheckFeature(def->os.arch, def->cpu, "invtsc");
 
 if (rc < 0) {
@@ -3870,6 +3865,13 @@ qemuProcessUpdateLiveGuestCPU(virQEMUDriverPtr driver,
 qemuProcessVerifyHypervFeatures(def, cpu) < 0)
 goto cleanup;
 
+if (!def->cpu ||
+(def->cpu->mode == VIR_CPU_MODE_CUSTOM &&
+ !def->cpu->model)) {
+ret = 0;
+goto cleanup;
+}
+
 if (qemuProcessVerifyCPUFeatures(def, cpu) < 0)
 goto cleanup;
 
-- 
2.12.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC] finegrained disk driver options control

[Denis V. Lunev]

On 03/18/2017 12:59 PM, Daniel P. Berrange wrote:
> On Thu, Mar 16, 2017 at 08:31:08PM +0300, Denis V. Lunev wrote:
>> On 03/16/2017 05:45 PM, Daniel P. Berrange wrote:
>>> On Thu, Mar 16, 2017 at 05:08:57PM +0300, Denis V. Lunev wrote:
 Hello, All!

 There is a problem in the current libvirt implementation. domain.xml
 allows to specify only basic set of options, especially in the case
 of QEMU, when there are really a lot of tweaks in format drivers.
 Most likely these options will never be supported in a good way
 in libvirt as recognizable entities.

 Right now in order to debug libvirt QEMU VM in production I am using
 very strange approach:
 - disk section of domain XML is removed
 - exact command line options to start the disk are specified at the end
   of domain.xml whithin  as described by Stefan
  
 http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html

 The problem is that when debug is finished and viable combinations of
 options is found I can not drop VM in such state in the production. This
 is the pain and problem. For example, I have spend 3 days with the
 VM of one customer which blames us for slow IO in the guest. I have
 found very good combination of non-standard options which increases
 disk performance 5 times (not 5%). Currently I can not put this combination
 in the production as libvirt does not see the disk.

 I propose to do very simple thing, may be I am not the first one here,
 but it would be nice to allow to pass arbitrary option to the QEMU
 command line. This could be done in a very generic way if we will
 allow to specify additional options inside  section like this:

 
   >>> iothread='1'>
   
   
   
   
   
 

 and so on. The meaning (at least for QEMU) is quite simple -
 these options will just be added to the end of the -drive command
 line. The meaning for other drivers should be the same and I
 think that there are ways to pass generic options in them.
>>> It is a general policy that we do *not* do generic option passthrough
>>> in this kind of manner. We always want to represent concepts explicitly
>>> with named attributes, so that if 2 hypervisors support the same concept
>>> we can map it the same way in the XML
>>>
>>> Regards,
>>> Daniel
>> In general this policy means that the management software which
>> wants to implement some differentiation in between VMs f.e.
>> in disk tuning is forced to use qemu:commandline backdoor.
>> That is a pity. Exactly like in the case with additional logs.
>>
>> Thank you for the discussion. At least I have found new way
>> to perform some fine tuning.
> Ignoring the question of generic option passthrough, I think we can model
> the cache settings in libvirt XML explicitly. Other types of disk besides
> qcow2 can have a cache concept, so I think we could create something like
> this:
>
>
>
>   
>   
>   
>
>
>
> The "bank" element would be permitted to be repeated multiple times if a
> particular diskk driver had multiple caches it needed.
>
> In the storage vol XML, we would want a way top report what the size of
> the L2 and refcount tables are when reporting qcow2 volumes, so apps
> know the maximum sensible size to use for cache.
>
> Regards,
> Daniel
For cache and anything which could be bound as cache this is not that
difficult. But are you going to limit possible bank names? Without
the limit this would work exactly the same as I have proposed.
With the limit, i.e. understanding of  allowed banks on a format
basis, we will stuck in a really LOT of details.

Den

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/14] Add tests for virCPUUpdateLive API

[Jiri Denemark]

On Sun, Mar 19, 2017 at 22:09:47 -0400, Laine Stump wrote:
> On 03/17/2017 12:36 PM, Jiri Denemark wrote:
> > Jiri Denemark (14):
> >   cpu_conf: Introduce virCPUDefFreeFeatures
> >   cpu: Introduce virCPUExpandFeatures
> >   cpu: Drop unused flags from cpuArchDecode
> >   cpu: Move feature expansion out of cpuBaseline
> >   cpu: Do not pass virConnectBaselineCPUFlags to cpuBaseline
> >   cputest: Move instantiation of JSONDecoder in cpu-convert.py
> >   cputest: Rename cpu-convert.py script as cpu-cpuid.py
> >   cputest: Add cpuidIsSet helper to cpu-cpuid.py
> >   cputest: Add cpuidLeaf helper to cpu-cpuid.py
> >   cputest: Add "diff" command to cpu-cpuid.py
> >   cputest: Generate data for virCPUUpdateLive
> >   cputest: Disable TSX on broken models
> >   cputest: Disable "cmt" feature unknown to QEMU
> >   cputest: Add tests for virCPUUpdateLive API
> 
> Does one of these perhaps fix a segv in virCPUUpdateLive? With current
> tip of master, it's being called with cpu == NULL:

Oops, none of these patches fix the crash. It's a bug in the caller not
in the virCPUUpdateLive itself. A patch is coming soon...

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/2] qemu: Validate the domain after marking the current domain as transient

[Marc Hartmayer]

On Wed, Mar 08, 2017 at 10:41 AM +0100, "Daniel P. Berrange" 
 wrote:
> On Wed, Mar 08, 2017 at 10:32:32AM +0100, Marc Hartmayer wrote:
>> On Mon, Feb 27, 2017 at 11:20 AM +0100, "Daniel P. Berrange" 
>>  wrote:
>> > On Mon, Feb 27, 2017 at 10:59:39AM +0100, Marc Hartmayer wrote:
>> >> On Thu, Feb 23, 2017 at 05:36 PM +0100, "Daniel P. Berrange" 
>> >>  wrote:
>> >> > On Thu, Feb 23, 2017 at 05:22:44PM +0100, Marc Hartmayer wrote:
>> >> >> On Thu, Feb 23, 2017 at 03:33 PM +0100, Michal Privoznik 
>> >> >>  wrote:
>> >> >> > On 02/23/2017 10:44 AM, Marc Hartmayer wrote:
>> >> >> >> Validate the domain that actually will be started. It's semantically
>> >> >> >> more clear and also it can detect failures that may have happened in
>> >> >> >> virDomainObjSetDefTransient().
>> >> >> >>
>> >> >> >> Signed-off-by: Marc Hartmayer 
>> >> >> >> Reviewed-by: Bjoern Walk 
>> >> >> >> Reviewed-by: Boris Fiuczynski 
>> >> >> >> ---
>> >> >> >>  src/qemu/qemu_process.c | 6 +++---
>> >> >> >>  1 file changed, 3 insertions(+), 3 deletions(-)
>> >> >> >>
>> >> >> >> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
>> >> >> >> index a57d136..bd3a8b8 100644
>> >> >> >> --- a/src/qemu/qemu_process.c
>> >> >> >> +++ b/src/qemu/qemu_process.c
>> >> >> >> @@ -4746,9 +4746,6 @@ qemuProcessInit(virQEMUDriverPtr driver,
>> >> >> >>
>> >> >> >> vm->def->os.machine)))
>> >> >> >>  goto cleanup;
>> >> >> >>
>> >> >> >> -if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps, 
>> >> >> >> flags) < 0)
>> >> >> >> -goto cleanup;
>> >> >> >> -
>> >> >> >>  /* Do this upfront, so any part of the startup process can add
>> >> >> >>   * runtime state to vm->def that won't be persisted. This 
>> >> >> >> let's us
>> >> >> >>   * report implicit runtime defaults in the XML, like vnc 
>> >> >> >> listen/socket
>> >> >> >> @@ -4757,6 +4754,9 @@ qemuProcessInit(virQEMUDriverPtr driver,
>> >> >> >>  if (virDomainObjSetDefTransient(caps, driver->xmlopt, vm) < 0)
>> >> >> >>  goto cleanup;
>> >> >> >>
>> >> >> >> +if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps, 
>> >> >> >> flags) < 0)
>> >> >> >> +goto cleanup;
>> >> >> >> +
>> >> >> >
>> >> >> > This needs to be goto stop for the reasons described in the previous 
>> >> >> > e-mail.
>> >> >> >
>> >> >> >>  if (flags & VIR_QEMU_PROCESS_START_PRETEND) {
>> >> >> >>  if (qemuDomainSetPrivatePaths(driver, vm) < 0)
>> >> >> >>  goto cleanup;
>> >> >> >>
>> >> >> >
>> >> >> > Honestly, I like what we have now better. I mean, SetDefTransient() 
>> >> >> > is
>> >> >> > very unlikely to fail. It's just doing a copy of domain definition 
>> >> >> > (in a
>> >> >> > very stupid way, but lets save that for a different discussion).
>> >> >> > Basically, it will fail on OOM only (which you will not get on a 
>> >> >> > Linux
>> >> >> > system, unless you really try).
>> >> >> 
>> >> >> It's semantically more clear (at least for me) and for example it
>> >> >> enables us to change some parts of the transient domain before
>> >> >> validation (affect the transient domain only, not the persistent).
>> >> >
>> >> > What are you planning to change in the config before validation ?
>> >> >
>> >> 
>> >> I'm implementing a feature which allows to select the boot device at
>> >> domain start time (something like 'virsh start --with-bootdevice sda
>> >> domain1'). The main reason why we want this is because the s390
>> >> architecture boots only from the first device specified in the boot
>> >> order.
>> >
>> > There's no need to changes in the QEMU driver todo this. You can just
>> > query the current XML config, change the boot device in it, and then
>> > run virDomainCreateXML to launch the guest with the changed config,
>> > or virDomainDefineXML again to make the changed boot device permanent.
>> >
>> 
>> First of all, I hope I understand you right :) (you can tell me as soon
>> as you have read the following text)
>> 
>> I've followed your advice and tried to add this functionality without
>> any changes in the QEMU/hypervisor. For this I've created a new function
>> in the remote driver which will call the needed functions (get current
>> XML config for the domain, manipulate the XML config, and then use
>> virDomainCreateXML for starting).
>> 
>> To get the current XML config is straightforward as you've mentioned -
>> just use 'virDomanGetXMLDesc(...)'.
>> 
>> But how can I change the boot device?
>> 1) I could use libxml2 for manipulating the XML string which we will get
>> with calling 'virDomainGetXMLDesc(..)' but this is error-prone and just
>> duplicate work as we have to parse the XML string and the information of
>> it. Also, if there are any additions in the future for 

Re: [libvirt] [PATCH v3 0/2] Allow saving VM state to pipe

[Chen Hanxiao]

At 2017-03-14 14:26:24, "Chen Hanxiao"  wrote:
>
>At 2017-03-09 12:22:21, "Chen Hanxiao"  wrote:
>>This series introduce flag VIR_DOMAIN_SAVE_DIRECT
>>to enable command 'save' to write to PIPE.
>>This will write QEMU_SAVE_MAGIC directly.
>>
>>Base upon patches from Roy Keene 
>>with some fixes.
>>
>>Change from original patch:
>>1) Check whether the specified path is a PIPE.
>>2) Rebase on upstream.
>>3) Add doc for virsh command
>>
>>v3:
>>  add doc/news.xml
>>  rebase on upstream
>>
>>v2-resend:
>>  rebase on upstream
>>
>>v2:
>>  rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT
>>  remove S_ISFIFO check
>>
>
>ping
>

ping

Regards,
- Chen

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH v2 REBASE 00/18] Introduce vGPU mdev framework to libvirt

[yonglihe]

On 2017年03月16日 22:41, Erik Skultety wrote:

[2] 2005
ubuntu@z-nuc-11:~/vgpu-meta/libvirt-stage$
***
start libvirt-d
2017-03-09 19:04:57.211+: 2059: info : libvirt version: 3.1.0
2017-03-09 19:04:57.211+: 2059: info : hostname: z-nuc-11.maas
2017-03-09 19:04:57.211+: 2059: error : qemuMonitorOpenUnix:367 :
failed to connect to monitor socket: No such process
2017-03-09 19:04:57.213+: 2059: error :
virMediatedDeviceGetIOMMUGroupDev:153 : internal error: IOMMU group file 
/sys/bus/mdev/devices/894f3983-1a36-42b3-b52c-1024aca216be/iommu_group
is not a symlink

When I saw this error message for the first time in the original thread, I got
confused, since this just checks whether the symlink exists, if it
doesn't, the vfio device probably also doesn't exist (but take this with a
grain of salt, I haven't investigated that deep) and libvirt needs it to pass
it onto qemu command line. I hit this issue once by accident in the past and at
that time I didn't understand what caused it, but after a reboot it was gone.
So seeing it here it caught my eye and I investigated it last week. What I
found out was that it's caused by the vfio-mdev module not being loaded
automatically as a dependency. I solved it by autoloading the module on system
boot. So this is not a libvirt issue, but just for a reference, there is a BZ
on this [1].

it's does not show up every time. might be my bad.



2017-03-09 19:04:57.213+: 2003: info : libvirt version: 3.1.0
2017-03-09 19:04:57.213+: 2003: info : hostname: z-nuc-11.maas
2017-03-09 19:04:57.213+: 2003: error : virNetSocketReadWire:1800 :
End of file while reading data: Input/output error

I suppose this corresponds to the problem above, do you hit this error if you
work around the vfio-mdev module problem described above?


the screen call trace while start the VM (same for Ubuntu, Win10 etc) 
==

ubuntu@z-nuc-11:~/vgpu-meta/libvirt-stage$ myvirsh start vgpu-ubuntu
2017-03-09 19:06:50.483+: 2232: info : libvirt version: 3.1.0
2017-03-09 19:06:50.483+: 2232: info : hostname: z-nuc-11.maas
2017-03-09 19:06:50.483+: 2232: warning : qemuDomainObjTaint:4056 :
Domain id=1 name='vgpu-ubuntu' uuid=972b5e38-0437-11e7-8f97-d36dba74552d
is tainted: high-privileges
2017-03-09 19:06:50.819+: 2204: info : libvirt version: 3.1.0
2017-03-09 19:06:50.819+: 2232: warning : virDomainAuditHostdev:456
: Unexpected hostdev type while encoding audit message: 4

This one's interesting, again, are you able to hit the error when you work
around the missing vfio-mdev module? I'll have a look at this if you actually
can hit the error, even if the XML is correct.
the module should be there,  the domain is running and virtual gpu is 
working.


ubuntu@z-nuc-11:~/vgpu-meta/libvirt-stage$ sudo lsmod| grep mdev
vfio_mdev  16384  1
mdev   20480  2 kvmgt,vfio_mdev
vfio   28672  6 vfio_iommu_type1,kvmgt,vfio_mdev

on the v3, the trace still there. refer to my "test by" email on mdev-next.

Regards
Yongli He


I posted v3 of the series and also created a new branch 'mdev-next' on my
github [2]. I dropped the attribute 'type' from the source address element, so
follow the example in the updated docs.

Thanks for giving it a try.
Erik

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1420572
[2] https://github.com/eskultety/libvirt/commits/mdev-next



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [RFC PATCH v2 REBASE 00/18] Introduce vGPU mdev framework to libvirt

[yonglihe]

tested v3, on the mdev-next branch:

none-root:
==
1. hacker the privilege operations
sudo sh -c "ulimit -l 3074424832 && exec su $LOGNAME"
sudo chown ubuntu:ubuntu /dev/vfio/0

 RFC: i don't know the correct way to do such thing while build it from 
sources. updated me, thanks.


2. myvirsh -c qemu:///session
#define ./libvirt/vgpu-win10.xml
Domain vgpu-win10 defined from ./libvirt/vgpu-win10.xml

 #start vgpu-win10
Domain vgpu-win10 started

3.ps aux | grep qemu

ubuntu3262  141 12.3 2929432 2017172 ? SLl  23:58   0:51 
/usr/bin/qemu-system-x86_64 -name guest=vgpu-win10,debug-threads=on -S 
-object 
secret,id=masterKey0,format=raw,file=/home/ubuntu/.config/libvirt/qemu/lib/domain-1-vgpu-win10/master-key.aes 
-machine pc-i440fx-2.3,accel=kvm,usb=off,dump-guest-core=off -m 1908 
-realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
916c5c36-0437-11e7-a23d-830ed1295d00 -no-user-config -nodefaults 
-chardev 
socket,id=charmonitor,path=/home/ubuntu/.config/libvirt/qemu/lib/domain-1-vgpu-win10/monitor.sock,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc 
-no-shutdown -boot strict=on -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/home/ubuntu/vgpu-meta/libvirt-stage/win10-64.qcow2,format=qcow2,if=none,id=drive-ide0-0-0,cache=none,aio=native 
-device 
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 
-chardev pty,id=charserial0 -device 
isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device 
cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
vfio-pci,sysfsdev=/sys/bus/mdev/devices/894f3983-1a36-42b3-b52c-1024aca216be,bus=pci.0,addr=0x4 
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -msg timestamp=on
ubuntu3276  0.0  0.0  10468  2216 pts/0S+   23:59   0:00 grep 
--color=auto qemu




rooted mode



start libvirt-d trace:
--

this trace shows occasionally while starting the libvirt-d, not every time.

2017-03-19 19:22:45.559+: 13104: info : libvirt version: 3.2.0
2017-03-19 19:22:45.559+: 13104: info : hostname: z-nuc-11.maas
2017-03-19 19:22:45.559+: 13104: error : qemuMonitorOpenUnix:367 : 
failed to connect to monitor socket: No such process

2017-03-19 19:22:45.562+: 13000: info : libvirt version: 3.2.0
2017-03-19 19:22:45.562+: 13000: info : hostname: z-nuc-11.maas
2017-03-19 19:22:45.562+: 13000: error : virNetSocketReadWire:1800 : 
End of file while reading data: Input/output error



start domian trace:
--
some time there is trace while starting the domain.

2017-03-19 19:22:50.912+: 13034: warning : qemuDomainObjTaint:4113 : 
Domain id=3 name='vgpu-win10' uuid=916c5c36-0437-11e7-a23d-830ed1295d00 
is tainted: high-privileges
2017-03-19 19:22:51.859+: 13000: error : virNetSocketReadWire:1800 : 
End of file while reading data: Input/output error
2017-03-19 19:22:51.859+: 13034: warning : virDomainAuditHostdev:456 
: Unexpected hostdev type while encoding audit message: 4

Domain vgpu-win10 started


NOTES:
   there is no traces under none root mode, though i don't think the 
trace is related to user privilege. fix me.



Regards
Yongli He


On 2017年03月16日 22:41, Erik Skultety wrote:

[2] 2005
ubuntu@z-nuc-11:~/vgpu-meta/libvirt-stage$
***
start libvirt-d
2017-03-09 19:04:57.211+: 2059: info : libvirt version: 3.1.0
2017-03-09 19:04:57.211+: 2059: info : hostname: z-nuc-11.maas
2017-03-09 19:04:57.211+: 2059: error : qemuMonitorOpenUnix:367 :
failed to connect to monitor socket: No such process
2017-03-09 19:04:57.213+: 2059: error :
virMediatedDeviceGetIOMMUGroupDev:153 : internal error: IOMMU group file 
/sys/bus/mdev/devices/894f3983-1a36-42b3-b52c-1024aca216be/iommu_group
is not a symlink

When I saw this error message for the first time in the original thread, I got
confused, since this just checks whether the symlink exists, if it
doesn't, the vfio device probably also doesn't exist (but take this with a
grain of salt, I haven't investigated that deep) and libvirt needs it to pass
it onto qemu command line. I hit this issue once by accident in the past and at
that time I didn't understand what caused it, but after a reboot it was gone.
So seeing it here it caught my eye and I investigated it last week. What I
found out was that it's caused by the vfio-mdev module not being loaded
automatically as a dependency. I solved it by autoloading the module on system
boot. So this is not a libvirt issue, but just for a reference, there is a BZ
on this [1].


2017-03-09 19:04:57.213+: 2003: info : libvirt version: 3.1.0
2017-03-09 19:04:57.213+: 2003: info : hostname: z-nuc-11.maas
2017-03-09 19:04:57.213+: 2003: error : virNetSocketReadWire:1800 :
End of file while reading data: Input/output error

I suppose this corresponds to the problem above, do you hit this error if you
work around the vfio-mdev module problem described