Re: [libvirt] [PATCH] docs: Format text in into a block

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote:
> With the rework of our webpage I've also noticed that we can make
> our  block look more uniform: stretch the lines so that each
> has the equal width. Just like if you hit "align to block" in
> your favourite text editor.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  docs/generic.css | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/docs/generic.css b/docs/generic.css
> index a6b2354df..4c8887d6d 100644
> --- a/docs/generic.css
> +++ b/docs/generic.css
> @@ -14,6 +14,7 @@ p, ul, ol, dl {
>  p {
>margin-top: 1em;
>margin-bottom: 1em;
> +  text-align: justify;
>  }

Justified text ends up looking very ugly unless the layout engine is also
capable of doing automatic hyphenation of words - without hyphenation, if
you have a long word that gets pushed to the next line, you get huge whitespace
gaps between words.

More specific to the libvirt site - it looks very odd to have 
justified, but nothing else - eg looking at formatdomain.html, we end
up with a mix of justified and non-justified text, depending on whether
we've used a ,  or  for the particular bit of docs.

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] [PATCH] docs: Format text in into a block

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 01:37:17PM +0100, Michal Privoznik wrote:
> On 02.12.2016 12:27, Daniel P. Berrange wrote:
> > On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote:
> >> With the rework of our webpage I've also noticed that we can make
> >> our  block look more uniform: stretch the lines so that each
> >> has the equal width. Just like if you hit "align to block" in
> >> your favourite text editor.
> >>
> >> Signed-off-by: Michal Privoznik 
> >> ---
> >>  docs/generic.css | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/docs/generic.css b/docs/generic.css
> >> index a6b2354df..4c8887d6d 100644
> >> --- a/docs/generic.css
> >> +++ b/docs/generic.css
> >> @@ -14,6 +14,7 @@ p, ul, ol, dl {
> >>  p {
> >>margin-top: 1em;
> >>margin-bottom: 1em;
> >> +  text-align: justify;
> >>  }
> > 
> > Justified text ends up looking very ugly unless the layout engine is also
> > capable of doing automatic hyphenation of words - without hyphenation, if
> > you have a long word that gets pushed to the next line, you get huge 
> > whitespace
> > gaps between words.
> > 
> > More specific to the libvirt site - it looks very odd to have 
> > justified, but nothing else - eg looking at formatdomain.html, we end
> > up with a mix of justified and non-justified text, depending on whether
> > we've used a ,  or  for the particular bit of docs.
> 
> So you're not against the idea if I include other elements too? Or we
> should postpone it until we have the automatic hyphenation engine?

I'm not really seeing any compelling benefit to justification and clear
downsides. The hyphenation mitigates it somewhat, but its still pretty
poor compared to how a proper print layout engine does justification,
to the extent that I don't really see any point.

This blog describes it in a clearer detail that I can:

  http://designforhackers.com/blog/never-justify-type-on-the-web/

...many other blogs say basically the same too

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] [PATCH] docs: Format text in into a block

[Martin Kletzander]

On Fri, Dec 02, 2016 at 01:28:05PM +, Daniel P. Berrange wrote:

On Fri, Dec 02, 2016 at 01:37:17PM +0100, Michal Privoznik wrote:

On 02.12.2016 12:27, Daniel P. Berrange wrote:
> On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote:
>> With the rework of our webpage I've also noticed that we can make
>> our  block look more uniform: stretch the lines so that each
>> has the equal width. Just like if you hit "align to block" in
>> your favourite text editor.
>>
>> Signed-off-by: Michal Privoznik 
>> ---
>>  docs/generic.css | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/docs/generic.css b/docs/generic.css
>> index a6b2354df..4c8887d6d 100644
>> --- a/docs/generic.css
>> +++ b/docs/generic.css
>> @@ -14,6 +14,7 @@ p, ul, ol, dl {
>>  p {
>>margin-top: 1em;
>>margin-bottom: 1em;
>> +  text-align: justify;
>>  }
>
> Justified text ends up looking very ugly unless the layout engine is also
> capable of doing automatic hyphenation of words - without hyphenation, if
> you have a long word that gets pushed to the next line, you get huge 
whitespace
> gaps between words.
>
> More specific to the libvirt site - it looks very odd to have 
> justified, but nothing else - eg looking at formatdomain.html, we end
> up with a mix of justified and non-justified text, depending on whether
> we've used a ,  or  for the particular bit of docs.

So you're not against the idea if I include other elements too? Or we
should postpone it until we have the automatic hyphenation engine?


I'm not really seeing any compelling benefit to justification and clear
downsides. The hyphenation mitigates it somewhat, but its still pretty
poor compared to how a proper print layout engine does justification,
to the extent that I don't really see any point.

This blog describes it in a clearer detail that I can:

 http://designforhackers.com/blog/never-justify-type-on-the-web/

...many other blogs say basically the same too



Oh, if designers say so...  But to be honest, they all use it (and show
it) on pages that use 20% of my screen width, which is IMHO even more
stupid.


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


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] docs: Format text in into a block

[Michal Privoznik]

On 02.12.2016 12:27, Daniel P. Berrange wrote:
> On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote:
>> With the rework of our webpage I've also noticed that we can make
>> our  block look more uniform: stretch the lines so that each
>> has the equal width. Just like if you hit "align to block" in
>> your favourite text editor.
>>
>> Signed-off-by: Michal Privoznik 
>> ---
>>  docs/generic.css | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/docs/generic.css b/docs/generic.css
>> index a6b2354df..4c8887d6d 100644
>> --- a/docs/generic.css
>> +++ b/docs/generic.css
>> @@ -14,6 +14,7 @@ p, ul, ol, dl {
>>  p {
>>margin-top: 1em;
>>margin-bottom: 1em;
>> +  text-align: justify;
>>  }
> 
> Justified text ends up looking very ugly unless the layout engine is also
> capable of doing automatic hyphenation of words - without hyphenation, if
> you have a long word that gets pushed to the next line, you get huge 
> whitespace
> gaps between words.
> 
> More specific to the libvirt site - it looks very odd to have 
> justified, but nothing else - eg looking at formatdomain.html, we end
> up with a mix of justified and non-justified text, depending on whether
> we've used a ,  or  for the particular bit of docs.

So you're not against the idea if I include other elements too? Or we
should postpone it until we have the automatic hyphenation engine?

Michal

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

Re: [libvirt] [PATCH] docs: Format text in into a block

[Martin Kletzander]

On Fri, Dec 02, 2016 at 11:27:10AM +, Daniel P. Berrange wrote:

On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote:

With the rework of our webpage I've also noticed that we can make
our  block look more uniform: stretch the lines so that each
has the equal width. Just like if you hit "align to block" in
your favourite text editor.

Signed-off-by: Michal Privoznik 
---
 docs/generic.css | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/generic.css b/docs/generic.css
index a6b2354df..4c8887d6d 100644
--- a/docs/generic.css
+++ b/docs/generic.css
@@ -14,6 +14,7 @@ p, ul, ol, dl {
 p {
   margin-top: 1em;
   margin-bottom: 1em;
+  text-align: justify;
 }


Justified text ends up looking very ugly unless the layout engine is also
capable of doing automatic hyphenation of words - without hyphenation, if
you have a long word that gets pushed to the next line, you get huge whitespace
gaps between words.

More specific to the libvirt site - it looks very odd to have 
justified, but nothing else - eg looking at formatdomain.html, we end
up with a mix of justified and non-justified text, depending on whether
we've used a ,  or  for the particular bit of docs.



I haven't checked all the pages, but I think there's way more paragraphs
that look way cleaner and better with the justified text than there are
occurrences of very long unbreakable words that make one line look too
spacious.  But of course it should be added to dd, li as well as p.

I think it wouldn't look good with our old page, but with the new
layout, it makes it look way clearer.


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


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 11:08:14AM +0100, Martin Kletzander wrote:
> On Fri, Dec 02, 2016 at 09:16:26AM +, Daniel P. Berrange wrote:
> > On Fri, Dec 02, 2016 at 10:14:22AM +0100, Martin Kletzander wrote:
> > > On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote:
> > > > Google announced OSS-Fuzz project [1]. It's aim is to test projects with
> > > > significant user base and/or critical projects to the global
> > > > infrastructure. I like to think that libvirt falls in both categories 
> > > > :-)
> > > > You can find a list of already accepted projects here [2]. Once accepted
> > > > to the project we would have to provide some scripts that build libvirt
> > > > and run some tests.
> > > >
> > > 
> > > I was thinking about that too.  And danpb would like that as well, I
> > > guess, since he came up with the fuzzing idea for GSoC.
> > > 
> > > > One of the disadvantages is that we have to provide a docker(!) image
> > > > where the scripts would run from.
> > > >
> > > 
> > > But it's not like the whole libvirt has to be installed and running
> > > there, right?  It's unit-test fuzzing, it will just link against
> > > libvirt.la and run random APIs (mostly public ones, I guess).
> > 
> > You have to write test harnesses for the fuzzer, so it'll fuzz whatever
> > APIs you call from your test harnesses.
> > 
> 
> Yeah, we choose what to do.  I was elaborating on what we are going to
> choose.  So I take it as you like the idea?

I'm totally supportive of fuzzing of libvirt in general. I'm ambivalent
on where we actually run the fuzzers we create. Whether its on Google
or our Jenkins CI, or both doesn't matter as long as we have something
running somewhere. Since our Jenkins CI is already maxing out CPU
capacity quite often, it makes sense to try Google for now - we can
easily move later if needed, since their framework is built around
opensource fuzzing libraries/tools.

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] bug, libvirt, internal error

[Martin Kletzander]

On Thu, Dec 01, 2016 at 06:37:02PM -0500, CESAR DAVID VASQUEZ ROMERO wrote:

Hi, I'm having a problem with libvirt.

Since a few days, when I try to create a virtual machine I get the
following error and I could not solve it

" Imposible completar la instalación: 'internal error: Cannot find suitable
CPU model for given data' "

-
Detalles:

imposible completar la instalación: 'internal error: Cannot find suitable
CPU model for given data'

Traceback (most recent call last):
 File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in
cb_wrapper
   callback(asyncjob, *args, **kwargs)
 File "/usr/share/virt-manager/virtManager/create.py", line 2277, in
_do_async_install
   guest.start_install(meter=meter)
 File "/usr/share/virt-manager/virtinst/guest.py", line 501, in
start_install
   noboot)
 File "/usr/share/virt-manager/virtinst/guest.py", line 416, in
_create_guest
   dom = self.conn.createLinux(start_xml or final_xml, 0)
 File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3606, in
createLinux
   if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: internal error: Cannot find suitable CPU model for given data

-


I tried deleting the / var / cache / libvirt / qemu / capabilities /
directory, and restarting libvirt but it did not work.



First read the error message.  It's probably not "internal" error, you
just have CPU specification that you can't use with your current system.


I have other virtual machines on the physical server and they work fine,
but I can not create new ones.

How can i fix this



At least you could post the domain XML.  Well, since you have two
domains and one of them works and the other one doesn't try comparing
the XMLs and find a difference related to the error message (hint: CPU).


Thank you


You're welcome =)


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


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] docs: Format text in into a block

[Michal Privoznik]

With the rework of our webpage I've also noticed that we can make
our  block look more uniform: stretch the lines so that each
has the equal width. Just like if you hit "align to block" in
your favourite text editor.

Signed-off-by: Michal Privoznik 
---
 docs/generic.css | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/generic.css b/docs/generic.css
index a6b2354df..4c8887d6d 100644
--- a/docs/generic.css
+++ b/docs/generic.css
@@ -14,6 +14,7 @@ p, ul, ol, dl {
 p {
   margin-top: 1em;
   margin-bottom: 1em;
+  text-align: justify;
 }
 
 ul, ol {
-- 
2.11.0

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

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

[David Gibson]

On Fri, Dec 02, 2016 at 04:17:50PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-02 at 15:18 +1100, David Gibson wrote:
> > But if you pass through multiple groups, things get weird.  On q35,
> > you'd generally expect physically separate (different slot) devices to
> > appear under separate root complexes.  Whereas on pseries they'll
> > appear as siblings on a virtual bus (which makes no physical sense for
> > point-to-point PCI-E).
> 
> It's also somewhat broken if they aren't in the same iommu domain
> because the way we pass the iommu buid is via the parent node, so
> a given iommu domain must reside below a common parent and not share
> it.

Uh.. I don't entirely follow you.  From the host point of view there
are multiple iommu groups (PEs), but from the guest point of view
there's only one.  On the guest side iommu granularity is always
per-vPHB.

> > I suppose we could try treating all devices on pseries as though they
> > were chipset builtin devices on q35, which will appear on the root
> > PCI-E bus without root complex.  But I suspect that's likely to cause
> > trouble with hotplug, and it will certainly need different address
> > allocation from libvirt.
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote:
> Google announced OSS-Fuzz project [1]. It's aim is to test projects with
> significant user base and/or critical projects to the global
> infrastructure. I like to think that libvirt falls in both categories :-)
> You can find a list of already accepted projects here [2]. Once accepted
> to the project we would have to provide some scripts that build libvirt
> and run some tests.
> 
> One of the disadvantages is that we have to provide a docker(!) image
> where the scripts would run from.
> 
> What are your thoughts on this? Should we apply?

I think we'd certainly benefit from some fuzzing of libvirt / libvirtd.

I was a little unclear on exactly how they're doing the fuzzing from those
docs, but looking at some of the project's they're already got it seems they
rely on providing some custom test programs that call the APIs.

eg

https://github.com/google/oss-fuzz/blob/master/projects/libyaml/libyaml_fuzzer.cc

https://github.com/google/oss-fuzz/blob/master/projects/libxml2/libxml2_xml_read_memory_fuzzer.cc

https://github.com/google/oss-fuzz/blob/master/projects/libxml2/libxml2_xml_regexp_compile_fuzzer.cc


OpenSSL is a little different as it seems they've natively integrated
support for libfuzz in their code base, so google merely turns that
on at configure stage

  https://github.com/google/oss-fuzz/blob/master/projects/openssl/build.sh


So someone is going to need to write the test harness to actually
exercise libvirt via the fuzzer still, which is work we've long had
an outstanding todo for - its even a GSoC suggestion

  
https://wiki.libvirt.org/page/Google_Summer_of_Code_2017#QEMU_command_line_generator_XML_fuzzing


Once that's done we could leverage google's infra to actually run it.
The XML parser is only half the story though - it'd be nice to get
fuzzing on the main public APIs too (and thus the remote RPC protocol
handling and QEMU driver code). Writing fuzzer test harnesses for all
the public APIs is an even bigger bit of work

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] bug, libvirt, internal error

[Jiri Denemark]

Hello.

On Thu, Dec 01, 2016 at 18:37:02 -0500, CESAR DAVID VASQUEZ ROMERO wrote:
> Hi, I'm having a problem with libvirt.

What version of libvirt and virt-manager do you use?

> Since a few days, when I try to create a virtual machine I get the
> following error and I could not solve it

Did anything change on the host before you started seeing this error,
was libvirt or virt-manager upgraded?

> " Imposible completar la instalación: 'internal error: Cannot find suitable
> CPU model for given data' "

OK, we need to get more details to be able to help you. Could you please
do the following:

1. run the following command (after installing cpuid) and send us the
output (root is NOT required to run the script):
http://libvirt.org/git/?p=libvirt.git;a=blob;f=tests/cputestdata/cpu-gather.sh

2. enable libvirtd debug logs as described at
http://wiki.libvirt.org/page/DebugLogs, restart libvirtd, try creating
new VM in virt-manager and when it fails send us
/var/log/libvirt/libvirtd.log and ~/.virt-manager/virt-manager.log

3. you probably want to disable libvirtd debug log and restart the
service once you're done

> I have other virtual machines on the physical server and they work fine,
> but I can not create new ones.

Are these machines already running or are they turned off, but can be
started?

Thanks.

Jirka

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

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

[Martin Kletzander]

On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote:

Google announced OSS-Fuzz project [1]. It's aim is to test projects with
significant user base and/or critical projects to the global
infrastructure. I like to think that libvirt falls in both categories :-)
You can find a list of already accepted projects here [2]. Once accepted
to the project we would have to provide some scripts that build libvirt
and run some tests.



