Re: [libvirt] Matching the type of mediated devices in the migration

[Zhi Wang]

Hi Alex and Kirti:

Thanks for your reply and discussion. :)  Sorry for my late reply since 
there quite some work and email needs to be caught up after my vacation.


From my point of view,  failing the migration because of the mismatch 
of version in different levels provides different pros/cons.


- Match version in userspace toolkit level, like in QEMU and Libvirt:

Pros: Better responsiveness since the match of the version would be 
figured out before actually suspend/resume devices. All the userspace 
toolkit could provide these information to UI or other management tool, 
like virtsh and virt manager, so it would be helpful for the 
administrator to know what's happening through the management interface.


Cons: Vendor driver has to expose the version information. Some vendor 
driver might not wish to expose that explicitly. Considering the mdev 
could be highly related to different vendors and different devices, this 
might happen in future as well.


- Match version in device state level (vendor-specific)

Pros: The vendor driver doesn't need to explain and expose the a 
explicit version of device state.


Cons: Waste of bandwidth. Bad responsiveness and informative.

How about we combine the two ideas together? The vendor driver could 
decide to use the device state or not. But still, the error information 
could be a problem since it's could be hard for the management tool like 
virtsh or virt-manager to get a error message from a remote node.


Let me cook some RFC patch in the next week.

Have a great weekend. :)

Thanks,
Zhi.

-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Monday, 
August 6, 2018 10:22 PM

To: Kirti Wankhede 
Cc: Wang, Zhi A ; libvir-list@redhat.com
Subject: Re: Matching the type of mediated devices in the migration

On Mon, 6 Aug 2018 23:45:21 +0530
Kirti Wankhede  wrote:


On 8/3/2018 11:26 PM, Alex Williamson wrote:
> On Fri, 3 Aug 2018 12:07:58 +
> "Wang, Zhi A"  wrote:
>   
>> Hi:

>>
>> Thanks for unfolding your idea. The picture is clearer to me now. I didn't realize that you also want to support cross hardware migration. Well, I thought for a while, the cross hardware migration might be not popular in vGPU case but could be quite popular in other mdev cases.  
> 
> Exactly, we need to think beyond the implementation for a specific 
> vendor or class of device.
>
>> Let me continue my summary:

>>
>> Mdev dev type has already included a parent driver name/a group name/physical device version/configuration type. For example i915-GVTg_V5_4. The driver name and the group name could already distinguish the vendor and the product between different mdevs, e.g. between Intel and Nvidia, between vGPU or vOther.  
> 
> Note that there are only two identifiers here, a vendor driver and a 
> type.  We included the vendor driver to avoid namespace collisions 
> between vendors.  The type itself should be considered opaque 
> regardless of how a specific vendor makes use of it.
>   
>> Each device provides a collection of the version of device state of data stream in a preferred order in a mdev type, as newer version of device state might contains more information which might help on performances. 
>>

>> Let's say a new device N and an old device O, they both support mdev_type M.
>>
>> For example:
>> Device N is newer and supports the versions of device state: [ 6.3  
>> 6.2 .6.1 ] in mdev type M Device O is older and supports the 
>> versions of device state: [ 5.3 5.2 5.1 ] in mdev type M

>>
>> - Version scheme of device state in backwards compatibility case: Migrate a 
VM from a VM with device O to a VM with device N, the mdev type is M.
>>
>> Device N: [ 6.3 6.2 6.1 5.3 ] in M
>> Device O: [ 5.3 5.2 5.1 ] in M
>> Version used in migration: 5.3
>> The new device directly supports mdev_type M with the preferred version on 
Device O. Good, best situation.
>>
>> Device N: [ 6.3 6.2 6.1 5.2 ] in M
>> Device O: [ 5.3 5.2 5.1 ] in M
>> Version used in migration: 5.2
>> The new device supports mdev_type M, but not the preferred version. After 
the migration, the vendor driver might have to disable some features which is not 
mentioned in 5.2 device state. But this totally depends on the vendor driver. If user 
wish to achieve the best experience, he should update the vendor driver in device N, 
which supports the preferred version on device O.
>>
>> Device N: [ 6.3 6.2 6.1 ] in M
>> Device O: [ 5.3 5.2 5.1 ] in M
>> Version used in migration: None
>> No version is matched. Migration would fail. User should update the vendor 
driver on device N and device O.
>>
>> - Version scheme of device state in forwards compatibility case: Migrate a 
VM from a VM with N to a VM with device O, the mdev type is M.
>>
>> Device N: [ 6.3 6.2 .6.1 ] in M
>> Device O: [ 5.3 5.2 5.1 ] in M, but the user updates the vendor 
>> driver on device O. Now device O could support [ 5.3 5.2 5.1 6.1 ] 
>> (As an old device, the Device O still prefers version 

Re: [libvirt] Missing repo file for virt-preview repo on fedorapeople

[Cole Robinson]

On 08/10/2018 04:20 AM, Roman Mohr wrote:



On Fri, Aug 10, 2018 at 10:02 AM Andrea Bolognani > wrote:


On Fri, 2018-08-10 at 08:54 +0200, Roman Mohr wrote:
 > Hi everyone,
 >
 > Is there a change on how to get the fedora-virt-preview.repo?
 >
 > So far we were referencing
 >
 >
https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo
 >
 > but that file does not seem to exist anymore.

Please post this kind of question to libvirt-users next time, and
refrain from CC'ing libvirt developers - we are all subscribed to
and read the lists.

As for your question,

https://fedoraproject.org/wiki/Virtualization_Preview_Repository



virt-preview is hosted on copr nowadays, I just removed the repo file 
yesterday from fedorapeople and updated the fedora wiki page to point to 
the new location.


If as a stop gap you want to access the old .repo file, you can get it here:

https://raw.githubusercontent.com/crobinso/build-fedora-virt-preview/bdc71474d31ffc826d59bd16ec9bff7708049d14/fedora-virt-preview.repo

However that repo location isn't being updated anymore, so you should 
switch to the copr repo soon.


Hopefully that works for you, let me know if you hit issues

Thanks,
Cole

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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 06:36:46PM +0300, Ivan Mishonov wrote:
> Yes, that makes sense. I'll try to find some time next week to redo my code
> and send another patch. Since my time for working on libvirt is very limited
> can you confirm that the LPC configuration should look like this:
> 
>    
>    
>    
> 
> Also can you send me an example of how you imagine the  setting
> for unimplemented MSRs?

Leading from this:

  https://libvirt.org/formatdomain.html#elementsFeatures

I would perhaps think

   
  ...
  
  ...
   


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

Yes, that makes sense. I'll try to find some time next week to redo my 
code and send another patch. Since my time for working on libvirt is 
very limited can you confirm that the LPC configuration should look like 
this:


   
   
   

Also can you send me an example of how you imagine the  
setting for unimplemented MSRs?


Regards,
Ivan

On 08/10/2018 06:24 PM, Daniel P. Berrangé wrote:

On Fri, Aug 10, 2018 at 06:11:57PM +0300, Ivan Mishonov wrote:

I'd like to hear Roman's opinion on this too since he wrote the initial
implementation. As for the command line arguments I was looking at
 since it's doing exactly the same thing and I thought it
would be nice to be consistent with it

It would still be reasonable to allow  for arbitrary
passthrough of new features which have no XML defined for them. I just
think it is reasonable to model these two example explicitly.

The namespaced passthrough is intended for short term hacks primarily.


On 08/10/2018 05:57 PM, Daniel P. Berrangé wrote:

On Fri, Aug 10, 2018 at 05:47:40PM +0300, Ivan Mishonov wrote:

Yes, this is totally doable. I just don't know if it's a good idea to add a
new device type specifically for bhyve LPC and nothing else. Even if we do
it like this I'll still have to send another patch including the bhyve XML
namespace as we need to be able to pass extra command line options to the
bhyve process related to unimplemented MSRs on AMD Zen systems. I thought
I'd do the 2 things in a similar manner as both of them are strictly bhyve
specific

IMHO  the LPC thing is definitely in scope for correct modelling in
the XML.

For the MSRs option, it is probable we'd consider that in scope as
well. Currently KVM has a global "ignore unknown msrs" option in the
kernel module, but I think it is conceptually reasonable to expect
that to be settable on a per-VM basis.

Probably would do the MSRs thing as a  flag, as we stuff
lots of random feature toggles under there

Regards,
Daniel

Regards,
Daniel


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

Re: [libvirt] [PATCH 16/17] vircgroup: Introduce virCgroupGetMemoryStat

[Pavel Hrdina]

On Fri, Aug 10, 2018 at 10:44:39AM +0200, Michal Privoznik wrote:
> On 08/09/2018 03:44 PM, Pavel Hrdina wrote:
> > Signed-off-by: Pavel Hrdina 
> > ---
> >  src/libvirt_private.syms |  1 +
> >  src/util/vircgroup.c | 88 
> >  src/util/vircgroup.h |  7 
> >  3 files changed, 96 insertions(+)
> > 
> > diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> > index 59d9bc380e..ee0dca6129 100644
> > --- a/src/libvirt_private.syms
> > +++ b/src/libvirt_private.syms
> > @@ -1532,6 +1532,7 @@ virCgroupGetDomainTotalCpuStats;
> >  virCgroupGetFreezerState;
> >  virCgroupGetMemoryHardLimit;
> >  virCgroupGetMemorySoftLimit;
> > +virCgroupGetMemoryStat;
> >  virCgroupGetMemoryUsage;
> >  virCgroupGetMemSwapHardLimit;
> >  virCgroupGetMemSwapUsage;
> > diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c
> > index 37982a9607..b91acd13c7 100644
> > --- a/src/util/vircgroup.c
> > +++ b/src/util/vircgroup.c
> > @@ -2427,6 +2427,94 @@ virCgroupSetMemory(virCgroupPtr group, unsigned long 
> > long kb)
> >  }
> >  
> >  
> > +/**
> > + * virCgroupGetMemoryStat:
> > + *
> > + * @group: The cgroup to change memory for
> > + * @cache: page cache memory in KiB
> > + * @activeAnon: anonymous and swap cache memory in KiB
> > + * @inactiveAnon: anonymous and swap cache memory in KiB
> > + * @activeFile: file-backed memory in KiB
> > + * @inactiveFile: file-backed memory in KiB
> > + * @unevictable: memory that cannot be reclaimed KiB
> > + *
> > + * Returns: 0 on success, -1 on error
> > + */
> > +int
> > +virCgroupGetMemoryStat(virCgroupPtr group,
> > +   unsigned long long *cache,
> > +   unsigned long long *activeAnon,
> > +   unsigned long long *inactiveAnon,
> > +   unsigned long long *activeFile,
> > +   unsigned long long *inactiveFile,
> > +   unsigned long long *unevictable)
> > +{
> > +int ret = -1;
> > +char *stat = NULL;
> > +char *line = NULL;
> > +unsigned long long cacheVal = 0;
> > +unsigned long long activeAnonVal = 0;
> > +unsigned long long inactiveAnonVal = 0;
> > +unsigned long long activeFileVal = 0;
> > +unsigned long long inactiveFileVal = 0;
> > +unsigned long long unevictableVal = 0;
> > +
> > +if (virCgroupGetValueStr(group,
> > + VIR_CGROUP_CONTROLLER_MEMORY,
> > + "memory.stat",
> > + ) < 0) {
> > +return -1;
> > +}
> > +
> > +line = stat;
> > +
> > +while (line) {
> > +char *newLine = strchr(line, '\n');
> > +char *valueStr = strchr(line, ' ');
> > +unsigned long long value;
> > +
> > +if (newLine)
> > +*newLine = '\0';
> > +
> > +if (!valueStr) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > +   _("Cannot parse 'memory.stat' cgroup file."));
> > +goto cleanup;
> > +}
> > +*valueStr = '\0';
> > +
> > +if (virStrToLong_ull(valueStr + 1, NULL, 10, ) < 0)
> > +goto cleanup;
> > +
> > +if (STREQ(line, "cache"))
> > +cacheVal = value >> 10;
> 
> 
> Can't we assign directly to *cache? Sure, you'd need to initialize it
> before, just like you're initializing cacheVal.

We can do that, some other functions in vircgroup.c are assigning values
directly into the passed parameters, I wanted to play it safe and update
the passed parameters only if everything succeeds.

Pavel


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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 06:11:57PM +0300, Ivan Mishonov wrote:
> I'd like to hear Roman's opinion on this too since he wrote the initial
> implementation. As for the command line arguments I was looking at
>  since it's doing exactly the same thing and I thought it
> would be nice to be consistent with it

It would still be reasonable to allow  for arbitrary
passthrough of new features which have no XML defined for them. I just
think it is reasonable to model these two example explicitly.

The namespaced passthrough is intended for short term hacks primarily.

> On 08/10/2018 05:57 PM, Daniel P. Berrangé wrote:
> > On Fri, Aug 10, 2018 at 05:47:40PM +0300, Ivan Mishonov wrote:
> > > Yes, this is totally doable. I just don't know if it's a good idea to add 
> > > a
> > > new device type specifically for bhyve LPC and nothing else. Even if we do
> > > it like this I'll still have to send another patch including the bhyve XML
> > > namespace as we need to be able to pass extra command line options to the
> > > bhyve process related to unimplemented MSRs on AMD Zen systems. I thought
> > > I'd do the 2 things in a similar manner as both of them are strictly bhyve
> > > specific
> > IMHO  the LPC thing is definitely in scope for correct modelling in
> > the XML.
> > 
> > For the MSRs option, it is probable we'd consider that in scope as
> > well. Currently KVM has a global "ignore unknown msrs" option in the
> > kernel module, but I think it is conceptually reasonable to expect
> > that to be settable on a per-VM basis.
> > 
> > Probably would do the MSRs thing as a  flag, as we stuff
> > lots of random feature toggles under there
> > 
> > Regards,
> > Daniel
> 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

I'd like to hear Roman's opinion on this too since he wrote the initial 
implementation. As for the command line arguments I was looking at 
 since it's doing exactly the same thing and I thought 
it would be nice to be consistent with it


Regards,
Ivan

On 08/10/2018 05:57 PM, Daniel P. Berrangé wrote:

On Fri, Aug 10, 2018 at 05:47:40PM +0300, Ivan Mishonov wrote:

Yes, this is totally doable. I just don't know if it's a good idea to add a
new device type specifically for bhyve LPC and nothing else. Even if we do
it like this I'll still have to send another patch including the bhyve XML
namespace as we need to be able to pass extra command line options to the
bhyve process related to unimplemented MSRs on AMD Zen systems. I thought
I'd do the 2 things in a similar manner as both of them are strictly bhyve
specific

IMHO  the LPC thing is definitely in scope for correct modelling in
the XML.

For the MSRs option, it is probable we'd consider that in scope as
well. Currently KVM has a global "ignore unknown msrs" option in the
kernel module, but I think it is conceptually reasonable to expect
that to be settable on a per-VM basis.

Probably would do the MSRs thing as a  flag, as we stuff
lots of random feature toggles under there

Regards,
Daniel


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

Re: [libvirt] [PATCH v2 20/20] qemu: ensure that memory 'discard' is used if specified in XML

[Pavel Hrdina]

