[libvirt-users] Compile libvirt on OSX 10.12

2017-09-13 Thread Homie Pawlowski 
I'm having issues with compiling libvirt on OSX 10.12

 ~/Development/github/libvirt/ [master] make
/Library/Developer/CommandLineTools/usr/bin/make  all-recursive

Making all in .
Making all in gnulib/lib
/Library/Developer/CommandLineTools/usr/bin/make  all-am
make[3]: Nothing to be done for `all-am'.
Making all in include/libvirt
make[2]: Nothing to be done for `all'.
Making all in src
/Library/Developer/CommandLineTools/usr/bin/make  all-am
  CC   util/libvirt_util_la-virthread.lo
util/virthread.c:272:17: error: 'syscall' is deprecated: first deprecated
in macOS 10.12 - syscall(2) is unsupported;
  please switch to a supported interface. For SYS_kdebug_trace use
kdebug_signpost().
  [-Werror,-Wdeprecated-declarations]
pid_t tid = syscall(SYS_gettid);
^
/usr/include/unistd.h:733:6: note: 'syscall' has been explicitly marked
deprecated here
int  syscall(int, ...);
 ^
1 error generated.
make[3]: *** [util/libvirt_util_la-virthread.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1

Anyone have any suggestion on how to do so?

Thanks,
-- 

HOMERO PAWLOWSKI

CLOUD CONSULTANT

Red Hat



140 Broadway 24th Floor

New York, NY 10005

hpawl...@redhat.com

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] DHCP logging settings

2017-09-13 Thread Darac Marjal 
Have you considered filtering out the messages at your syslog daemon?


On 05/09/17 02:17, Shannon wrote:
> I find that libvirt clogs up syslog with trivial DHCP notifications. I
> know how to configure alternate logging with dnsmasq directly via
> 'log-facility' and/or 'quiet-dhcp' options but the XML format used by
> libvirt appears to have no equivalent options. Is there a way to
> reduce syslog spam from libvirt without switching to a system-wide
> dnsmasq service?
>
> ___
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] DHCP logging settings

2017-09-13 Thread Daniel P. Berrange 
On Wed, Sep 13, 2017 at 12:59:57PM -0400, Laine Stump wrote:
> On 09/04/2017 09:17 PM, Shannon wrote:
> > I find that libvirt clogs up syslog with trivial DHCP notifications. I
> > know how to configure alternate logging with dnsmasq directly via
> > 'log-facility' and/or 'quiet-dhcp' options
> 
> (Unfortunately there isn't currently any knob you can easily turn to
> reduce dnsmasq's logs)
> 
> Interesting. A long time ago I was annoyed by all the logging produced
> by dnsmasq and searched the standard/sample dnsmasq.conf for an option
> to reduce the logging, but all I saw were options to *increase* it! I
> guess I didn't look far enough.
> 
> It would be nice for libvirt to take advantage of this, but since the
> logging levels of other parts of libvirt are handled in libvirtd.conf
> and qemu.conf, maybe it would be better to add the option there rather
> than making it a part of the config for each network. (on the other
> hand, it might be nice to be able to have more verbose logs for some
> networks than for others).
> 
> Does anyone have an opinion about this? Maybe we could have a
> "dhcp_quiet" option in libvirtd.conf? (alternately I guess we could a
>  element to networks, but that would require something sufficiently
> generic that it would also be useful if someone decided to, e.g., write
> a network driver that used the ISC dhcpd instead of dnsmasq).

NB it would want to be in /etc/libvirt/network.conf, since this would
be specific to the network driver.  It seems reasonable to add such
a thing.

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

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] network configuration for guest specific dns-servers