I was thinking about that too.  And danpb would like that as well, I
guess, since he came up with the fuzzing idea for GSoC.


One of the disadvantages is that we have to provide a docker(!) image
where the scripts would run from.



But it's not like the whole libvirt has to be installed and running
there, right?  It's unit-test fuzzing, it will just link against
libvirt.la and run random APIs (mostly public ones, I guess).


What are your thoughts on this? Should we apply?



I was already reading up on it when you sent the mail, so I'd say yes.


Michal


1:
https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html

2: https://github.com/google/oss-fuzz

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


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

[Daniel P. Berrange]

On Fri, Dec 02, 2016 at 10:14:22AM +0100, Martin Kletzander wrote:
> On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote:
> > Google announced OSS-Fuzz project [1]. It's aim is to test projects with
> > significant user base and/or critical projects to the global
> > infrastructure. I like to think that libvirt falls in both categories :-)
> > You can find a list of already accepted projects here [2]. Once accepted
> > to the project we would have to provide some scripts that build libvirt
> > and run some tests.
> > 
> 
> I was thinking about that too.  And danpb would like that as well, I
> guess, since he came up with the fuzzing idea for GSoC.
> 
> > One of the disadvantages is that we have to provide a docker(!) image
> > where the scripts would run from.
> > 
> 
> But it's not like the whole libvirt has to be installed and running
> there, right?  It's unit-test fuzzing, it will just link against
> libvirt.la and run random APIs (mostly public ones, I guess).

You have to write test harnesses for the fuzzer, so it'll fuzz whatever
APIs you call from your test harnesses.



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] Should Libvirt apply for OSS-Fuzz?

[Martin Kletzander]

On Fri, Dec 02, 2016 at 09:16:26AM +, Daniel P. Berrange wrote:

On Fri, Dec 02, 2016 at 10:14:22AM +0100, Martin Kletzander wrote:

On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote:
> Google announced OSS-Fuzz project [1]. It's aim is to test projects with
> significant user base and/or critical projects to the global
> infrastructure. I like to think that libvirt falls in both categories :-)
> You can find a list of already accepted projects here [2]. Once accepted
> to the project we would have to provide some scripts that build libvirt
> and run some tests.
>

I was thinking about that too.  And danpb would like that as well, I
guess, since he came up with the fuzzing idea for GSoC.

> One of the disadvantages is that we have to provide a docker(!) image
> where the scripts would run from.
>

But it's not like the whole libvirt has to be installed and running
there, right?  It's unit-test fuzzing, it will just link against
libvirt.la and run random APIs (mostly public ones, I guess).


You have to write test harnesses for the fuzzer, so it'll fuzz whatever
APIs you call from your test harnesses.



Yeah, we choose what to do.  I was elaborating on what we are going to
choose.  So I take it as you like the idea?




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/ :|


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Candidate Release 2 for libvirt-2.5.0 is out

[Daniel Veillard]

  As planned I tagged it in git head and pushed the signed tarball and rpms
to the usual place:

  ftp://libvirt.org/libvirt/

 Nothing special noticed, seems that Laine patches are in so this looks
good to me from my minimal viewpoint. That said having report for other
platforms and systems is always a good thing.

  Unless something negative shows up in the meantime, I will push the
final version of 2.5.0 out during the w.e.

  but again, please give it a try,

thanks,

Daniel

-- 
Daniel Veillard  | Open Source and Standards, Red Hat
veill...@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/

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

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

[Alexey Kardashevskiy]

On 03/12/16 08:41, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-02 at 16:50 +1100, David Gibson wrote:
>>
>> Uh.. I don't entirely follow you.  From the host point of view there
>> are multiple iommu groups (PEs), but from the guest point of view
>> there's only one.  On the guest side iommu granularity is always
>> per-vPHB.
> 
> Ok so the H_PUT_TCE calls affect all the underlying tables ?

Yes, it updates all hardware tables attached to the same guest's LIOBN
(which in reality can only be seen on power7 as power8 shares tables
between PEs).


-- 
Alexey

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

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

[Benjamin Herrenschmidt]

On Fri, 2016-12-02 at 15:18 +1100, David Gibson wrote:
> But if you pass through multiple groups, things get weird.  On q35,
> you'd generally expect physically separate (different slot) devices to
> appear under separate root complexes.  Whereas on pseries they'll
> appear as siblings on a virtual bus (which makes no physical sense for
> point-to-point PCI-E).

It's also somewhat broken if they aren't in the same iommu domain
because the way we pass the iommu buid is via the parent node, so
a given iommu domain must reside below a common parent and not share
it.

> I suppose we could try treating all devices on pseries as though they
> were chipset builtin devices on q35, which will appear on the root
> PCI-E bus without root complex.  But I suspect that's likely to cause
> trouble with hotplug, and it will certainly need different address
> allocation from libvirt.

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

Re: [libvirt] [PATCH 4/5] conf: add global check for duplicate drive addresses

[Michal Privoznik]

On 30.11.2016 12:47, Marc Hartmayer wrote:
> Add a global check for duplicate drive addresses. This will fix the
> problem of duplicate disk and hostdev drive addresses.
> 
> Example for duplicate drive addresses:
> 
>   ...
>   
> 
> 
>   ...
>   
>   
> 
> 
> Another example:
> 
>   
>   ...
>   
>   
> 
> 
>   
>   ...
>   
>   
> 
> 
> Unfortunately the fixes (1b08cc170a84077afd4d15f4639a9a2cf398e9a2,
> 8d46386bfe01b84982e25e915ad9cfbae5cf4cb1) weren't enough to catch these
> cases and it isn't possible to add additional checks in
> virDomainDeviceDefPostParseInternal() for SCSI hostdevs or
> virDomainDiskDefAssignAddress() for SCSI/IDE/FDC/SATA disks without
> adding another parse flag (virDomainDefParseFlags) to disable this
> validation while updating or detaching a disk or hostdev.
> 
> Signed-off-by: Marc Hartmayer 
> Reviewed-by: Boris Fiuczynski 
> ---
>  src/conf/domain_conf.c | 104 
> +
>  1 file changed, 104 insertions(+)
> 
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index cd30728..cb47980 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -4841,6 +4841,107 @@ virDomainDefCheckDuplicateDiskInfo(const virDomainDef 
> *def)
>  return 0;
>  }
>  
> +/**
> + * virDomainDefCheckDuplicateDriveAddresses:
> + * @def: domain definition to check against
> + *
> + * This function checks @def for duplicate drive addresses. Drive
> + * addresses are only in use for disks and hostdevs at the moment.
> + *
> + * Returns 0 in case of there are no duplicate drive addresses, -1
> + * otherwise.
> + */
> +static int
> +virDomainDefCheckDuplicateDriveAddresses(const virDomainDef *def)
> +{
> +size_t i;
> +size_t j;
> +
> +for (i = 0; i < def->ndisks; i++) {
> +virDomainDiskDefPtr disk_i = def->disks[i];
> +virDomainDeviceInfoPtr disk_info_i = _i->info;
> +if (disk_info_i->type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE)
> +continue;

We like to have an empty line between variable declarations and the
actual code. Just like you did at the beginning of this function. But
that's something I can fix before pushing.

> +
> +for (j = i + 1; j < def->ndisks; j++) {
> +virDomainDiskDefPtr disk_j = def->disks[j];
> +virDomainDeviceInfoPtr disk_info_j = _j->info;
> +if (disk_i->bus != disk_j->bus)
> +continue;
> +
> +if (disk_info_j->type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE)
> +continue;
> +
> +if (virDomainDeviceInfoAddressIsEqual(disk_info_i, disk_info_j)) 
> {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> +   _("Found duplicate drive address for disk 
> with "
> + "target name '%s' controller='%u' bus='%u' "
> + "target='%u' unit='%u'"),
> +   disk_i->dst,
> +   disk_info_i->addr.drive.controller,
> +   disk_info_i->addr.drive.bus,
> +   disk_info_i->addr.drive.target,
> +   disk_info_i->addr.drive.unit);
> +return -1;
> +}
> +}
> +
> +/* Note: There is no need to check for conflicts with SCSI
> + * hostdevs above, because conflicts with hostdevs are checked
> + * in the next loop.
> + */
> +}

Michal

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

Re: [libvirt] [PATCH v2] storage: vz storage pool support

[Olga Krishtal]

On 20/09/16 23:30, John Ferlan wrote:


On 07/14/2016 01:13 PM, Olga Krishtal wrote:

This patch supports pool and volume management within Virtuozzo Storage.
Virtuozzo Storage is a highly-available distributed software defined storage
with built-in replication and disaster recovery. From client's point of
view it looks like network attached storage (NFS or GlusterFS).
More information about vzstorage can be found here: 
https://openvz.org/Virtuozzo_Storage
It supports the same volume formats as directory, nfs, etc.
Default format is raw.

Signed-off-by: Olga Krishtal 
---
  configure.ac  |  31 +++
  docs/schemas/storagepool.rng  |  29 ++
  include/libvirt/libvirt-storage.h |   1 +
  src/conf/storage_conf.c   |  16 +-
  src/conf/storage_conf.h   |   4 +-
  src/storage/storage_backend.c |   3 +
  src/storage/storage_backend_fs.c  | 112 +-
  src/storage/storage_backend_fs.h  |   3 +
  src/storage/storage_driver.c  |   2 +
  tools/virsh-pool.c|   2 +
  tools/virsh.c |   3 +
  11 files changed, 203 insertions(+), 3 deletions(-)


In an effort to go through older on list bugs I'm wondering about the
relative importance of this compared to the fspool series.  Shall I
assume this is dropped in favor of that?

Tks -


No, we will not drop it. We want to have Virtuozzo Storage as backend 
for storage pool.




John

FWIW: It compiled, but failed syntax-check.


I have checked it once again - and in my case -syntax-check is passed.
Can you tell me what is wrong in your case? (The patch is ok for upstream)


  Also the name "vstorage"
would seemingly be a bit too generic. I saw and thought virtual storage
not Virtuozzo Storage



All tools we use to manage Virtuozzo storage starts with vstorage*.
However, I can use vzstorage instead.


diff --git a/configure.ac b/configure.ac
index 2c81c95..2ee8b8c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1692,6 +1692,10 @@ AC_ARG_WITH([storage-zfs],
[AS_HELP_STRING([--with-storage-zfs],
  [with ZFS backend for the storage driver @<:@default=check@:>@])],
[],[with_storage_zfs=check])
+AC_ARG_WITH([storage-vstorage],
+  [AS_HELP_STRING([--with-storage-vstorage],
+[with VZ backend for the storage driver @<:@default=check@:>@])],
+  [],[with_storage_vstorage=check])
  
  if test "$with_libvirtd" = "no"; then

with_storage_dir=no
@@ -1705,6 +1709,7 @@ if test "$with_libvirtd" = "no"; then
with_storage_sheepdog=no
with_storage_gluster=no
with_storage_zfs=no
+  with_storage_vstorage=no
  fi
  if test "$with_storage_dir" = "yes" ; then
AC_DEFINE_UNQUOTED([WITH_STORAGE_DIR], 1, [whether directory backend for 
storage driver is enabled])
@@ -1963,6 +1968,31 @@ if test "$with_storage_fs" = "yes" ||
fi
  fi
  
+if test "$with_storage_vstorage" = "yes" || test "$with_storage_vstorage" = "check"; then

+   AC_PATH_PROG([VSTORAGE], [vstorage], [], [$PATH:/sbin:/usr/bin])
+   AC_PATH_PROG([VSTORAGE_MOUNT], [vstorage-mount], [], [$PATH:/sbin/usr/bin])
+  if test "$with_storage_vstorage" = "yes"; then
+if test -z "$VSTORAGE" ; then AC_MSG_ERROR([We need vstorage tools for 
virtuozzo storage driver]); fi
+if test -z "$VSTORAGE_MOUNT" ; then AC_MSG_ERROR([We need vstorage mount 
tool for virtuozzo storage driver]); fi
+if test  "$with_storage_fs" = "no"; then AC_MSG_ERROR([We need fs backend 
for vstorage pool]); fi
+  else
+if test -z "$VSTORAGE" ; then with_storage_vstorage=no; fi
+if test -z "$VSTORAGE" ; then with_storage_vstorage=no; fi
+if test  "$with_storage_fs"= "no"; then with_storage_vstorage=no; fi
+
+if test "$with_storage_vstorage" = "check" ; then 
with_storage_vstorage=yes ; fi
+  fi
+  if test "$with_storage_vstorage" = "yes"; then
+  AC_DEFINE_UNQUOTED([WITH_STORAGE_VSTORAGE], 1, [whether virtuozzo 
storage backend for storage driver is enabled])
+  AC_DEFINE_UNQUOTED([VSTORAGE], ["$VSTORAGE"], [Location or name of 
vstorage program])
+  AC_DEFINE_UNQUOTED([VSTORAGE_MOUNT], ["$VSTORAGE_MOUNT"], [Location or 
name of vstorage-mount program])
+  AC_DEFINE_UNQUOTED([with_storage_fs], ["$VSTORAGE_MOUNT"], [must be on])
+  fi
+
+  if test "$with_storage_vstorage" = "check" ; then with_storage_vstorage=yes 
; fi
+fi
+AM_CONDITIONAL([WITH_STORAGE_VSTORAGE], [test "$with_storage_vstorage" = 
"yes"])
+
  LIBPARTED_CFLAGS=
  LIBPARTED_LIBS=
  if test "$with_storage_disk" = "yes" ||
@@ -2759,6 +2789,7 @@ AC_MSG_NOTICE([ RBD: $with_storage_rbd])
  AC_MSG_NOTICE([Sheepdog: $with_storage_sheepdog])
  AC_MSG_NOTICE([ Gluster: $with_storage_gluster])
  AC_MSG_NOTICE([ ZFS: $with_storage_zfs])
+AC_MSG_NOTICE([Vstorage: $with_storage_vstorage])
  AC_MSG_NOTICE([])
  AC_MSG_NOTICE([Security Drivers])
  AC_MSG_NOTICE([])
diff --git a/docs/schemas/storagepool.rng b/docs/schemas/storagepool.rng
index 49d212f..8ad5616 100644
--- 

Re: [libvirt] [PATCH 0/5] Reject duplicate drive addresses

[Michal Privoznik]

On 30.11.2016 12:47, Marc Hartmayer wrote:
> Reject duplicate drive addresses at domain definition. Hot-plug for
> disks and hostdevs is still to fix and this is why the old version of
> drive address checking is still there. Additionally, it isn't that
> easy to be sure that the changes won't break other drivers as these
> are common code changes.
> 
> Marc Hartmayer (5):
>   conf: simplify functions virDomainSCSIDriveAddressIsUsedBy*()
>   conf: virDomainDriveAddressIsUsedByDisk: Rename type to bus_type
>   tests: don't use duplicate disk addresses
>   conf: add global check for duplicate drive addresses
>   tests: add test cases for address conflicts
> 
>  src/conf/domain_conf.c | 184 
> +
>  .../qemuxml2argv-disk-drive-address-conflict.xml   |  27 +++
>  ...xml2argv-disk-hostdev-scsi-address-conflict.xml |  30 
>  ...emuxml2argv-hostdevs-drive-address-conflict.xml |  33 
>  .../qemuxml2argv-seclabel-dynamic-override.args|   4 +-
>  .../qemuxml2argv-seclabel-dynamic-override.xml |   2 +-
>  tests/qemuxml2argvtest.c   |   8 +
>  .../qemuxml2xmlout-seclabel-dynamic-override.xml   |   2 +-
>  8 files changed, 251 insertions(+), 39 deletions(-)
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-disk-drive-address-conflict.xml
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-disk-hostdev-scsi-address-conflict.xml
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-hostdevs-drive-address-conflict.xml
> 

ACK series. We are currently in freeze so I will push this after the
release. Technically this could go in as it is a bug fix, but rather a
big one so I'd rather push it after the release, if you don't mind.

Michal

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

[libvirt] [PATCH RFC v3 13/15] FSPool: driver methods implementation

[Olga Krishtal]