On Fri, Aug 10, 2018 at 09:26:27AM +0200, Michal Privoznik wrote:
> On 08/09/2018 02:38 PM, Pavel Hrdina wrote:
> > Signed-off-by: Pavel Hrdina 
> > ---
> >  src/qemu/qemu_command.c|  4 +++-
> >  .../pages-discard-hugepages.args   | 11 +++
> >  tests/qemuxml2argvdata/pages-discard.args  | 18 ++
> >  3 files changed, 24 insertions(+), 9 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> > index dbeb3a54f6..a7859feae6 100644
> > --- a/src/qemu/qemu_command.c
> > +++ b/src/qemu/qemu_command.c
> > @@ -3147,6 +3147,7 @@ qemuBuildMemoryBackendProps(virJSONValuePtr 
> > *backendProps,
> >  return -1;
> >  
> >  if (useHugepage || mem->nvdimmPath || memAccess ||
> > +discard == VIR_TRISTATE_BOOL_YES ||
> >  def->mem.source == VIR_DOMAIN_MEMORY_SOURCE_FILE) {
> >  
> >  if (useHugepage) {
> > @@ -3228,7 +3229,8 @@ qemuBuildMemoryBackendProps(virJSONValuePtr 
> > *backendProps,
> >  if (!needHugepage && !mem->sourceNodes && !nodeSpecified &&
> >  !mem->nvdimmPath &&
> >  memAccess == VIR_DOMAIN_MEMORY_ACCESS_DEFAULT &&
> > -def->mem.source != VIR_DOMAIN_MEMORY_SOURCE_FILE && !force) {
> > +def->mem.source != VIR_DOMAIN_MEMORY_SOURCE_FILE && !force &&
> > +discard != VIR_TRISTATE_BOOL_YES) {
> >  /* report back that using the new backend is not necessary
> >   * to achieve the desired configuration */
> >  ret = 1;
> > diff --git a/tests/qemuxml2argvdata/pages-discard-hugepages.args 
> > b/tests/qemuxml2argvdata/pages-discard-hugepages.args
> > index 2dfacefe4a..d859480c26 100644
> > --- a/tests/qemuxml2argvdata/pages-discard-hugepages.args
> > +++ b/tests/qemuxml2argvdata/pages-discard-hugepages.args
> > @@ -10,10 +10,13 @@ QEMU_AUDIO_DRV=none \
> >  -machine pc,accel=tcg,usb=off,dump-guest-core=off \
> >  -m 1024 \
> >  -smp 2,sockets=2,cores=1,threads=1 \
> > --mem-prealloc \
> > --mem-path /dev/hugepages2M/libvirt/qemu/-1-SomeDummyHugepagesGu \
> > --numa node,nodeid=0,cpus=0,mem=256 \
> > --numa node,nodeid=1,cpus=1,mem=768 \
> > +-object memory-backend-file,id=ram-node0,prealloc=yes,\
> > +mem-path=/dev/hugepages2M/libvirt/qemu/-1-SomeDummyHugepagesGu,size=268435456
> >  \
> > +-numa node,nodeid=0,cpus=0,memdev=ram-node0 \
> > +-object memory-backend-file,id=ram-node1,prealloc=yes,\
> > +mem-path=/dev/hugepages2M/libvirt/qemu/-1-SomeDummyHugepagesGu,\
> > +discard-data=yes,size=805306368 \
> > +-numa node,nodeid=1,cpus=1,memdev=ram-node1 \
> 
> This will break migration. But at the same time, it's very unlikely that
> anybody is using discard without hugepages.

So there is different issue, with this patch guest without any hugepages
will fail to start as the memory file is generated in
/var/lib/libvirt/qemu/ram/libvirt/ and QEMU exits with:

memory.c:2053: memory_region_get_ram_ptr: Assertion `mr->ram_block' failed.

I'm dropping this patch :/.

Pavel

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


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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 05:47:40PM +0300, Ivan Mishonov wrote:
> Yes, this is totally doable. I just don't know if it's a good idea to add a
> new device type specifically for bhyve LPC and nothing else. Even if we do
> it like this I'll still have to send another patch including the bhyve XML
> namespace as we need to be able to pass extra command line options to the
> bhyve process related to unimplemented MSRs on AMD Zen systems. I thought
> I'd do the 2 things in a similar manner as both of them are strictly bhyve
> specific

IMHO  the LPC thing is definitely in scope for correct modelling in
the XML.

For the MSRs option, it is probable we'd consider that in scope as
well. Currently KVM has a global "ignore unknown msrs" option in the
kernel module, but I think it is conceptually reasonable to expect
that to be settable on a per-VM basis.

Probably would do the MSRs thing as a  flag, as we stuff
lots of random feature toggles under there

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

Yes, this is totally doable. I just don't know if it's a good idea to 
add a new device type specifically for bhyve LPC and nothing else. Even 
if we do it like this I'll still have to send another patch including 
the bhyve XML namespace as we need to be able to pass extra command line 
options to the bhyve process related to unimplemented MSRs on AMD Zen 
systems. I thought I'd do the 2 things in a similar manner as both of 
them are strictly bhyve specific


Regards,
Ivan

On 08/10/2018 04:58 PM, Daniel P. Berrangé wrote:

On Fri, Aug 10, 2018 at 03:41:09PM +0300, Ivan Mishonov wrote:

This is how it's described in bhyve(8). Basically you need to configure one
for each bhyve VM. Otherwise the VM won't boot. I'm not sure if there's an
equivalent device in other Hypervisors. I've used KVM for quite some time
and didn't need to configure anything similar

lpc LPC PCI-ISA bridge with COM1 and COM2
     16550 serial ports and a boot ROM.
     The LPC bridge emulation can only be
     configured on bus 0.

Ok, so we have the same thing in QEMU, but it is a built-in part of the
machine type which we can't move between different PCI slots, so we have
never had to represent it in the XML.

I think conceptually we'd probably map this to a new controller type eg

   
   
   

So you'd just need to define the new "isa-bridge" controller type for
the parser and have the bhyve driver honour the , if provided.

Regards,
Daniel


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

Re: [libvirt] [PATCH] src: Move DLOPEN_LIBS to libraries introducing the dependency

[Jim Fehlig]

On 08/09/2018 11:45 PM, Michal Privoznik wrote:

There are few places where dlopen() is called. This call means we
have to link with DLOPEN_LIBS. However, instead of having each
final, installable library linking with it, move the directive to
the source that introduced the dependency.

Signed-off-by: Michal Privoznik 


Reviewed-by: Jim Fehlig 


---
  src/Makefile.am  | 2 ++
  src/util/Makefile.inc.am | 1 +
  tools/Makefile.am| 4 ++--
  3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index a4f213480e..61876cf382 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -752,6 +752,7 @@ libvirt_setuid_rpc_client_la_CFLAGS = \
$(AM_CFLAGS) \
$(SECDRIVER_CFLAGS) \
$(XDR_CFLAGS) \
+   $(DLOPEN_LIBS) \
$(NULL)
  endif WITH_SETUID_RPC_CLIENT
  
@@ -1000,6 +1001,7 @@ libvirt_nss_la_CFLAGS = \

$(NULL)
  libvirt_nss_la_LDFLAGS = \
$(AM_LDFLAGS) \
+   $(DLOPEN_LIBS) \
$(NULL)
  endif WITH_NSS
  
diff --git a/src/util/Makefile.inc.am b/src/util/Makefile.inc.am

index 8ef9ee1dfa..c5c50f1844 100644
--- a/src/util/Makefile.inc.am
+++ b/src/util/Makefile.inc.am
@@ -278,6 +278,7 @@ libvirt_util_la_LIBADD = \
$(NUMACTL_LIBS) \
$(ACL_LIBS) \
$(GNUTLS_LIBS) \
+   $(DLOPEN_LIBS) \
$(NULL)
  
  
diff --git a/tools/Makefile.am b/tools/Makefile.am

index 26c887649e..3e129c04c4 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -528,7 +528,7 @@ nss_libnss_libvirt_impl_la_CFLAGS = \
  nss_libnss_libvirt_impl_la_LIBADD = \
../gnulib/lib/libgnu.la \
../src/libvirt-nss.la \
-   $(DLOPEN_LIBS)
+   $(NULL)
  
  nss_libnss_libvirt_la_SOURCES =

  nss_libnss_libvirt_la_LDFLAGS = \
@@ -556,7 +556,7 @@ nss_libnss_libvirt_guest_impl_la_CFLAGS = \
  nss_libnss_libvirt_guest_impl_la_LIBADD = \
../gnulib/lib/libgnu.la \
../src/libvirt-nss.la \
-   $(DLOPEN_LIBS)
+   $(NULL)
  
  nss_libnss_libvirt_guest_la_SOURCES =

  nss_libnss_libvirt_guest_la_LDFLAGS = \



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

Re: [libvirt] [PATCH v2] storage: add wipeVol to iscsi-direct storage backend

[Michal Privoznik]

On 08/10/2018 03:33 PM, c...@lse.epita.fr wrote:
> From: Clementine Hayat 
> 
> Change set volume capacity to get volume capacity and put the connection
> and helpers in one function to avoid code duplicates.
> 
> Signed-off-by: Clementine Hayat 
> ---
> 
> Set BLOCK_PER_PACKET to 128. Not sure about this value. Should be
> potentially tuned.
> 
>  src/storage/storage_backend_iscsi_direct.c | 173 ++---
>  1 file changed, 152 insertions(+), 21 deletions(-)

Apart from Jano's comments 

> 
> diff --git a/src/storage/storage_backend_iscsi_direct.c 
> b/src/storage/storage_backend_iscsi_direct.c
> index 0764356b62..958f5937f9 100644
> --- a/src/storage/storage_backend_iscsi_direct.c
> +++ b/src/storage/storage_backend_iscsi_direct.c
> @@ -41,6 +41,8 @@
>  
>  #define ISCSI_DEFAULT_TARGET_PORT 3260
>  #define VIR_ISCSI_TEST_UNIT_TIMEOUT 30 * 1000
> +#define BLOCK_PER_PACKET 128
> +#define VOL_NAME_PREFIX "unit:0:0:"
>  
>  VIR_LOG_INIT("storage.storage_backend_iscsi_direct");
>  
> @@ -225,7 +227,7 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr 
> pool,
>  {
>  virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
>  
> -if (virAsprintf(>name, "unit:0:0:%u", lun) < 0)
> +if (virAsprintf(>name, "%s%u", VOL_NAME_PREFIX, lun) < 0)
>  return -1;
>  if (virAsprintf(>key, "ip-%s-iscsi-%s-lun-%u", portal,
>  def->source.devices[0].path, lun) < 0)
> @@ -237,13 +239,13 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr 
> pool,
>  }
>  
>  static int
> -virISCSIDirectSetVolumeCapacity(struct iscsi_context *iscsi,
> -virStorageVolDefPtr vol,
> -int lun)
> +virISCSIDirectGetVolumeCapacity(struct iscsi_context *iscsi,
> +int lun,
> +uint32_t *block_size,
> +uint32_t *nb_block)
>  {
>  struct scsi_task *task = NULL;
>  struct scsi_inquiry_standard *inq = NULL;
> -long long size = 0;
>  int ret = -1;
>  
>  if (!(task = iscsi_inquiry_sync(iscsi, lun, 0, 0, 64)) ||
> @@ -282,10 +284,8 @@ virISCSIDirectSetVolumeCapacity(struct iscsi_context 
> *iscsi,
>  goto cleanup;
>  }
>  
> -size  = rc10->block_size;
> -size *= rc10->lba;
> -vol->target.capacity = size;
> -vol->target.allocation = size;
> +*block_size  = rc10->block_size;
> +*nb_block = rc10->lba;
>  
>  }
>  
> @@ -303,6 +303,8 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
>  {
>  virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
>  virStorageVolDefPtr vol = NULL;
> +uint32_t block_size;
> +uint32_t nb_block;
>  int ret = -1;
>  
>  virStoragePoolObjClearVols(pool);
> @@ -314,9 +316,12 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
>  
>  vol->type = VIR_STORAGE_VOL_NETWORK;
>  
> -if (virISCSIDirectSetVolumeCapacity(iscsi, vol, lun) < 0)
> +if (virISCSIDirectGetVolumeCapacity(iscsi, lun,
> +_size, _block) < 0)
>  goto cleanup;
>  
> +vol->target.capacity = block_size * nb_block;
> +vol->target.allocation = block_size * nb_block;
>  def->capacity += vol->target.capacity;
>  def->allocation += vol->target.allocation;
>  
> @@ -553,24 +558,33 @@ virStorageBackendISCSIDirectFindPoolSources(const char 
> *srcSpec,
>  virStoragePoolSourceFree(source);
>  return ret;
>  }
> +static int
> +virStorageBackendISCSIDirectSetConnection(virStoragePoolObjPtr pool,
> +  struct iscsi_context **iscsi,
> +  char **portal)
> +{
> +virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
> +
> +if (!(*iscsi = virISCSIDirectCreateContext(def->source.initiator.iqn)))
> +return -1;
> +if (!(*portal = virStorageBackendISCSIDirectPortal(>source)))
> +return -1;
> +if (virStorageBackendISCSIDirectSetAuth(*iscsi, >source) < 0)
> +return -1;
> +if (virISCSIDirectSetContext(*iscsi, def->source.devices[0].path, 
> ISCSI_SESSION_NORMAL) < 0)
> +return -1;
> +if (virISCSIDirectConnect(*iscsi, *portal) < 0)
> +return -1;
> +return 0;

This function can return iscsi directly. And can accept @portal to be
NULL (in which case caller says "I don't care about portal").

Apart from that the patch looks good.

Michal

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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 03:41:09PM +0300, Ivan Mishonov wrote:
> This is how it's described in bhyve(8). Basically you need to configure one
> for each bhyve VM. Otherwise the VM won't boot. I'm not sure if there's an
> equivalent device in other Hypervisors. I've used KVM for quite some time
> and didn't need to configure anything similar
> 
> lpc LPC PCI-ISA bridge with COM1 and COM2
>     16550 serial ports and a boot ROM.
>     The LPC bridge emulation can only be
>     configured on bus 0.

Ok, so we have the same thing in QEMU, but it is a built-in part of the
machine type which we can't move between different PCI slots, so we have
never had to represent it in the XML.

I think conceptually we'd probably map this to a new controller type eg

  
  
  

So you'd just need to define the new "isa-bridge" controller type for
the parser and have the bhyve driver honour the , if provided.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[libvirt] [jenkins-ci PATCH] projects: Document rationale for skipping jobs

[Andrea Bolognani]

In general, we strive for full coverage and build all
projects on all targets; however, in some cases that's
simply not feasible and we have to skip the corresponding
job. Document the rationale for each such case.

Signed-off-by: Andrea Bolognani 
---
 projects/libvirt-dbus.yaml| 3 +++
 projects/libvirt-sandbox.yaml | 3 +++
 projects/libvirt-tck.yaml | 2 ++
 projects/libvirt.yaml | 2 ++
 projects/virt-manager.yaml| 1 +
 projects/virt-viewer.yaml | 2 ++
 6 files changed, 13 insertions(+)

diff --git a/projects/libvirt-dbus.yaml b/projects/libvirt-dbus.yaml
index 3212465..88b4c88 100644
--- a/projects/libvirt-dbus.yaml
+++ b/projects/libvirt-dbus.yaml
@@ -18,6 +18,9 @@
 - libvirt-freebsd-11
   - autotools-check-job:
   parent_jobs: 'libvirt-dbus-master-build'
+  # libvirt-dbus' test suite uses Python 3, but Debian 8 doesn't
+  # include a recent enough version and CentOS 7 doesn't include
+  # Python 3 at all
   machines:
 - libvirt-debian-9
 - libvirt-fedora-27
diff --git a/projects/libvirt-sandbox.yaml b/projects/libvirt-sandbox.yaml
index da9bf77..6a474c8 100644
--- a/projects/libvirt-sandbox.yaml
+++ b/projects/libvirt-sandbox.yaml
@@ -1,6 +1,9 @@
 
 - project:
 name: libvirt-sandbox
+# libvirt-sandbox is Linux only; among Linux platforms, CentOS 7 has
+# to be excluded because it doesn't ship a version of xz suitable for
+# statically linking against
 machines:
   - libvirt-debian-8
   - libvirt-debian-9
diff --git a/projects/libvirt-tck.yaml b/projects/libvirt-tck.yaml
index c406fda..38f8c09 100644
--- a/projects/libvirt-tck.yaml
+++ b/projects/libvirt-tck.yaml
@@ -1,6 +1,8 @@
 
 - project:
 name: libvirt-tck
+# CentOS 7 doesn't include perl-generators, which is necessary to
+# build libvirt-tck
 machines:
   - libvirt-debian-8
   - libvirt-debian-9
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
index c64ac5b..ce4698e 100644
--- a/projects/libvirt.yaml
+++ b/projects/libvirt.yaml
@@ -10,6 +10,8 @@
   parent_jobs:
   - autotools-syntax-check-job:
   parent_jobs: 'libvirt-master-build'
+  # We limit syntax-check to Linux platforms because it calls some
+  # commands with more arguments than FreeBSD supports
   machines:
 - libvirt-centos-7
 - libvirt-debian-8
diff --git a/projects/virt-manager.yaml b/projects/virt-manager.yaml
index 84a95a6..6f806af 100644
--- a/projects/virt-manager.yaml
+++ b/projects/virt-manager.yaml
@@ -1,6 +1,7 @@
 
 - project:
 name: virt-manager
+# virt-manager is Python 3 only, so it can't be built on CentOS 7
 machines:
   - libvirt-debian-9
   - libvirt-fedora-27
diff --git a/projects/virt-viewer.yaml b/projects/virt-viewer.yaml
index e68a23b..9188239 100644
--- a/projects/virt-viewer.yaml
+++ b/projects/virt-viewer.yaml
@@ -13,6 +13,8 @@
   parent_jobs: 'virt-viewer-master-syntax-check'
   - autotools-rpm-job:
   parent_jobs: 'virt-viewer-master-check'
+  # The spec file for virt-viewer requires a very recent version
+  # of spice-gtk, so we have to skip this job on older distros
   machines:
 - libvirt-fedora-28
 - libvirt-fedora-rawhide
-- 
2.17.1

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

Re: [libvirt] [PATCH v2] storage: add wipeVol to iscsi-direct storage backend

[Ján Tomko]

On Fri, Aug 10, 2018 at 03:33:59PM +0200, c...@lse.epita.fr wrote:

From: Clementine Hayat 

Change set volume capacity to get volume capacity and put the connection
and helpers in one function to avoid code duplicates.


virStorageBackendISCSIDirectSetConnection addition should be in a
separate commit. And the Set->Get change in another one, leaving just
the wipeVol addition here.

For more on splitting changes into commits, see:
https://www.berrange.com/posts/2012/06/27/thoughts-on-improving-openstack-git-commit-practicehistory/

Jano



Signed-off-by: Clementine Hayat 
---

Set BLOCK_PER_PACKET to 128. Not sure about this value. Should be
potentially tuned.

src/storage/storage_backend_iscsi_direct.c | 173 ++---
1 file changed, 152 insertions(+), 21 deletions(-)



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

Re: [libvirt] [PATCH 1/2] Add API for printing tables.

[Michal Privoznik]

On 08/10/2018 11:11 AM, Simon Kobyda wrote:
> It solves problems with alignment of columns. Width of each column
> is calculated by its biggest cell. Should solve unicode bug.
> In future, it may be implemented in virsh, virt-admin...
> 
> This API has 5 public functions:
> - vshTableNew - adds new table and defines its header
> - vshTableRowAppend - appends new row (for same number of columns as in
> header)
> - vshTablePrintToStdout
> - vshTablePrintToString
> - vshTableFree
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1574624
> https://bugzilla.redhat.com/show_bug.cgi?id=1584630
> 
> Signed-off-by: Simon Kobyda 
> ---
>  tools/Makefile.am |   4 +-
>  tools/vsh-table.c | 367 ++
>  tools/vsh-table.h |  42 ++
>  3 files changed, 412 insertions(+), 1 deletion(-)
>  create mode 100644 tools/vsh-table.c
>  create mode 100644 tools/vsh-table.h
> 

Missing cover letter. When sending more than one patch it's necessary.
Also the patch should have "vsh: " prefix so that it's obvious what part
of the ever growing source it's touching.

> diff --git a/tools/Makefile.am b/tools/Makefile.am
> index 26c887649e..ed23575aa7 100644
> --- a/tools/Makefile.am
> +++ b/tools/Makefile.am
> @@ -144,7 +144,9 @@ libvirt_shell_la_LIBADD = \
>   $(READLINE_LIBS) \
>   ../gnulib/lib/libgnu.la \
>   $(NULL)
> -libvirt_shell_la_SOURCES = vsh.c vsh.h
> +libvirt_shell_la_SOURCES = \
> + vsh.c vsh.h \
> + vsh-table.c vsh-table.h
>  
>  virt_host_validate_SOURCES = \
>   virt-host-validate.c \
> diff --git a/tools/vsh-table.c b/tools/vsh-table.c
> new file mode 100644
> index 00..11dc807ba9
> --- /dev/null
> +++ b/tools/vsh-table.c
> @@ -0,0 +1,367 @@
> +/*
> + * vsh-table.c: table printing helper
> + *
> + * Copyright (C) 2018 Red Hat, Inc.
> + *
> + * 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
> + * .
> + *
> + * Authors:
> + *   Simon Kobyda 
> + *
> + */
> +
> +#include 
> +#include "vsh-table.h"
> +#include "virsh-util.h"
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "viralloc.h"
> +#include "virbuffer.h"
> +#include "virstring.h"

Nit pick, we tend to include system headers first and only after that
the local ones.

> +
> +typedef void (*vshPrintCB)(vshControl *ctl, const char *fmt, ...);
> +
> +struct _vshTableRow {
> +char **cells;
> +size_t ncells;
> +};
> +
> +struct _vshTable {
> +vshTableRowPtr *rows;
> +size_t nrows;
> +};
> +
> +static void
> +vshTableRowFree(vshTableRowPtr row)
> +{
> +size_t i;
> +
> +if (!row)
> +return;
> +
> +for (i = 0; i < row->ncells; i++)
> +VIR_FREE(row->cells[i]);
> +
> +VIR_FREE(row->cells);
> +VIR_FREE(row);
> +}
> +
> +void
> +vshTableFree(vshTablePtr table)
> +{
> +size_t i;
> +
> +if (!table)
> +return;
> +
> +for (i = 0; i < table->nrows; i++)
> +vshTableRowFree(table->rows[i]);
> +VIR_FREE(table->rows);
> +VIR_FREE(table);
> +}
> +
> +/**
> + * vshTableRowNew:
> + * @size: expected number of cells in row.
> + * @arg: the first argument.
> + * @ap: list of variadic arguments
> + *
> + * Creates a new row in the table. Each argument passed
> + * represents a cell in the row. If the number of cells is not
> + * equal to @size, then NULL is returned.  However, if @size is
> + * equal to 0, the aforementioned check is suppressed.
> + *
> + * Returns: pointer to vshTableRowPtr row or NULL.
> + */
> +static vshTableRowPtr
> +vshTableRowNew(size_t size, const char *arg, va_list ap)

I know we discussed this in person, but now that I see this code and
think about it more I think this @size argument should be dropped from
this function and the corresponding check should be moved to [1]

> +{
> +vshTableRowPtr row = NULL;
> +char *tmp = NULL;
> +
> +if (!arg) {
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +_("Table row cannot be empty"));
> +goto error;
> +}
> +
> +if (VIR_ALLOC(row) < 0)
> +goto error;
> +
> +while (arg) {
> +if (VIR_STRDUP(tmp, arg) < 0)
> +goto error;
> +
> +if (VIR_APPEND_ELEMENT(row->cells, row->ncells, tmp) < 0)
> +goto error;
> +
> +arg = va_arg(ap, const char *);
> +}
> +
> +

Re: [libvirt] [PATCH 2/2] virsh: Implement new table API for virsh list

[Michal Privoznik]

On 08/10/2018 11:11 AM, Simon Kobyda wrote:
> Instead of printing it straight in virsh, it creates table struct
> which is filled with header and rows(domains). It allows us to know
> more about table before printing to calculate alignment right.
> 
> Signed-off-by: Simon Kobyda 
> ---
>  tools/virsh-domain-monitor.c | 39 ++--
>  1 file changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c
> index b9b4f9739b..f6842877f5 100644
> --- a/tools/virsh-domain-monitor.c
> +++ b/tools/virsh-domain-monitor.c
> @@ -39,6 +39,7 @@
>  #include "virmacaddr.h"
>  #include "virxml.h"
>  #include "virstring.h"
> +#include "vsh-table.h"
>  
>  VIR_ENUM_DECL(virshDomainIOError)
>  VIR_ENUM_IMPL(virshDomainIOError,
> @@ -1901,6 +1902,7 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
>  char id_buf[INT_BUFSIZE_BOUND(unsigned int)];
>  unsigned int id;
>  unsigned int flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE;
> +vshTablePtr table = NULL;
>  
>  /* construct filter flags */
>  if (vshCommandOptBool(cmd, "inactive") ||
> @@ -1940,15 +1942,12 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
>  /* print table header in legacy mode */
>  if (optTable) {
>  if (optTitle)
> -vshPrintExtra(ctl, " %-5s %-30s %-10s %-20s\n%s\n",
> -  _("Id"), _("Name"), _("State"), _("Title"),
> -  "-"
> -  "-");
> +table = vshTableNew("Id", "Name", "State", "Title", NULL);
>  else
> -vshPrintExtra(ctl, " %-5s %-30s %s\n%s\n",
> -  _("Id"), _("Name"), _("State"),
> -  "-"
> -  "---");
> +table = vshTableNew("Id", "Name", "State", NULL);
> +
> +if (!table)
> +goto cleanup;
>  }
>  
>  for (i = 0; i < list->ndomains; i++) {
> @@ -1973,20 +1972,18 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
>  if (optTitle) {
>  if (!(title = virshGetDomainDescription(ctl, dom, true, 0)))
>  goto cleanup;
> -
> -vshPrint(ctl, " %-5s %-30s %-10s %-20s\n", id_buf,
> - virDomainGetName(dom),
> - state == -2 ? _("saved")
> - : virshDomainStateToString(state),
> - title);
> -
> +vshTableRowAppend(table, id_buf, virDomainGetName(dom),
> +  state == -2 ? _("saved")
> +  : virshDomainStateToString(state),
> +  title, NULL);

You need to check for vshTableRowAppend() retval here.

>  VIR_FREE(title);
>  } else {
> -vshPrint(ctl, " %-5s %-30s %s\n", id_buf,
> - virDomainGetName(dom),
> - state == -2 ? _("saved")
> - : virshDomainStateToString(state));
> +vshTableRowAppend(table, id_buf, virDomainGetName(dom),
> +  state == -2 ? _("saved")
> +  : virshDomainStateToString(state),
> +  NULL);

Another approach might be to initialize title to NULL, and then set it
iff optTitle and then call:

   vshTableRowAppend(table, id_buf, virDomainGetName(dom),
 state == -2 ? _("saved")
 : virshDomainStateToString(state),
 title, NULL);


Anyway, the rest looks good.

Michal

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

[libvirt] [jenkins-ci PATCH 1/5] jobs: Call rpmbuild explicitly for Python projects

[Andrea Bolognani]

Instead of using the custom 'rpm' target of setup.py,
generate a dist archive using the 'sdist' target and then
call rpmbuild ourselves: this way we can define _topdir
and stop artifacts from ending up in ~/rpmbuild.

Signed-off-by: Andrea Bolognani 
---
 jobs/python-distutils.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/jobs/python-distutils.yaml b/jobs/python-distutils.yaml
index 0b20b17..5601d26 100644
--- a/jobs/python-distutils.yaml
+++ b/jobs/python-distutils.yaml
@@ -122,7 +122,9 @@
   {global_env}
   {local_env}
   sed -i -e 's/BuildRequires: libvirt.*devel.*//' *.spec.in
-  $PYTHON ./setup.py rpm
+  rm -f dist/*.tar.{{ archive_format }}
+  $PYTHON ./setup.py sdist
+  rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta dist/*.tar.{{ 
archive_format }}
 publishers:
   - email:
   recipients: '{obj:spam}'
-- 
2.17.1

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

[libvirt] [jenkins-ci PATCH 4/5] jobs: Minimize strip_buildrequires

[Andrea Bolognani]

We can drop some entries and tweak some others to be
less verbose without losing in functionality.

Signed-off-by: Andrea Bolognani 
---
 jobs/defaults.yaml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml
index e4d1f2c..bab5bc4 100644
--- a/jobs/defaults.yaml
+++ b/jobs/defaults.yaml
@@ -24,11 +24,9 @@
 global_env: |
 local_env: |
 strip_buildrequires: |
-  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
-  sed -i -e 's/BuildRequires: *osinfo-db-tools.*//' *.spec*
+  sed -i -e 's/BuildRequires: *libvirt.*//' *.spec*
   sed -i -e 's/BuildRequires: *osinfo-db.*//' *.spec*
   sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec*
-  sed -i -e 's/BuildRequires: *perl-Sys-Virt.*//' *.spec*
   sed -i -e 's/BuildRequires: *pkgconfig(libvirt.*).*//' *.spec*
 mingw32_local_env: |
   export VIRT_PREFIX="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw"
-- 
2.17.1

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

[libvirt] [jenkins-ci PATCH 3/5] jobs: Introduce strip_buildrequires

[Andrea Bolognani]

There's no harm in attempting to strip more BuildRequires
than are present in a spec file, so define a shell snippet
we can reuse for the the purpose without duplicating the
same lines all over the place.

Signed-off-by: Andrea Bolognani 
---
 jobs/autotools.yaml| 4 +---
 jobs/defaults.yaml | 7 +++
 jobs/perl-modulebuild.yaml | 4 +---
 jobs/python-distutils.yaml | 2 +-
 projects/osinfo-db.yaml| 2 +-
 5 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml
index ebf5bd8..f8a7e87 100644
--- a/jobs/autotools.yaml
+++ b/jobs/autotools.yaml
@@ -167,9 +167,7 @@
   {global_env}
   {local_env}
   cd build
-  sed -i -e 's/BuildRequires: *osinfo-db.*//' *.spec*
-  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
-  sed -i -e 's/BuildRequires: *pkgconfig(libvirt.*).*//' *.spec*
+  {strip_buildrequires}
   rm -f *.tar.{archive_format}
   $MAKE dist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
*.tar.{archive_format}
diff --git a/jobs/defaults.yaml b/jobs/defaults.yaml
index eb04f32..e4d1f2c 100644
--- a/jobs/defaults.yaml
+++ b/jobs/defaults.yaml
@@ -23,6 +23,13 @@
 archive_format: gz
 global_env: |
 local_env: |
+strip_buildrequires: |
+  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
+  sed -i -e 's/BuildRequires: *osinfo-db-tools.*//' *.spec*
+  sed -i -e 's/BuildRequires: *osinfo-db.*//' *.spec*
+  sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec*
+  sed -i -e 's/BuildRequires: *perl-Sys-Virt.*//' *.spec*
+  sed -i -e 's/BuildRequires: *pkgconfig(libvirt.*).*//' *.spec*
 mingw32_local_env: |
   export VIRT_PREFIX="$VIRT_PREFIX/i686-w64-mingw32/sys-root/mingw"
   export PKG_CONFIG_PATH="$VIRT_PREFIX/lib/pkgconfig"
diff --git a/jobs/perl-modulebuild.yaml b/jobs/perl-modulebuild.yaml
index 93f7054..8b30d7e 100644
--- a/jobs/perl-modulebuild.yaml
+++ b/jobs/perl-modulebuild.yaml
@@ -121,9 +121,7 @@
   - shell: |
   {global_env}
   {local_env}
-  sed -i -e 's/BuildRequires: *perl-Sys-Virt.*//' *.spec*
-  sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec*
-  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
+  {strip_buildrequires}
   rm -f *.tar.{archive_format}
   perl Build dist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
*.tar.{archive_format}
diff --git a/jobs/python-distutils.yaml b/jobs/python-distutils.yaml
index 2cdf25b..eae5b6f 100644
--- a/jobs/python-distutils.yaml
+++ b/jobs/python-distutils.yaml
@@ -121,7 +121,7 @@
   - shell: |
   {global_env}
   {local_env}
-  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
+  {strip_buildrequires}
   rm -f dist/*.tar.{{ archive_format }}
   $PYTHON ./setup.py sdist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta dist/*.tar.{{ 
archive_format }}
diff --git a/projects/osinfo-db.yaml b/projects/osinfo-db.yaml
index b8b609e..7ee84a3 100644
--- a/projects/osinfo-db.yaml
+++ b/projects/osinfo-db.yaml
@@ -19,5 +19,5 @@
   parent_jobs: 'osinfo-db-master-check'
   machines: '{rpm_machines}'
   command: |
-sed -i -e 's/BuildRequires: *osinfo-db-tools.*//' *.spec*
+{strip_buildrequires}
 rpmbuild --clean --define "_topdir `pwd`/rpmbuild" --define 
"_sourcedir `pwd`" -ba osinfo-db.spec
-- 
2.17.1

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

[libvirt] [jenkins-ci PATCH 5/5] jobs: Don't remove non-existing archives

[Andrea Bolognani]

None of our jobs create the archives as a side-effect, so
trying to remove them before generating them is pointless.

Signed-off-by: Andrea Bolognani 
---
 jobs/autotools.yaml| 1 -
 jobs/perl-modulebuild.yaml | 1 -
 jobs/python-distutils.yaml | 1 -
 3 files changed, 3 deletions(-)

diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml
index f8a7e87..4e075bd 100644
--- a/jobs/autotools.yaml
+++ b/jobs/autotools.yaml
@@ -168,7 +168,6 @@
   {local_env}
   cd build
   {strip_buildrequires}
-  rm -f *.tar.{archive_format}
   $MAKE dist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
*.tar.{archive_format}
 publishers:
diff --git a/jobs/perl-modulebuild.yaml b/jobs/perl-modulebuild.yaml
index 8b30d7e..855e6ba 100644
--- a/jobs/perl-modulebuild.yaml
+++ b/jobs/perl-modulebuild.yaml
@@ -122,7 +122,6 @@
   {global_env}
   {local_env}
   {strip_buildrequires}
-  rm -f *.tar.{archive_format}
   perl Build dist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
*.tar.{archive_format}
 publishers:
diff --git a/jobs/python-distutils.yaml b/jobs/python-distutils.yaml
index eae5b6f..e640434 100644
--- a/jobs/python-distutils.yaml
+++ b/jobs/python-distutils.yaml
@@ -122,7 +122,6 @@
   {global_env}
   {local_env}
   {strip_buildrequires}
-  rm -f dist/*.tar.{{ archive_format }}
   $PYTHON ./setup.py sdist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta dist/*.tar.{{ 
archive_format }}
 publishers:
-- 
2.17.1

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

[libvirt] [jenkins-ci PATCH 2/5] jobs: Call rpmbuild and sed consistently

[Andrea Bolognani]

Doing so will allow us to refactor away the common parts.

Signed-off-by: Andrea Bolognani 
---
 jobs/autotools.yaml| 8 
 jobs/perl-modulebuild.yaml | 6 +++---
 jobs/python-distutils.yaml | 2 +-
 projects/osinfo-db.yaml| 2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/jobs/autotools.yaml b/jobs/autotools.yaml
index f1ebf7b..ebf5bd8 100644
--- a/jobs/autotools.yaml
+++ b/jobs/autotools.yaml
@@ -167,12 +167,12 @@
   {global_env}
   {local_env}
   cd build
-  sed -i -e 's/BuildRequires: osinfo-db.*//' {name}.spec
-  sed -i -e 's/BuildRequires: libvirt.*devel.*//' {name}.spec
-  sed -i -e 's/BuildRequires: pkgconfig(libvirt.*).*//' {name}.spec
+  sed -i -e 's/BuildRequires: *osinfo-db.*//' *.spec*
+  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
+  sed -i -e 's/BuildRequires: *pkgconfig(libvirt.*).*//' *.spec*
   rm -f *.tar.{archive_format}
   $MAKE dist
-  rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
{name}-*.tar.{archive_format}
+  rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
*.tar.{archive_format}
 publishers:
   - email:
   recipients: '{obj:spam}'
diff --git a/jobs/perl-modulebuild.yaml b/jobs/perl-modulebuild.yaml
index 3f3f537..93f7054 100644
--- a/jobs/perl-modulebuild.yaml
+++ b/jobs/perl-modulebuild.yaml
@@ -121,9 +121,9 @@
   - shell: |
   {global_env}
   {local_env}
-  sed -i -e 's/BuildRequires: *perl-Sys-Virt.*//' *.spec
-  sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec
-  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec
+  sed -i -e 's/BuildRequires: *perl-Sys-Virt.*//' *.spec*
+  sed -i -e 's/BuildRequires: *perl(Sys::Virt).*//' *.spec*
+  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
   rm -f *.tar.{archive_format}
   perl Build dist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta 
*.tar.{archive_format}
diff --git a/jobs/python-distutils.yaml b/jobs/python-distutils.yaml
index 5601d26..2cdf25b 100644
--- a/jobs/python-distutils.yaml
+++ b/jobs/python-distutils.yaml
@@ -121,7 +121,7 @@
   - shell: |
   {global_env}
   {local_env}
-  sed -i -e 's/BuildRequires: libvirt.*devel.*//' *.spec.in
+  sed -i -e 's/BuildRequires: *libvirt.*devel.*//' *.spec*
   rm -f dist/*.tar.{{ archive_format }}
   $PYTHON ./setup.py sdist
   rpmbuild --clean --define "_topdir `pwd`/rpmbuild" -ta dist/*.tar.{{ 
archive_format }}
diff --git a/projects/osinfo-db.yaml b/projects/osinfo-db.yaml
index d154c98..b8b609e 100644
--- a/projects/osinfo-db.yaml
+++ b/projects/osinfo-db.yaml
@@ -19,5 +19,5 @@
   parent_jobs: 'osinfo-db-master-check'
   machines: '{rpm_machines}'
   command: |
-perl -i -p -e 's/BuildRequires: osinfo-db-tools.*//' osinfo-db.spec
+sed -i -e 's/BuildRequires: *osinfo-db-tools.*//' *.spec*
 rpmbuild --clean --define "_topdir `pwd`/rpmbuild" --define 
"_sourcedir `pwd`" -ba osinfo-db.spec
-- 
2.17.1

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

[libvirt] [jenkins-ci PATCH 0/5] Drop last use of ~/rpmbuild, other cleanups

[Andrea Bolognani]

Patch 1/5 ensures ~/rpmbuild is no longer used, while the
remaining ones increase consistency in the various rules
used to build RPMs.

Andrea Bolognani (5):
  jobs: Call rpmbuild explicitly for Python projects
  jobs: Call rpmbuild and sed consistently
  jobs: Introduce strip_buildrequires
  jobs: Minimize strip_buildrequires
  jobs: Don't remove non-existing archives

 jobs/autotools.yaml| 7 ++-
 jobs/defaults.yaml | 5 +
 jobs/perl-modulebuild.yaml | 5 +
 jobs/python-distutils.yaml | 5 +++--
 projects/osinfo-db.yaml| 2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.17.1

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

[libvirt] [PATCH v2] storage: add wipeVol to iscsi-direct storage backend

[clem]

From: Clementine Hayat 

Change set volume capacity to get volume capacity and put the connection
and helpers in one function to avoid code duplicates.

Signed-off-by: Clementine Hayat 
---

Set BLOCK_PER_PACKET to 128. Not sure about this value. Should be
potentially tuned.

 src/storage/storage_backend_iscsi_direct.c | 173 ++---
 1 file changed, 152 insertions(+), 21 deletions(-)

diff --git a/src/storage/storage_backend_iscsi_direct.c 
b/src/storage/storage_backend_iscsi_direct.c
index 0764356b62..958f5937f9 100644
--- a/src/storage/storage_backend_iscsi_direct.c
+++ b/src/storage/storage_backend_iscsi_direct.c
@@ -41,6 +41,8 @@
 
 #define ISCSI_DEFAULT_TARGET_PORT 3260
 #define VIR_ISCSI_TEST_UNIT_TIMEOUT 30 * 1000
+#define BLOCK_PER_PACKET 128
+#define VOL_NAME_PREFIX "unit:0:0:"
 
 VIR_LOG_INIT("storage.storage_backend_iscsi_direct");
 
@@ -225,7 +227,7 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr pool,
 {
 virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
 
-if (virAsprintf(>name, "unit:0:0:%u", lun) < 0)
+if (virAsprintf(>name, "%s%u", VOL_NAME_PREFIX, lun) < 0)
 return -1;
 if (virAsprintf(>key, "ip-%s-iscsi-%s-lun-%u", portal,
 def->source.devices[0].path, lun) < 0)
@@ -237,13 +239,13 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr 
pool,
 }
 
 static int
-virISCSIDirectSetVolumeCapacity(struct iscsi_context *iscsi,
-virStorageVolDefPtr vol,
-int lun)
+virISCSIDirectGetVolumeCapacity(struct iscsi_context *iscsi,
+int lun,
+uint32_t *block_size,
+uint32_t *nb_block)
 {
 struct scsi_task *task = NULL;
 struct scsi_inquiry_standard *inq = NULL;
-long long size = 0;
 int ret = -1;
 
 if (!(task = iscsi_inquiry_sync(iscsi, lun, 0, 0, 64)) ||
@@ -282,10 +284,8 @@ virISCSIDirectSetVolumeCapacity(struct iscsi_context 
*iscsi,
 goto cleanup;
 }
 
-size  = rc10->block_size;
-size *= rc10->lba;
-vol->target.capacity = size;
-vol->target.allocation = size;
+*block_size  = rc10->block_size;
+*nb_block = rc10->lba;
 
 }
 
@@ -303,6 +303,8 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
 {
 virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
 virStorageVolDefPtr vol = NULL;
+uint32_t block_size;
+uint32_t nb_block;
 int ret = -1;
 
 virStoragePoolObjClearVols(pool);
@@ -314,9 +316,12 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
 
 vol->type = VIR_STORAGE_VOL_NETWORK;
 
-if (virISCSIDirectSetVolumeCapacity(iscsi, vol, lun) < 0)
+if (virISCSIDirectGetVolumeCapacity(iscsi, lun,
+_size, _block) < 0)
 goto cleanup;
 
+vol->target.capacity = block_size * nb_block;
+vol->target.allocation = block_size * nb_block;
 def->capacity += vol->target.capacity;
 def->allocation += vol->target.allocation;
 
@@ -553,24 +558,33 @@ virStorageBackendISCSIDirectFindPoolSources(const char 
*srcSpec,
 virStoragePoolSourceFree(source);
 return ret;
 }
+static int
+virStorageBackendISCSIDirectSetConnection(virStoragePoolObjPtr pool,
+  struct iscsi_context **iscsi,
+  char **portal)
+{
+virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
+
+if (!(*iscsi = virISCSIDirectCreateContext(def->source.initiator.iqn)))
+return -1;
+if (!(*portal = virStorageBackendISCSIDirectPortal(>source)))
+return -1;
+if (virStorageBackendISCSIDirectSetAuth(*iscsi, >source) < 0)
+return -1;
+if (virISCSIDirectSetContext(*iscsi, def->source.devices[0].path, 
ISCSI_SESSION_NORMAL) < 0)
+return -1;
+if (virISCSIDirectConnect(*iscsi, *portal) < 0)
+return -1;
+return 0;
+}
 
 static int
 virStorageBackendISCSIDirectRefreshPool(virStoragePoolObjPtr pool)
 {
-virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
 struct iscsi_context *iscsi = NULL;
 char *portal = NULL;
 int ret = -1;
-
-if (!(iscsi = virISCSIDirectCreateContext(def->source.initiator.iqn)))
-goto cleanup;
-if (!(portal = virStorageBackendISCSIDirectPortal(>source)))
-goto cleanup;
-if (virStorageBackendISCSIDirectSetAuth(iscsi, >source) < 0)
-goto cleanup;
-if (virISCSIDirectSetContext(iscsi, def->source.devices[0].path, 
ISCSI_SESSION_NORMAL) < 0)
-goto cleanup;
-if (virISCSIDirectConnect(iscsi, portal) < 0)
+if (virStorageBackendISCSIDirectSetConnection(pool, , ) <0)
 goto cleanup;
 if (virISCSIDirectReportLuns(pool, iscsi, portal) < 0)
 goto disconect;
@@ -584,12 +598,129 @@ 
virStorageBackendISCSIDirectRefreshPool(virStoragePoolObjPtr pool)
 return ret;
 }
 
+static int

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

This is how it's described in bhyve(8). Basically you need to configure 
one for each bhyve VM. Otherwise the VM won't boot. I'm not sure if 
there's an equivalent device in other Hypervisors. I've used KVM for 
quite some time and didn't need to configure anything similar


lpc LPC PCI-ISA bridge with COM1 and COM2
    16550 serial ports and a boot ROM.
    The LPC bridge emulation can only be
    configured on bus 0.
Regards,
Ivan

On 08/10/2018 03:25 PM, Daniel P. Berrangé wrote:

On Fri, Aug 10, 2018 at 03:20:06PM +0300, Ivan Mishonov wrote:

The problem is that LPC is not defined as a device in the XML. Is there a
device type we can use for the LPC slot configuration similarly to disk, NIC
etc? I couldn't find one, but I'm not that familiar with the code so maybe
I'm missing something

What is the LPC ?

Regards,
Daniel


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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 03:20:06PM +0300, Ivan Mishonov wrote:
> The problem is that LPC is not defined as a device in the XML. Is there a
> device type we can use for the LPC slot configuration similarly to disk, NIC
> etc? I couldn't find one, but I'm not that familiar with the code so maybe
> I'm missing something

What is the LPC ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

The problem is that LPC is not defined as a device in the XML. Is there 
a device type we can use for the LPC slot configuration similarly to 
disk, NIC etc? I couldn't find one, but I'm not that familiar with the 
code so maybe I'm missing something


Regards,
Ivan

On 08/10/2018 02:34 PM, Daniel P. Berrangé wrote:

On Fri, Aug 10, 2018 at 02:22:32PM +0300, Ivan Mishonov wrote:

Windows UEFI guests didn't have working keyboard input through VNC
when LPC is on slot 1. The FreeBSD Handbook examples use slot 31
for UEFI guests. Borrowed most of the code from the qemu:commandline
implementation and made LPC slot number configurable e.g.

   


Isn't the LPC slot number just referring to a PCI address slot ?
If so, the XML should be using our PCI addressing data.


Regards,
Daniel


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

Re: [libvirt] [jenkins-ci PATCH 1/6] guests: Don't prepare Ubuntu 16.04 for virt-manager

[Andrea Bolognani]

On Fri, 2018-08-10 at 13:16 +0200, Erik Skultety wrote:
> To be honest, I kinda was counting on you sending a follow-up regardless of
> my comment, because as you said, it's always better to document this properly
> in relevant files :). At the same time though, I needed to experience e.g. the
> failure with missing xz-static on CentOS 7 myself to actually figure out, what
> it is that makes the build fail. So, even though I'm not insisting on you
> changing the commit messages, I think that dropping a note about specific
> missing requirements for a successful build as a justification for those 2
> patches in play won't add much work. Anyhow, my RB still stands.

Note that the ultimate source of truth for which projects can be
successfully built on which platform is the Jenkins configuration,
not the guest configuration, and I'm not touching the former at
all because we were (correctly) already excluding platforms where
we knew the build would fail; this commit and the following one
merely clean up an oversight which caused a few unnecessary
packages to be installed in guests.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [PATCH] storage: add wipeVol to iscsi-direct storage backend

[Michal Privoznik]

On 08/10/2018 01:12 PM, c...@lse.epita.fr wrote:
> From: Clementine Hayat 
> 
> Change set volume capacity to get volume capacity to avoid code
> duplicate.
> 
> Signed-off-by: Clementine Hayat 
> ---
> 
> Set BLOCK_PER_PACKET to 128. Not sure about this value. Should be
> potentially tuned.
> 
>  src/storage/storage_backend_iscsi_direct.c | 152 +++--
>  1 file changed, 143 insertions(+), 9 deletions(-)

This fails 'make syntax-check'. You should see an automated e-mail in a while 
(hopefully patchew is up and running).

> 
> diff --git a/src/storage/storage_backend_iscsi_direct.c 
> b/src/storage/storage_backend_iscsi_direct.c
> index 0764356b62..094425c101 100644
> --- a/src/storage/storage_backend_iscsi_direct.c
> +++ b/src/storage/storage_backend_iscsi_direct.c
> @@ -41,6 +41,7 @@
>  
>  #define ISCSI_DEFAULT_TARGET_PORT 3260
>  #define VIR_ISCSI_TEST_UNIT_TIMEOUT 30 * 1000
> +#define BLOCK_PER_PACKET 128
>  
>  VIR_LOG_INIT("storage.storage_backend_iscsi_direct");
>  
> @@ -237,13 +238,13 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr 
> pool,
>  }
>  
>  static int
> -virISCSIDirectSetVolumeCapacity(struct iscsi_context *iscsi,
> -virStorageVolDefPtr vol,
> -int lun)
> +virISCSIDirectGetVolumeCapacity(struct iscsi_context *iscsi,
> +int lun,
> +uint32_t *block_size,
> +uint32_t *nb_block)
>  {
>  struct scsi_task *task = NULL;
>  struct scsi_inquiry_standard *inq = NULL;
> -long long size = 0;
>  int ret = -1;
>  
>  if (!(task = iscsi_inquiry_sync(iscsi, lun, 0, 0, 64)) ||
> @@ -282,10 +283,8 @@ virISCSIDirectSetVolumeCapacity(struct iscsi_context 
> *iscsi,
>  goto cleanup;
>  }
>  
> -size  = rc10->block_size;
> -size *= rc10->lba;
> -vol->target.capacity = size;
> -vol->target.allocation = size;
> + *block_size  = rc10->block_size;

This is one problem that syntax-check raises. We use spaces, not TABs.

> +*nb_block = rc10->lba;
>  
>  }
>  
> @@ -303,6 +302,8 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
>  {
>  virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
>  virStorageVolDefPtr vol = NULL;
> +uint32_t block_size;
> +uint32_t nb_block;
>  int ret = -1;
>  
>  virStoragePoolObjClearVols(pool);
> @@ -314,9 +315,12 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
>  
>  vol->type = VIR_STORAGE_VOL_NETWORK;
>  
> -if (virISCSIDirectSetVolumeCapacity(iscsi, vol, lun) < 0)
> +if (virISCSIDirectGetVolumeCapacity(iscsi, lun,
> +_size, _block) < 0)
>  goto cleanup;
>  
> +vol->target.capacity = block_size * nb_block;
> +vol->target.allocation = block_size * nb_block;
>  def->capacity += vol->target.capacity;
>  def->allocation += vol->target.allocation;
>  
> @@ -584,12 +588,142 @@ 
> virStorageBackendISCSIDirectRefreshPool(virStoragePoolObjPtr pool)
>  return ret;
>  }
>  
> +static int
> +virStorageBackendISCSIDirectGetLun(virStorageVolDefPtr vol,
> +   int *lun)
> +{
> +char *name = NULL;
> +char **name_split = NULL;
> +int ret = -1;
> +
> +if (VIR_STRDUP(name, vol->name) < 0)
> +return -1;
> +if (!(name_split = virStringSplit(name, ":", 4)))
> +goto cleanup;
> +if (!name_split[3])

This is unsafe. What if name is "a:b"? Then there is not going to be 
name_split[3] and the code crashes.

I think we are just safe with something like this:

diff --git i/src/storage/storage_backend_iscsi_direct.c 
w/src/storage/storage_backend_iscsi_direct.c
index 094425c101..d473366382 100644
--- i/src/storage/storage_backend_iscsi_direct.c
+++ w/src/storage/storage_backend_iscsi_direct.c
@@ -218,6 +218,9 @@ virISCSIDirectTestUnitReady(struct iscsi_context *iscsi,
 return ret;
 }
 
+
+#define VOL_NAME_PREFIX "unit:0:0:"
+
 static int
 virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr pool,
   virStorageVolDefPtr vol,
@@ -226,7 +229,7 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr pool,
 {
 virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
 
-if (virAsprintf(>name, "unit:0:0:%u", lun) < 0)
+if (virAsprintf(>name, VOL_NAME_PREFIX "%u", lun) < 0)
 return -1;
 if (virAsprintf(>key, "ip-%s-iscsi-%s-lun-%u", portal,
 def->source.devices[0].path, lun) < 0)

And then:

const char *name = vol->name;
int ret = -1;

if (!STRPREFIX(name, VOL_NAME_PREFIX)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
   _("Invalid volume name %s"), name);
goto cleanup;
}

name += strlen(VOL_NAME_PREFIX);
if (virStrToLong_i(name, NULL, 10, lun) < 0)
goto cleanup;

ret = 0;
 cleanup:
return ret;


> +

Re: [libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 02:22:32PM +0300, Ivan Mishonov wrote:
> Windows UEFI guests didn't have working keyboard input through VNC
> when LPC is on slot 1. The FreeBSD Handbook examples use slot 31
> for UEFI guests. Borrowed most of the code from the qemu:commandline
> implementation and made LPC slot number configurable e.g. 
>  xmlns:bhyve='http://libvirt.org/schemas/domain/bhyve/1.0'>
>   


Isn't the LPC slot number just referring to a PCI address slot ?
If so, the XML should be using our PCI addressing data.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 10:38:10AM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 10, 2018 at 11:29:30AM +0200, Michal Privoznik wrote:
> > G_ADD_PRIVATE was added in 2.38 and older functions are getting deprecated:
> > https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits
> 
> Our min glib2 version is currently 2.36, since that's what RHEL-7 has.
> 
> So this change would have to increase the min required version too.

We could use some compat magic without making it too horrible:


#if GLIB_CHECK_VERSION(2, 38, 0)
#define G_TYPE_ADD_PRIVATE(klass, typ) \
  (void)klass;

#else

#define G_TYPE_ADD_PRIVATE(klass, typ)  \
 g_type_class_add_private(klass, 
sizeof(GVirConfigDomainChardevSourcePtyPrivate));

#define G_DEFINE_TYPE_WITH_PRIVATE(a, b, c) \
   G_DEFINE_TYPE(a, b, c)

#endif



Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 01:16:20PM +0200, Michal Privoznik wrote:
> On 08/10/2018 01:03 PM, Michal Privoznik wrote:
> > On 08/10/2018 11:38 AM, Daniel P. Berrangé wrote:
> >> On Fri, Aug 10, 2018 at 11:29:30AM +0200, Michal Privoznik wrote:
> >>> G_ADD_PRIVATE was added in 2.38 and older functions are getting 
> >>> deprecated:
> >>> https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits
> >>
> >> Our min glib2 version is currently 2.36, since that's what RHEL-7 has.
> > 
> > That's a bummer. But okay, I'll keep the patch in my local repo until
> > RHEL rebases. But this is breaking build in more modern distros (e.g.
> > Fedora rawhide).
> > 
> > Disabling warnings looks like a temporal workaround to me.
> > 
> 
> Hold on, spice did the same change just a while ago:
> 
> https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=950cf050aed637f8cb72a0f5899f75eeeffd2ebd
> 
> and they are only requiring 2.28 :-) Nevermind.

Looks like they just effectively bumped their min version without
realizing it !


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[libvirt] [PATCH 0/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

Windows UEFI guests didn't have working keyboard input through VNC
when LPC is on slot 1. The FreeBSD Handbook examples use slot 31
for UEFI guests. Borrowed most of the code from the qemu:commandline
implementation and made LPC slot number configurable e.g. 

  

Ivan Mishonov (1):
  bhyve: Make LPC slot number configurable

 docs/schemas/domaincommon.rng | 15 ++
 src/bhyve/bhyve_command.c |  7 ++-
 src/bhyve/bhyve_conf.c| 12 +
 src/bhyve/bhyve_conf.h|  9 
 src/bhyve/bhyve_device.c  | 16 ---
 src/bhyve/bhyve_domain.c  | 86 ++-
 src/bhyve/bhyve_domain.h  |  1 +
 7 files changed, 138 insertions(+), 8 deletions(-)

-- 
2.17.1

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

[libvirt] [PATCH 1/1] bhyve: Make LPC slot number configurable

[Ivan Mishonov]

Signed-off-by: Ivan Mishonov 
---
 docs/schemas/domaincommon.rng | 15 ++
 src/bhyve/bhyve_command.c |  7 ++-
 src/bhyve/bhyve_conf.c| 12 +
 src/bhyve/bhyve_conf.h|  9 
 src/bhyve/bhyve_device.c  | 16 ---
 src/bhyve/bhyve_domain.c  | 86 ++-
 src/bhyve/bhyve_domain.h  |  1 +
 7 files changed, 138 insertions(+), 8 deletions(-)

diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 1a786968cc..102bfbda87 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -75,6 +75,9 @@
 
   
 
+
+  
+
 
   
 
@@ -6015,6 +6018,18 @@
 
   
 
+  
+  
+
+  http://libvirt.org/schemas/domain/bhyve/1.0;>
+
+  
+
+  
+
   
diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
index 802997bd2d..14e5635011 100644
--- a/src/bhyve/bhyve_command.c
+++ b/src/bhyve/bhyve_command.c
@@ -27,6 +27,7 @@
 
 #include "bhyve_capabilities.h"
 #include "bhyve_command.h"
+#include "bhyve_conf.h"
 #include "bhyve_domain.h"
 #include "bhyve_driver.h"
 #include "datatypes.h"
@@ -329,7 +330,11 @@ static int
 bhyveBuildLPCArgStr(const virDomainDef *def ATTRIBUTE_UNUSED,
 virCommandPtr cmd)
 {
-virCommandAddArgList(cmd, "-s", "1,lpc", NULL);
+unsigned int lpcslotnumber = virBhyveGetLPCSlotNumber(def);
+
+virCommandAddArg(cmd, "-s");
+virCommandAddArgFormat(cmd, "%d,lpc", lpcslotnumber);
+
 return 0;
 }
 
diff --git a/src/bhyve/bhyve_conf.c b/src/bhyve/bhyve_conf.c
index 153de7b391..ce234e4546 100644
--- a/src/bhyve/bhyve_conf.c
+++ b/src/bhyve/bhyve_conf.c
@@ -44,6 +44,18 @@ static int virBhyveConfigOnceInit(void)
 
 VIR_ONCE_GLOBAL_INIT(virBhyveConfig)
 
+void bhyveDomainDefFree(bhyveDomainDefPtr def)
+{
+VIR_FREE(def);
+}
+
+int virBhyveGetLPCSlotNumber(const virDomainDef *def) {
+bhyveDomainDefPtr bhyveopts;
+
+bhyveopts = def->namespaceData;
+return bhyveopts ? bhyveopts->lpc_slot_number : 1;
+}
+
 virBhyveDriverConfigPtr
 virBhyveDriverConfigNew(void)
 {
diff --git a/src/bhyve/bhyve_conf.h b/src/bhyve/bhyve_conf.h
index 3f105ace1c..441b7ef2b9 100644
--- a/src/bhyve/bhyve_conf.h
+++ b/src/bhyve/bhyve_conf.h
@@ -29,4 +29,13 @@ virBhyveDriverConfigPtr virBhyveDriverGetConfig(bhyveConnPtr 
driver);
 int virBhyveLoadDriverConfig(virBhyveDriverConfigPtr cfg,
  const char *filename);
 
+typedef struct _bhyveDomainDef bhyveDomainDef;
+typedef bhyveDomainDef *bhyveDomainDefPtr;
+struct _bhyveDomainDef {
+unsigned int lpc_slot_number;
+};
+
+void bhyveDomainDefFree(bhyveDomainDefPtr def);
+int virBhyveGetLPCSlotNumber(const virDomainDef *def);
+
 #endif /* BHYVE_CONF_H */
diff --git a/src/bhyve/bhyve_device.c b/src/bhyve/bhyve_device.c
index 03aa6c93bd..651b8f02f1 100644
--- a/src/bhyve/bhyve_device.c
+++ b/src/bhyve/bhyve_device.c
@@ -22,6 +22,7 @@
 
 #include 
 
+#include "bhyve_conf.h"
 #include "bhyve_device.h"
 #include "domain_addr.h"
 #include "viralloc.h"
@@ -44,14 +45,16 @@ bhyveCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
 
 virDomainPCIAddressSetPtr addrs = opaque;
 virPCIDeviceAddressPtr addr = >addr.pci;
+unsigned int lpcslotnumber = virBhyveGetLPCSlotNumber(def);
 
 if (addr->domain == 0 && addr->bus == 0) {
 if (addr->slot == 0) {
 return 0;
-} else if (addr->slot == 1) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
-   _("PCI bus 0 slot 1 is reserved for the implicit "
- "LPC PCI-ISA bridge"));
+} else if (addr->slot == lpcslotnumber) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+_("PCI bus 0 slot %d is reserved for the implicit "
+  "LPC PCI-ISA bridge"),
+lpcslotnumber);
 return -1;
 }
 }
@@ -95,9 +98,10 @@ bhyveAssignDevicePCISlots(virDomainDefPtr def,
 size_t i;
 virPCIDeviceAddress lpc_addr;
 
-/* explicitly reserve slot 1 for LPC-ISA bridge */
+/* explicitly reserve slot for LPC-ISA bridge */
+unsigned int lpcslotnumber = virBhyveGetLPCSlotNumber(def);
 memset(_addr, 0, sizeof(lpc_addr));
-lpc_addr.slot = 0x1;
+lpc_addr.slot = lpcslotnumber;
 
 if (virDomainPCIAddressReserveAddr(addrs, _addr,
VIR_PCI_CONNECT_TYPE_PCI_DEVICE, 0) < 
0) {
diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c
index 3c23441969..09715f3dd5 100644
--- a/src/bhyve/bhyve_domain.c
+++ b/src/bhyve/bhyve_domain.c
@@ -20,18 +20,23 @@
  * Author: Roman Bogorodskiy
  */
 
+#include 
 #include 
 
+#include "bhyve_conf.h"
 #include "bhyve_device.h"
 #include "bhyve_domain.h"
 #include "bhyve_capabilities.h"
 #include "viralloc.h"
 #include "virlog.h"
+#include "virstring.h"
 
 #define VIR_FROM_THIS VIR_FROM_BHYVE
 
 VIR_LOG_INIT("bhyve.bhyve_domain");

Re: [libvirt] [jenkins-ci PATCH 1/6] guests: Don't prepare Ubuntu 16.04 for virt-manager

[Erik Skultety]

On Fri, Aug 10, 2018 at 12:24:46PM +0200, Andrea Bolognani wrote:
> On Fri, 2018-08-10 at 10:31 +0200, Erik Skultety wrote:
> > On Thu, Aug 09, 2018 at 03:16:38PM +0200, Andrea Bolognani wrote:
> > > virt-manager can't be built successfully on the
> > > platform, so we shouldn't install the corresponding
> > > build dependencies.
> >
> > For the sake of history, it would be nice to be a bit more detailed as why 
> > it
> > can't be built on a specific distro.
>
> As mentioned on IRC, whenever we have to introduce an exception
> to our general "build every project on every platform" mantra, it's
> certainly useful to document the rationale. We have a few examples
> of that happening already, but there's plenty of room for
> improvement as well.
>
> I think that information belongs to the code rather than to the
> commit messages, though. So would you be okay if I pushed these
> patches as-is and posted a follow-up series that adds information
> about all exceptions as comments in the relevant files?

To be honest, I kinda was counting on you sending a follow-up regardless of
my comment, because as you said, it's always better to document this properly
in relevant files :). At the same time though, I needed to experience e.g. the
failure with missing xz-static on CentOS 7 myself to actually figure out, what
it is that makes the build fail. So, even though I'm not insisting on you
changing the commit messages, I think that dropping a note about specific
missing requirements for a successful build as a justification for those 2
patches in play won't add much work. Anyhow, my RB still stands.

Erik

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

Re: [libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Michal Privoznik]

On 08/10/2018 01:03 PM, Michal Privoznik wrote:
> On 08/10/2018 11:38 AM, Daniel P. Berrangé wrote:
>> On Fri, Aug 10, 2018 at 11:29:30AM +0200, Michal Privoznik wrote:
>>> G_ADD_PRIVATE was added in 2.38 and older functions are getting deprecated:
>>> https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits
>>
>> Our min glib2 version is currently 2.36, since that's what RHEL-7 has.
> 
> That's a bummer. But okay, I'll keep the patch in my local repo until
> RHEL rebases. But this is breaking build in more modern distros (e.g.
> Fedora rawhide).
> 
> Disabling warnings looks like a temporal workaround to me.
> 

Hold on, spice did the same change just a while ago:

https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=950cf050aed637f8cb72a0f5899f75eeeffd2ebd

and they are only requiring 2.28 :-) Nevermind.

Michal

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

[libvirt] [PATCH] storage: add wipeVol to iscsi-direct storage backend

[clem]

From: Clementine Hayat 

Change set volume capacity to get volume capacity to avoid code
duplicate.

Signed-off-by: Clementine Hayat 
---

Set BLOCK_PER_PACKET to 128. Not sure about this value. Should be
potentially tuned.

 src/storage/storage_backend_iscsi_direct.c | 152 +++--
 1 file changed, 143 insertions(+), 9 deletions(-)

diff --git a/src/storage/storage_backend_iscsi_direct.c 
b/src/storage/storage_backend_iscsi_direct.c
index 0764356b62..094425c101 100644
--- a/src/storage/storage_backend_iscsi_direct.c
+++ b/src/storage/storage_backend_iscsi_direct.c
@@ -41,6 +41,7 @@
 
 #define ISCSI_DEFAULT_TARGET_PORT 3260
 #define VIR_ISCSI_TEST_UNIT_TIMEOUT 30 * 1000
+#define BLOCK_PER_PACKET 128
 
 VIR_LOG_INIT("storage.storage_backend_iscsi_direct");
 
@@ -237,13 +238,13 @@ virISCSIDirectSetVolumeAttributes(virStoragePoolObjPtr 
pool,
 }
 
 static int
-virISCSIDirectSetVolumeCapacity(struct iscsi_context *iscsi,
-virStorageVolDefPtr vol,
-int lun)
+virISCSIDirectGetVolumeCapacity(struct iscsi_context *iscsi,
+int lun,
+uint32_t *block_size,
+uint32_t *nb_block)
 {
 struct scsi_task *task = NULL;
 struct scsi_inquiry_standard *inq = NULL;
-long long size = 0;
 int ret = -1;
 
 if (!(task = iscsi_inquiry_sync(iscsi, lun, 0, 0, 64)) ||
@@ -282,10 +283,8 @@ virISCSIDirectSetVolumeCapacity(struct iscsi_context 
*iscsi,
 goto cleanup;
 }
 
-size  = rc10->block_size;
-size *= rc10->lba;
-vol->target.capacity = size;
-vol->target.allocation = size;
+   *block_size  = rc10->block_size;
+*nb_block = rc10->lba;
 
 }
 
@@ -303,6 +302,8 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
 {
 virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool);
 virStorageVolDefPtr vol = NULL;
+uint32_t block_size;
+uint32_t nb_block;
 int ret = -1;
 
 virStoragePoolObjClearVols(pool);
@@ -314,9 +315,12 @@ virISCSIDirectRefreshVol(virStoragePoolObjPtr pool,
 
 vol->type = VIR_STORAGE_VOL_NETWORK;
 
-if (virISCSIDirectSetVolumeCapacity(iscsi, vol, lun) < 0)
+if (virISCSIDirectGetVolumeCapacity(iscsi, lun,
+_size, _block) < 0)
 goto cleanup;
 
+vol->target.capacity = block_size * nb_block;
+vol->target.allocation = block_size * nb_block;
 def->capacity += vol->target.capacity;
 def->allocation += vol->target.allocation;
 
@@ -584,12 +588,142 @@ 
virStorageBackendISCSIDirectRefreshPool(virStoragePoolObjPtr pool)
 return ret;
 }
 
+static int
+virStorageBackendISCSIDirectGetLun(virStorageVolDefPtr vol,
+   int *lun)
+{
+char *name = NULL;
+char **name_split = NULL;
+int ret = -1;
+
+if (VIR_STRDUP(name, vol->name) < 0)
+return -1;
+if (!(name_split = virStringSplit(name, ":", 4)))
+goto cleanup;
+if (!name_split[3])
+goto cleanup;
+if (virStrToLong_i(name_split[3], NULL, 10, lun) < 0)
+goto cleanup;
+
+ret = 0;
+ cleanup:
+VIR_FREE(name);
+virStringListFree(name_split);
+printf("\n");
+return ret;
+}
+
+static int
+virStorageBackendISCSIDirectVolWipeZero(virStorageVolDefPtr vol,
+struct iscsi_context *iscsi)
+{
+uint32_t lba = 0;
+uint32_t block_size;
+uint32_t nb_block;
+struct scsi_task *task = NULL;
+int lun = 0;
+int ret = -1;
+unsigned char *data;
+
+if (virStorageBackendISCSIDirectGetLun(vol, ) < 0)
+return ret;
+if (virISCSIDirectTestUnitReady(iscsi, lun) < 0)
+return ret;
+if (virISCSIDirectGetVolumeCapacity(iscsi, lun, _size, _block))
+return ret;
+if (VIR_ALLOC_N(data, block_size * BLOCK_PER_PACKET))
+return ret;
+
+while (lba < nb_block) {
+if (nb_block - lba > block_size * BLOCK_PER_PACKET) {
+if (!(task = iscsi_write10_sync(iscsi, lun, lba, data,
+block_size * BLOCK_PER_PACKET,
+block_size, 0, 0, 0, 0, 0)))
+goto cleanup;
+scsi_free_scsi_task(task);
+   lba += BLOCK_PER_PACKET;
+}
+   else {
+if (!(task = iscsi_write10_sync(iscsi, lun, lba, data, block_size,
+block_size, 0, 0, 0, 0, 0)))
+goto cleanup;
+scsi_free_scsi_task(task);
+   lba++;
+}
+}
+
+ret = 0;
+ cleanup:
+VIR_FREE(data);
+return ret;
+}
+
+static int
+virStorageBackenISCSIDirectWipeVol(virStoragePoolObjPtr pool,
+   virStorageVolDefPtr vol,
+   unsigned int algorithm,
+   unsigned int flags)
+{
+

Re: [libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Michal Privoznik]

On 08/10/2018 11:38 AM, Daniel P. Berrangé wrote:
> On Fri, Aug 10, 2018 at 11:29:30AM +0200, Michal Privoznik wrote:
>> G_ADD_PRIVATE was added in 2.38 and older functions are getting deprecated:
>> https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits
> 
> Our min glib2 version is currently 2.36, since that's what RHEL-7 has.

That's a bummer. But okay, I'll keep the patch in my local repo until
RHEL rebases. But this is breaking build in more modern distros (e.g.
Fedora rawhide).

Disabling warnings looks like a temporal workaround to me.

Michal

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

Re: [libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 10:38:10AM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 10, 2018 at 11:29:30AM +0200, Michal Privoznik wrote:
> > G_ADD_PRIVATE was added in 2.38 and older functions are getting deprecated:
> > https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits
> 
> Our min glib2 version is currently 2.36, since that's what RHEL-7 has.
> 
> So this change would have to increase the min required version too.

Alternatively we could just use pragma to disable the deprecation warnings
around the g_add_private method call


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

Re: [libvirt] [jenkins-ci PATCH 1/6] guests: Don't prepare Ubuntu 16.04 for virt-manager

[Andrea Bolognani]

On Fri, 2018-08-10 at 10:31 +0200, Erik Skultety wrote:
> On Thu, Aug 09, 2018 at 03:16:38PM +0200, Andrea Bolognani wrote:
> > virt-manager can't be built successfully on the
> > platform, so we shouldn't install the corresponding
> > build dependencies.
> 
> For the sake of history, it would be nice to be a bit more detailed as why it
> can't be built on a specific distro.

As mentioned on IRC, whenever we have to introduce an exception
to our general "build every project on every platform" mantra, it's
certainly useful to document the rationale. We have a few examples
of that happening already, but there's plenty of room for
improvement as well.

I think that information belongs to the code rather than to the
commit messages, though. So would you be okay if I pushed these
patches as-is and posted a follow-up series that adds information
about all exceptions as comments in the relevant files?

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [PATCH v1 1/6] virlockspace: Introduce VIR_LOCK_SPACE_ACQUIRE_METADATA flag

[Daniel P . Berrangé]

On Thu, Aug 09, 2018 at 03:34:39PM +0200, Michal Privoznik wrote:
> This flag is going to be used to alter default behaviour of the
> lock. Firstly, it means we will lock different offset in the file
> (offset 1 instead of 0). Secondly, it means the lock acquiring
> will actually wait for the lock to be set (compared to default
> behaviour which is set or error out).
> Signed-off-by: Michal Privoznik 
> ---
>  src/util/virlockspace.c | 40 +---
>  src/util/virlockspace.h |  1 +
>  2 files changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/src/util/virlockspace.c b/src/util/virlockspace.c
> index 3364c843aa..a7ec0c05bf 100644
> --- a/src/util/virlockspace.c
> +++ b/src/util/virlockspace.c
> @@ -111,6 +111,8 @@ static void 
> virLockSpaceResourceFree(virLockSpaceResourcePtr res)
>  VIR_FREE(res);
>  }
>  
> +#define DEFAULT_OFFSET 0
> +#define METADATA_OFFSET 1
>  
>  static virLockSpaceResourcePtr
>  virLockSpaceResourceNew(virLockSpacePtr lockspace,
> @@ -120,6 +122,18 @@ virLockSpaceResourceNew(virLockSpacePtr lockspace,
>  {
>  virLockSpaceResourcePtr res;
>  bool shared = !!(flags & VIR_LOCK_SPACE_ACQUIRE_SHARED);
> +bool metadata = !!(flags & VIR_LOCK_SPACE_ACQUIRE_METADATA);
> +off_t start = DEFAULT_OFFSET;
> +bool waitForLock = false;
> +
> +if (metadata) {
> +/* We want the metadata lock to act like pthread mutex.
> + * This means waiting for the lock to be acquired. */
> +waitForLock = true;
> +
> +/* Also, we are locking different offset. */
> +start = METADATA_OFFSET;
> +}
>  
>  if (VIR_ALLOC(res) < 0)
>  return NULL;
> @@ -157,7 +171,7 @@ virLockSpaceResourceNew(virLockSpacePtr lockspace,
>  goto error;
>  }
>  
> -if (virFileLock(res->fd, shared, 0, 1, false) < 0) {
> +if (virFileLock(res->fd, shared, start, 1, waitForLock) < 0) {
>  if (errno == EACCES || errno == EAGAIN) {
>  virReportError(VIR_ERR_RESOURCE_BUSY,
> _("Lockspace resource '%s' is locked"),
> @@ -204,7 +218,7 @@ virLockSpaceResourceNew(virLockSpacePtr lockspace,
>  goto error;
>  }
>  
> -if (virFileLock(res->fd, shared, 0, 1, false) < 0) {
> +if (virFileLock(res->fd, shared, start, 1, waitForLock) < 0) {
>  if (errno == EACCES || errno == EAGAIN) {
>  virReportError(VIR_ERR_RESOURCE_BUSY,
> _("Lockspace resource '%s' is locked"),
> @@ -621,7 +635,15 @@ int virLockSpaceAcquireResource(virLockSpacePtr 
> lockspace,
>lockspace, resname, flags, (unsigned long long)owner);
>  
>  virCheckFlags(VIR_LOCK_SPACE_ACQUIRE_SHARED |
> -  VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE, -1);
> +  VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE |
> +  VIR_LOCK_SPACE_ACQUIRE_METADATA, -1);
> +
> +if (flags & VIR_LOCK_SPACE_ACQUIRE_METADATA &&
> +flags & VIR_LOCK_SPACE_ACQUIRE_SHARED) {
> +virReportInvalidArg(flags, "%s",
> +_("metadata and shared are mutually exclusive"));
> +return -1;
> +}
>  
>  virMutexLock(>lock);
>  
> @@ -635,10 +657,14 @@ int virLockSpaceAcquireResource(virLockSpacePtr 
> lockspace,
>  
>  goto done;
>  }
> -virReportError(VIR_ERR_RESOURCE_BUSY,
> -   _("Lockspace resource '%s' is locked"),
> -   resname);
> -goto cleanup;
> +
> +if (!(res->flags & VIR_LOCK_SPACE_ACQUIRE_METADATA) ||
> +!(flags & VIR_LOCK_SPACE_ACQUIRE_METADATA)) {
> +virReportError(VIR_ERR_RESOURCE_BUSY,
> +   _("Lockspace resource '%s' is locked"),
> +   resname);
> +goto cleanup;
> +}
>  }
>  
>  if (!(res = virLockSpaceResourceNew(lockspace, resname, flags, owner)))
> diff --git a/src/util/virlockspace.h b/src/util/virlockspace.h
> index 041cf20396..a9a3b2e73f 100644
> --- a/src/util/virlockspace.h
> +++ b/src/util/virlockspace.h
> @@ -45,6 +45,7 @@ int virLockSpaceDeleteResource(virLockSpacePtr lockspace,
>  typedef enum {
>  VIR_LOCK_SPACE_ACQUIRE_SHARED = (1 << 0),
>  VIR_LOCK_SPACE_ACQUIRE_AUTOCREATE = (1 << 1),
> +VIR_LOCK_SPACE_ACQUIRE_METADATA   = (1 << 2),
>  } virLockSpaceAcquireFlags;
>  
>  int virLockSpaceAcquireResource(virLockSpacePtr lockspace,

The virLockSpace code is intended to be a bit more generic than the
locking protocol.

So I'd have a preference for having a VIR_LOCK_SPACE_ACQUIRE_WAIT
flag, and passing in the offset + length to the APIs as parameters.

Just have the "METADATA" concept in the lock driver only, not this
general purpose code.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-  

Re: [libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Daniel P . Berrangé]

On Fri, Aug 10, 2018 at 11:29:30AM +0200, Michal Privoznik wrote:
> G_ADD_PRIVATE was added in 2.38 and older functions are getting deprecated:
> https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits

Our min glib2 version is currently 2.36, since that's what RHEL-7 has.

So this change would have to increase the min required version too.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[libvirt] [libvirt-glib][PATCH] Use new GObject define macros with private

[Michal Privoznik]

G_ADD_PRIVATE was added in 2.38 and older functions are getting deprecated:
https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits

Signed-off-by: Michal Privoznik 
---

This was generated mostly using:

sed -i "s/G_DEFINE_TYPE(/G_DEFINE_TYPE_WITH_PRIVATE(/
sed -i "/^\s\+g_type_class_add_private.*$/ d"

and then adding G_GNUC_UNUSED wherever compiler complained.

 libvirt-gconfig/libvirt-gconfig-capabilities-cpu-feature.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-cpu-model.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-cpu-topology.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-cpu.c | 3 +--
 libvirt-gconfig/libvirt-gconfig-capabilities-guest-arch.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-guest-domain.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-guest-feature.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-guest.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-host-secmodel.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities-host.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-capabilities.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-address-pci.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-address-usb.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-address.c   | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-channel.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-chardev-source-pty.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-chardev-source-spiceport.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-chardev-source-spicevmc.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-chardev-source-unix.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-chardev-source.c| 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-chardev.c   | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-clock.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-console.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-controller-usb.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-controller.c| 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-cpu-feature.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-cpu-model.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-cpu.c   | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-device.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-disk-driver.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-disk.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-filesys.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-graphics-desktop.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-graphics-rdp.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-graphics-sdl.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-graphics-spice.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-graphics-vnc.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-graphics.c  | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-hostdev-pci.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-hostdev.c   | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-input.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-interface-bridge.c  | 5 ++---
 .../libvirt-gconfig-domain-interface-filterref-parameter.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-interface-filterref.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-interface-network.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-interface-user.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-interface.c | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-memballoon.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-os.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-parallel.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-power-management.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-redirdev.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-seclabel.c  | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-serial.c| 5 ++---
 .../libvirt-gconfig-domain-smartcard-host-certificates.c   | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-smartcard-host.c| 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-smartcard-passthrough.c | 5 ++---
 libvirt-gconfig/libvirt-gconfig-domain-smartcard.c | 3 +--
 libvirt-gconfig/libvirt-gconfig-domain-snapshot-disk.c | 5 ++---
 

[libvirt] [PATCH 1/2] Add API for printing tables.

[Simon Kobyda]

It solves problems with alignment of columns. Width of each column
is calculated by its biggest cell. Should solve unicode bug.
In future, it may be implemented in virsh, virt-admin...

This API has 5 public functions:
- vshTableNew - adds new table and defines its header
- vshTableRowAppend - appends new row (for same number of columns as in
header)
- vshTablePrintToStdout
- vshTablePrintToString
- vshTableFree

https://bugzilla.redhat.com/show_bug.cgi?id=1574624
https://bugzilla.redhat.com/show_bug.cgi?id=1584630

Signed-off-by: Simon Kobyda 
---
 tools/Makefile.am |   4 +-
 tools/vsh-table.c | 367 ++
 tools/vsh-table.h |  42 ++
 3 files changed, 412 insertions(+), 1 deletion(-)
 create mode 100644 tools/vsh-table.c
 create mode 100644 tools/vsh-table.h

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 26c887649e..ed23575aa7 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -144,7 +144,9 @@ libvirt_shell_la_LIBADD = \
$(READLINE_LIBS) \
../gnulib/lib/libgnu.la \
$(NULL)
-libvirt_shell_la_SOURCES = vsh.c vsh.h
+libvirt_shell_la_SOURCES = \
+   vsh.c vsh.h \
+   vsh-table.c vsh-table.h
 
 virt_host_validate_SOURCES = \
virt-host-validate.c \
diff --git a/tools/vsh-table.c b/tools/vsh-table.c
new file mode 100644
index 00..11dc807ba9
--- /dev/null
+++ b/tools/vsh-table.c
@@ -0,0 +1,367 @@
+/*
+ * vsh-table.c: table printing helper
+ *
+ * Copyright (C) 2018 Red Hat, Inc.
+ *
+ * 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
+ * .
+ *
+ * Authors:
+ *   Simon Kobyda 
+ *
+ */
+
+#include 
+#include "vsh-table.h"
+#include "virsh-util.h"
+
+#include 
+#include 
+#include 
+
+#include "viralloc.h"
+#include "virbuffer.h"
+#include "virstring.h"
+
+typedef void (*vshPrintCB)(vshControl *ctl, const char *fmt, ...);
+
+struct _vshTableRow {
+char **cells;
+size_t ncells;
+};
+
+struct _vshTable {
+vshTableRowPtr *rows;
+size_t nrows;
+};
+
+static void
+vshTableRowFree(vshTableRowPtr row)
+{
+size_t i;
+
+if (!row)
+return;
+
+for (i = 0; i < row->ncells; i++)
+VIR_FREE(row->cells[i]);
+
+VIR_FREE(row->cells);
+VIR_FREE(row);
+}
+
+void
+vshTableFree(vshTablePtr table)
+{
+size_t i;
+
+if (!table)
+return;
+
+for (i = 0; i < table->nrows; i++)
+vshTableRowFree(table->rows[i]);
+VIR_FREE(table->rows);
+VIR_FREE(table);
+}
+
+/**
+ * vshTableRowNew:
+ * @size: expected number of cells in row.
+ * @arg: the first argument.
+ * @ap: list of variadic arguments
+ *
+ * Creates a new row in the table. Each argument passed
+ * represents a cell in the row. If the number of cells is not
+ * equal to @size, then NULL is returned.  However, if @size is
+ * equal to 0, the aforementioned check is suppressed.
+ *
+ * Returns: pointer to vshTableRowPtr row or NULL.
+ */
+static vshTableRowPtr
+vshTableRowNew(size_t size, const char *arg, va_list ap)
+{
+vshTableRowPtr row = NULL;
+char *tmp = NULL;
+
+if (!arg) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+_("Table row cannot be empty"));
+goto error;
+}
+
+if (VIR_ALLOC(row) < 0)
+goto error;
+
+while (arg) {
+if (VIR_STRDUP(tmp, arg) < 0)
+goto error;
+
+if (VIR_APPEND_ELEMENT(row->cells, row->ncells, tmp) < 0)
+goto error;
+
+arg = va_arg(ap, const char *);
+}
+
+if (size && row->ncells != size) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+_("Incorrect number of cells in a table row"));
+goto error;
+}
+
+return row;
+
+ error:
+vshTableRowFree(row);
+return NULL;
+}
+
+/**
+ * vshTableNew:
+ * @arg: List of column names (NULL terminated)
+ *
+ * Creates a new table.
+ *
+ * Returns: pointer to table or NULL.
+ */
+vshTablePtr
+vshTableNew(const char *arg, ...)
+{
+vshTablePtr table;
+vshTableRowPtr header = NULL;
+va_list ap;
+
+if (VIR_ALLOC(table) < 0)
+goto error;
+
+va_start(ap, arg);
+header = vshTableRowNew(0, arg, ap);
+va_end(ap);
+
+if (!header)
+goto error;
+
+if (VIR_APPEND_ELEMENT(table->rows, table->nrows, header) < 0)
+goto error;
+
+return table;

[libvirt] [PATCH 2/2] virsh: Implement new table API for virsh list

[Simon Kobyda]

Instead of printing it straight in virsh, it creates table struct
which is filled with header and rows(domains). It allows us to know
more about table before printing to calculate alignment right.

Signed-off-by: Simon Kobyda 
---
 tools/virsh-domain-monitor.c | 39 ++--
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c
index b9b4f9739b..f6842877f5 100644
--- a/tools/virsh-domain-monitor.c
+++ b/tools/virsh-domain-monitor.c
@@ -39,6 +39,7 @@
 #include "virmacaddr.h"
 #include "virxml.h"
 #include "virstring.h"
+#include "vsh-table.h"
 
 VIR_ENUM_DECL(virshDomainIOError)
 VIR_ENUM_IMPL(virshDomainIOError,
@@ -1901,6 +1902,7 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
 char id_buf[INT_BUFSIZE_BOUND(unsigned int)];
 unsigned int id;
 unsigned int flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE;
+vshTablePtr table = NULL;
 
 /* construct filter flags */
 if (vshCommandOptBool(cmd, "inactive") ||
@@ -1940,15 +1942,12 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
 /* print table header in legacy mode */
 if (optTable) {
 if (optTitle)
-vshPrintExtra(ctl, " %-5s %-30s %-10s %-20s\n%s\n",
-  _("Id"), _("Name"), _("State"), _("Title"),
-  "-"
-  "-");
+table = vshTableNew("Id", "Name", "State", "Title", NULL);
 else
-vshPrintExtra(ctl, " %-5s %-30s %s\n%s\n",
-  _("Id"), _("Name"), _("State"),
-  "-"
-  "---");
+table = vshTableNew("Id", "Name", "State", NULL);
+
+if (!table)
+goto cleanup;
 }
 
 for (i = 0; i < list->ndomains; i++) {
@@ -1973,20 +1972,18 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
 if (optTitle) {
 if (!(title = virshGetDomainDescription(ctl, dom, true, 0)))
 goto cleanup;
-
-vshPrint(ctl, " %-5s %-30s %-10s %-20s\n", id_buf,
- virDomainGetName(dom),
- state == -2 ? _("saved")
- : virshDomainStateToString(state),
- title);
-
+vshTableRowAppend(table, id_buf, virDomainGetName(dom),
+  state == -2 ? _("saved")
+  : virshDomainStateToString(state),
+  title, NULL);
 VIR_FREE(title);
 } else {
-vshPrint(ctl, " %-5s %-30s %s\n", id_buf,
- virDomainGetName(dom),
- state == -2 ? _("saved")
- : virshDomainStateToString(state));
+vshTableRowAppend(table, id_buf, virDomainGetName(dom),
+  state == -2 ? _("saved")
+  : virshDomainStateToString(state),
+  NULL);
 }
+
 } else if (optUUID && optName) {
 if (virDomainGetUUIDString(dom, uuid) < 0) {
 vshError(ctl, "%s", _("Failed to get domain's UUID"));
@@ -2004,8 +2001,12 @@ cmdList(vshControl *ctl, const vshCmd *cmd)
 }
 }
 
+if (optTable)
+vshTablePrintToStdout(ctl, table);
+
 ret = true;
  cleanup:
+vshTableFree(table);
 virshDomainListFree(list);
 return ret;
 }
-- 
2.17.1

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

Re: [libvirt] [PATCH 05/17] vircgroup: Extract file link resolving into separate function

[Michal Privoznik]

On 08/09/2018 03:44 PM, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
>  src/util/vircgroup.c | 85 +---
>  1 file changed, 48 insertions(+), 37 deletions(-)
> 
> diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c
> index 5144b33d43..fd58ba154f 100644
> --- a/src/util/vircgroup.c
> +++ b/src/util/vircgroup.c
> @@ -356,6 +356,51 @@ virCgroupCopyMounts(virCgroupPtr group,
>  }
>  
>  
> +static int
> +virCgroupResolveMountLink(const char *mntDir,

@mntDir shouldn't be const char. You're changing it in the function,
even though not directly rather than via @dirName.

> +  const char *typeStr,
> +  virCgroupControllerPtr controller)
> +{
> +VIR_AUTOFREE(char *) linkSrc = NULL;
> +char *dirName;
> +struct stat sb;
> +
> +dirName = strrchr(mntDir, '/');
> +if (!dirName) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> +   _("Missing '/' separator in cgroup mount '%s'"), 
> mntDir);
> +return -1;
> +}
> +
> +if (!strchr(dirName + 1, ','))
> +return 0;
> +
> +*dirName = '\0';
> +if (virAsprintf(, "%s/%s", mntDir, typeStr) < 0)
> +return -1;
> +*dirName = '/';

Pre-existing and probably doesn't matter, but if above virAsprintf()
fails, @dirName is not written back and thus @mntDir is left mangled.

> +
> +if (lstat(linkSrc, ) < 0) {
> +if (errno == ENOENT) {
> +VIR_WARN("Controller %s co-mounted at %s is missing symlink at 
> %s",
> + typeStr, mntDir, linkSrc);
> +} else {
> +virReportSystemError(errno, _("Cannot stat %s"), linkSrc);
> +return -1;
> +}
> +} else {
> +if (!S_ISLNK(sb.st_mode)) {
> +VIR_WARN("Expecting a symlink at %s for controller %s",
> + linkSrc, typeStr);
> +} else {
> +VIR_STEAL_PTR(controller->linkPoint, linkSrc);
> +}
> +}
> +
> +return 0;
> +}


Michal

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

Re: [libvirt] [PATCH 16/17] vircgroup: Introduce virCgroupGetMemoryStat

[Michal Privoznik]

On 08/09/2018 03:44 PM, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
>  src/libvirt_private.syms |  1 +
>  src/util/vircgroup.c | 88 
>  src/util/vircgroup.h |  7 
>  3 files changed, 96 insertions(+)
> 
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 59d9bc380e..ee0dca6129 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1532,6 +1532,7 @@ virCgroupGetDomainTotalCpuStats;
>  virCgroupGetFreezerState;
>  virCgroupGetMemoryHardLimit;
>  virCgroupGetMemorySoftLimit;
> +virCgroupGetMemoryStat;
>  virCgroupGetMemoryUsage;
>  virCgroupGetMemSwapHardLimit;
>  virCgroupGetMemSwapUsage;
> diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c
> index 37982a9607..b91acd13c7 100644
> --- a/src/util/vircgroup.c
> +++ b/src/util/vircgroup.c
> @@ -2427,6 +2427,94 @@ virCgroupSetMemory(virCgroupPtr group, unsigned long 
> long kb)
>  }
>  
>  
> +/**
> + * virCgroupGetMemoryStat:
> + *
> + * @group: The cgroup to change memory for
> + * @cache: page cache memory in KiB
> + * @activeAnon: anonymous and swap cache memory in KiB
> + * @inactiveAnon: anonymous and swap cache memory in KiB
> + * @activeFile: file-backed memory in KiB
> + * @inactiveFile: file-backed memory in KiB
> + * @unevictable: memory that cannot be reclaimed KiB
> + *
> + * Returns: 0 on success, -1 on error
> + */
> +int
> +virCgroupGetMemoryStat(virCgroupPtr group,
> +   unsigned long long *cache,
> +   unsigned long long *activeAnon,
> +   unsigned long long *inactiveAnon,
> +   unsigned long long *activeFile,
> +   unsigned long long *inactiveFile,
> +   unsigned long long *unevictable)
> +{
> +int ret = -1;
> +char *stat = NULL;
> +char *line = NULL;
> +unsigned long long cacheVal = 0;
> +unsigned long long activeAnonVal = 0;
> +unsigned long long inactiveAnonVal = 0;
> +unsigned long long activeFileVal = 0;
> +unsigned long long inactiveFileVal = 0;
> +unsigned long long unevictableVal = 0;
> +
> +if (virCgroupGetValueStr(group,
> + VIR_CGROUP_CONTROLLER_MEMORY,
> + "memory.stat",
> + ) < 0) {
> +return -1;
> +}
> +
> +line = stat;
> +
> +while (line) {
> +char *newLine = strchr(line, '\n');
> +char *valueStr = strchr(line, ' ');
> +unsigned long long value;
> +
> +if (newLine)
> +*newLine = '\0';
> +
> +if (!valueStr) {
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +   _("Cannot parse 'memory.stat' cgroup file."));
> +goto cleanup;
> +}
> +*valueStr = '\0';
> +
> +if (virStrToLong_ull(valueStr + 1, NULL, 10, ) < 0)
> +goto cleanup;
> +
> +if (STREQ(line, "cache"))
> +cacheVal = value >> 10;


Can't we assign directly to *cache? Sure, you'd need to initialize it
before, just like you're initializing cacheVal.

Michal

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

Re: [libvirt] [PATCH 00/17] some cgroup cleanup patches

[Michal Privoznik]

On 08/09/2018 03:43 PM, Pavel Hrdina wrote:
> Preparation for cgroupv2 support.
> 
> Pavel Hrdina (17):
>   docs: List cpuacct in controllers used by QEMU driver
>   docs: Update how we create cgroup directory names
>   vircgroup: Rename structs to start with underscore
>   vircgroup: Introduce standard set of typedefs and use them
>   vircgroup: Extract file link resolving into separate function
>   vircgroup: Remove unused function virCgroupKill()
>   vircgroup: Unexport unused function virCgroupAddTaskController()
>   vircgroup: Unexport unused function virCgroupRemoveRecursively
>   vircgroup: Move function used in tests into vircgrouppriv.h
>   vircgroup: Remove pointless bool parameter
>   vircgroup: Extract mount options matching into function
>   vircgroup: Use virCgroupMountOptsMatchController in
> virCgroupDetectPlacement
>   vircgroup: Introduce virCgroupEnableMissingControllers
>   vircgroup: machinename will never be NULL
>   vircgroup: Remove virCgroupAddTaskController
>   vircgroup: Introduce virCgroupGetMemoryStat
>   lxc: Use virCgroupGetMemoryStat
> 
>  docs/cgroups.html.in |  47 ++--
>  src/libvirt_private.syms |   4 +-
>  src/lxc/lxc_cgroup.c |  65 +
>  src/util/vircgroup.c | 521 ---
>  src/util/vircgroup.h |  31 +--
>  src/util/vircgrouppriv.h |  21 +-
>  6 files changed, 330 insertions(+), 359 deletions(-)
> 

ACK series.

Michal

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

Re: [libvirt] [jenkins-ci PATCH 6/6] projects: Build libvirt-dbus on Debian 8

[Erik Skultety]

On Thu, Aug 09, 2018 at 03:16:43PM +0200, Andrea Bolognani wrote:
> As with CentOS 7, we can't run 'make check' on the
> platform because we don't have a recent enough Python
> interpreter, but the daemon itself will build and run
> just fine.
>
> Signed-off-by: Andrea Bolognani 
> ---

collectively to patches [4-6]:
Reviewed-by: Erik Skultety 

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

Re: [libvirt] [jenkins-ci PATCH 2/6] guests: Don't prepare CentOS 7 for libvirt-sandbox

[Erik Skultety]

On Thu, Aug 09, 2018 at 03:16:39PM +0200, Andrea Bolognani wrote:
> libvirt-sandbox can't be built successfully on the
> platform, so we shouldn't install the corresponding
> build dependencies.

Same comment as in patch 1.
With that addressed:
Reviewed-by: Erik Skultety 

>
> Signed-off-by: Andrea Bolognani 
> ---
>  guests/host_vars/libvirt-centos-7/main.yml | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/guests/host_vars/libvirt-centos-7/main.yml 
> b/guests/host_vars/libvirt-centos-7/main.yml
> index 4c80e22..e220849 100644
> --- a/guests/host_vars/libvirt-centos-7/main.yml
> +++ b/guests/host_vars/libvirt-centos-7/main.yml
> @@ -9,7 +9,6 @@ projects:
>- libvirt-go-xml
>- libvirt-perl
>- libvirt-python
> -  - libvirt-sandbox
>- osinfo-db
>- osinfo-db-tools
>- virt-viewer
> --
> 2.17.1
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

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

Re: [libvirt] [jenkins-ci PATCH 1/6] guests: Don't prepare Ubuntu 16.04 for virt-manager

[Erik Skultety]

On Thu, Aug 09, 2018 at 03:16:38PM +0200, Andrea Bolognani wrote:
> virt-manager can't be built successfully on the
> platform, so we shouldn't install the corresponding
> build dependencies.
>

For the sake of history, it would be nice to be a bit more detailed as why it
can't be built on a specific distro.

With that added:
Reviewed-by: Erik Skultety 

> Signed-off-by: Andrea Bolognani 
> ---
>  guests/host_vars/libvirt-ubuntu-16/main.yml | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/guests/host_vars/libvirt-ubuntu-16/main.yml 
> b/guests/host_vars/libvirt-ubuntu-16/main.yml
> index 92296b4..4d9914a 100644
> --- a/guests/host_vars/libvirt-ubuntu-16/main.yml
> +++ b/guests/host_vars/libvirt-ubuntu-16/main.yml
> @@ -12,7 +12,6 @@ projects:
>- libvirt-tck
>- osinfo-db
>- osinfo-db-tools
> -  - virt-manager
>- virt-viewer
>
>  package_format: deb
> --
> 2.17.1
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

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

Re: [libvirt] Missing repo file for virt-preview repo on fedorapeople

[Roman Mohr]

On Fri, Aug 10, 2018 at 10:02 AM Andrea Bolognani 
wrote:

> On Fri, 2018-08-10 at 08:54 +0200, Roman Mohr wrote:
> > Hi everyone,
> >
> > Is there a change on how to get the fedora-virt-preview.repo?
> >
> > So far we were referencing
> >
> >
> https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo
> >
> > but that file does not seem to exist anymore.
>
> Please post this kind of question to libvirt-users next time, and
> refrain from CC'ing libvirt developers - we are all subscribed to
> and read the lists.
>
> As for your question,
>
>   https://fedoraproject.org/wiki/Virtualization_Preview_Repository


Thank you.

Roman

>
>
> (which was the first result when searching "fedora virt-preview"
> with Google) should contain the information you're looking for.
>
> --
> Andrea Bolognani / Red Hat / Virtualization
>
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Missing repo file for virt-preview repo on fedorapeople

[Andrea Bolognani]

On Fri, 2018-08-10 at 08:54 +0200, Roman Mohr wrote:
> Hi everyone,
> 
> Is there a change on how to get the fedora-virt-preview.repo?
> 
> So far we were referencing
> 
> https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo
> 
> but that file does not seem to exist anymore.

Please post this kind of question to libvirt-users next time, and
refrain from CC'ing libvirt developers - we are all subscribed to
and read the lists.

As for your question,

  https://fedoraproject.org/wiki/Virtualization_Preview_Repository

(which was the first result when searching "fedora virt-preview"
with Google) should contain the information you're looking for.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

Re: [libvirt] [PATCH v2 00/20] Fix and improve hugepage code

[Michal Privoznik]

On 08/09/2018 02:38 PM, Pavel Hrdina wrote:
> changes in v2:
> - renamed existing test cases to sensible names
> - split of some existing test cases
> - fixed uncovered issue with memory discard
> 
> v1: https://www.redhat.com/archives/libvir-list/2018-July/msg00667.html
> 
> Pavel Hrdina (20):
>   tests: rename hugepages to hugepages-default
>   tests: extract hugepages-numa-default-dimm out of hugepages-numa
>   tests: rename hugepages-numa into hugepages-numa-default
>   tests: remove unnecessary XML elements from hugepages-numa-default
>   tests: extract pages-discard out of hugepages-pages
>   tests: rename hugepages-pages into hugepages-numa-nodeset
>   tests: rename hugepages-pages2 into hugepages-numa-default-2M
>   tests: extract pages-discard-hugepages out of hugepages-pages3
>   tests: rename hugepages-pages3 into hugepages-numa-nodeset-part
>   tests: rename hugepages-pages4 into hugepages-numa-nodeset-nonexist
>   tests: rename hugepages-pages5 into hugepages-default-2M
>   tests: rename hugepages-pages6 into hugepages-default-system-size
>   tests: rename hugepages-pages7 into pages-dimm-discard
>   tests: rename hugepages-pages8 into hugepages-nodeset-nonexist
>   tests: introduce hugepages-default-1G-nodeset-2M
>   tests: introduce hugepages-nodeset
>   conf: Move hugepage XML validation check out of qemu_command
>   conf: Move hugepages validation out of XML parser
>   conf: Introduce virDomainDefPostParseMemtune
>   qemu: ensure that memory 'discard' is used if specified in XML
> 
>  src/conf/domain_conf.c| 134 +-
>  src/qemu/qemu_command.c   |  38 +
>  ...s => hugepages-default-1G-nodeset-2M.args} |   7 +-
>  .../hugepages-default-1G-nodeset-2M.xml   |  31 
>  ...-pages5.args => hugepages-default-2M.args} |   5 +-
>  ...es-pages5.xml => hugepages-default-2M.xml} |  13 +-
>  .../hugepages-default-system-size.args|  24 
>  xml => hugepages-default-system-size.xml} |  13 +-
>  ...{hugepages.args => hugepages-default.args} |   2 -
>  .../{hugepages.xml => hugepages-default.xml}  |   5 -
>  ...es8.xml => hugepages-nodeset-nonexist.xml} |  13 +-
>  tests/qemuxml2argvdata/hugepages-nodeset.args |  26 
>  tests/qemuxml2argvdata/hugepages-nodeset.xml  |  30 
>  ...s2.args => hugepages-numa-default-2M.args} |   5 +-
>  ...ges2.xml => hugepages-numa-default-2M.xml} |   8 +-
>  args => hugepages-numa-default-dimm.args} |  12 +-
>  .../hugepages-numa-default-dimm.xml   |  45 ++
>  .../hugepages-numa-default.args   |  27 
>  .../hugepages-numa-default.xml|  30 
>  ...ml => hugepages-numa-nodeset-nonexist.xml} |  17 +--
>  args => hugepages-numa-nodeset-part.args} |   8 +-
>  .../hugepages-numa-nodeset-part.xml   |  34 +
>  ...pages.args => hugepages-numa-nodeset.args} |  17 +--
>  ...s-pages.xml => hugepages-numa-nodeset.xml} |  15 +-
>  tests/qemuxml2argvdata/hugepages-numa.args|  63 
>  tests/qemuxml2argvdata/hugepages-numa.xml | 111 ---
>  .../qemuxml2argvdata/pages-dimm-discard.args  |  33 +
>  ...ages-pages7.xml => pages-dimm-discard.xml} |  18 +--
>  .../pages-discard-hugepages.args  |  31 
>  ...pages3.xml => pages-discard-hugepages.xml} |  16 +--
>  tests/qemuxml2argvdata/pages-discard.args |  38 +
>  tests/qemuxml2argvdata/pages-discard.xml  |  36 +
>  .../seclabel-dynamic-none-relabel.xml |   2 +-
>  tests/qemuxml2argvtest.c  |  56 
>  .../hugepages-default-2M.xml  |   1 +
>  .../hugepages-default-system-size.xml |   1 +
>  .../{hugepages.xml => hugepages-default.xml}  |   6 -
>  .../qemuxml2xmloutdata/hugepages-nodeset.xml  |  30 
>  ...ges2.xml => hugepages-numa-default-2M.xml} |  13 +-
>  .../hugepages-numa-default-dimm.xml   |   1 +
>  .../hugepages-numa-nodeset-part.xml   |  36 +
>  ...s-pages.xml => hugepages-numa-nodeset.xml} |  20 +--
>  tests/qemuxml2xmloutdata/hugepages-pages3.xml |  47 --
>  tests/qemuxml2xmloutdata/hugepages-pages4.xml |   1 -
>  tests/qemuxml2xmloutdata/hugepages-pages5.xml |   1 -
>  tests/qemuxml2xmloutdata/hugepages-pages6.xml |   1 -
>  tests/qemuxml2xmloutdata/hugepages-pages7.xml |   1 -
>  .../qemuxml2xmloutdata/pages-dimm-discard.xml |   1 +
>  .../pages-discard-hugepages.xml   |   1 +
>  tests/qemuxml2xmloutdata/pages-discard.xml|   1 +
>  .../seclabel-dynamic-none-relabel.xml |   2 +-
>  tests/qemuxml2xmltest.c   |  19 +--
>  52 files changed, 634 insertions(+), 512 deletions(-)
>  rename tests/qemuxml2argvdata/{hugepages-pages6.args => 
> hugepages-default-1G-nodeset-2M.args} (72%)
>  create mode 100644 tests/qemuxml2argvdata/hugepages-default-1G-nodeset-2M.xml
>  rename tests/qemuxml2argvdata/{hugepages-pages5.args => 
> hugepages-default-2M.args} (75%)
>  rename 

Re: [libvirt] [PATCH v2 20/20] qemu: ensure that memory 'discard' is used if specified in XML

[Michal Privoznik]

On 08/09/2018 02:38 PM, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
>  src/qemu/qemu_command.c|  4 +++-
>  .../pages-discard-hugepages.args   | 11 +++
>  tests/qemuxml2argvdata/pages-discard.args  | 18 ++
>  3 files changed, 24 insertions(+), 9 deletions(-)
> 
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index dbeb3a54f6..a7859feae6 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -3147,6 +3147,7 @@ qemuBuildMemoryBackendProps(virJSONValuePtr 
> *backendProps,
>  return -1;
>  
>  if (useHugepage || mem->nvdimmPath || memAccess ||
> +discard == VIR_TRISTATE_BOOL_YES ||
>  def->mem.source == VIR_DOMAIN_MEMORY_SOURCE_FILE) {
>  
>  if (useHugepage) {
> @@ -3228,7 +3229,8 @@ qemuBuildMemoryBackendProps(virJSONValuePtr 
> *backendProps,
>  if (!needHugepage && !mem->sourceNodes && !nodeSpecified &&
>  !mem->nvdimmPath &&
>  memAccess == VIR_DOMAIN_MEMORY_ACCESS_DEFAULT &&
> -def->mem.source != VIR_DOMAIN_MEMORY_SOURCE_FILE && !force) {
> +def->mem.source != VIR_DOMAIN_MEMORY_SOURCE_FILE && !force &&
> +discard != VIR_TRISTATE_BOOL_YES) {
>  /* report back that using the new backend is not necessary
>   * to achieve the desired configuration */
>  ret = 1;
> diff --git a/tests/qemuxml2argvdata/pages-discard-hugepages.args 
> b/tests/qemuxml2argvdata/pages-discard-hugepages.args
> index 2dfacefe4a..d859480c26 100644
> --- a/tests/qemuxml2argvdata/pages-discard-hugepages.args
> +++ b/tests/qemuxml2argvdata/pages-discard-hugepages.args
> @@ -10,10 +10,13 @@ QEMU_AUDIO_DRV=none \
>  -machine pc,accel=tcg,usb=off,dump-guest-core=off \
>  -m 1024 \
>  -smp 2,sockets=2,cores=1,threads=1 \
> --mem-prealloc \
> --mem-path /dev/hugepages2M/libvirt/qemu/-1-SomeDummyHugepagesGu \
> --numa node,nodeid=0,cpus=0,mem=256 \
> --numa node,nodeid=1,cpus=1,mem=768 \
> +-object memory-backend-file,id=ram-node0,prealloc=yes,\
> +mem-path=/dev/hugepages2M/libvirt/qemu/-1-SomeDummyHugepagesGu,size=268435456
>  \
> +-numa node,nodeid=0,cpus=0,memdev=ram-node0 \
> +-object memory-backend-file,id=ram-node1,prealloc=yes,\
> +mem-path=/dev/hugepages2M/libvirt/qemu/-1-SomeDummyHugepagesGu,\
> +discard-data=yes,size=805306368 \
> +-numa node,nodeid=1,cpus=1,memdev=ram-node1 \

This will break migration. But at the same time, it's very unlikely that
anybody is using discard without hugepages.

Michal

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

Re: [libvirt] [PATCH v3 0/3] Don't touch user data from tests

[Michal Privoznik]

On 07/27/2018 05:24 PM, Michal Privoznik wrote:
> v3 of:
> 
> https://www.redhat.com/archives/libvir-list/2018-July/msg00747.html
> 
> diff to v2:
> - pushed some already ACKed patches
> - dropped controversial line from 1/3 that turned off error reporting
> 
> Michal Prívozník (3):
>   qemuxml2argvtest: Set more fake drivers
>   check-file-access: Allow specifying action
>   virtestmock: Track action
> 
>  tests/check-file-access.pl  | 32 +++-
>  tests/file_access_whitelist.txt | 15 ++-
>  tests/qemuxml2argvtest.c|  4 
>  tests/virtestmock.c | 39 ++-
>  4 files changed, 63 insertions(+), 27 deletions(-)
> 

Ping?

Michal

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

[libvirt] Missing repo file for virt-preview repo on fedorapeople

[Roman Mohr]

Hi everyone,

Is there a change on how to get the fedora-virt-preview.repo?

So far we were referencing

https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo

but that file does not seem to exist anymore.

Best Regards,
Roman
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list