2017-09-13 Thread Laine Stump 
On 08/31/2017 08:17 AM, Martin Kletzander wrote:
> On Thu, Aug 31, 2017 at 01:09:14PM +0200, David Ayers wrote:
>> Am Donnerstag, den 31.08.2017, 11:32 +0200 schrieb David Ayers:
>>>
>>> Am Donnerstag, den 31.08.2017, 10:11 +0200 schrieb Martin Kletzander:
>>> >
>>> > AFAIK the support for this was not added.  Feel free to request
>>> this in
>>> > our bugzilla [1] so that we can track it.  Or, even better, send a
>>> patch
>>> > if you have some time ;) It should not be difficult.
>>>
>>> Okay, I'll be sure to add it to bugzilla sometime soon.
>>
>> Actually, this was already reported (on the last day of 2010):
>> https://bugzilla.redhat.com/show_bug.cgi?id=666556
>> and seems to restated (two years later) in:
>> https://bugzilla.redhat.com/show_bug.cgi?id=824573
>>
>> and by the looks of this, generic dhcp options at global scope are
>> already contentious, let alone at host scope.
>>
>> So I guess we my stop configuring dnsmasq via libvirt.
>>
>
> Oh, look at that.  It's good that you've found it.  Of course there are
> people more proficient in the networking area who have way more thing on
> their radar.  Looks like this is very often requested thing also.  I
> can't speak for arbitrary options, but named ones that we know what to
> map them to, should be fine and not rejected (at least not right away).
> But others (especially Laine; Cc'd) could be more specific WRT your
> request.

The first attempt at this was really just a passthrough for dnsmasq
commandline options, and as such was ripe with potentials for ambiguous
interpretation (when certain special characters were present),
idiosyncracies specific to dnsmasq's implementation details, etc, so we
pulled it out to re-tool, but I think I tried to be too ambitious about
the design, and so it stagnated rather than proceeding with something
simple but expandable.

What we need is for someone with enough vested interest to map out the
proper XML structure to allow supporting all dhcp options, and then
someone to write the support for the first example dhcp option. After
that, new options could be added as needed. The bit that produces the
reluctance to start is that we need to be sure that whatever we setup
for the initially-supported options needs to be expandable to work for
all options. (I tried to map out such a beast, and it was just too much
work vs. other more pressing things). If somebody wants to pick it up,
I'd be happy to offer my advice/opinions :-)

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] DHCP logging settings

2017-09-13 Thread Laine Stump 
On 09/04/2017 09:17 PM, Shannon wrote:
> I find that libvirt clogs up syslog with trivial DHCP notifications. I
> know how to configure alternate logging with dnsmasq directly via
> 'log-facility' and/or 'quiet-dhcp' options

(Unfortunately there isn't currently any knob you can easily turn to
reduce dnsmasq's logs)

Interesting. A long time ago I was annoyed by all the logging produced
by dnsmasq and searched the standard/sample dnsmasq.conf for an option
to reduce the logging, but all I saw were options to *increase* it! I
guess I didn't look far enough.

It would be nice for libvirt to take advantage of this, but since the
logging levels of other parts of libvirt are handled in libvirtd.conf
and qemu.conf, maybe it would be better to add the option there rather
than making it a part of the config for each network. (on the other
hand, it might be nice to be able to have more verbose logs for some
networks than for others).

Does anyone have an opinion about this? Maybe we could have a
"dhcp_quiet" option in libvirtd.conf? (alternately I guess we could a
 element to networks, but that would require something sufficiently
generic that it would also be useful if someone decided to, e.g., write
a network driver that used the ISC dhcpd instead of dnsmasq).

Adding a conf file option could be a good candidate for a "My first
libvirt patch" task for someone...

> but the XML format used by libvirt appears to have no equivalent
> options. Is there a way to reduce syslog spam from libvirt without
> switching to a system-wide dnsmasq service?
>
> ___
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] [virtual interface] detach interface during boot succeed with no changes

2017-09-13 Thread Laine Stump 
On 09/04/2017 03:37 AM, Yalan Zhang wrote:
> Hi guys,
>
> when I detach an interface from vm during boot (vm boot not finished), it
> always fail. I'm not sure if there is an existing bug. I have
> confirmed with someone that for disk, there is similar behavior, if
> this is also acceptable?