Signed-off-by: Olga Krishtal 
---
 src/fs/fs_driver.c | 1723 +---
 1 file changed, 1515 insertions(+), 208 deletions(-)

diff --git a/src/fs/fs_driver.c b/src/fs/fs_driver.c
index 98d91fa..f913ce5 100644
--- a/src/fs/fs_driver.c
+++ b/src/fs/fs_driver.c
@@ -82,314 +82,1621 @@ virFSBackendForType(int type)
 }
 
 /* General fspool/item implementation */
+
 static int
-fsConnectListAllFSPools(virConnectPtr conn ATTRIBUTE_UNUSED,
-virFSPoolPtr **fspools ATTRIBUTE_UNUSED,
+fsConnectListAllFSPools(virConnectPtr conn,
+virFSPoolPtr **fspools,
 unsigned int flags)
 {
-virCheckFlags(0, -1);
+int ret = -1;
 
-virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
-   _("the operation is not yet supported"));
+virCheckFlags(VIR_CONNECT_LIST_FSPOOLS_FILTERS_ALL, -1);
+
+if (virConnectListAllFSPoolsEnsureACL(conn) < 0)
+goto cleanup;
+
+fsDriverLock();
+ret = virFSPoolObjListExport(conn, driver->fspools, fspools,
+ virConnectListAllFSPoolsCheckACL,
+ flags);
+fsDriverUnlock();
+
+ cleanup:
+return ret;
 
-return -1;
 }
 
 static virFSPoolPtr
-fsPoolLookupByName(virConnectPtr conn ATTRIBUTE_UNUSED,
-   const char *name ATTRIBUTE_UNUSED)
+fsPoolLookupByName(virConnectPtr conn,
+   const char *name)
 {
-virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
-   _("the operation is not yet supported"));
+virFSPoolObjPtr fspool;
+virFSPoolPtr ret = NULL;
 
-return NULL;
+fsDriverLock();
+fspool = virFSPoolObjFindByName(>fspools, name);
+fsDriverUnlock();
+
+if (!fspool) {
+virReportError(VIR_ERR_NO_FSPOOL,
+   _("no fspool with matching name '%s'"), name);
+return NULL;
+}
+
+if (virFSPoolLookupByNameEnsureACL(conn, fspool->def) < 0)
+goto cleanup;
+
+ret = virGetFSPool(conn, fspool->def->name, fspool->def->uuid,
+   NULL, NULL);
+
+ cleanup:
+virFSPoolObjUnlock(fspool);
+return ret;
 }
 
 static virFSPoolPtr
-fsPoolLookupByUUID(virConnectPtr conn ATTRIBUTE_UNUSED,
-   const unsigned char *uuid ATTRIBUTE_UNUSED)
+fsPoolLookupByUUID(virConnectPtr conn,
+   const unsigned char *uuid)
 {
-virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
-   _("the operation is not yet supported"));
+virFSPoolObjPtr fspool;
+virFSPoolPtr ret = NULL;
 
-return NULL;
+fsDriverLock();
+fspool = virFSPoolObjFindByUUID(>fspools, uuid);
+fsDriverUnlock();
+
+if (!fspool) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+virUUIDFormat(uuid, uuidstr);
+virReportError(VIR_ERR_NO_FSPOOL,
+   _("no fspool with matching uuid '%s'"), uuidstr);
+return NULL;
+}
+
+if (virFSPoolLookupByUUIDEnsureACL(conn, fspool->def) < 0)
+goto cleanup;
+
+ret = virGetFSPool(conn, fspool->def->name, fspool->def->uuid,
+   NULL, NULL);
+
+ cleanup:
+virFSPoolObjUnlock(fspool);
+return ret;
 }
 
 static virFSPoolPtr
-fsPoolLookupByItem(virFSItemPtr item ATTRIBUTE_UNUSED)
+fsPoolLookupByItem(virFSItemPtr item)
 {
-virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
-   _("the operation is not yet supported"));
+virFSPoolObjPtr fspool;
+virFSPoolPtr ret = NULL;
 
-return NULL;
+fsDriverLock();
+fspool = virFSPoolObjFindByName(>fspools, item->pool);
+fsDriverUnlock();
+
+if (!fspool) {
+virReportError(VIR_ERR_NO_FSPOOL,
+   _("no fspool with matching name '%s'"),
+   item->pool);
+return NULL;
+}
+
+if (virFSPoolLookupByItemEnsureACL(item->conn, fspool->def) < 0)
+goto cleanup;
+
+ret = virGetFSPool(item->conn, fspool->def->name, fspool->def->uuid,
+NULL, NULL);
+
+ cleanup:
+virFSPoolObjUnlock(fspool);
+return ret;
 }
 
 static virFSPoolPtr