unplugging a PCI device properly requires cooperation from the guest OS.
If the guest OS isn't running yet, the unplug won't complete, so qemu
(and libvirt) still show the device as plugged into the guest.

virsh reports success on the unplug because unplugging a device is done
asynchronously - the "success" means "libvirt successfully told qemu to
unplug the device, qemu has told the virtual machine to unplug the
device, and is waiting for acknowledgment from the virtual machine that
the guest has completed removal". At some later time the guest OS may
complete its part of the unplug; when that happens, qemu will get a
notification and will send an event to libvirt - at that time the device
will be removed from libvirt's list of devices.

tl;dr - this is all expected.


>
> # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2;  virsh
> detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
> dumpxml rhel7.2 |grep /interface -B9
> Domain rhel7.2 destroyed
>
> Domain rhel7.2 started
>
> Interface detached successfully
>
>function='0x0'/>
> 
> 
>   
>   
>   
>   
>   
>function='0x0'/>
> 
>
> When I detach after the vm boot, expand the sleep time to 10, it will succeed.
>
> # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10;  virsh
> detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
> dumpxml rhel7.2 |grep /interface -B9
> Domain rhel7.2 destroyed
>
> Domain rhel7.2 started
>
> Interface detached successfully
>
>
> ---
> Best Regards,
> Yalan Zhang
> IRC: yalzhang
> Internal phone: 8389413
>
> ___
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] external snapshot is missing object secrets

2017-09-13 Thread Peter Krempa 
On Fri, Aug 25, 2017 at 09:49:10 +0200, Markus Schade wrote:
> Hello,
> 
> I have virtual machines running with a ceph storage backend.
> 
> When creating an external qcow2 snapshot with a libvirt version without
> support for the new object secret passing, the backing file info would
> list the ceph secret in plain,e.g.
> 
> # virsh snapshot-create-as vm-123 --no-metadata --disk-only --diskspec
> sda,file=/var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2
> 
> # qemu-img info /var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2
> ...
> backing file:
> rbd:vms_pool0/disk-123:id=libvirt:key=SECRET:auth_supported=cephx\;none:mon_host=192.168.1.1\:6789\;192.168.1.11\:6789\;192.168.1.21\:6789
> 
> While this is problematic from a security perspective (and one of the
> reasons for the new method), it enabled starting the virtual machine
> again in case it died or got powered off.
> 
> With the newer libvirt object secret passing the backing file
> of the qcow image only references the secret id.
> 
> # qemu-img info /var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2
> ...
> backing file: json:{"driver": "raw", "file": {"password-secret":
> "scsi0-0-0-0-secret0", "pool": "vms_pool", "image": "disk-123",
> "driver": "rbd", "user": "libvirt", "=keyvalue-pairs":
> "[\"auth_supported\", \"cephx;none\", \"mon_host\",
> \"192.168.1.1:6789;192.168.1.11:6789;192.168.1.21:6789\"]"}}
> 
> This is fine as long as the virtual machine is running and with
> qemu-2.10 it is even possible to block-commit this external snapshot
> (Yeah!).
> 
> However, should the VM die or be powered off, it is now longer possible
> to start the domain or at least recover the data:
> 
> Could not open backing file: No secret with id 'scsi0-0-0-0-secret0'

Yes, the issue here is that even if qemu records the secret alias,
libvirt does not remember it in the XML and thus does not create the
objects.

> I guess this problems happens with any disk type that is accessed with
> object secrets, which is why I would consider this a bug.
> 
> The question is, should/can this be fixed in libvirt or qemu?

I'm currently working on this. This needs to be fixed in libvirt by
tracking the full backing chain.

> 
> I think libvirt should create the snapshot file with the object secret
> stored in a persistent file (and reference this file in the backing file
> definition)

Libvirt will store the authentication credentials in the XML along with
the backing chain. With that you can specify the authentication for
every image, so a new start of the VM should work as expected.

The {"password-secret": field in the backing chain then will be ignored
and libvirt will create a new secret object with the proper name.


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