-fsPoolCreateXML(virConnectPtr conn ATTRIBUTE_UNUSED,
-const char *xml ATTRIBUTE_UNUSED,
+fsPoolCreateXML(virConnectPtr conn,
+const char *xml,
 unsigned int flags)
 {
-virCheckFlags(0, NULL);
-virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
-   _("the operation is not yet supported"));
+virFSPoolDefPtr def;
+virFSPoolObjPtr fspool = NULL;
+virFSPoolPtr ret = NULL;
+virFSBackendPtr backend;
+char *stateFile = NULL;
+unsigned int build_flags = 0;
 
-return NULL;
+virCheckFlags(VIR_FSPOOL_CREATE_WITH_BUILD_OVERWRITE |
+  VIR_FSPOOL_CREATE_WITH_BUILD_NO_OVERWRITE, NULL);
+
+VIR_EXCLUSIVE_FLAGS_RET(VIR_FSPOOL_BUILD_OVERWRITE,
+

[libvirt] [PATCH RFC v3 11/15] virsh: filesystem pools commands

[Olga Krishtal]

Signed-off-by: Nikolay Shirokovskiy 
Signed-off-by: Maxim Nestratov 
---
 po/POTFILES.in   |2 +
 tools/Makefile.am|2 +
 tools/virsh-fsitem.c | 1293 +
 tools/virsh-fsitem.h |   39 ++
 tools/virsh-fspool.c | 1574 ++
 tools/virsh-fspool.h |   38 ++
 tools/virsh.c|4 +
 tools/virsh.h|9 +
 tools/virsh.pod  |  252 +++-
 9 files changed, 3212 insertions(+), 1 deletion(-)
 create mode 100644 tools/virsh-fsitem.c
 create mode 100644 tools/virsh-fsitem.h
 create mode 100644 tools/virsh-fspool.c
 create mode 100644 tools/virsh-fspool.h

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 7ad9174..2d4c191 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -289,8 +289,10 @@ tools/virsh-console.c
 tools/virsh-domain-monitor.c
 tools/virsh-domain.c
 tools/virsh-edit.c
+tools/virsh-fspool.c
 tools/virsh-host.c
 tools/virsh-interface.c
+tools/virsh-fsitem.c
 tools/virsh-network.c
 tools/virsh-nodedev.c
 tools/virsh-nwfilter.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 319abb2..ff68bd2 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -198,9 +198,11 @@ virsh_SOURCES =
\
virsh-nodedev.c virsh-nodedev.h \
virsh-nwfilter.c virsh-nwfilter.h   \
virsh-pool.c virsh-pool.h   \
+   virsh-fspool.c virsh-fspool.h   \
virsh-secret.c virsh-secret.h   \
virsh-snapshot.c virsh-snapshot.h   \
virsh-volume.c virsh-volume.h   \
+   virsh-fsitem.c virsh-fsitem.h   \
$(NULL)
 
 virsh_LDFLAGS = \
diff --git a/tools/virsh-fsitem.c b/tools/virsh-fsitem.c
new file mode 100644
index 000..87fb327
--- /dev/null
+++ b/tools/virsh-fsitem.c
@@ -0,0 +1,1293 @@
+/*
+ * virsh-fsitem.c: Commands to manage storage item
+ *
+ * Copyright (C) 2016 Parallels IP Holdings GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ *
+ *  Olga Krishtal 
+ *
+ */
+#include 
+#include "virsh-fsitem.h"
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "internal.h"
+#include "virbuffer.h"
+#include "viralloc.h"
+#include "virutil.h"
+#include "virfile.h"
+#include "virsh-fspool.h"
+#include "virxml.h"
+#include "virstring.h"
+
+#define VIRSH_COMMON_OPT_FSPOOL_FULL\
+VIRSH_COMMON_OPT_FSPOOL(N_("fspool name or uuid"))\
+
+#define VIRSH_COMMON_OPT_FSPOOL_NAME\
+VIRSH_COMMON_OPT_FSPOOL(N_("fspool name"))\
+
+#define VIRSH_COMMON_OPT_FSPOOL_OPTIONAL\
+{.name = "fspool",  \
+ .type = VSH_OT_STRING,   \
+ .help = N_("fspool name or uuid")  \
+} \
+
+#define VIRSH_COMMON_OPT_ITEM   \
+{.name = "item",   \
+ .type = VSH_OT_DATA, \
+ .flags = VSH_OFLAG_REQ,  \
+ .help = N_("item name, key or path")  \
+} \
+
+virFSItemPtr
+virshCommandOptItemBy(vshControl *ctl, const vshCmd *cmd,
+  const char *optname,
+  const char *fspooloptname,
+  const char **name, unsigned int flags)
+{
+virFSItemPtr item = NULL;
+virFSPoolPtr fspool = NULL;
+const char *n = NULL, *p = NULL;
+virshControlPtr priv = ctl->privData;
+
+virCheckFlags(VIRSH_BYUUID | VIRSH_BYNAME, NULL);
+
+if (vshCommandOptStringReq(ctl, cmd, optname, ) < 0)
+return NULL;
+
+if (fspooloptname != NULL &&
+vshCommandOptStringReq(ctl, cmd, fspooloptname, ) < 0)
+return NULL;
+
+if (p) {
+if (!(fspool = virshCommandOptFSPoolBy(ctl, cmd, fspooloptname, name, 
flags)))
+return NULL;
+
+if 

[libvirt] [PATCH RFC v3 02/15] storage pools: functions refactoring

[Olga Krishtal]

After reusage of all possible storage pool structures
we will able to use some storage pool functions.

Signed-off-by: Olga Krishtal 
---
 src/Makefile.am   |   2 +-
 src/conf/storage_conf.c   | 162 --
 src/conf/storage_conf.h   |  13 +---
 src/libvirt_private.syms  |  11 ++--
 src/util/virpoolcommon.c  | 125 +++
 src/util/virpoolcommon.h  |  16 +
 src/util/virstoragefile.c |  73 +
 src/util/virstoragefile.h |   3 +
 8 files changed, 225 insertions(+), 180 deletions(-)
 create mode 100644 src/util/virpoolcommon.c

diff --git a/src/Makefile.am b/src/Makefile.am
index f8d4a5b..13a4976 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -185,7 +185,7 @@ UTIL_SOURCES =  
\
util/viruuid.c util/viruuid.h   \
util/virxdrdefs.h   \
util/virxml.c util/virxml.h \
-   util/virpoolcommon.h\
+   util/virpoolcommon.h util/virpoolcommon.c   \
 $(NULL)
 
 EXTRA_DIST += $(srcdir)/util/keymaps.csv $(srcdir)/util/virkeycode-mapgen.py
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index 7e7bb72..f452fba 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -96,10 +96,6 @@ VIR_ENUM_IMPL(virStoragePartedFs,
   "ext2", "ext2",
   "extended")
 
-VIR_ENUM_IMPL(virStoragePoolSourceAdapter,
-  VIR_STORAGE_POOL_SOURCE_ADAPTER_TYPE_LAST,
-  "default", "scsi_host", "fc_host")
-
 typedef const char *(*virStorageVolFormatToString)(int format);
 typedef int (*virStorageVolFormatFromString)(const char *format);
 
@@ -328,73 +324,6 @@ virStorageVolDefFree(virStorageVolDefPtr def)
 VIR_FREE(def);
 }
 
-static void
-virStoragePoolSourceAdapterClear(virStoragePoolSourceAdapterPtr adapter)
-{
-if (adapter->type == VIR_STORAGE_POOL_SOURCE_ADAPTER_TYPE_FC_HOST) {
-VIR_FREE(adapter->data.fchost.wwnn);
-VIR_FREE(adapter->data.fchost.wwpn);
-VIR_FREE(adapter->data.fchost.parent);
-} else if (adapter->type ==
-   VIR_STORAGE_POOL_SOURCE_ADAPTER_TYPE_SCSI_HOST) {
-VIR_FREE(adapter->data.scsi_host.name);
-}
-}
-
-void
-virStoragePoolSourceDeviceClear(virStoragePoolSourceDevicePtr dev)
-{
-VIR_FREE(dev->freeExtents);
-VIR_FREE(dev->path);
-}
-
-void
-virStoragePoolSourceClear(virStoragePoolSourcePtr source)
-{
-size_t i;
-
-if (!source)
-return;
-
-for (i = 0; i < source->nhost; i++)
-VIR_FREE(source->hosts[i].name);
-VIR_FREE(source->hosts);
-
-for (i = 0; i < source->ndevice; i++)
-virStoragePoolSourceDeviceClear(>devices[i]);
-VIR_FREE(source->devices);
-VIR_FREE(source->dir);
-VIR_FREE(source->name);
-virStoragePoolSourceAdapterClear(>adapter);
-VIR_FREE(source->initiator.iqn);
-virStorageAuthDefFree(source->auth);
-VIR_FREE(source->vendor);
-VIR_FREE(source->product);
-}
-
-void
-virStoragePoolSourceFree(virStoragePoolSourcePtr source)
-{
-virStoragePoolSourceClear(source);
-VIR_FREE(source);
-}
-
-void
-virStoragePoolDefFree(virStoragePoolDefPtr def)
-{
-if (!def)
-return;
-
-VIR_FREE(def->name);
-
-virStoragePoolSourceClear(>source);
-
-VIR_FREE(def->target.path);
-VIR_FREE(def->target.perms.label);
-VIR_FREE(def);
-}
-
-
 void
 virStoragePoolObjFree(virStoragePoolObjPtr obj)
 {
@@ -730,83 +659,6 @@ virStoragePoolDefParseSourceString(const char *srcSpec,
 return ret;
 }
 
-static int
-virStorageDefParsePerms(xmlXPathContextPtr ctxt,
-virStoragePermsPtr perms,
-const char *permxpath)
-{
-char *mode;
-long long val;
-int ret = -1;
-xmlNodePtr relnode;
-xmlNodePtr node;
-
-node = virXPathNode(permxpath, ctxt);
-if (node == NULL) {
-/* Set default values if there is not  element */
-perms->mode = (mode_t) -1;
-perms->uid = (uid_t) -1;
-perms->gid = (gid_t) -1;
-perms->label = NULL;
-return 0;
-}
-
-relnode = ctxt->node;
-ctxt->node = node;
-
-if ((mode = virXPathString("string(./mode)", ctxt))) {
-int tmp;
-
-if (virStrToLong_i(mode, NULL, 8, ) < 0 || (tmp & ~0777)) {
-VIR_FREE(mode);
-virReportError(VIR_ERR_XML_ERROR, "%s",
-   _("malformed octal mode"));
-goto error;
-}
-perms->mode = tmp;
-VIR_FREE(mode);
-} else {
-perms->mode = (mode_t) -1;
-}
-
-if (virXPathNode("./owner", ctxt) == NULL) {
-perms->uid = (uid_t) -1;
-} else {
-/* We previously could output -1, so continue to parse it */
-if (virXPathLongLong("number(./owner)", ctxt, ) < 0 ||
-

[libvirt] [PATCH RFC v3 04/15] FSPool: defining the public API

[Olga Krishtal]

Provides public API for fspools and item management.

Signed-off-by: Nikolay Shirokovskiy 
Signed-off-by: Maxim Nestratov 
---
 docs/schemas/fsitem.rng  |  66 +++
 docs/schemas/fspool.rng  |  82 ++
 include/libvirt/libvirt-fs.h | 254 +++
 include/libvirt/libvirt.h|   1 +
 src/libvirt_public.syms  |  46 
 5 files changed, 449 insertions(+)
 create mode 100644 docs/schemas/fsitem.rng
 create mode 100644 docs/schemas/fspool.rng
 create mode 100644 include/libvirt/libvirt-fs.h

diff --git a/docs/schemas/fsitem.rng b/docs/schemas/fsitem.rng
new file mode 100644
index 000..d828978
--- /dev/null
+++ b/docs/schemas/fsitem.rng
@@ -0,0 +1,66 @@
+
+
+http://relaxng.org/ns/structure/1.0;
+datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes;>
+  
+  
+
+  
+
+  
+
+  
+
+dir
+
+  
+  
+
+  
+
+
+  
+
+  
+
+
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+
+
+  
+
+  
+
+  
+
+
diff --git a/docs/schemas/fspool.rng b/docs/schemas/fspool.rng
new file mode 100644
index 000..33ea0a2
--- /dev/null
+++ b/docs/schemas/fspool.rng
@@ -0,0 +1,82 @@
+
+
+http://relaxng.org/ns/structure/1.0;
+datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes;>
+  
+  
+
+  
+
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  dir
+
+
+  
+  
+  
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+  
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+
+  
+
+  
+
+  
+
+  
+  
+
+  
+
+
diff --git a/include/libvirt/libvirt-fs.h b/include/libvirt/libvirt-fs.h
new file mode 100644
index 000..1668000
--- /dev/null
+++ b/include/libvirt/libvirt-fs.h
@@ -0,0 +1,254 @@
+/* libvirt-fs.h
+ * Summary: APIs for management of filesystem pools and items
+ * Description: Provides APIs for the management of filesystem pools and items
+ * Author: Olga Krishtal 
+ *
+ * Copyright (C) 2016 Parallels IP Holdings GmbH
+ *
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ */
+
+#ifndef __VIR_LIBVIRT_FS_H__
+# define __VIR_LIBVIRT_FS_H__
+
+# ifndef __VIR_LIBVIRT_H_INCLUDES__
+#  error "Don't include this file directly, only use libvirt/libvirt.h"
+# endif
+
+typedef enum {
+VIR_FSPOOL_CREATE_NORMAL = 0,
+
+/* Create the fspool and perform fspool build using the
+ * exclusive to VIR_FSPOOL_CREATE_WITH_BUILD_NO_OVERWRITE */
+VIR_FSPOOL_CREATE_WITH_BUILD_OVERWRITE = 1 << 0,
+
+/* Create the pool and perform pool build using the
+ * VIR_FSPOOL_BUILD_NO_OVERWRITE flag. This is mutually
+ * exclusive to VIR_FSPOOL_CREATE_WITH_BUILD_OVERWRITE */
+VIR_FSPOOL_CREATE_WITH_BUILD_NO_OVERWRITE = 1 << 1,
+} virFSPoolCreateFlags;
+
+typedef enum {
+VIR_FSPOOL_BUILD_NO_OVERWRITE = (1 << 2),  /* Do not overwrite existing 
pool */
+VIR_FSPOOL_BUILD_OVERWRITE = (1 << 3),  /* Overwrite data */
+} virFSPoolBuildFlags;
+
+/**
+ * virFSPool:
+ *
+ * a virFSPool is a private structure representing a fspool
+ */
+typedef struct _virPoolCommon virFSPool;
+
+/**
+ * virFSPoolPtr:
+ *
+ * a virFSPoolPtr is pointer to a virFSPool private structure, this is the
+ * type used to reference a fspool in the API.
+ */
+typedef virFSPool *virFSPoolPtr;
+
+typedef enum {
+VIR_FSPOOL_INACTIVE = 0,
+VIR_FSPOOL_BUILDING = 1,
+VIR_FSPOOL_RUNNING = 2,
+
+# ifdef VIR_ENUM_SENTINELS
+VIR_FSPOOL_STATE_LAST
+# endif
+} virFSPoolState;
+
+typedef struct _virFSPoolInfo virFSPoolInfo;
+
+struct _virFSPoolInfo {
+int state; /* virFSPoolState flags */
+unsigned long long capacity;   /* Logical size bytes */
+unsigned long long allocation; /* Current allocation bytes */
+unsigned long long available;  /* Remaining free space bytes */
+};
+
+typedef 

[libvirt] [PATCH RFC v3 03/15] storage pools: refactoring of fs backend

[Olga Krishtal]

The fs backend for storage pools works a lot with
directories and etc. The same is true for filesystem pools with
directory backend. In order to avoid rewriting the same code once again
patch moves this code to virpoolcommon.c.

Signed-off-by: Olga Krishtal 
---
 po/POTFILES.in   |  1 +
 src/libvirt_private.syms |  3 ++
 src/storage/storage_backend.h|  1 -
 src/storage/storage_backend_fs.c | 74 +++---
 src/util/virpoolcommon.c | 87 
 src/util/virpoolcommon.h |  7 
 6 files changed, 104 insertions(+), 69 deletions(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 1469240..29bc45c 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -229,6 +229,7 @@ src/util/virpci.c
 src/util/virperf.c
 src/util/virpidfile.c
 src/util/virpolkit.c
+src/util/virpoolcommon.c
 src/util/virportallocator.c
 src/util/virprocess.c
 src/util/virqemu.c
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index a061799..67ebe2a 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2709,6 +2709,9 @@ virStoragePoolSourceFree;
 virStoragePoolSourceDeviceClear;
 virStoragePoolSourceClear;
 virStoragePoolSourceListNewSource;
+virDirPoolDelete;
+virDirItemCreate;
+virDirPoolBuild;
 
 # Let emacs know we want case-insensitive sorting
 # Local Variables:
diff --git a/src/storage/storage_backend.h b/src/storage/storage_backend.h
index 28e1a65..a08a725 100644
--- a/src/storage/storage_backend.h
+++ b/src/storage/storage_backend.h
@@ -214,7 +214,6 @@ int virStorageBackendVolOpen(const char *path, struct stat 
*sb,
 ATTRIBUTE_RETURN_CHECK
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
 
-# define VIR_STORAGE_DEFAULT_POOL_PERM_MODE 0755
 # define VIR_STORAGE_DEFAULT_VOL_PERM_MODE  0600
 
 int virStorageBackendUpdateVolInfo(virStorageVolDefPtr vol,
diff --git a/src/storage/storage_backend_fs.c b/src/storage/storage_backend_fs.c
index 6c8bae2..c21fbc8 100644
--- a/src/storage/storage_backend_fs.c
+++ b/src/storage/storage_backend_fs.c
@@ -45,6 +45,7 @@
 #include "storage_backend_fs.h"
 #include "storage_conf.h"
 #include "virstoragefile.h"
+#include "virpoolcommon.h"
 #include "vircommand.h"
 #include "viralloc.h"
 #include "virxml.h"
@@ -809,11 +810,7 @@ virStorageBackendFileSystemBuild(virConnectPtr conn 
ATTRIBUTE_UNUSED,
  unsigned int flags)
 {
 int ret = -1;
-char *parent = NULL;
-char *p = NULL;
-mode_t mode;
 bool needs_create_as_uid;
-unsigned int dir_create_flags;
 
 virCheckFlags(VIR_STORAGE_POOL_BUILD_OVERWRITE |
   VIR_STORAGE_POOL_BUILD_NO_OVERWRITE, ret);
@@ -822,45 +819,9 @@ virStorageBackendFileSystemBuild(virConnectPtr conn 
ATTRIBUTE_UNUSED,
  VIR_STORAGE_POOL_BUILD_NO_OVERWRITE,
  error);
 
-if (VIR_STRDUP(parent, pool->def->target.path) < 0)
-goto error;
-if (!(p = strrchr(parent, '/'))) {
-virReportError(VIR_ERR_INVALID_ARG,
-   _("path '%s' is not absolute"),
-   pool->def->target.path);
-goto error;
-}
-
-if (p != parent) {
-/* assure all directories in the path prior to the final dir
- * exist, with default uid/gid/mode. */
-*p = '\0';
-if (virFileMakePath(parent) < 0) {
-virReportSystemError(errno, _("cannot create path '%s'"),
- parent);
-goto error;
-}
-}
-
-dir_create_flags = VIR_DIR_CREATE_ALLOW_EXIST;
 needs_create_as_uid = (pool->def->type == VIR_STORAGE_POOL_NETFS);
-mode = pool->def->target.perms.mode;
-
-if (mode == (mode_t) -1 &&
-(needs_create_as_uid || !virFileExists(pool->def->target.path)))
-mode = VIR_STORAGE_DEFAULT_POOL_PERM_MODE;
-if (needs_create_as_uid)
-dir_create_flags |= VIR_DIR_CREATE_AS_UID;
-
-/* Now create the final dir in the path with the uid/gid/mode
- * requested in the config. If the dir already exists, just set
- * the perms. */
-if (virDirCreate(pool->def->target.path,
- mode,
- pool->def->target.perms.uid,
- pool->def->target.perms.gid,
- dir_create_flags) < 0)
-goto error;
+if (virDirPoolBuild(pool->def, needs_create_as_uid) < 0)
+return ret;
 
 if (flags != 0) {
 ret = virStorageBackendMakeFileSystem(pool, flags);
@@ -869,7 +830,6 @@ virStorageBackendFileSystemBuild(virConnectPtr conn 
ATTRIBUTE_UNUSED,
 }
 
  error:
-VIR_FREE(parent);
 return ret;
 }
 
@@ -1054,14 +1014,8 @@ virStorageBackendFileSystemDelete(virConnectPtr conn 
ATTRIBUTE_UNUSED,
 
 /* XXX delete all vols first ? */
 
-if (rmdir(pool->def->target.path) < 0) {
-virReportSystemError(errno,
- _("failed to remove 

[libvirt] [PATCH RFC v3 00/15] FSPool: backend directory

[Olga Krishtal]

Hi everyone, we would like to propose the first implementation of fspool
with directory backend according to previous discussions:

https://www.redhat.com/archives/libvir-list/2016-April/msg01941.html
https://www.redhat.com/archives/libvir-list/2016-May/msg00208.html
https://www.redhat.com/archives/libvir-list/2016-September/msg00463.html

Filesystem pools is a facility to manage filesystems resources similar
to how storage pools manages volume resources.The manageble unit is a  single
filesystem, so fspool items have only one type - dir (storage pools can manage 
files,
block devices, etc). However, backends for fspools can be different.
This series introduses the simplest backend - host directory.

API mostly follows storage pool API: we can create fspool, build it,
populate with items.  Moreover, to create filesystem pool  we need
some storage. So, all structures to describe storage that will hold
fspool is borrowed from storage pool ones. The same is true for functions
that work with them.

As it was mentioned before -  here we present directory backend for fspool.
To mangae fspools and items we tried to use  as much functionality from storage 
pool
(directory and fs backend) as possible.

The first 3 patches  - is preparational refactoring. Both storage pool and 
fspool
reside upon some storage, so there is a good chance to use the same code for
describing storage source and functions that work with it. All reusable code is 
moved
virpoolcommon.c/.h  It would be great if you share you thoughts about such 
changes.
Because what we trying to achive - is to have less copy/paste and  to have
separate drivers for storage pools and filesystem pools.

All other patches is devoted to  fspool implementation and is presented 
according
libvirt recommendations.

Uploading/downloading operations
are not defined yet as it is not obvious how to make it properly. I guess
we can use some kind of tar to make a stream from a filesystem. Please share
you thoughts on this particular issue.


v2:
- renamed Fs to FS
- in configure.ac script macro m4 is used
- updates docs
- created simple tests
- updated virsh.pod
- added information abot fspool in fotmatfs.html

v3:
- in this version storage pool code is reused
- resplitted patches
- fixed some errors


Olga Krishtal (15):
  storage pools: refactoring of basic structs
  storage pools: functions refactoring
  storage pools: refactoring of fs backend
  FSPool: defining the public API
  FSPool: defining the internal API
  FSpool: implementing the public API
  FSPool: added access control objects and permissions
  FSPool: added --with-fs compilation option
  FSPool: implementation of remote protocol
  FSPool: added configuration description
  virsh: filesystem pools commands
  FSPool: empty implementation of driver methods
  FSPool: driver methods implementation
  FSPool: directory backend inplementation
  FSPool: Tests and documentation

 configure.ac   |6 +
 daemon/Makefile.am |4 +
 daemon/libvirtd.c  |9 +
 daemon/remote.c|   35 +
 docs/formatfs.html.in  |  206 ++
 docs/fspool.html.in|   41 +
 docs/schemas/fsitem.rng|   66 +
 docs/schemas/fspool.rng|   82 +
 docs/sitemap.html.in   |4 +
 include/libvirt/libvirt-fs.h   |  254 +++
 include/libvirt/libvirt-storage.h  |5 +-
 include/libvirt/libvirt.h  |1 +
 include/libvirt/virterror.h|7 +
 m4/virt-driver-fspool.m4   |   43 +
 po/POTFILES.in |7 +
 src/Makefile.am|   59 +-
 src/access/viraccessdriver.h   |   15 +
 src/access/viraccessdrivernop.c|   21 +
 src/access/viraccessdriverpolkit.c |   47 +
 src/access/viraccessdriverstack.c  |   50 +
 src/access/viraccessmanager.c  |   32 +
 src/access/viraccessmanager.h  |   11 +-
 src/access/viraccessperm.c |   15 +-
 src/access/viraccessperm.h |  126 ++
 src/check-driverimpls.pl   |2 +
 src/conf/fs_conf.c | 1479 ++
 src/conf/fs_conf.h |  262 +++
 src/conf/storage_conf.c|  162 --
 src/conf/storage_conf.h|  137 +-
 src/datatypes.c|  150 ++
 src/datatypes.h|   60 +-
 src/driver-fs.h|  193 ++
 src/driver.h   |3 +
 src/fs/fs_backend.h

[libvirt] [PATCH RFC v3 08/15] FSPool: added --with-fs compilation option

[Olga Krishtal]

In order to use fspool use --with-fs configuration option.
It is is turned off by default.

Signed-off-by: Olga Krishtal 
---
 configure.ac |  6 ++
 m4/virt-driver-fspool.m4 | 33 +
 2 files changed, 39 insertions(+)
 create mode 100644 m4/virt-driver-fspool.m4

diff --git a/configure.ac b/configure.ac
index 9e26b8c..2f9b78d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1074,6 +1074,11 @@ dnl
 
 LIBVIRT_DRIVER_CHECK_BHYVE
 
+dnl
+dnl Checks for FSPOOL driver
+dnl
+
+LIBVIRT_DRIVER_CHECK_FSPOOL
 
 dnl
 dnl check for kernel headers required by src/bridge.c
@@ -2636,6 +2641,7 @@ AC_MSG_NOTICE([  ESX: $with_esx])
 AC_MSG_NOTICE([  Hyper-V: $with_hyperv])
 LIBVIRT_DRIVER_RESULT_VZ
 LIBVIRT_DRIVER_RESULT_BHYVE
+LIBVIRT_DRIVER_RESULT_FSPOOL
 AC_MSG_NOTICE([ Test: $with_test])
 AC_MSG_NOTICE([   Remote: $with_remote])
 AC_MSG_NOTICE([  Network: $with_network])
diff --git a/m4/virt-driver-fspool.m4 b/m4/virt-driver-fspool.m4
new file mode 100644
index 000..634cb7f
--- /dev/null
+++ b/m4/virt-driver-fspool.m4
@@ -0,0 +1,33 @@
+dnl The FSPool driver checks
+dnl
+dnl This library is free software; you can redistribute it and/or
+dnl modify it under the terms of the GNU Lesser General Public
+dnl License as published by the Free Software Foundation; either
+dnl version 2.1 of the License, or (at your option) any later version.
+dnl
+dnl This library is distributed in the hope that it will be useful,
+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+dnl Lesser General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU Lesser General Public
+dnl License along with this library.  If not, see
+dnl .
+dnl
+
+AC_DEFUN([LIBVIRT_DRIVER_CHECK_FSPOOL],[
+AC_ARG_WITH([fs],
+ [AS_HELP_STRING([--with-fs],
+   [add FS driver  @<:@default=check@:>@])])
+m4_divert_text([DEFAULTS], [with_fs=check])
+
+if test "$with_fs" = "yes"; then
+AC_DEFINE_UNQUOTED([WITH_FS], 1,
+   [whether fs driver is enabled])
+fi
+AM_CONDITIONAL([WITH_FS], [test "$with_fs" = "yes"])
+])
+
+AC_DEFUN([LIBVIRT_DRIVER_RESULT_FSPOOL],[
+AC_MSG_NOTICE([   FSPool: $with_fs])
+])
-- 
1.8.3.1

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

[libvirt] [PATCH for-2.9 14/17] qapi: add static/migration-safe info to query-cpu-model-expansion

[Eduardo Habkost]

On x86, "-cpu host" enables some features that can't be
represented by a static CPU model definition: cache info
passthrough ("host-cache-info") and PMU passthrough ("pmu"). This
means a type=static expansion of "host" can't include those
features.

A type=full expansion of "host", on the other hand, can include
those features, but then the returned data won't be a static CPU
model representation.

Add a note to the documentation explaining that when using CPU
models that include non-migration-safe features, users need to
choose being precision and safety: a precise expansion of the CPU
model (full) won't be safe (static), (because they would include
pmu=on and host-cache-info=on), and a safe (static) expansion of
the CPU model won't be precise.

Architectures where CPU model expansion is always migration-safe
(e.g. s390x) can simply do what they already do, and set
'migration-safe' and 'static' to true.

Cc: Cornelia Huck 
Cc: Christian Borntraeger 
Cc: David Hildenbrand 
Cc: libvir-list@redhat.com
Cc: Jiri Denemark 
Cc: "Jason J. Herne" 
Cc: Markus Armbruster 
Cc: Eric Blake 
Signed-off-by: Eduardo Habkost 
---
 qapi-schema.json  | 25 -
 target-s390x/cpu_models.c |  4 
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 8d113f8..a102534 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3291,6 +3291,15 @@
 #migration-safe, but allows tooling to get an insight and work with
 #model details.
 #
+# Note: When a non-migration-safe CPU model is expanded in static mode, some
+# features enabled by the CPU model may be omitted, because they can't be
+# implemented by a static CPU model definition (e.g. cache info passthrough and
+# PMU passthrough in x86). If you need an accurate representation of the
+# features enabled by a non-migration-safe CPU model, use @full. If you need a
+# static representation that will keep ABI compatibility even when changing 
QEMU
+# version or machine-type, use @static (but keep in mind that some features may
+# be omitted).
+#
 # Since: 2.8.0
 ##
 { 'enum': 'CpuModelExpansionType',
@@ -3304,10 +3313,24 @@
 #
 # @model: the expanded CpuModelInfo.
 #
+# @migration-safe: the expanded CPU model in @model is a migration-safe
+#  CPU model. See @CpuDefinitionInfo.migration-safe.
+#  If expansion type was @static, this is always true.
+#  (since 2.9)
+#
+# @static: the expanded CPU model in @model is a static CPU model.
+#  See @CpuDefinitionInfo.static. If expansion type was @static,
+#  this is always true.
+#  (since 2.9)
+#
+# query-cpu-model-expansion with static expansion type should always
+# return a static and migration-safe expansion.
+#
 # Since: 2.8.0
 ##
 { 'struct': 'CpuModelExpansionInfo',
-  'data': { 'model': 'CpuModelInfo' } }
+  'data': { 'model': 'CpuModelInfo', 'static': 'bool',
+'migration-safe': 'bool' } }
 
 
 ##
diff --git a/target-s390x/cpu_models.c b/target-s390x/cpu_models.c
index 5b66d33..f934add 100644
--- a/target-s390x/cpu_models.c
+++ b/target-s390x/cpu_models.c
@@ -448,6 +448,10 @@ CpuModelExpansionInfo 
*arch_query_cpu_model_expansion(CpuModelExpansionType type
 /* convert it back to a static representation */
 expansion_info = g_malloc0(sizeof(*expansion_info));
 expansion_info->model = g_malloc0(sizeof(*expansion_info->model));
+
+/* We always expand to a static and migration-safe CpuModelInfo */
+expansion_info->q_static = true;
+expansion_info->migration_safe = true;
 cpu_info_from_model(expansion_info->model, _model, delta_changes);
 return expansion_info;
 }
-- 
2.7.4

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

[libvirt] [PATCH for-2.9 17/17] target-i386: Implement query-cpu-model-expansion QMP command

[Eduardo Habkost]

Implement query-cpu-model-expansion for target-i386.

The code needs to be careful to handle non-migration-safe
features ("pmu" and "host-cache-info") according to the expansion
type.

Cc: libvir-list@redhat.com
Cc: Jiri Denemark 
Signed-off-by: Eduardo Habkost 
---
 tests/Makefile.include |   3 +
 monitor.c  |   4 +-
 target-i386/cpu.c  | 195 -
 3 files changed, 200 insertions(+), 2 deletions(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 63c4347..c7bbfca 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -251,6 +251,9 @@ check-qtest-x86_64-y += $(check-qtest-i386-y)
 gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
 gcov-files-x86_64-y = $(subst 
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
 
+check-simpleqtest-x86_64-y += $(SRC_PATH)/tests/query-cpu-model-test.py
+check-simpleqtest-i386-y += $(SRC_PATH)/tests/query-cpu-model-test.py
+
 check-qtest-alpha-y = tests/boot-serial-test$(EXESUF)
 
 check-qtest-mips-y = tests/endianness-test$(EXESUF)
diff --git a/monitor.c b/monitor.c
index 0841d43..90c12b3 100644
--- a/monitor.c
+++ b/monitor.c
@@ -983,8 +983,10 @@ static void qmp_unregister_commands_hack(void)
 #ifndef TARGET_ARM
 qmp_unregister_command("query-gic-capabilities");
 #endif
-#if !defined(TARGET_S390X)
+#if !defined(TARGET_S390X) && !defined(TARGET_I386)
 qmp_unregister_command("query-cpu-model-expansion");
+#endif
+#if !defined(TARGET_S390X)
 qmp_unregister_command("query-cpu-model-baseline");
 qmp_unregister_command("query-cpu-model-comparison");
 #endif
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index bf4ac09..198014a 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -29,10 +29,14 @@
 #include "qemu/option.h"
 #include "qemu/config-file.h"
 #include "qapi/qmp/qerror.h"
+#include "qapi/qmp/qstring.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qbool.h"
 
 #include "qapi-types.h"
 #include "qapi-visit.h"
 #include "qapi/visitor.h"
+#include "qom/qom-qobject.h"
 #include "sysemu/arch_init.h"
 
 #if defined(CONFIG_KVM)
@@ -2259,7 +2263,7 @@ static void x86_cpu_apply_props(X86CPU *cpu, PropValue 
*props)
 }
 }
 
-/* Load data from X86CPUDefinition
+/* Load data from X86CPUDefinition into a X86CPU object
  */
 static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
 {
@@ -2268,6 +2272,11 @@ static void x86_cpu_load_def(X86CPU *cpu, 
X86CPUDefinition *def, Error **errp)
 char host_vendor[CPUID_VENDOR_SZ + 1];
 FeatureWord w;
 
+/*NOTE: any property set by this function should be returned by
+ * x86_cpu_to_dict(), so CPU model data returned by
+ * query-cpu-model-expansion is always complete.
+ */
+
 /* CPU models only set _minimum_ values for level/xlevel: */
 object_property_set_int(OBJECT(cpu), def->level, "min-level", errp);
 object_property_set_int(OBJECT(cpu), def->xlevel, "min-xlevel", errp);
@@ -2312,6 +2321,190 @@ static void x86_cpu_load_def(X86CPU *cpu, 
X86CPUDefinition *def, Error **errp)
 
 }
 
+/* Convert CPU model data from X86CPU object to a property dictionary
+ * that can recreate exactly the same CPU model.
+ *
+ * This function does the opposite of x86_cpu_load_def(). Any
+ * property changed by x86_cpu_load_def() or instance_init
+ * methods should be returned by this function too.
+ */
+static void x86_cpu_to_dict(X86CPU *cpu, QDict *props, Error **errp)
+{
+Object *obj = OBJECT(cpu);
+FeatureWord w;
+PropValue *pv;
+
+/* This code could simply iterate over all writeable properties in the
+ * CPU object, and return all of them. But then the aliases properties
+ * would be returned as well. Returning only the known features
+ * is more reliable.
+ */
+qdict_put_obj(props, "min-level",
+  object_property_get_qobject(obj, "min-level", errp));
+qdict_put_obj(props, "min-xlevel",
+  object_property_get_qobject(obj, "min-xlevel", errp));
+
+qdict_put_obj(props, "family",
+  object_property_get_qobject(obj, "family", errp));
+qdict_put_obj(props, "model",
+  object_property_get_qobject(obj, "model", errp));
+qdict_put_obj(props, "stepping",
+  object_property_get_qobject(obj, "stepping", errp));
+qdict_put_obj(props, "model-id",
+  object_property_get_qobject(obj, "model-id", errp));
+
+for (w = 0; w < FEATURE_WORDS; w++) {
+FeatureWordInfo *fi = _word_info[w];
+int bit;
+for (bit = 0; bit < 32; bit++) {
+if (!fi->feat_names[bit]) {
+continue;
+}
+qdict_put_obj(props, fi->feat_names[bit],
+  object_property_get_qobject(obj, fi->feat_names[bit],
+  errp));
+}
+}
+
+for (pv = kvm_default_props; pv->prop; pv++) {

[libvirt] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion

[Eduardo Habkost]

This series implements query-cpu-model-expansion on target-i386.

QAPI / interface changes


When implementing this, I have noticed that the "host" CPU model
in i386 includes some migration-unsafe features that can't be
translated to any migration-safe representation: "pmu", and
"host-cache-info".

To be able to handle the migration-unsafe features, I have
extended the query-cpu-model-expansion definition to be clear
about what happens to those features when the CPU model is
expanded (in short: static expansion removes them, full expansion
keeps them).

I also added "static" and "migration-safe" fields to the return
value of query-cpu-model-expansion, so callers can know if the
the expanded representation is static and migration-safe.

Test code
-

I have added a Python test script for the feature, that will try
multiple combinations of the expansion operation, and see if the
returned data keeps matches some constratins.

The test script works with the s390x query-cpu-model-expansion
command, except that: 1) I couldn't test it with KVM; 2) qtest.py
error handling when QEMU refuses to run is unreliable (so the
script needs runnability information to be availble in TCG mode,
too, to skip not-runnable CPU models and avoid problems).

Future versions of the test script could run a arch-specific
CPUID-dump guest binary, and validate data seen by the guest
directly. While we don't do that, the script validates all QOM
properties on the CPU objects looking for unexpected changes. At
least in the case of x86, the QOM properties will include lots of
the CPUID data seen by the guest, giving us decent coverage.

Patches from other series
-

This series includes patches from other series, just to help on
the implementation of the test code:
* "qmp: Report QOM type name on query-cpu-definitions", that
  was already submitted for 2.9
* qemu.py, qtest.py, and tests/Makefile.include changes

---
Cc: Cornelia Huck 
Cc: Christian Borntraeger 
Cc: David Hildenbrand 
Cc: libvir-list@redhat.com
Cc: Jiri Denemark 
Cc: "Jason J. Herne" 
Cc: Markus Armbruster 
Cc: Richard Henderson 
Cc: Igor Mammedov 
Cc: Eric Blake 

Eduardo Habkost (17):
  qmp: Report QOM type name on query-cpu-definitions
  qemu.py: Make logging optional
  qtest.py: Support QTEST_LOG environment variable
  qtest.py: make logging optional
  qtest.py: Make 'binary' parameter optional
  tests: Add rules to non-gtester qtest test cases
  target-i386: Reorganize and document CPUID initialization steps
  target-i386: Support "-cpu host" on TCG too
  target-i386: Move "host" properties to base class
  target-i386: Allow short strings to be used as vendor ID
  target-i386: Remove AMD feature flag aliases from Opteron models
  target-i386: Return migration-safe field on query-cpu-definitions
  cpu: Support comma escaping when parsing -cpu
  qapi: add static/migration-safe info to query-cpu-model-expansion
  target-i386: Define static "base" CPU model
  tests: query-cpu-model-test.py test code
  target-i386: Implement query-cpu-model-expansion QMP command

 qapi-schema.json  |  30 ++-
 scripts/qemu.py   |  25 ++-
 scripts/qtest.py  |  15 +-
 target-i386/cpu-qom.h |   8 +-
 tests/Makefile.include|  40 +++-
 tests/query-cpu-model-test.py | 421 
 tests/test-x86-cpuid-compat.c |  19 ++
 monitor.c |   4 +-
 qom/cpu.c |  32 ++-
 target-arm/helper.c   |   1 +
 target-i386/cpu.c | 481 +++---
 target-ppc/translate_init.c   |   1 +
 target-s390x/cpu_models.c |   5 +
 13 files changed, 928 insertions(+), 154 deletions(-)
 create mode 100755 tests/query-cpu-model-test.py

-- 
2.7.4

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

[libvirt] [PATCH] storage: Fix type PLOOP type check for storageVolUpload

[John Ferlan]

Commit id '03e750f3' added support for checking the PLOOP type; however,
it used 'target.type' which no storage code ever fills in, so it will
never be set.  Change to just vol->type (could use vol->target.format
as well).

Signed-off-by: John Ferlan 
---

 Found this by chance while digging through the code to investigate
 something else. Turns out the storage/volume code does not fill in
 the target.type field.

 src/storage/storage_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index df65807..a79acc6 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -2427,7 +2427,7 @@ storageVolUpload(virStorageVolPtr obj,
 if (VIR_ALLOC(cbdata) < 0 ||
 VIR_STRDUP(cbdata->pool_name, pool->def->name) < 0)
 goto cleanup;
-if (vol->target.type == VIR_STORAGE_VOL_PLOOP &&
+if (vol->type == VIR_STORAGE_VOL_PLOOP &&
 VIR_STRDUP(cbdata->vol_path, vol->target.path) < 0)
 goto cleanup;
 
-- 
2.7.4

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

Re: [libvirt] [PATCH 0/7] Adjustments for storage/qemu volume/file backing size settings

[Michal Privoznik]

On 02.12.2016 01:39, John Ferlan wrote:
> A bit of a mix between fixing some bugs and merging some code between
> the block info/stats fetching of backing store data and storage backend
> data for volume allocation, capacity, and physical sizes.
> 
> Patch 1 just adjusts some comments
> 
> Patches 2-3 are code motion
> 
> Patch 4 alters how domain/qemu will open the backing store from an open
> to a qemuFileOpen and it allows for fetching of more physical sizes (the
> code only gets the block backing stores now)
> 
> Patch 5 shares the setting of the various size values between storage driver
> and domain/qemu
> 
> Patch 6 shares the recalculation of the capacity value (it may not be 
> necessary
> for patch 5, but I left it there since there's multiple other paths to the
> VolTargetInfoFD API).
> 
> Patch 7 fixes an issue with displaying the allocation value of a qcow2 backed
> file for the GetBlockInfo API (the results will match volume code now).
> 
> 
> John Ferlan (7):
>   qemu: Clean up description for qemuStorageLimitsRefresh
>   qemu: Add helpers to handle stat data for qemuStorageLimitsRefresh
>   qemu: Introduce helper qemuDomainStorageUpdatePhysical
>   util: Introduce virStorageSourceUpdatePhysicalSize
>   util: Introduce virStorageSourceUpdateBackingSizes
>   util: Introduce virStorageSourceUpdateCapacity
>   qemu: Fix GetBlockInfo setting allocation from wr_highest_offset
> 
>  src/libvirt_private.syms  |   5 +-
>  src/qemu/qemu_driver.c| 237 
> --
>  src/storage/storage_backend.c |  41 +---
>  src/util/virstoragefile.c | 173 ++
>  src/util/virstoragefile.h |  15 ++-
>  5 files changed, 304 insertions(+), 167 deletions(-)
> 

ACK but I suggest postponing the push after the release.

Michal

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

[libvirt] [PATCH RFC v3 15/15] FSPool: Tests and documentation

[Olga Krishtal]

Patch adds general documentation for fspool and
tests for directory backend.

Signed-off-by: Olga Krishtal 
---
 docs/formatfs.html.in  | 206 +
 docs/fspool.html.in|  41 
 docs/sitemap.html.in   |   4 +
 tests/Makefile.am  |  12 ++
 tests/fsitemxml2xmlin/item.xml |  13 ++
 tests/fsitemxml2xmlout/item.xml|  13 ++
 tests/fsitemxml2xmltest.c  | 105 +++
 .../dir-missing-target-path-invalid.xml|  12 ++
 tests/fspoolxml2xmlin/fspool-dir.xml   |  16 ++
 tests/fspoolxml2xmlout/fspool-dir.xml  |  16 ++
 tests/fspoolxml2xmltest.c  |  81 
 11 files changed, 519 insertions(+)
 create mode 100644 docs/formatfs.html.in
 create mode 100644 docs/fspool.html.in
 create mode 100644 tests/fsitemxml2xmlin/item.xml
 create mode 100644 tests/fsitemxml2xmlout/item.xml
 create mode 100644 tests/fsitemxml2xmltest.c
 create mode 100644 tests/fspoolschemadata/dir-missing-target-path-invalid.xml
 create mode 100644 tests/fspoolxml2xmlin/fspool-dir.xml
 create mode 100644 tests/fspoolxml2xmlout/fspool-dir.xml
 create mode 100644 tests/fspoolxml2xmltest.c

diff --git a/docs/formatfs.html.in b/docs/formatfs.html.in
new file mode 100644
index 000..b50034c
--- /dev/null
+++ b/docs/formatfs.html.in
@@ -0,0 +1,206 @@
+
+http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
+http://www.w3.org/1999/xhtml;>
+  
+Filesystem pool and item XML format
+
+
+
+Filesystem pool XML
+
+
+  Filesystem pools is a facility to manage filesystems. They has a lot in 
common with
+  storage pools (nearly the same api and way of managment). However the 
managment units
+  are completely different. To avoid the misunderstanding in fspool usage 
use this XML
+  description. See fspool driver page
+
+
+
+  The root element is named fspool. It has attribute 
type,
+  at the moment fspool has only one type dir. It represents 
fspool that
+  holds filesystems in subdirectories on a host filesystem.
+
+
+General metadata
+
+
+  fspool type="dir"
+namevirfs/name
+uuid4584ee21-db40-4e98-980e-44802c47b62f/uuid
+allocation1000/allocation
+capacity5000/capacity
+available4000/available
+...
+
+
+  name
+  Providing a name for the fspool which is unique to the host.
+This is mandatory when defining a filesystem pool.
+  uuid
+  Providing an identifier for the fspool which is globally unique.
+This is optional when defining a fspool, a UUID will be generated if
+omitted.
+  allocation
+  Providing the total storage allocation for the pool. This value is 
in bytes.
+This is not applicable when creating a fspool.
+  capacity
+  Providing the total capacity for the fspool. This value is in bytes. 
This
+is not applicable when creating a fspool.
+  available
+  Providing the free space available for allocating new items
+in the fspool. This value is in bytes. This is not applicable when 
creating a
+fspool.
+
+
+Source elements
+
+
+  A single source element is contained within the top level
+  fspool element. This tag is used to describe the source of
+  the fspool. At the moment it is left empty.
+
+
+Target elements
+
+
+  A single target element is contained within the top level
+  fspool element for all types of fspools (fspool types 
dir).
+  This tag is used to describe the mapping of fspool into the host 
filesystem.
+  It can contain the following child elements:
+
+
+
+...
+target
+  path/path/in/host/fs/path
+  permissions
+owner107/owner
+group107/group
+mode0744/mode
+  /permissions
+/target
+  /fspool
+
+
+  path
+  Provides the location at which the fspool will be mapped into
+the local filesystem namespace, as an absolute path. For a fspool with 
directory
+backend  it will be a fully qualified name of the directory in which 
items
+will be created.
+  
+  permissions
+ It provides information about the permissions to use for the
+final directory when the fspool is built. There are 4 child elements.
+The mode element contains the octal permission set.
+The mode defaults to 0755 when not provided.
+The owner element contains the numeric user ID.
+The group element contains the numeric group ID.
+If owner or group aren't specified when
+creating a directory, the values are inherited from the parent
+directory.
+  
+
+
+Item XML
+
+  An item is a directory 

[libvirt] [PATCH RFC v3 05/15] FSPool: defining the internal API

[Olga Krishtal]

This patch introduces new filesystem pool driver.

Signed-off-by: Olga Krishtal 
---
 src/driver-fs.h | 193 
 src/driver.h|   1 +
 2 files changed, 194 insertions(+)
 create mode 100644 src/driver-fs.h

diff --git a/src/driver-fs.h b/src/driver-fs.h
new file mode 100644
index 000..ba35ec2
--- /dev/null
+++ b/src/driver-fs.h
@@ -0,0 +1,193 @@
+/*
+* driver-fs.h: entry points for fs drivers
+* Author: Olga Krishtal 
+*
+* Copyright (C) 2016 Parallels IP Holdings GmbH
+*
+* This library is free software; you can redistribute it and/or
+* modify it under the terms of the GNU Lesser General Public
+* License as published by the Free Software Foundation; either
+* version 2.1 of the License, or (at your option) any later version.
+*
+* This library is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this library.  If not, see
+* .
+*/
+
+#ifndef __VIR_DRIVER_FS_H__
+# define __VIR_DRIVER_FS_H__
+
+# ifndef __VIR_DRIVER_H_INCLUDES___
+#  error "Don't include this file directly, only use driver.h"
+# endif
+
+typedef int
+(*virDrvConnectListAllFSPools)(virConnectPtr conn,
+   virFSPoolPtr **pools,
+   unsigned int flags);
+
+typedef virFSPoolPtr
+(*virDrvFSPoolLookupByName)(virConnectPtr conn,
+const char *name);
+
+typedef virFSPoolPtr
+(*virDrvFSPoolLookupByUUID)(virConnectPtr conn,
+const unsigned char *uuid);
+
+typedef virFSPoolPtr
+(*virDrvFSPoolLookupByItem)(virFSItemPtr item);
+
+typedef virFSPoolPtr
+(*virDrvFSPoolCreateXML)(virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags);
+
+typedef virFSPoolPtr
+(*virDrvFSPoolDefineXML)(virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags);
+
+typedef int
+(*virDrvFSPoolUndefine)(virFSPoolPtr fspool);
+
+typedef int
+(*virDrvFSPoolBuild)(virFSPoolPtr fspool,
+ unsigned int flags);
+
+typedef int
+(*virDrvFSPoolCreate)(virFSPoolPtr fspool,
+  unsigned int flags);
+typedef int
+(*virDrvFSPoolDestroy)(virFSPoolPtr fspool);
+typedef int
+(*virDrvFSPoolRefresh)(virFSPoolPtr fspool,
+   unsigned int flags);
+
+typedef int
+(*virDrvFSPoolDelete)(virFSPoolPtr fspool,
+  unsigned int flags);
+
+typedef int
+(*virDrvFSPoolGetInfo)(virFSPoolPtr fspool,
+   virFSPoolInfoPtr info);
+
+typedef char *
+(*virDrvFSPoolGetXMLDesc)(virFSPoolPtr fspool,
+  unsigned int flags);
+typedef int
+(*virDrvFSPoolGetAutostart)(virFSPoolPtr fspool,
+int *autostart);
+typedef int
+(*virDrvFSPoolSetAutostart)(virFSPoolPtr fspool,
+int autostart);
+
+typedef int
+(*virDrvFSPoolNumOfItems)(virFSPoolPtr fspool);
+
+typedef int
+(*virDrvFSPoolListItems)(virFSPoolPtr fspool,
+ char **const names,
+ int maxnames);
+
+typedef int
+(*virDrvFSPoolListAllItems)(virFSPoolPtr fspool,
+virFSItemPtr **items,
+unsigned int flags);
+
+typedef virFSItemPtr
+(*virDrvFSItemLookupByName)(virFSPoolPtr fspool,
+const char *name);
+
+typedef virFSItemPtr
+(*virDrvFSItemLookupByKey)(virConnectPtr fspool,
+   const char *key);
+
+typedef virFSItemPtr
+(*virDrvFSItemLookupByPath)(virConnectPtr fspool,
+const char *path);
+
+typedef virFSItemPtr
+(*virDrvFSItemCreateXML)(virFSPoolPtr fspool,
+ const char *xmldesc,
+ unsigned int flags);
+
+typedef int
+(*virDrvFSItemDelete)(virFSItemPtr item,
+  unsigned int flags);
+
+
+typedef int
+(*virDrvFSItemGetInfo)(virFSItemPtr item,
+   virFSItemInfoPtr info);
+
+typedef char *
+(*virDrvFSItemGetXMLDesc)(virFSItemPtr fspool,
+  unsigned int flags);
+
+typedef char *
+(*virDrvFSItemGetPath)(virFSItemPtr item);
+
+typedef virFSItemPtr
+(*virDrvFSItemCreateXMLFrom)(virFSPoolPtr fspool,
+ const char *xmldesc,
+ virFSItemPtr cloneitem,
+ unsigned int flags);
+
+typedef struct _virFSDriver virFSDriver;
+typedef virFSDriver *virFSDriverPtr;
+
+typedef int
+(*virDrvFSPoolIsActive)(virFSPoolPtr fspool);
+
+typedef int
+(*virDrvFSPoolIsPersistent)(virFSPoolPtr fspool);
+
+
+
+/**
+ * _virFSDriver:
+ 

[libvirt] [PATCH RFC v3 12/15] FSPool: empty implementation of driver methods

[Olga Krishtal]

Signed-off-by: Olga Krishtal 
---
 daemon/Makefile.am  |   4 +
 daemon/libvirtd.c   |   9 +
 po/POTFILES.in  |   1 +
 src/Makefile.am |  33 ++-
 src/fs/fs_backend.h |  94 +++
 src/fs/fs_driver.c  | 729 
 src/fs/fs_driver.h  |  10 +
 7 files changed, 879 insertions(+), 1 deletion(-)
 create mode 100644 src/fs/fs_backend.h
 create mode 100644 src/fs/fs_driver.c
 create mode 100644 src/fs/fs_driver.h

diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index 927d16f..5e95106 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -260,6 +260,10 @@ endif WITH_SECRETS
 if WITH_NWFILTER
 libvirtd_LDADD += ../src/libvirt_driver_nwfilter.la
 endif WITH_NWFILTER
+
+if WITH_FS
+libvirtd_LDADD += ../src/libvirt_driver_fs.la
+endif WITH_FS
 endif ! WITH_DRIVER_MODULES
 
 libvirtd_LDADD += ../src/libvirt.la
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index cd25b50..e978075 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -92,6 +92,9 @@
 # ifdef WITH_STORAGE
 #  include "storage/storage_driver.h"
 # endif
+# ifdef WITH_FS
+#  include "fs/fs_driver.h"
+# endif
 # ifdef WITH_NODE_DEVICES
 #  include "node_device/node_device_driver.h"
 # endif
@@ -374,6 +377,9 @@ static void daemonInitialize(void)
 # ifdef WITH_NWFILTER
 virDriverLoadModule("nwfilter");
 # endif
+# ifdef WITH_FS
+virDriverLoadModule("fs");
+# endif
 # ifdef WITH_XEN
 virDriverLoadModule("xen");
 # endif
@@ -408,6 +414,9 @@ static void daemonInitialize(void)
 # ifdef WITH_STORAGE
 storageRegister();
 # endif
+# ifdef WITH_FS
+fsRegister();
+# endif
 # ifdef WITH_NODE_DEVICES
 nodedevRegister();
 # endif
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 2d4c191..942e099 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -60,6 +60,7 @@ src/esx/esx_vi.c
 src/esx/esx_vi_methods.c
 src/esx/esx_vi_types.c
 src/fdstream.c
+src/fs/fs_driver.c
 src/hyperv/hyperv_driver.c
 src/hyperv/hyperv_util.c
 src/hyperv/hyperv_wmi.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 07e55ec..d18d3f4 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -651,7 +651,8 @@ DRIVER_SOURCE_FILES = \
$(VMWARE_DRIVER_SOURCES) \
$(XEN_DRIVER_SOURCES) \
$(XENAPI_DRIVER_SOURCES) \
-   $(NULL)
+   $(FS_DRIVER_SOURCES)\
+$(NULL)
 
 STATEFUL_DRIVER_SOURCE_FILES = \
$(BHYVE_DRIVER_SOURCES) \
@@ -667,6 +668,7 @@ STATEFUL_DRIVER_SOURCE_FILES = \
$(UML_DRIVER_SOURCES) \
$(XEN_DRIVER_SOURCES) \
$(VZ_DRIVER_SOURCES) \
+$(FS_DRIVER_SOURCES)\
$(NULL)
 
 
@@ -1113,6 +1115,10 @@ XENCONFIG_SOURCES += 
\
xenconfig/xen_xl.c xenconfig/xen_xl.h
 endif WITH_LIBXL
 
+FS_DRIVER_SOURCES = \
+   fs/fs_driver.h fs/fs_driver.c \
+fs/fs_backend.h
+
 pkgdata_DATA = cpu/cpu_map.xml
 
 EXTRA_DIST +=  $(pkgdata_DATA)
@@ -1637,6 +1643,30 @@ endif WITH_DRIVER_MODULES
 libvirt_driver_secret_la_SOURCES = $(SECRET_DRIVER_SOURCES)
 endif WITH_SECRETS
 
+libvirt_driver_fs_impl_la_SOURCES =
+libvirt_driver_fs_impl_la_CFLAGS = \
+   -I$(srcdir)/access \
+   -I$(srcdir)/conf \
+   $(AM_CFLAGS)
+libvirt_driver_fs_impl_la_LDFLAGS = $(AM_LDFLAGS)
+libvirt_driver_fs_impl_la_LIBADD =
+libvirt_driver_fs_impl_la_LIBADD += $(SECDRIVER_LIBS) $(LIBXML_LIBS)
+if WITH_FS
+noinst_LTLIBRARIES += libvirt_driver_fs_impl.la
+libvirt_driver_fs_la_SOURCES =
+libvirt_driver_fs_la_LIBADD = libvirt_driver_fs_impl.la
+if WITH_DRIVER_MODULES
+mod_LTLIBRARIES += libvirt_driver_fs.la
+libvirt_driver_fs_la_LIBADD += ../gnulib/lib/libgnu.la
+libvirt_driver_fs_la_LDFLAGS = -module -avoid-version $(AM_LDFLAGS)
+else ! WITH_DRIVER_MODULES
+noinst_LTLIBRARIES += libvirt_driver_fs.la
+# Stateful, so linked to daemon instead
+#libvirt_la_BUILT_LIBADD += libvirt_driver_fs.la
+endif ! WITH_DRIVER_MODULES
+libvirt_driver_fs_impl_la_SOURCES += $(FS_DRIVER_SOURCES)
+endif WITH_FS
+
 # Needed to keep automake quiet about conditionals
 libvirt_driver_storage_impl_la_SOURCES =
 libvirt_driver_storage_impl_la_CFLAGS = \
@@ -1908,6 +1938,7 @@ EXTRA_DIST += 
\
$(BHYVE_DRIVER_SOURCES) \
$(NETWORK_DRIVER_SOURCES)   \
$(INTERFACE_DRIVER_SOURCES) \
+   $(FS_DRIVER_SOURCES)\
$(STORAGE_DRIVER_SOURCES)   \
$(STORAGE_DRIVER_FS_SOURCES)\
$(STORAGE_DRIVER_LVM_SOURCES)   \
diff --git a/src/fs/fs_backend.h b/src/fs/fs_backend.h
new file mode 100644
index 000..67ea30c
--- /dev/null
+++ b/src/fs/fs_backend.h
@@ -0,0 +1,94 @@
+/*
+ * fs_backend.h: file system backend implementation
+ * Author: Olga Krishtal 
+ *
+ * Copyright (C) 2016 

[libvirt] [PATCH RFC v3 06/15] FSpool: implementing the public API

[Olga Krishtal]

Implementation of driver API and basic structs defenition

Signed-off-by: Olga Krishtal 
---
 include/libvirt/virterror.h |7 +
 po/POTFILES.in  |1 +
 src/conf/fs_conf.h  |  159 +
 src/datatypes.c |  150 +
 src/datatypes.h |   56 ++
 src/driver.h|2 +
 src/libvirt-fs.c| 1555 +++
 src/libvirt.c   |   30 +-
 src/libvirt_private.syms|4 +-
 src/util/virerror.c |   37 +
 10 files changed, 1999 insertions(+), 2 deletions(-)
 create mode 100644 src/conf/fs_conf.h
 create mode 100644 src/libvirt-fs.c

diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h
index efe83aa..677812e 100644
--- a/include/libvirt/virterror.h
+++ b/include/libvirt/virterror.h
@@ -132,6 +132,7 @@ typedef enum {
 
 VIR_FROM_PERF = 65, /* Error from perf */
 
+VIR_FROM_FSPOOL = 66, /* Error from FS pool */
 # ifdef VIR_ENUM_SENTINELS
 VIR_ERR_DOMAIN_LAST
 # endif
@@ -317,6 +318,12 @@ typedef enum {
 VIR_ERR_NO_CLIENT = 96, /* Client was not found */
 VIR_ERR_AGENT_UNSYNCED = 97,/* guest agent replies with wrong id
to guest-sync command */
+VIR_ERR_INVALID_FSPOOL = 98,/* invalid fspool object */
+VIR_ERR_INVALID_FSITEM = 99,/* invalid fspool object */
+VIR_WAR_NO_FSPOOL = 100, /* failed to start fspool */
+VIR_ERR_NO_FSPOOL = 101,/* fspool not found */
+VIR_ERR_NO_FSITEM = 102,/* fstem not found */
+VIR_ERR_FSITEM_EXIST = 103, /* fspool item already exists */
 } virErrorNumber;
 
 /**
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 29bc45c..0c9b3e4 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -68,6 +68,7 @@ src/internal.h
 src/libvirt-admin.c
 src/libvirt-domain-snapshot.c
 src/libvirt-domain.c
+src/libvirt-fs.c
 src/libvirt-host.c
 src/libvirt-lxc.c
 src/libvirt-network.c
diff --git a/src/conf/fs_conf.h b/src/conf/fs_conf.h
new file mode 100644
index 000..4f05659
--- /dev/null
+++ b/src/conf/fs_conf.h
@@ -0,0 +1,159 @@
+/*
+ * fs_conf.h: config handling for fs driver
+ * Author: Olga Krishtal 
+ *
+ * Copyright (C) 2016 Parallels IP Holdings GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ */
+
+#ifndef __VIR_FS_CONF_H__
+# define __VIR_FS_CONF_H__
+
+# include "internal.h"
+# include "virbitmap.h"
+# include "virthread.h"
+# include "virutil.h"
+# include "virpoolcommon.h"
+# include  "virstoragefile.h"
+# include 
+
+# define VIR_CONNECT_LIST_FSPOOLS_FILTERS_POOL_TYPE  \
+ VIR_CONNECT_LIST_FSPOOLS_DIR
+
+# define VIR_CONNECT_LIST_FSPOOLS_FILTERS_ACTIVE   \
+(VIR_CONNECT_LIST_FSPOOLS_ACTIVE | \
+ VIR_CONNECT_LIST_FSPOOLS_INACTIVE)
+
+# define VIR_CONNECT_LIST_FSPOOLS_FILTERS_PERSISTENT   \
+(VIR_CONNECT_LIST_FSPOOLS_PERSISTENT | \
+ VIR_CONNECT_LIST_FSPOOLS_TRANSIENT)
+
+# define VIR_CONNECT_LIST_FSPOOLS_FILTERS_AUTOSTART\
+(VIR_CONNECT_LIST_FSPOOLS_AUTOSTART |  \
+ VIR_CONNECT_LIST_FSPOOLS_NO_AUTOSTART)
+
+# define VIR_CONNECT_LIST_FSPOOLS_FILTERS_ALL  \
+(VIR_CONNECT_LIST_FSPOOLS_FILTERS_ACTIVE | \
+ VIR_CONNECT_LIST_FSPOOLS_FILTERS_PERSISTENT | \
+ VIR_CONNECT_LIST_FSPOOLS_FILTERS_AUTOSTART  | \
+ VIR_CONNECT_LIST_FSPOOLS_FILTERS_POOL_TYPE)
+
+VIR_ENUM_DECL(virFSItem)
+VIR_ENUM_DECL(virFS)
+
+typedef struct _virFSSourcePoolDef virFSSourcePoolDef;
+typedef virFSSourcePoolDef *virFSSourcePoolDefPtr;
+struct _virFSSourcePoolDef {
+char *pool; /* pool name */
+char *item; /* item name */
+int itemtype; /* virFSItemType, internal only */
+int pooltype; /* virFSPoolType internal only */
+};
+
+typedef struct _virStorageSource virFSSource;
+typedef virFSSource *virFSSourcePtr;
+
+typedef enum {
+VIR_FSPOOL_DIR,  /* Local directory */
+VIR_FSPOOL_LAST,
+} virFSPoolType;
+
+VIR_ENUM_DECL(virFSPool)
+
+typedef struct _virFSItemDef virFSItemDef;
+typedef virFSItemDef *virFSItemDefPtr;
+struct _virFSItemDef {
+char *name;
+char *key;
+int type;/* * 

[libvirt] [PATCH RFC v3 01/15] storage pools: refactoring of basic structs

[Olga Krishtal]

This is the first patch in fspool patchest.
FSPool and storage pools has a lot in common, however we
want to have separate drivers for its managment.

We want to use almost all storage pool descriptional structures
for filesystem pool. All common structs is moved to
virpoolcommon.h

Signed-off-by: Olga Krishtal 
---
 include/libvirt/libvirt-storage.h |   5 +-
 src/Makefile.am   |   5 +-
 src/conf/storage_conf.h   | 126 +++--
 src/datatypes.h   |   4 +-
 src/util/virpoolcommon.h  | 166 ++
 5 files changed, 184 insertions(+), 122 deletions(-)
 create mode 100644 src/util/virpoolcommon.h

diff --git a/include/libvirt/libvirt-storage.h 
b/include/libvirt/libvirt-storage.h
index 0974f6e..8572685 100644
--- a/include/libvirt/libvirt-storage.h
+++ b/include/libvirt/libvirt-storage.h
@@ -34,7 +34,7 @@
  *
  * a virStoragePool is a private structure representing a storage pool
  */
-typedef struct _virStoragePool virStoragePool;
+typedef struct _virPoolCommon virStoragePool;
 
 /**
  * virStoragePoolPtr:
@@ -44,7 +44,6 @@ typedef struct _virStoragePool virStoragePool;
  */
 typedef virStoragePool *virStoragePoolPtr;
 
-
 typedef enum {
 VIR_STORAGE_POOL_INACTIVE = 0, /* Not running */
 VIR_STORAGE_POOL_BUILDING = 1, /* Initializing pool, not available */
@@ -104,7 +103,7 @@ typedef virStoragePoolInfo *virStoragePoolInfoPtr;
  *
  * a virStorageVol is a private structure representing a storage volume
  */
-typedef struct _virStorageVol virStorageVol;
+typedef struct _virItemCommon virStorageVol;
 
 /**
  * virStorageVolPtr:
diff --git a/src/Makefile.am b/src/Makefile.am
index 8ee5567..f8d4a5b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -170,7 +170,7 @@ UTIL_SOURCES =  
\
util/virstats.c util/virstats.h \
util/virstorageencryption.c util/virstorageencryption.h \
util/virstoragefile.c util/virstoragefile.h \
-   util/virstring.h util/virstring.c   \
+util/virstring.h util/virstring.c  \
util/virsysinfo.c util/virsysinfo.h \
util/virsystemd.c util/virsystemd.h \
util/virthread.c util/virthread.h   \
@@ -185,7 +185,8 @@ UTIL_SOURCES =  
\
util/viruuid.c util/viruuid.h   \
util/virxdrdefs.h   \
util/virxml.c util/virxml.h \
-   $(NULL)
+   util/virpoolcommon.h\
+$(NULL)
 
 EXTRA_DIST += $(srcdir)/util/keymaps.csv $(srcdir)/util/virkeycode-mapgen.py
 
diff --git a/src/conf/storage_conf.h b/src/conf/storage_conf.h
index 185ae5e..8a9a789 100644
--- a/src/conf/storage_conf.h
+++ b/src/conf/storage_conf.h
@@ -27,6 +27,7 @@
 # include "internal.h"
 # include "virstorageencryption.h"
 # include "virstoragefile.h"
+# include "virpoolcommon.h"
 # include "virbitmap.h"
 # include "virthread.h"
 # include "device_conf.h"
@@ -58,7 +59,6 @@ struct _virStorageVolSource {
* backend for partition type creation */
 };
 
-
 typedef struct _virStorageVolDef virStorageVolDef;
 typedef virStorageVolDef *virStorageVolDefPtr;
 struct _virStorageVolDef {
@@ -73,6 +73,7 @@ struct _virStorageVolDef {
 virStorageSource target;
 };
 
+
 typedef struct _virStorageVolDefList virStorageVolDefList;
 typedef virStorageVolDefList *virStorageVolDefListPtr;
 struct _virStorageVolDefList {
@@ -112,12 +113,8 @@ typedef enum {
 /*
  * For remote pools, info on how to reach the host
  */
-typedef struct _virStoragePoolSourceHost virStoragePoolSourceHost;
+typedef virPoolSourceHost virStoragePoolSourceHost;
 typedef virStoragePoolSourceHost *virStoragePoolSourceHostPtr;
-struct _virStoragePoolSourceHost {
-char *name;
-int port;
-};
 
 
 /*
@@ -142,127 +139,27 @@ struct _virStoragePoolSourceDeviceExtent {
 int type; /* virStorageFreeType */
 };
 
-typedef struct _virStoragePoolSourceInitiatorAttr 
virStoragePoolSourceInitiatorAttr;
-struct _virStoragePoolSourceInitiatorAttr {
-char *iqn; /* Initiator IQN */
-};
-
 /*
  * Pools can be backed by one or more devices, and some
  * allow us to track free space on underlying devices.
  */
-typedef struct _virStoragePoolSourceDevice virStoragePoolSourceDevice;
+typedef virPoolSourceDevice virStoragePoolSourceDevice;
 typedef virStoragePoolSourceDevice *virStoragePoolSourceDevicePtr;
-struct _virStoragePoolSourceDevice {
-int nfreeExtent;
-virStoragePoolSourceDeviceExtentPtr freeExtents;
-char *path;
-int format; /* Pool specific source format */
-int part_separator;  /* enum virTristateSwitch */
-
-/* When the source device is a physical disk,
- * the geometry data 

[libvirt] [PATCH RFC v3 14/15] FSPool: directory backend inplementation

[Olga Krishtal]

Signed-off-by: Olga Krishtal 
---
 m4/virt-driver-fspool.m4 |  14 ++-
 po/POTFILES.in   |   1 +
 src/Makefile.am  |  10 +-
 src/fs/fs_backend_dir.c  | 290 +++
 src/fs/fs_backend_dir.h  |   8 ++
 src/fs/fs_driver.c   |  10 +-
 6 files changed, 328 insertions(+), 5 deletions(-)
 create mode 100644 src/fs/fs_backend_dir.c
 create mode 100644 src/fs/fs_backend_dir.h

diff --git a/m4/virt-driver-fspool.m4 b/m4/virt-driver-fspool.m4
index 634cb7f..2507879 100644
--- a/m4/virt-driver-fspool.m4
+++ b/m4/virt-driver-fspool.m4
@@ -17,17 +17,27 @@ dnl
 
 AC_DEFUN([LIBVIRT_DRIVER_CHECK_FSPOOL],[
 AC_ARG_WITH([fs],
- [AS_HELP_STRING([--with-fs],
+ [AS_HELP_STRING([--with-fs-dir],
[add FS driver  @<:@default=check@:>@])])
-m4_divert_text([DEFAULTS], [with_fs=check])
+m4_divert_text([DEFAULTS], [with_fs_dir=check])
 
 if test "$with_fs" = "yes"; then
 AC_DEFINE_UNQUOTED([WITH_FS], 1,
[whether fs driver is enabled])
 fi
+
+if test "$with_fs_dir" = "yes"; then
+AC_DEFINE_UNQUOTED([WITH_FS], 1,
+   [whether fs driver is enabled])
+AC_DEFINE_UNQUOTED([WITH_FS_DIR], 1,
+   [whether fs directory backend is enabled])
+fi
+
 AM_CONDITIONAL([WITH_FS], [test "$with_fs" = "yes"])
+AM_CONDITIONAL([WITH_FS_DIR], [test "$with_fs_dir" = "yes"])
 ])
 
 AC_DEFUN([LIBVIRT_DRIVER_RESULT_FSPOOL],[
 AC_MSG_NOTICE([   FSPool: $with_fs])
+AC_MSG_NOTICE([FSPool dir: $with_fs_dir])
 ])
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 942e099..cdb6296 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -60,6 +60,7 @@ src/esx/esx_vi.c
 src/esx/esx_vi_methods.c
 src/esx/esx_vi_types.c
 src/fdstream.c
+src/fs/fs_backend_dir.c
 src/fs/fs_driver.c
 src/hyperv/hyperv_driver.c
 src/hyperv/hyperv_util.c
diff --git a/src/Makefile.am b/src/Makefile.am
index d18d3f4..10e1161 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1119,6 +1119,10 @@ FS_DRIVER_SOURCES = \
fs/fs_driver.h fs/fs_driver.c \
 fs/fs_backend.h
 
+FS_DRIVER_DIR_SOURCES =\
+   fs/fs_backend_dir.h fs/fs_backend_dir.c
+
+
 pkgdata_DATA = cpu/cpu_map.xml
 
 EXTRA_DIST +=  $(pkgdata_DATA)
@@ -1665,6 +1669,7 @@ noinst_LTLIBRARIES += libvirt_driver_fs.la
 #libvirt_la_BUILT_LIBADD += libvirt_driver_fs.la
 endif ! WITH_DRIVER_MODULES
 libvirt_driver_fs_impl_la_SOURCES += $(FS_DRIVER_SOURCES)
+libvirt_driver_fs_impl_la_SOURCES += $(FS_DRIVER_DIR_SOURCES)
 endif WITH_FS
 
 # Needed to keep automake quiet about conditionals
@@ -1938,8 +1943,9 @@ EXTRA_DIST += 
\
$(BHYVE_DRIVER_SOURCES) \
$(NETWORK_DRIVER_SOURCES)   \
$(INTERFACE_DRIVER_SOURCES) \
-   $(FS_DRIVER_SOURCES)\
-   $(STORAGE_DRIVER_SOURCES)   \
+   $(FS_DRIVER_SOURCES)\
+   $(FS_DRIVER_DIR_SOURCES)\
+$(STORAGE_DRIVER_SOURCES)  \
$(STORAGE_DRIVER_FS_SOURCES)\
$(STORAGE_DRIVER_LVM_SOURCES)   \
$(STORAGE_DRIVER_ISCSI_SOURCES) \
diff --git a/src/fs/fs_backend_dir.c b/src/fs/fs_backend_dir.c
new file mode 100644
index 000..814c2cb
--- /dev/null
+++ b/src/fs/fs_backend_dir.c
@@ -0,0 +1,290 @@
+/*
+ * fs_backend_dir.c: file system backend implementation
+ * Author: Olga Krishtal 
+ *
+ * Copyright (C) 2016 Parallels IP Holdings GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "virerror.h"
+#include "fs_backend_dir.h"
+#include "fs_conf.h"
+#include "vircommand.h"
+#include "viralloc.h"
+#include "virxml.h"
+#include "virfile.h"
+#include "virpoolcommon.h"
+#include "virlog.h"
+#include "virstring.h"
+#include "fdstream.h"
+#include "stat-time.h"
+
+#define VIR_FROM_THIS VIR_FROM_FSPOOL
+

[libvirt] [PATCH RFC v3 07/15] FSPool: added access control objects and permissions

[Olga Krishtal]

Signed-off-by: Olga Krishtal 
---
 src/access/viraccessdriver.h   |  15 +
 src/access/viraccessdrivernop.c|  21 +++
 src/access/viraccessdriverpolkit.c |  47 ++
 src/access/viraccessdriverstack.c  |  50 +++
 src/access/viraccessmanager.c  |  32 ++
 src/access/viraccessmanager.h  |  11 +++-
 src/access/viraccessperm.c |  15 -
 src/access/viraccessperm.h | 126 +
 src/libvirt_private.syms   |   5 +-
 9 files changed, 318 insertions(+), 4 deletions(-)

diff --git a/src/access/viraccessdriver.h b/src/access/viraccessdriver.h
index e3050b6..194aa2f 100644
--- a/src/access/viraccessdriver.h
+++ b/src/access/viraccessdriver.h
@@ -61,6 +61,19 @@ typedef int 
(*virAccessDriverCheckStorageVolDrv)(virAccessManagerPtr manager,
  virStorageVolDefPtr vol,
  virAccessPermStorageVol av);
 
+typedef int (*virAccessDriverCheckFSPoolDrv)(virAccessManagerPtr manager,
+ const char *driverName,
+ virFSPoolDefPtr fspool,
+ virAccessPermFSPool av);
+typedef int (*virAccessDriverCheckFSItemDrv)(virAccessManagerPtr manager,
+ const char *driverName,
+ virFSPoolDefPtr fspool,
+ virFSItemDefPtr item,
+ virAccessPermFSItem av);
+
+typedef int (*virAccessDriverSetupDrv)(virAccessManagerPtr manager);
+typedef void (*virAccessDriverCleanupDrv)(virAccessManagerPtr manager);
+
 typedef int (*virAccessDriverSetupDrv)(virAccessManagerPtr manager);
 typedef void (*virAccessDriverCleanupDrv)(virAccessManagerPtr manager);
 
@@ -83,6 +96,8 @@ struct _virAccessDriver {
 virAccessDriverCheckSecretDrv checkSecret;
 virAccessDriverCheckStoragePoolDrv checkStoragePool;
 virAccessDriverCheckStorageVolDrv checkStorageVol;
+virAccessDriverCheckFSPoolDrv checkFSPool;
+virAccessDriverCheckFSItemDrv checkFSItem;
 };
 
 
diff --git a/src/access/viraccessdrivernop.c b/src/access/viraccessdrivernop.c
index 86ceef3..a936711 100644
--- a/src/access/viraccessdrivernop.c
+++ b/src/access/viraccessdrivernop.c
@@ -104,6 +104,25 @@ virAccessDriverNopCheckStorageVol(virAccessManagerPtr 
manager ATTRIBUTE_UNUSED,
 }
 
 
+static int
+virAccessDriverNopCheckFSPool(virAccessManagerPtr manager ATTRIBUTE_UNUSED,
+  const char *driverName ATTRIBUTE_UNUSED,
+  virFSPoolDefPtr fspool ATTRIBUTE_UNUSED,
+  virAccessPermFSPool perm ATTRIBUTE_UNUSED)
+{
+return 1; /* Allow */
+}
+
+static int
+virAccessDriverNopCheckFSItem(virAccessManagerPtr manager ATTRIBUTE_UNUSED,
+  const char *driverName ATTRIBUTE_UNUSED,
+  virFSPoolDefPtr fspool ATTRIBUTE_UNUSED,
+  virFSItemDefPtr item ATTRIBUTE_UNUSED,
+  virAccessPermFSItem perm ATTRIBUTE_UNUSED)
+{
+return 1; /* Allow */
+}
+
 virAccessDriver accessDriverNop = {
 .name = "none",
 .checkConnect = virAccessDriverNopCheckConnect,
@@ -115,4 +134,6 @@ virAccessDriver accessDriverNop = {
 .checkSecret = virAccessDriverNopCheckSecret,
 .checkStoragePool = virAccessDriverNopCheckStoragePool,
 .checkStorageVol = virAccessDriverNopCheckStorageVol,
+.checkFSPool = virAccessDriverNopCheckFSPool,
+.checkFSItem = virAccessDriverNopCheckFSItem,
 };
diff --git a/src/access/viraccessdriverpolkit.c 
b/src/access/viraccessdriverpolkit.c
index 0d9e0a1..2beaf74 100644
--- a/src/access/viraccessdriverpolkit.c
+++ b/src/access/viraccessdriverpolkit.c
@@ -399,6 +399,51 @@ virAccessDriverPolkitCheckStorageVol(virAccessManagerPtr 
manager,
   attrs);
 }
 
+static int
+virAccessDriverPolkitCheckFSPool(virAccessManagerPtr manager,
+ const char *driverName,
+ virFSPoolDefPtr fspool,
+ virAccessPermFSPool perm)
+{
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+const char *attrs[] = {
+"connect_driver", driverName,
+"fspool_name", fspool->name,
+"fspool_uuid", uuidstr,
+NULL,
+};
+virUUIDFormat(fspool->uuid, uuidstr);
+
+return virAccessDriverPolkitCheck(manager,
+  "fs-pool",
+  virAccessPermFSPoolTypeToString(perm),
+  attrs);
+}
+
+static int
+virAccessDriverPolkitCheckFSItem(virAccessManagerPtr manager,
+ const char *driverName,
+ 

[libvirt] [PATCH RFC v3 09/15] FSPool: implementation of remote protocol

[Olga Krishtal]

Signed-off-by: Olga Krishtal 
---
 daemon/remote.c  |  35 
 src/Makefile.am  |   6 +-
 src/check-driverimpls.pl |   2 +
 src/remote/remote_driver.c   |  66 ++
 src/remote/remote_protocol.x | 466 ++-
 src/remote_protocol-structs  | 165 +++
 src/rpc/gendispatch.pl   |  23 ++-
 7 files changed, 753 insertions(+), 10 deletions(-)

diff --git a/daemon/remote.c b/daemon/remote.c
index e414f92..33e5e77 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -88,6 +88,8 @@ static virNetworkPtr get_nonnull_network(virConnectPtr conn, 
remote_nonnull_netw
 static virInterfacePtr get_nonnull_interface(virConnectPtr conn, 
remote_nonnull_interface iface);
 static virStoragePoolPtr get_nonnull_storage_pool(virConnectPtr conn, 
remote_nonnull_storage_pool pool);
 static virStorageVolPtr get_nonnull_storage_vol(virConnectPtr conn, 
remote_nonnull_storage_vol vol);
+static virFSPoolPtr get_nonnull_fspool(virConnectPtr conn, 
remote_nonnull_fspool fspool);
+static virFSItemPtr get_nonnull_fsitem(virConnectPtr conn, 
remote_nonnull_fsitem item);
 static virSecretPtr get_nonnull_secret(virConnectPtr conn, 
remote_nonnull_secret secret);
 static virNWFilterPtr get_nonnull_nwfilter(virConnectPtr conn, 
remote_nonnull_nwfilter nwfilter);
 static virDomainSnapshotPtr get_nonnull_domain_snapshot(virDomainPtr dom, 
remote_nonnull_domain_snapshot snapshot);
@@ -97,6 +99,8 @@ static void make_nonnull_network(remote_nonnull_network 
*net_dst, virNetworkPtr
 static void make_nonnull_interface(remote_nonnull_interface *interface_dst, 
virInterfacePtr interface_src);
 static void make_nonnull_storage_pool(remote_nonnull_storage_pool *pool_dst, 
virStoragePoolPtr pool_src);
 static void make_nonnull_storage_vol(remote_nonnull_storage_vol *vol_dst, 
virStorageVolPtr vol_src);
+static void make_nonnull_fspool(remote_nonnull_fspool *fspool_dst, 
virFSPoolPtr fspool_src);
+static void make_nonnull_fsitem(remote_nonnull_fsitem *item_dst, virFSItemPtr 
item_src);
 static void make_nonnull_node_device(remote_nonnull_node_device *dev_dst, 
virNodeDevicePtr dev_src);
 static void make_nonnull_secret(remote_nonnull_secret *secret_dst, 
virSecretPtr secret_src);
 static void make_nonnull_nwfilter(remote_nonnull_nwfilter *net_dst, 
virNWFilterPtr nwfilter_src);
@@ -6660,6 +6664,22 @@ get_nonnull_domain_snapshot(virDomainPtr dom, 
remote_nonnull_domain_snapshot sna
 return virGetDomainSnapshot(dom, snapshot.name);
 }
 
+static virFSPoolPtr
+get_nonnull_fspool(virConnectPtr conn, remote_nonnull_fspool fspool)
+{
+return virGetFSPool(conn, fspool.name, BAD_CAST fspool.uuid,
+NULL, NULL);
+}
+
+static virFSItemPtr
+get_nonnull_fsitem(virConnectPtr conn, remote_nonnull_fsitem item)
+{
+virFSItemPtr ret;
+ret = virGetFSItem(conn, item.fspool, item.name, item.key,
+   NULL, NULL);
+return ret;
+}
+
 static virNodeDevicePtr
 get_nonnull_node_device(virConnectPtr conn, remote_nonnull_node_device dev)
 {
@@ -6706,6 +6726,21 @@ make_nonnull_storage_vol(remote_nonnull_storage_vol 
*vol_dst, virStorageVolPtr v
 }
 
 static void
+make_nonnull_fspool(remote_nonnull_fspool *fspool_dst, virFSPoolPtr fspool_src)
+{
+ignore_value(VIR_STRDUP_QUIET(fspool_dst->name, fspool_src->name));
+memcpy(fspool_dst->uuid, fspool_src->uuid, VIR_UUID_BUFLEN);
+}
+
+static void
+make_nonnull_fsitem(remote_nonnull_fsitem *item_dst, virFSItemPtr item_src)
+{
+ignore_value(VIR_STRDUP_QUIET(item_dst->fspool, item_src->pool));
+ignore_value(VIR_STRDUP_QUIET(item_dst->name, item_src->name));
+ignore_value(VIR_STRDUP_QUIET(item_dst->key, item_src->key));
+}
+
+static void
 make_nonnull_node_device(remote_nonnull_node_device *dev_dst, virNodeDevicePtr 
dev_src)
 {
 ignore_value(VIR_STRDUP_QUIET(dev_dst->name, dev_src->name));
diff --git a/src/Makefile.am b/src/Makefile.am
index 13a4976..2c9d675 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -233,7 +233,8 @@ DRIVER_SOURCES =
\
locking/lock_driver_nop.h locking/lock_driver_nop.c \
locking/domain_lock.h locking/domain_lock.c \
logging/log_manager.c logging/log_manager.h \
-   $(NULL)
+   libvirt-fs.c   \
+$(NULL)
 
 LOCK_DRIVER_SANLOCK_SOURCES = \
locking/lock_driver_sanlock.c
@@ -2400,7 +2401,8 @@ libvirt_setuid_rpc_client_la_SOURCES =\
libvirt-storage.c   \
libvirt-stream.c\
libvirt-lxc.c   \
-   $(NULL)
+   libvirt-fs.c\
+$(NULL)
 
 libvirt_setuid_rpc_client_la_LDFLAGS = \
$(AM_LDFLAGS)   \
diff --git a/src/check-driverimpls.pl b/src/check-driverimpls.pl
index 

[libvirt] [PATCH RFC v3 10/15] FSPool: added configuration description

[Olga Krishtal]

Due to reusage of structs and some of functions from storage pools
we operate in storage terms.

Signed-off-by: Olga Krishtal 
---
 po/POTFILES.in   |1 +
 src/Makefile.am  |7 +-
 src/conf/fs_conf.c   | 1479 ++
 src/conf/fs_conf.h   |  103 
 src/libvirt_private.syms |   35 ++
 5 files changed, 1624 insertions(+), 1 deletion(-)
 create mode 100644 src/conf/fs_conf.c

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 0c9b3e4..7ad9174 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -25,6 +25,7 @@ src/conf/domain_addr.c
 src/conf/domain_capabilities.c
 src/conf/domain_conf.c
 src/conf/domain_event.c
+src/conf/fs_conf.c
 src/conf/interface_conf.c
 src/conf/netdev_bandwidth_conf.c
 src/conf/netdev_vlan_conf.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 2c9d675..07e55ec 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -399,6 +399,10 @@ CHRDEV_CONF_SOURCES =  
\
 DEVICE_CONF_SOURCES =   \
conf/device_conf.c conf/device_conf.h
 
+# FSPool driver sources
+FS_CONF_SOURCES =  \
+   conf/fs_conf.c conf/fs_conf.h
+
 CONF_SOURCES = \
$(NETDEV_CONF_SOURCES)  \
$(DOMAIN_CONF_SOURCES)  \
@@ -415,7 +419,8 @@ CONF_SOURCES =  
\
$(SECRET_CONF_SOURCES)  \
$(CPU_CONF_SOURCES) \
$(CHRDEV_CONF_SOURCES)  \
-   $(DEVICE_CONF_SOURCES)
+   $(DEVICE_CONF_SOURCES)  \
+$(FS_CONF_SOURCES)
 
 # The remote RPC driver, covering domains, storage, networks, etc
 REMOTE_DRIVER_GENERATED = \
diff --git a/src/conf/fs_conf.c b/src/conf/fs_conf.c
new file mode 100644
index 000..4114ac3
--- /dev/null
+++ b/src/conf/fs_conf.c
@@ -0,0 +1,1479 @@
+/*
+ * fs_conf.c: config handling for fs driver
+ * Author: Olga Krishtal 
+ *
+ * Copyright (C) 2016 Parallels IP Holdings GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virerror.h"
+#include "datatypes.h"
+#include "fs_conf.h"
+
+#include "virxml.h"
+#include "viruuid.h"
+#include "virbuffer.h"
+#include "viralloc.h"
+#include "virfile.h"
+#include "virstring.h"
+#include "virlog.h"
+
+#define VIR_FROM_THIS VIR_FROM_FSPOOL
+
+VIR_LOG_INIT("conf.fs_conf");
+
+VIR_ENUM_IMPL(virFSPool,
+  VIR_FSPOOL_LAST,
+  "dir")
+
+VIR_ENUM_IMPL(virFSItem,
+  VIR_FSITEM_LAST,
+  "dir")
+
+/* Flags to indicate mandatory components in the fspool source */
+enum {
+VIR_FSPOOL_SOURCE_DIR = (1 << 2),
+VIR_FSPOOL_SOURCE_NAME= (1 << 4),
+VIR_FSPOOL_SOURCE_NETWORK = (1 << 6),
+};
+
+typedef const char *(*virFSItemFormatToString)(int format);
+typedef int (*virFSItemFormatFromString)(const char *format);
+
+typedef const char *(*virFSPoolFormatToString)(int format);
+typedef int (*virFSPoolFormatFromString)(const char *format);
+
+typedef struct _virFSItemOptions virFSItemOptions;
+typedef virFSItemOptions *virFSItemOptionsPtr;
+struct _virFSItemOptions {
+int defaultFormat;
+virFSItemFormatToString formatToString;
+virFSItemFormatFromString formatFromString;
+};
+
+typedef struct _virFSPoolOptions virFSPoolOptions;
+typedef virFSPoolOptions *virFSPoolOptionsPtr;
+struct _virFSPoolOptions {
+unsigned int flags;
+int defaultFormat;
+virFSPoolFormatToString formatToString;
+virFSPoolFormatFromString formatFromString;
+};
+
+typedef struct _virFSPoolTypeInfo virFSPoolTypeInfo;
+typedef virFSPoolTypeInfo *virFSPoolTypeInfoPtr;
+struct _virFSPoolTypeInfo {
+int fspoolType;
+virFSPoolOptions fspoolOptions;
+virFSItemOptions itemOptions;
+};
+
+static virFSPoolTypeInfo fspoolTypeInfo[] = {
+{.fspoolType = VIR_FSPOOL_DIR}
+};
+
+
+static virFSPoolTypeInfoPtr
+virFSPoolTypeInfoLookup(int type)
+{
+   

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

[Benjamin Herrenschmidt]

On Fri, 2016-12-02 at 16:50 +1100, David Gibson wrote:
> 
> Uh.. I don't entirely follow you.  From the host point of view there
> are multiple iommu groups (PEs), but from the guest point of view
> there's only one.  On the guest side iommu granularity is always
> per-vPHB.

Ok so the H_PUT_TCE calls affect all the underlying tables ?

Cheers,
Ben.

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