Re: CAN virtualization

2023-09-18 Thread Martin Kletzander

On Tue, Sep 12, 2023 at 01:04:11PM +, Sánta, Márton (ext) wrote:

Dear Users,

I use KVM with libvirt 9.0.0. The host and guest OS-es are also AGL needlefish 
images. I am currently trying to virtualize a CAN driver and provide virtual 
machines access to the physical CAN channels.

I started with the virtual network handling as CAN interface is a network interface, I 
tried to find analogies, solutions like "traditional" network handling but it 
did not work.
I also tried out to define a nodedev device via .xml config file. The 
interesting thing is, that when I list all the available nodedev devices with 
'virsh nodedev-list', I can see 'net_can0' and 'net_can1' on the output as 
'net' type device but I cannot attach these devices to the guests, and I do not 
know how to define it in the guest .xml file. I tried out many different 
things, but when I try to add it as a 'hostdev' device with different mode and 
type settings, I always get an error (e.g. not a PCI device or not supported 
device type etc.). It would be long to write down all the configurations I 
tried out, so my first question would be that does anybody know how could I 
provide access to guests to the physical CAN interfaces? The aim is to be able 
to send CAN messages from guest OS-es. If no direct access is possible, it 
would be also OK to have access to virtual CAN interfaces on the host and then 
transfer messages to the physical CAN channel.




Hi.  CAN devices need a couple more specifications for how the device should be 
created and even though your analogy went the right way libvirt does not (yet) 
support CAN device emulation for any hypervisor driver.  I had a plan to write 
it at some point, but I saw nobody requesting that and did not have enough free 
time to do that.


Thank you very much for your feedback. Is there any other solutions you know 
about? Maybe any QEMU passthrough argument which could help to virtualize CAN 
driver?



You can definitely use passthrough for that:

https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands

I don't know about many other options for now.


For completeness sake; the fact that you see the devices in nodedev-list is a 
consequence of us not filtering the devices at all, just reporting on what we 
find on the host.



Patches would be appreciated, I myself won't probably get to adding such 
support any time soon.



Have a nice day,
Martin


Thank you!

Márton

-Original Message-----
From: Martin Kletzander 
Sent: Tuesday, August 29, 2023 9:16 AM
To: Sánta, Márton (ext) 
Cc: libvirt-users@redhat.com
Subject: Re: CAN virtualization

On Wed, Aug 23, 2023 at 01:15:36PM +, Sánta, Márton (ext) wrote:

Dear Users,

I use KVM with libvirt 9.0.0. The host and guest OS-es are also AGL needlefish 
images. I am currently trying to virtualize a CAN driver and provide virtual 
machines access to the physical CAN channels.

I started with the virtual network handling as CAN interface is a network interface, I 
tried to find analogies, solutions like "traditional" network handling but it 
did not work.
I also tried out to define a nodedev device via .xml config file. The 
interesting thing is, that when I list all the available nodedev devices with 
'virsh nodedev-list', I can see 'net_can0' and 'net_can1' on the output as 
'net' type device but I cannot attach these devices to the guests, and I do not 
know how to define it in the guest .xml file. I tried out many different 
things, but when I try to add it as a 'hostdev' device with different mode and 
type settings, I always get an error (e.g. not a PCI device or not supported 
device type etc.). It would be long to write down all the configurations I 
tried out, so my first question would be that does anybody know how could I 
provide access to guests to the physical CAN interfaces? The aim is to be able 
to send CAN messages from guest OS-es. If no direct access is possible, it 
would be also OK to have access to virtual CAN interfaces on the host and then 
transfer messages to the physical CAN channel.



Hi.  CAN devices need a couple more specifications for how the device should be 
created and even though your analogy went the right way libvirt does not (yet) 
support CAN device emulation for any hypervisor driver.  I had a plan to write 
it at some point, but I saw nobody requesting that and did not have enough free 
time to do that.

For completeness sake; the fact that you see the devices in nodedev-list is a 
consequence of us not filtering the devices at all, just reporting on what we 
find on the host.

Patches would be appreciated, I myself won't probably get to adding such 
support any time soon.

Have a nice day,
Martin


Thank you in advance for an early reply!

Best regard,

Márton Sánta


This transmission is intended solely for the addressee and contains 
confidential information.
If you are not the intended recipient, please immediately inform the sender and 
delete

Re: Question about encryption and tls

2023-09-11 Thread Martin Kletzander

On Sun, Sep 10, 2023 at 01:00:21PM +0200, Kamil Jońca wrote:

(Posted few days ago on qemu group but no reactions)

Do I understand correctly that ssl shoudl be configured independently
for libvirt and each hypervisor?


It depends what you are asking about.  There are various connections,
each of you can configure separately.


I asked because I configured libvirt connection as

qemu+tls://bambus.kjonca/system?pkipath=...



This ^^ uses TLS to communicate between the libvirt client and server,
e.g. virsh.


(and on bambus in /etc/libvirt/libvirtd.conf) I set
key_file = ...
cert_file = ...
ca_file = ...

But after connect and lauching (on bambus) vm I tried to snif traffic to
bambus:5900 on client) and wireshark was able to detect "VNC"


For VNC that is another connection which you need to configure
separately.  And that is because there might be various requirements for
various use cases.


protocol (BTW not spice?), so I am confused.
should I configure in  /etc/libvirt/qemu.conf



There is default_tls which should be enough to start, then you need to
turn on tls usage for want.  There's vnc_tls, spice_tls, vxhs_tls,
nbd_tls, migrate_tls, backup_tls, and you can even configure different
certificates for each of them.


spice_tls option and certificates ?



That, and also don't forget to configure the domain XML so that it uses
what you want, probably something like:



and then some, check the following for more details:

https://libvirt.org/formatdomain.html#graphical-framebuffers


KJ



signature.asc
Description: PGP signature


Re: CAN virtualization

2023-08-29 Thread Martin Kletzander

On Wed, Aug 23, 2023 at 01:15:36PM +, Sánta, Márton (ext) wrote:

Dear Users,

I use KVM with libvirt 9.0.0. The host and guest OS-es are also AGL needlefish 
images. I am currently trying to virtualize a CAN driver and provide virtual 
machines access to the physical CAN channels.

I started with the virtual network handling as CAN interface is a network interface, I 
tried to find analogies, solutions like "traditional" network handling but it 
did not work.
I also tried out to define a nodedev device via .xml config file. The 
interesting thing is, that when I list all the available nodedev devices with 
'virsh nodedev-list', I can see 'net_can0' and 'net_can1' on the output as 
'net' type device but I cannot attach these devices to the guests, and I do not 
know how to define it in the guest .xml file. I tried out many different 
things, but when I try to add it as a 'hostdev' device with different mode and 
type settings, I always get an error (e.g. not a PCI device or not supported 
device type etc.). It would be long to write down all the configurations I 
tried out, so my first question would be that does anybody know how could I 
provide access to guests to the physical CAN interfaces? The aim is to be able 
to send CAN messages from guest OS-es. If no direct access is possible, it 
would be also OK to have access to virtual CAN interfaces on the host and then 
transfer messages to the physical CAN channel.



Hi.  CAN devices need a couple more specifications for how the device
should be created and even though your analogy went the right way
libvirt does not (yet) support CAN device emulation for any hypervisor
driver.  I had a plan to write it at some point, but I saw nobody
requesting that and did not have enough free time to do that.

For completeness sake; the fact that you see the devices in nodedev-list
is a consequence of us not filtering the devices at all, just reporting
on what we find on the host.

Patches would be appreciated, I myself won't probably get to adding such
support any time soon.

Have a nice day,
Martin


Thank you in advance for an early reply!

Best regard,

Márton Sánta


This transmission is intended solely for the addressee and contains 
confidential information.
If you are not the intended recipient, please immediately inform the sender and 
delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone 
unless agreed otherwise. To the extent permitted by law we shall in no way be 
liable for any damages, whatever their nature, arising out of transmission 
failures, viruses, external influence, delays and the like.


signature.asc
Description: PGP signature


Re: You will need to grant the 'libvirt-qemu' user search permissions for the following directories....

2023-08-07 Thread Martin Kletzander

On Mon, Aug 07, 2023 at 01:06:55PM +0200, Sebastien WILLEMIJNS wrote:

Hello,

Why LIBVIRT software/libs need to chown "near the root level" (home/blahblah/) 
when raw/vdi/vhd can contains lots of directories as 
/home/user/Virtual_HDs/desktop/daddy/private/bedroom/number2/hd.vdi ?

on ubuntu, "/media/hostname" can contains all our external HD's without 
relation with virtualization !!! :-(

another sample picked up in the net:
WARNING /home/jwright/virtualMachines/images/fedora25.qcow2 may not be 
accessible by the hypervisor. You will need to grant the 'qemu' user search 
permissions for the following directories: ['/home/jwright']


When you want to run a VM under non-root user (running it as root is not
the right way to go) you want the emulator to have access to the disk.
But if /home/jwright is owned by different user and group than the user
under which the emulator runs (i.e. qemu), and it has no search
permission for others (the last "x" in "rwx-x" for example is
enough) then there is no way it can access that disk because it cannot
go "through" /home/jwright.  The "search" permission does not allow
"reading", i.e. the qemu user would still not be able to read the
directory and list the files under it, but it could access a file under
said directory if it knows the full path and has permissions for that
file (and "search" permission for all the subdirectories that it lies
inside).

HTH,
Martin


signature.asc
Description: PGP signature


Re: virsh not connecting to libvertd ?

2023-06-08 Thread Martin Kletzander

On Tue, Jun 06, 2023 at 04:56:38PM -0400, Jerry Buburuz wrote:

I have identical two hypervisors same operating system: Ubuntu 22.04.2 LTS

Recently both virsh stopped talking to the libvirtd. Both stopped within a
few days of each other.

Currently if I run:

virsh uri
virsh version
virsh list

# virsh list
..nothing just hangs

When I ran strace on these broken machines it get stuck at same spot:



Is libvirtd running?  It might be that you have socket activation with
systemd and the socket this virsh is connecting to is not properly
associated with the service.  One of the things that might happen is
that you want to debug the service, stop the service and a socket unit,
but that will not remove it.  Before debugging this make sure everything
related in systemd is stopped and then try running libvirtd (or
virtqemud, there are two services) with debugging enabled and then run
the virsh commands with debugging enabled as well.

Martin


strace virsh list
...


access("/var/run/libvirt/virtqemud-sock", F_OK) = -1 ENOENT (No such file
or directory)
access("/var/run/libvirt/libvirt-sock", F_OK) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"},
110) = 0
getsockname(5, {sa_family=AF_UNIX}, [128 => 2]) = 0
futex(0x7fa716a672f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
fcntl(5, F_GETFD)   = 0
fcntl(5, F_SETFD, FD_CLOEXEC)   = 0
fcntl(5, F_GETFL)   = 0x2 (flags O_RDWR)
fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK)= 0
futex(0x7fa716a67348, FUTEX_WAKE_PRIVATE, 2147483647) = 0
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 6
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7fa70c001cb0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fa716a6786c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fa716a67378, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7fa70c001cb0, FUTEX_WAKE_PRIVATE, 1) = 1
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigprocmask(SIG_BLOCK, [PIPE CHLD WINCH], [], 8) = 0
poll([{fd=5, events=POLLOUT}, {fd=6, events=POLLIN}], 2, -1) = 2 ([{fd=5,
revents=POLLOUT}, {fd=6, revents=POLLIN}])
read(6, "\2\0\0\0\0\0\0\0", 16) = 8
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x5628ce6e9710, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(5, "\0\0\0\34 \0\200\206\0\0\0\1\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0",
28) = 28
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
rt_sigprocmask(SIG_BLOCK, [PIPE CHLD WINCH], [], 8) = 0
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = 1 ([{fd=6,
revents=POLLIN}])
read(6, "\5\0\0\0\0\0\0\0", 16) = 8
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1

It gets stuck at this  poll(). Note I tested strace on identical new
install of ubtuntu 22.04 where virsh connects fine and get identical
strace, except after this poll() it continues on with read/write ..etc.

I turned on debugging for libvirtd and get no errors while virsh is trying
to connect.

I am able to get a virsh# shell. The shell only hangs when I try "connect,
uri, version".

Another method of debugging I tried was:

LIBVIRT_DEBUG=error LIBVIRT_LOG_FILTERS="1:* " virsh uri
..
..
2023-06-06 20:51:22.312+: 1647: debug : doRemoteOpen:1128 : Trying
authentication
2023-06-06 20:51:22.312+: 1647: debug : virNetMessageNew:44 :
msg=0x55b996539680 tracked=0
2023-06-06 20:51:22.312+: 1647: debug : virNetMessageEncodePayload:383
: Encode length as 28
2023-06-06 20:51:22.312+: 1647: info : virNetClientSendInternal:2151 :
RPC_CLIENT_MSG_TX_QUEUE: client=0x55b996538010 len=28 prog=536903814
vers=1 proc=66 type=0 status=0 serial=0
2023-06-06 20:51:22.312+: 1647: debug : virNetClientCallNew:2107 : New
call 0x55b996535f80: msg=0x55b996539680, expectReply=1, nonBlock=0
2023-06-06 20:51:22.312+: 1647: debug : virNetClientIO:1920 : Outgoing
message prog=536903814 version=1 serial=0 proc=66 type=0 length=28
dispatch=(nil)
2023-06-06 20:51:22.312+: 1647: debug : virNetClientIO:1978 : We have
the buck head=0x55b996535f80 call=0x55b996535f80
2023-06-06 20:51:22.312+: 1647: info : virEventGLibHandleUpdate:195 :
EVENT_GLIB_UPDATE_HANDLE: watch=1 events=0
2023-06-06 20:51:22.312+: 1647: debug : virEventGLibHandleUpdate:206 :
Update handle data=0x55b996534d30 watch=1 fd=5 events=0
2023-06-06 20:51:22.312+: 1647: debug : virEventGLibHandleUpdate:229 :
Removed old handle source=0x55b996534de0
2023-06-06 20:51:22.312+: 1648: debug : virEventRunDefaultImpl:341 :
running default event implementation

Any help would be appreciated.

thanks
jerry














signature.asc
Description: PGP signature


Re: Question regaring correct usage of CPU shares

2023-05-26 Thread Martin Kletzander

On Fri, May 12, 2023 at 11:36:36AM +, mailing-libv...@posteo.de wrote:

Hi there,



Hi, sorry for the late answer.


I have a question regarding the shares option of the cputune section. I
want to illustrate my question with the following example. Let's assume
I have two virtual machines like the following on four dedicated core
with two threads each:

VM1:

 512
 
 


VM2:
cputune>
 512
 
 
 
 
 
 


Those two virtual machines I just mentioned won't interfere with one
another since they are pinned to different cores. However I introduce
another, third virtual machine, like this:

VM3:

 512
 
 
 
 
 
 
 
 


What I want is that VM1, VM2 and VM3 all receive half of the cores CPU
time if congestion appears. My question is how the shares are


That is what should, theoretically, happen, yes.  And it does not matter
if the value is 512, 7 or 2.


calculated. Are they calculated on a per core basis? Meaning VM1 and


No, they are set per-VM.


VM3 use the first core so each will get half of the cores capacity when
congestion appears, or are the shares calculated over all cores a
virtual machine uses and I need to scale the amount of shares with
increasing number of cores. What is the correct setting here so that
all virtual machines in this example are guaranteed half of the
capacity of each of their respective cores if congestion appears?



The above is okay from this point of view.  But it depends on the rest
of your system.  What scheduler you have, what are the other processes
running, etc.  You can have a look at the settings in cgroups (in v1
this is cpu.shares, in v2 I think that's cpu.weight) and see how they
are set.

Hope that helps,
Martin


signature.asc
Description: PGP signature


Re: How can I check the history of all console logs starting from the first second of bootup

2022-09-22 Thread Martin Kletzander

On Thu, Sep 22, 2022 at 10:24:46AM +0800, Lucas Liu wrote:

Gratings:

Recently, I got an error while installing a guest, the error message is
this,:
[image: image.png]

Is there a method to get the full log? I have tried to use virt-install
--console, or attach   to get
the full log, but they didn't work.


My guess is that the kernel (and bios/uefi) was not set up to output to
a serial console.  You could use virt-install's --boot
bios.useserial=on, or for the kernel to output on the console you might
try kernel_args="console=ttyS0" if you're booting kernel directly, or
--extra-args "console=ttyS0" if you're installing from --location.  But
that could be changed in the bootloader before choosing the kernel.


signature.asc
Description: PGP signature


Re: Backup KVM Guest VM in OVA or VMDK format

2022-09-21 Thread Martin Kletzander

On Mon, Sep 19, 2022 at 09:13:37PM +0530, Kaushal Shriyan wrote:

On Wed, Sep 14, 2022 at 7:38 PM Kaushal Shriyan 
wrote:




On Sat, Sep 3, 2022 at 12:28 AM Kaushal Shriyan 
wrote:




On Thu, Sep 1, 2022 at 9:39 PM Kaushal Shriyan 
wrote:


Hi,

Is there a way to backup KVM Guest VM in kvmguestosimage.ova or
kvmguestosimage.vmdk format as I am trying to restore it in AWS by
referring to https://aws.amazon.com/ec2/vm-import/ article as per the
below supported file format.

[1] Open Virtualization Archive (OVA)
[2] Virtual Machine Disk (VMDK)
[3] Virtual Hard Disk (VHD/VHDX)
[4] raw



Well, raw image is the most versatile, but the other formats (especially
1 and 2) might have also other metadata like the number of cpus, memory
size, devices etc.


Also any method to take full and incremental backup of KVM Guest VM.



I am not experienced with backups, but my guess is you can either create
your own workflow using various blockjobs or you might want to check out
backup-* and checkpoint-* commands.


Any help will be highly appreciated. I look forward to hearing from you.
Thanks in Advance.

Best Regards,

Kaushal




Hi,

Checking in again if someone can pitch in for my earlier post to this
mailing list. Thanks in advance.

Best Regards,

Kaushal



Hi,

I followed the below steps by referring to
https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html
.

# qemu-img -h | grep Supported
Supported formats: blkdebug blklogwrites blkverify compress
copy-before-write copy-on-read file ftp ftps gluster host_cdrom host_device
http https iscsi iser luks nbd null-aio null-co nvme preallocate qcow2
quorum raw rbd ssh throttle vhdx vmdk vpc



This might be a bit misleading since VMDK may meat a lot of things, it's
not one format, it can store different things, and the support may mean
different things.


# qemu-img --version
qemu-img version 6.2.0 (qemu-kvm-6.2.0-12.module_el8.7.0+1140+ff0772f9)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
#

*Step No. 1*
#qemu-img convert -O vmdk openapibox.img openapibox.vmdk -p



I see you are also just using QEMU, is this anyway libvirt-related or
are you just using qemu command line?

Since you are not adding any metadata, then why not just use the raw
image since I presume openapibox.img is in raw and not qcow format.  If
it is qcow, then you can convert it to raw and use that.  The
disadvantage of the raw format is also the fact that most tools will not
keep the sparseness, so you might end up with a high storage usage.
Maybe you can try vhdx instead since that *should* just be a disk image.


*Step No. 2*
#aws ec2 import-image --disk-containers
Format=vmdk,UserBucket="{S3Bucket=daclabservers,S3Key=openapidbox.vmdk}"
{
"ImportTaskId": "import-ami-0232f452194f6efe0",
"Progress": "1",
"SnapshotDetails": [
{
"DiskImageSize": 0.0,
"Format": "VMDK",
"UserBucket": {
"S3Bucket": "daclabservers",
"S3Key": "openapibox.vmdk"
}
}
],
"Status": "active",
"StatusMessage": "pending"
}

*Step No. 3*
#aws ec2 describe-import-image-tasks --import-task-ids
import-ami-0232f452194f6efe0
{
"ImportImageTasks": [
{
"ImportTaskId": "import-ami-0232f452194f6efe0",
"SnapshotDetails": [
{
"DiskImageSize": 0.0,
"Status": "completed"
}
],
"Status": "deleted",
"StatusMessage": "ClientError: Disk validation failed
[Unsupported VMDK File Format]",


As you see here VMDK itself has various formats.


"Tags": []
}
]
}

Please guide me. Am I missing anything? Thanks in advance.

Best Regards,

Kaushal



Hi,

I will appreciate it if someone can pitch in for my earlier post to this
mailing list and need guidance in this regard. I look forward to hearing
from you. Thanks in advance.

Best Regards,

Kaushal


signature.asc
Description: PGP signature


Re: Can RHEL7 VM run remote libvirt commands to Fedora36 host?

2022-08-01 Thread Martin Kletzander

On Mon, Aug 01, 2022 at 07:11:20AM -0400, Carol Bouchard wrote:

I've attached output from lsof & systemctl commands.  I enabled
virtproxyd.service Friday which got
me past my problem but it is curious how I got into this if the default is
for proxy to be enabled.



Enabling virtproxyd.socket ought to be enough, no need for the service to run
when nobody is connected.  Looks like it is set up properly now, maybe it was
some misconfig or a stuck socket somewhere.


On Mon, Aug 1, 2022 at 5:02 AM Martin Kletzander 
wrote:


On Thu, Jul 28, 2022 at 02:14:30PM -0400, Carol Bouchard wrote:
>I have a test environment that use to work but no longer does. My
>laptop is Fedora36 (libvirt version 8.1.0.2) while the VMs it spawns are
>RHEL7 (max libvirt version is 4.5.0). The source of my problem
>seems to be that RHEL7 libvirt needs rw socket
/var/run/libvirt/libvirt-sock
>which no longer exists in fedora36.
>
>The following is successful from RHEL7 VM to laptop:
>virsh -d0 --connect
>'qemu+ssh://
192.168.120.1/system?*socket*=/var/run/libvirt/libvirt-sock-ro'
>domstate beaker-test-vm1.beaker
>
>If I change the action from domstate to start, it fails on
>error: Failed to start domain beaker-test-vm1.beaker
>error: operation forbidden: read only access prevents virDomainCreate
>which made me realize ro stands for read-only; however, there is no
>libvirt-sock. I tried some of the other socket files without success.
>Is there a work-around?
>

It is pretty weird that something is listening on the libvirt-sock-ro and
not on
libvirt-sock.  Could you run a quick lsof to figure out who's listening on
libvirt-sock?  If it is systemd, then you have socket activation set up
for the
read-only socket *only* and you need to also enable libvirtd.socket.
Something
along the lines of:

 systemctl enable --now libvirtd.socket libvirtd-ro.socket
 systemctl stop libvirtd.service

should suffice.

You might also be running in the newer split daemon scenario and you have
virtqemud running instead.  The service listening to libvirt socket might
be for
virtproxyd[0] instead and you might need to do the following instead:

 systemctl enable --now virtproxyd.socket virtproxyd-ro.socket
 systemctl stop virtproxyd.service

To make sure try figuring out which systemd service/socket is associated
with
the socket, by running `systemctl status libvirtd virtproxyd`.

Martin

[0] https://libvirt.org/manpages/virtproxyd.html







signature.asc
Description: PGP signature


Re: Can RHEL7 VM run remote libvirt commands to Fedora36 host?

2022-08-01 Thread Martin Kletzander

On Thu, Jul 28, 2022 at 02:14:30PM -0400, Carol Bouchard wrote:

I have a test environment that use to work but no longer does. My
laptop is Fedora36 (libvirt version 8.1.0.2) while the VMs it spawns are
RHEL7 (max libvirt version is 4.5.0). The source of my problem
seems to be that RHEL7 libvirt needs rw socket /var/run/libvirt/libvirt-sock
which no longer exists in fedora36.

The following is successful from RHEL7 VM to laptop:
virsh -d0 --connect
'qemu+ssh://192.168.120.1/system?*socket*=/var/run/libvirt/libvirt-sock-ro'
domstate beaker-test-vm1.beaker

If I change the action from domstate to start, it fails on
error: Failed to start domain beaker-test-vm1.beaker
error: operation forbidden: read only access prevents virDomainCreate
which made me realize ro stands for read-only; however, there is no
libvirt-sock. I tried some of the other socket files without success.
Is there a work-around?



It is pretty weird that something is listening on the libvirt-sock-ro and not on
libvirt-sock.  Could you run a quick lsof to figure out who's listening on
libvirt-sock?  If it is systemd, then you have socket activation set up for the
read-only socket *only* and you need to also enable libvirtd.socket.  Something
along the lines of:

systemctl enable --now libvirtd.socket libvirtd-ro.socket
systemctl stop libvirtd.service

should suffice.

You might also be running in the newer split daemon scenario and you have
virtqemud running instead.  The service listening to libvirt socket might be for
virtproxyd[0] instead and you might need to do the following instead:

systemctl enable --now virtproxyd.socket virtproxyd-ro.socket
systemctl stop virtproxyd.service

To make sure try figuring out which systemd service/socket is associated with
the socket, by running `systemctl status libvirtd virtproxyd`.

Martin

[0] https://libvirt.org/manpages/virtproxyd.html


signature.asc
Description: PGP signature


Re: Incomplete information in the website Wiki for libvirt.org

2022-07-04 Thread Martin Kletzander

On Fri, Jul 01, 2022 at 04:37:55AM -0500, Uriel Emmanuel Pelaez Hernández wrote:

Dear Web Marster from wiki.libvirt.org,

I tried to look for the libvirtd, the demon that is suppose to run under
Linux/Unix environment,
but your site didn't show any information. Only a statement appeared:
"Create the page libvirtd "



Hi, we are slowly migrating the wiki pages to knowledge base articles
due to various issues with the wiki.


Please, update your site or suggest any other weblink with the information.



Have a look at our docs page: https://libvirt.org/docs.html where you
might find what you are looking for.  There is a particular page about
daemons here: https://libvirt.org/daemons.html


In theory CygWin use your package, but the information is incomplete too,
about this issue.

I send this mail to these both Email address by the information displayed
in your wiki, about the contact address to solve this kind of problems.



Unfortunately I am not sure what are you trying to solve, so I don't
know what clearer pointers to give you.


By now, Google Service in my region is deprecated, so the information that
the WebBrowser display is not the best.

I send this request from my Email of Graduated Student form the University
domain.

Best Regards,
Mr. Peláez Uriel.
Mexico City


Have a nice day,
Martin


signature.asc
Description: PGP signature


Re: [Libvirt][emulator-cores][dpdk] Emulatorpin cpuset best practices

2022-06-07 Thread Martin Kletzander

On Wed, Jun 01, 2022 at 05:57:14PM -0400, Laurent Dumont wrote:

Hey folks,

I am curious to understand a bit more the core use of the emulatorpin CPUs
with libvirt.

For example :

   
   
   
   
   



qemu launched like this is one process with (at least, but let's omit
that) 5 threads.  There is one thread for each vCPU and an extra thread
for all the extra work not running in the guest.  That can be I/O,
serving the monitor etc.  If you pin it onto the same host CPUs as the
vCPUs then you cannot expect to have enough resources allocated for
serving 100% utilisation in the guest.  But it is of course configurable
because overcommitting is sometimes wanted.


In this case :

  - The VM has 4 vCPUs.
  - Each of the core is pinned to a physical/thread core - 34,14,10,30
  - The emulatorpin is also attached to the same physical CPUs.

In our case :

  - Same setup for cores.
  - Running DPDK inside the virtual machine.
  - The compute/libvirt is using OVS but without DPDK.

What we saw is the following :

  - DPDK is polling two cores at 100% to process packets.
  - From the compute metrics, we see USER %usage at 100% when the
  application starts.
  - From the compute metrics, as traffic increases, we see %SYSTEM going
  up.
  - As %SYSTEM goes up, %USER goes down.

We are not quite sure, but we are wondering if this could cause a direct
impact to the ability of DPDK to process traffic at the same X speed?

  - We can "live" move the emulator CPU to other cores.
  - This seems to be the recommended default setup for VNF/NFV deployments.


Feels like I am missing a piece of the puzzle but gotta start somewhere!

Thanks!


signature.asc
Description: PGP signature


Re: Help with libvirt

2022-04-13 Thread Martin Kletzander

On Mon, Apr 11, 2022 at 01:06:54PM +, Eduardo Kiassucumuca wrote:

Good morning I'm Eduardo, a computer science student and I'm doing a
final course work focused on virtualization. The work consists of
creating virtual machines on a server and allowing ssh access to the
virtual machines that are on the server containing
qemu/kvm/libvirt. The problem is that I can't access the virtual
machines from an external network but I can access them inside the
server. I would like to know what would be the best way since we want
to have a single public ip and be able to have a reverse proxy to
access the virtual machines, I would like to know from your experience
what you recommend?


It all depends on what network are the VMs running.  There are lot of
options, but my guess is you are using the default network.  It also
depends on whether you want to just forward few ports or have those
machines fully accessible.  For port forwarding you can have a look at
our wiki:

  https://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections

but there are always more ways to do the same thing, so that page
describes only few variants.

Have a nice day,
Martin


signature.asc
Description: PGP signature


Re: Libvirt Daemon Question

2022-04-13 Thread Martin Kletzander

On Fri, Apr 01, 2022 at 05:56:06PM -0400, Michael Espinoza wrote:

Hi

I’ve been googling this for a bit with no luck.  Is there a way of
determining what mode an already running libvirt daemon is running
in.(session or system)  From the docs it sounded like it was determined by
what user started the daemon. But in a test node I set up, I have libvirtd


libvirtd running as root is a system daemon, for all other users it is a
session daemon


running as root yet I can still connect to both the session and system
qemus with virsh.


That's because the session daemon does not need to be started to connect
to it, virsh will start it when you want to connect and then it will end
itself after a certain timeout with no operation.


And if I were to want libvirtd only in session mode, how would I do
that?



Do not start the system daemon and also disable socket activation for
all the daemons you do not want to be used (if you are using systemd for
example).


Thanks for the help!  This stuff is really awesome and I’m just trying to
get a full understanding of it.



Glad we could help, enjoy the day ;)


-Mike
--
Michael Espinoza
Mobile Phone : 646 327 9273
Email : mikespin...@gmail.com


signature.asc
Description: PGP signature


Re: How to make the libvirt VM installed under the regular user boot during the system bootup?

2022-03-21 Thread Martin Kletzander

On Sun, Mar 20, 2022 at 10:09:36PM +0200, Martin T wrote:

Hi.

I installed a virtual machine under a regular user(in other words, not
under root user) with virt-install and configured this VM to boot
automatically:

$ virsh dominfo vm
Id: 1
Name:   vm
UUID:   eef95dd6-5efe-4059-8dcc-3e35db12f55d
OS Type:hvm
State:  running
CPU(s): 4
CPU time:   253.7s
Max memory: 4194304 KiB
Used memory:4194304 KiB
Persistent: yes
Autostart:  enable
Managed save:   no
Security model: none
Security DOI:   0

$ ls -l /home/user/.config/libvirt/qemu/autostart/
total 0
lrwxrwxrwx 1 user user 47 Apr 30 16:59 vm.xml ->
/home/user/.config/libvirt/qemu/vm.xml
$



This is still using the session daemon, which only starts when you
connect to it or when you log in with the session daemon service setup
to start automatically.

There are two ways to overcome this.  One is to use the system daemon
instead (virsh -c qemu:///system) which you can also set as your default
for example by setting uri_default = "qemu:///system" in
~/.config/libvirt/libvirt.conf and there are other means as well.

If you are running a system with systemd then you can also setup
lingering for your user (loginctl enable-linger ) as that
would enable running the user services even without being logged in.


The vm indeed starts automatically, but only when the regular user has
logged in. I would like libvirtd(started by the systemd) to execute
this VM already during the system bootup when the regular user has not
yet logged in. How to accomplish this? I also made a symlink under
/etc/libvirt/qemu/autostart/, but this did not help.


thanks,
Martin



signature.asc
Description: PGP signature


Re: networking question

2022-02-25 Thread Martin Kletzander

On Thu, Feb 24, 2022 at 07:07:18PM +0100, Natxo Asenjo wrote:

hi,

I have an issue with one host at a customer's site. I think this cannot
work, but I would like to ask you just in case I am confused.

host:
eno1: 172.20.10.x/24 management interface gw 172.20.10.254
bridge-service: 0.0.0.0/24
tun0: openvpn tunnel to external data center
internal-bridge: x.x.x.x/28 ; routed subnet that goes to openvpn tun0

on vm:
eth0: x.x.x.x/28 on internal-bridge (default gw)
eth1: 172.20.10.x/24 bridge-service gw 172.20.10.254 (same as eno1)

Connectivity to and from openvpn (from and to datacenter) is perfect. All
vms are directly reachable from our management services, no natting.


From hypervisor I can ping the gw, from vm I cannot ping 172.20.10.254.


My gut feeling is that this cannot work because traffic for the hypervisor
for subnet 172.20.10.x/24 flows through eno1, but for vm through the
bridge-loggin interface. So that cannot work.



I am not sure, but I would try to see where the packets are really going
through by using wireshark/tshark or tcpdump.

The only thing that I can come up on the spot is that it is trying to go
through different interface at some point due to reverse path filtering,
settings for that are in /proc/sys/net/ipv4/conf/*/rp_filter, it might
be routed elsewhere anywhere along the way.  But it is hard to say
without knowing how all the networks are connected.  Maybe I'm just bad
at understanding your situation, for me it is usually better to see this
stuff happen in wireshark.  But I figured I at least let know know one
idea which we had an issue before as well.

Hope that helps,
Martin


Should we just ask the customer to give us different subnets for the host
and the vm?

TIA.
--
regards,
Natxo


signature.asc
Description: PGP signature


Re: frequent network collapse possibly due to bridging

2022-01-24 Thread Martin Kletzander

On Fri, Jan 21, 2022 at 08:42:58AM -0600, Hakan E. Duran wrote:

Hi,

I would like some help to troubleshoot the problem I have been having
lately with my VM host, which contains 5 VMs, one of which is for
pi-hole, unbound services. It has been a relatively common occurrence in
the last few weeks for me to find that the host machine has lost its
network when I get back home from work. Restoring the VM/VMs do not fix
the problem, the host needs to be restarted for a fix, otherwise there
is both loss of name resolution, as well as an internet connection; I
cannot ping even IPs such as 8.8.8.8. Since I use the pi-hole VM as the DNS
server for my LAN, this means that my whole LAN gets disconnected from
internet, until the host machine is rebooted. The host machine has a
little complicated network setup: the two gigabit connections are bonded
and bridged to the VMs; however this set up has been serving me so well
for several years now. The problem, on the other hand, appeared a few
weeks ago. This doesn't happen every day but often enough to be annoying
and disruptive for my family.



Always good to check what has changed those weeks ago, but I understand
it is difficult to find out what you were updating and where.


My question is, how can I troubleshoot this problem and figure out
whether it is truly due to network bridging somehow collapsing or not? I
tried to find some log files but all I could find were the
/var/log/libvirt/qemu/$VM files, and the particular log file for the pi-hole
VM reported the following lines; however, I am not sure if they are
associated with a real crash or just due to shutting down and restarting
the host (please excuse the word-wrapping):

char device redirected to /dev/pts/2 (label charserial0)
qxl_send_events: spice-server bug: guest stopped, ignoring
2022-01-20T23:41:17.012445Z qemu-system-x86_64: terminating on signal 15 from 
pid 1 (/sbin/init)


Probably restarting the host as it got SIGTERM'd by init.  Maybe it was
restarted in a bad time and there is some inconsistency on the disk?
Using something like libvirt-guests which can manage your machines when
rebooting would be a good idea.


2022-01-20 23:41:17.716+: shutting down, reason=crashed
2022-01-20 23:42:46.059+: starting up libvirt version: 7.10.0, qemu
version: 6.2.0, kernel: 5.10.89-1-MANJARO, hostname: -redacted-

Please excuse my ignorance but is there a way to restart the
networking without rebooting the host machine? This will not solve my


You can do:

virsh net-destroy 
virsh net-start 

but depending on what the network looks like, how it is set up etc. you
might need to restart some of the VMs or manually plug them in.


problem since I won't be able to reach to the host remotely if the
networking is down. The real solution would be preventing these network
crashes and the first step in that would be effective troubleshooting in
my opinion. Any input/guidance will be greatly appreciated.

I can provide more info about my host/VM(s) if the above is not adequate.



I'm not sure how much more I can help as I do not understand what is the
actual setup.  What I would do is try to figure out what exactly happens
when it breaks and then go from that (setting up logging etc.), just
general tips I guess.


Thanks,

Hakan Duran






signature.asc
Description: PGP signature


Re: Best way to install guest when it is not listed in output of osinfo-query os

2021-12-20 Thread Martin Kletzander

On Mon, Dec 20, 2021 at 03:26:09AM -0800, Andrea Bolognani wrote:

On Mon, Dec 20, 2021 at 06:52:46AM +0100, john doe wrote:

Hello all,

I would like to install Debian Bullseye using virt-install, as part of
the command I usually specify the OS used with the option '--os-variant'.
This works great untill Buster ('debian10'), but now the guest is
Bullseye ('debian11') and is not listed in the output of 'osinfo-query
os' (1).

If I don't use the '--os-variant' flag I get the following warning:

"WARNING  No operating system detected, VM performance may suffer.
Specify an OS with --os-variant for optimal results."


Should I ignore the warning or what is the best way forward to install a
Debian Bullseye guest?

Both the host and the guest are  Debian 11.

1)  https://lists.debian.org/debian-user/2021/12/msg00742.html


You can just use '--os-variant debian10', it will work fine.

Alternatively, you can install a newer version of the osinfo database
by using osinfo-db-import. Doing so is probably overkill for your use
case.


Pino, do you think it would make sense to rebase osinfo-db in the
next Debian 11 update? Or at least cherry-pick the debian11 entry so
that things work as expected when creating a Debian 11 VM on a Debian
11 host? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980744 was
AFAICT intended to achieve just that.



Any reason for debian not having an -unknown version like lot of the
other distros?


--
Andrea Bolognani / Red Hat / Virtualization



signature.asc
Description: PGP signature


Re: Libvirt + Debian Live = Heart Attack

2021-11-25 Thread Martin Kletzander

On Thu, Nov 25, 2021 at 01:21:23PM +0100, Elias Mobery wrote:

Hey Martin, wow thanks for the detailed info!

I'll definitely look into this, but I kind of figured it out, I believe.

So, I keep the images in the read-only squashfs, boot the live system and
use snapshot writeback:
virsh snapshot-create-as with options --disk-only --diskspec



Well, this basically does a very similar thing, only in a way that
libvirt keeps more metadata about the fact.


This pretty much fixes my problem, and only disk writes occur in tmpfs,
instead of the entire image being copied.

BUT, now I have to reduce the disk space within the  VM to almost 0 to save
space.



Not sure which space you mean.  If that is inside the VM, then
uninstalling unneeded stuff is the way to go, if it is the image file in
the ISO, then virt-sparsify before creating the ISO will punch holes
where there is no usable data.  If you mean in the overlay/snapshot,
then it only records the changes.


I'm reading up on qemu-img convert and virt-sparsify to accomplish this,
but I will also try your method now, it seems more professional.

Thank you for your amazing input and patience, I love this community.
Sharing this information is the literal definition of freedom IMO, thank
you all!



Thanks ;)


On Thu, Nov 25, 2021, 11:40 AM Martin Kletzander 
wrote:


On Wed, Nov 24, 2021 at 06:21:22PM +0100, Elias Mobery wrote:
>Hey Martin & Michal, thank you both for the replies!
>
>Yes, sorry I messed up that seclabel entry, thanks. I fixed it and there
is
>no more error, but the images are still copied unfortunately.
>
>@Michal yes, I have been reading the Debian Live Manual like a contract,
>after messing with qemu.conf and permissions for days, I think its
>something in the live build and not libvirt.
>
>@Martin yeah both virsh start and virt-manager cause the images to be
>copied to /run. first.
>
>Yes, when I boot the Debian Live ISO, plug in the USB (mounted rw), copy
>the images to the live system from the USB and click run in virt-manager,
>the VM starts instantly and no copies are made in /run
>
>I use ISO loopback and toram to load the system directly into ram via
tmpfs
>mount. That's my grub.cfg
>
>menuentry "debian-live.iso" { set iso="/ISO/debian-live.iso" set
>root=(hd0,5) loopback loop $iso linux (loop)/live/vmlinuz-4.19.0-6-amd64
>boot=live components toram findiso=$iso initrd
>(loop)/live/initrd.img-4.19.0-6-amd64 }
>
>So, the squashfs is mounted read-only in
>/run/live/rootfs/filesystem.squashfs and its /dev/loop1
>
>/proc/mounts says:
>
>tmpfs /run/live/overlay rw
>overlay rw  lowerdir=/run/live/rootfs/filesystem.squashfs
>upperdir=/run/live/overlay/rw  (same place where the images are copied)
>

I do not think this is relevant, but sometimes overlayfs wants to have a
workdir as well.

>So you think that because the images are part of the squashfs which is
>read-only, they are first copied to /run/live/overlay/rw... to be written
>to?
>

Are they really copied?  I can't think of many more things why this
would happen.  Maybe some locking code does that in the backend (both
libvirt and qemu lock parts of the disks).

>I always thought that tmpfs is mounted on top of squash, so it's as if the
>squashfs were writable, without having to literally copy between the two
>filesystems.
>

It is not mounted over, if you mount over something you lose the
lowerdir, that's why it needs to be done with overlayfs which does the
copy-on-write.

That leads me to another idea.  Since you want copy-on-write for the
images, I presume, the image will get copied anyway once the guest
writes even a single byte to the image.  Unfortunately overlayfs is not
the best way for this scenario due to the granularity it offers
(per-file, not per-block or anything smaller).  What I think you
actually want in this case is to have a qcow image with the original
image used as backing.  You can create those with libvirt or even
without it, just using qemu-img, for example like this:

   qemu-img create -b /path/to/non-modified.image -f qcow2 -F
   format_of_backing_file /path/to/new-image.qcow2

For more information please read the qemu-img manual page to make sure
you use it properly, I just wrote the above from the top of my head, not
tested it.  The backing file path can also be relative.

If you specify the new image for the machines then the granularity
changes to way smaller blocks than the whole file making it occupy
less space in case of changes.

>Also I made the same build with Virtualbox and there is no copying of the
>images to /run/live/overlay.
>
>I will do some serious research into squashfs and tmpfs rn.
>

If you want to figure out when it happens I would suggest enabling debug
logs for libvirt, starting the qemu VM with --paused, but maybe it will
need some more debugging on lower layers

Re: Libvirt + Debian Live = Heart Attack

2021-11-25 Thread Martin Kletzander

On Wed, Nov 24, 2021 at 06:21:22PM +0100, Elias Mobery wrote:

Hey Martin & Michal, thank you both for the replies!

Yes, sorry I messed up that seclabel entry, thanks. I fixed it and there is
no more error, but the images are still copied unfortunately.

@Michal yes, I have been reading the Debian Live Manual like a contract,
after messing with qemu.conf and permissions for days, I think its
something in the live build and not libvirt.

@Martin yeah both virsh start and virt-manager cause the images to be
copied to /run. first.

Yes, when I boot the Debian Live ISO, plug in the USB (mounted rw), copy
the images to the live system from the USB and click run in virt-manager,
the VM starts instantly and no copies are made in /run

I use ISO loopback and toram to load the system directly into ram via tmpfs
mount. That's my grub.cfg

menuentry "debian-live.iso" { set iso="/ISO/debian-live.iso" set
root=(hd0,5) loopback loop $iso linux (loop)/live/vmlinuz-4.19.0-6-amd64
boot=live components toram findiso=$iso initrd
(loop)/live/initrd.img-4.19.0-6-amd64 }

So, the squashfs is mounted read-only in
/run/live/rootfs/filesystem.squashfs and its /dev/loop1

/proc/mounts says:

tmpfs /run/live/overlay rw
overlay rw  lowerdir=/run/live/rootfs/filesystem.squashfs
upperdir=/run/live/overlay/rw  (same place where the images are copied)



I do not think this is relevant, but sometimes overlayfs wants to have a
workdir as well.


So you think that because the images are part of the squashfs which is
read-only, they are first copied to /run/live/overlay/rw... to be written
to?



Are they really copied?  I can't think of many more things why this
would happen.  Maybe some locking code does that in the backend (both
libvirt and qemu lock parts of the disks).


I always thought that tmpfs is mounted on top of squash, so it's as if the
squashfs were writable, without having to literally copy between the two
filesystems.



It is not mounted over, if you mount over something you lose the
lowerdir, that's why it needs to be done with overlayfs which does the
copy-on-write.

That leads me to another idea.  Since you want copy-on-write for the
images, I presume, the image will get copied anyway once the guest
writes even a single byte to the image.  Unfortunately overlayfs is not
the best way for this scenario due to the granularity it offers
(per-file, not per-block or anything smaller).  What I think you
actually want in this case is to have a qcow image with the original
image used as backing.  You can create those with libvirt or even
without it, just using qemu-img, for example like this:

  qemu-img create -b /path/to/non-modified.image -f qcow2 -F
  format_of_backing_file /path/to/new-image.qcow2

For more information please read the qemu-img manual page to make sure
you use it properly, I just wrote the above from the top of my head, not
tested it.  The backing file path can also be relative.

If you specify the new image for the machines then the granularity
changes to way smaller blocks than the whole file making it occupy
less space in case of changes.


Also I made the same build with Virtualbox and there is no copying of the
images to /run/live/overlay.

I will do some serious research into squashfs and tmpfs rn.



If you want to figure out when it happens I would suggest enabling debug
logs for libvirt, starting the qemu VM with --paused, but maybe it will
need some more debugging on lower layers.  Anyway I really believe the
approach suggested above is what will lead to better results for you.

Have a nice day
Martin





On Wed, Nov 24, 2021, 5:10 PM Martin Kletzander  wrote:


On Wed, Nov 24, 2021 at 04:01:34PM +0100, Elias Mobery wrote:
>Hello Michal, thank you for the reply!
>
>I've carefully tested everything you suggested, thanks.
>
>I set dynamic_ownership=0 and use these hooks during the live build for
>permissions. (I googled a lot, and apparently libvirt needs the images to
>be executable too)
>
>chown -R libvirt-qemu:kvm  /var/lib/libvirt/images
>chmod -R g+rwx /var/lib/libvirt/images
>

I do not see why would the images need to be executable, you might need
an executable bit set on the directory so that your and qemu user can
browse it.

>Booting the live debian iso everything works in virt-manager, but again,
>after clicking "run", a copy of the vm image is created in
>/run/live/overlay/rw/var/lib/libvirt/images and only then does the VM
start.
>

Does that happen when you try to run it with virsh instead of
virt-manager?  Are you connected to the system daemon?

>Either it's still being chowned or chmodded somehow, or it's something
>else, but I can't stop this copy being made.
>
>Interestingly, when I boot the Live debian iso and then copy the images
>into /var/lib/libvirt/images from my USB stick, the VM starts immediately
>without creating any copies in the /run/live directory. So my gues

Re: Libvirt + Debian Live = Heart Attack

2021-11-24 Thread Martin Kletzander

On Wed, Nov 24, 2021 at 04:01:34PM +0100, Elias Mobery wrote:

Hello Michal, thank you for the reply!

I've carefully tested everything you suggested, thanks.

I set dynamic_ownership=0 and use these hooks during the live build for
permissions. (I googled a lot, and apparently libvirt needs the images to
be executable too)

chown -R libvirt-qemu:kvm  /var/lib/libvirt/images
chmod -R g+rwx /var/lib/libvirt/images



I do not see why would the images need to be executable, you might need
an executable bit set on the directory so that your and qemu user can
browse it.


Booting the live debian iso everything works in virt-manager, but again,
after clicking "run", a copy of the vm image is created in
/run/live/overlay/rw/var/lib/libvirt/images and only then does the VM start.



Does that happen when you try to run it with virsh instead of
virt-manager?  Are you connected to the system daemon?


Either it's still being chowned or chmodded somehow, or it's something
else, but I can't stop this copy being made.

Interestingly, when I boot the Live debian iso and then copy the images
into /var/lib/libvirt/images from my USB stick, the VM starts immediately
without creating any copies in the /run/live directory. So my guess is
that maybe the squashfs could be the issue?



Oh, interesting, is the USB stick filesystem mounted R/W and the live
ISO filesystem mounted read-only?  How is the overlay mounted?


Editing the XML


 
   

This results in an error:
Unsupported Configuration:
Security driver model 'null' not available



For issues like this it is most helpful to check the documentation:

  https://libvirt.org/formatdomain.html

where you can see it is just a missing attribute `model`, in this case
model="dac".


Here I tried setting security_driver=none in qemu.conf but same error after.


   
 



Same here.


This also returns an Error but I'm still googling to understand it properly.

XML document failed to validate against schema
Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
Invalid element relabel  for element seclabel
Extra element seclabel in interleave
Element domain failed to validate content

Thanks again so much for your helo, I've been messing with this for weeks
now and it's killing me.

On Tue, Nov 23, 2021, 9:43 PM Michal Prívozník  wrote:


On 11/23/21 17:25, Elias Mobery wrote:
>
> Hi everyone!
>
> I've built a Debian Live ISO with packages qemu and libvirt to run a VM
> in the live environment.
>
> The guest images are placed in  /var/lib/libvirt/images and 2GB each.
>
> Everything works great, except for one issue.
>
> When starting a VM, libvirt automatically issues a chown command to the
> images, changing ownership.
>
> This results in a copy of the images being created in
> /run/live/overlay/rw/var/lib/libvirt/images
>
> I don't want these copies to be made but can't stop it.
>
> I've tried editing qemu.conf user/group, dynamic ownership etc. without
> any luck.
>
> Is there a way to STOP libvirt from changing the ownership of these
images?
>
>

Setting dynamic_ownership=0 in qemu.conf is the way to go (don't forget
to restart the daemon after you made the change).

Alternatively, you can set  either for whole domain or
individual disks, e.g. like this:

  


  

  

or for whole domain:

...


  

I'm not sure what your setup is, but if chown() is a problem then what
if guest tries to write onto its disk? Wouldn't that create a copy in
overlay?

Michal




signature.asc
Description: PGP signature


Re: vm vcpu uses isolated cores

2021-09-02 Thread Martin Kletzander

On Thu, Sep 02, 2021 at 10:44:06AM +0800, Jiatong Shen wrote:

Hello,

  I am trying to understand why qemu vm CPU threads uses isolated cpus.

 I have a host which isolates some cpus using isolcpu
like isolcpus=1,2,3,4,5,7,8,9,10,11. unfortunately, vcpupin does not mask
out these cpus (vcpupin is still something like ).


That is because there are use cases which need this.  They isolate cpus
to be used by VM only (sometimes even moving kernel workload from these
cpus) and automatically removing isolcpus from the set would break this
valid behaviour.


When I log in to the system, seems qemu cpu thread only runs on these
isolcpus. I do not quite understand this behavior, because I think by using
isolcpu, kernel schedule will exclude these cpus and thus vcpu thread
shouldn't use these cores unless taskset explicitly got called.. So my
question is how does cpu thread got scheduled on isolated cpus?



libvirt sets the affinity for VMs because libvirt itself might not be
running on all cores and qemu being a child process would otherwise
inherit the affinity.  We even have this in the documentation and if you
want to limit the cpus it needs to be defined in the XML.

It begs the question whether we should somehow coordinate with the
kernel based on isolcpus, but I am not sure under what circumstances we
should do that and what is the proper way to do that.  I would suggest
you file an issue to discuss this further unless someone comes up with a
clear decision here.

Thank you,
Martin


Thank you.

--

Best Regards,

Jiatong Shen


signature.asc
Description: PGP signature


Re: Are secrets hidden from admins too - ?

2021-08-16 Thread Martin Kletzander

On Mon, Aug 09, 2021 at 11:48:11AM +0100, lejeczek wrote:

Hi guys.

On a remote & "shared" systems - are private secrets
completely 100% safe? Can root get to those?
(naturally excluding hacking of unknown bugs & exploits and
theories such as "no computer system is ultimately safe")



Well, the secret needs to be kept somewhere.  The most secure you can
get with secrets is the ephemeral ones, but those still need to be kept
in memory.  You could encrypt them, but then you would need to provide
the decryption passphrase or key when you want to use them and that
would be like providing the secret itself anyway.  Even thought there
are some limitations to unlimited memory access in Linux when someone
has root access you have to assume they have access to what the system
has access too.

The best you can do to mitigate that is using something like Intel SGX,
AMD SEV and such like.  There is Launch Security [0] in libvirt, but I
think it only supports SEV and something on s390.  But I do not have any
experience with those.

[0] https://libvirt.org/formatdomain.html#id113


And if answer is yes then - do you have any best practices
for storing & managing of those secrets?

many thanks, L.



signature.asc
Description: PGP signature


Re: issues with vm after upgrade

2021-08-12 Thread Martin Kletzander

On Wed, Aug 11, 2021 at 08:53:10PM +0200, daggs wrote:

Greetings Martin,



Sent: Wednesday, August 11, 2021 at 6:08 PM
From: "daggs" 
To: "Martin Kletzander" 
Cc: d...@berrange.com, libvirt-users@redhat.com
Subject: Re: issues with vm after upgrade

Greetings Martin,

> Sent: Wednesday, August 11, 2021 at 4:13 PM
> From: "Martin Kletzander" 
> To: "daggs" 
> Cc: d...@berrange.com, libvirt-users@redhat.com
> Subject: Re: issues with vm after upgrade
>
> On Wed, Aug 11, 2021 at 03:09:34PM +0200, daggs wrote:
> >Greetings Martin,
> >
> >> Sent: Wednesday, August 11, 2021 at 10:14 AM
> >> From: "Martin Kletzander" 
> >> To: "daggs" 
> >> Cc: d...@berrange.com, libvirt-users@redhat.com
> >> Subject: Re: issues with vm after upgrade
> >>


[...]


> >>
> >> 2) To your issue with starting the domain it would be good to know what
> >> is the error you get from virsh (or however you are starting the
> >> domain) and the debug logs of libvirtd, ideally just for the part of
> >> the domain starting.
> >that is the issue, there wasn't any error. the vm just didn't booted.
>
> Oh, so I misunderstood.  What was the state of the VM in libvirt?
> "paused" or "running"?  Was there serial console working?
it was marked as running and there was no serial



That's a pity we could not examine what was actually happening.


>
> >I can diff the original xml with the new one to see the diffs and post them 
here if you wish
> >
>
> Would be nice to see if there are any differences.  The newly created
> one works then?
>

I'll sent it later today



here: https://dpaste.com/5VBUU8Z9W



Unfortunately there are many differences there.  The machine type
changes _something_ in qemu, there is different PCI(e) topology, and I
do not think I will be able to figure this out without the non-working
machine.

So if your current setup works for you right now I'd leave figuring out
the previous issue to others, if there is anyone wanting to figure out
if there is some libvirt issue.

Have a nice day


signature.asc
Description: PGP signature


Re: issues with vm after upgrade

2021-08-11 Thread Martin Kletzander

On Wed, Aug 11, 2021 at 03:09:34PM +0200, daggs wrote:

Greetings Martin,


Sent: Wednesday, August 11, 2021 at 10:14 AM
From: "Martin Kletzander" 
To: "daggs" 
Cc: d...@berrange.com, libvirt-users@redhat.com
Subject: Re: issues with vm after upgrade

On Tue, Aug 10, 2021 at 09:21:00PM +0200, daggs wrote:
>Greetings Martin, Dan
>
>> Sent: Wednesday, August 04, 2021 at 1:54 PM
>> From: "daggs" 
>> To: "Martin Kletzander" 
>> Cc: libvirt-users@redhat.com, d...@berrange.com
>> Subject: Re: issues with vm after upgrade
>>
>> Greetings Martin,
>>
>> > Sent: Wednesday, August 04, 2021 at 11:52 AM
>> > From: "Martin Kletzander" 
>> > To: "daggs" 
>> > Cc: libvirt-users@redhat.com, d...@berrange.com
>> > Subject: Re: issues with vm after upgrade
>> >
>> > On Wed, Aug 04, 2021 at 10:30:29AM +0200, daggs wrote:
>> > >Greetings Martin ,
>> > >
>> > >> Sent: Wednesday, August 04, 2021 at 11:11 AM
>> > >> From: "Martin Kletzander" 
>> > >> To: "daggs" 
>> > >> Cc: libvirt-users@redhat.com, d...@berrange.com
>> > >> Subject: Re: issues with vm after upgrade
>> > >>
>> > >> On Tue, Aug 03, 2021 at 08:47:20PM +0200, daggs wrote:
>> > >> >> Sent: Tuesday, August 03, 2021 at 6:51 PM
>> > >> >> From: "daggs" 
>> > >> >> To: d...@berrange.com
>> > >> >> Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
>> > >> >> Subject: Re: issues with vm after upgrade
>> > >> >>
>> > >> >> Greetings Daniel,
>> > >> >>
>> > >> >> > Sent: Tuesday, August 03, 2021 at 6:39 PM
>> > >> >> > From: "Daniel P. Berrange" 
>> > >> >> > To: "daggs" 
>> > >> >> > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
>> > >> >> > Subject: Re: issues with vm after upgrade
>> > >> >> >
>> > >> >> > On Tue, Aug 03, 2021 at 05:34:53PM +0200, daggs wrote:
>> > >> >> > > > Sent: Tuesday, August 03, 2021 at 6:29 PM
>> > >> >> > > > From: "Daniel P. Berrange" 
>> > >> >> > > > To: "daggs" 
>> > >> >> > > > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
>> > >> >> > > > Subject: Re: issues with vm after upgrade
>> > >> >> > > >
>> > >> >> > > > On Tue, Aug 03, 2021 at 05:21:52PM +0200, daggs wrote:
>> > >> >> > > > > Greetings Daniel,
>> > >> >> > > > >
>> > >> >> > > > > > Sent: Tuesday, August 03, 2021 at 4:12 PM
>> > >> >> > > > > > From: "Daniel P. Berrange" 
>> > >> >> > > > > > To: "daggs" 
>> > >> >> > > > > > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
>> > >> >> > > > > > Subject: Re: issues with vm after upgrade
>> > >> >> > > > > >
>> > >> >> > > > > > The  element just refers to the *host* backend used 
for audio
>> > >> >> > > > > > playback. It would not affect guest hardware. Further, 
this has always
>> > >> >> > > > > > existed - it just wasn't exposed in the XML previously.
>> > >> >> > > > > >
>> > >> >> > > > > >
>> > >> >> > > > >
>> > >> >> > > > > the upgrade changed something, here is the qemu cmd before 
the upgrade: https://dpaste.com/F2N5T8CT8
>> > >> >> > > > > here is after https://dpaste.com/F2N5T8CT8
>> > >> >> > > >
>> > >> >> > > > Those links are both the same I'm afraid
>> > >> >> > > >
>> > >> >> > >
>> > >> >> > > Duh! my bad!
>> > >> >> > > good log: http://dpaste.com/F2N5T8CT8
>> > >> >> > > bad log: http://dpaste.com/6ECUHD2J8
>> > >> >> >
>> > >> >> &g

Re: vmware ESXi in KVM

2021-08-11 Thread Martin Kletzander

On Tue, Aug 10, 2021 at 09:45:37PM +0200, Gunnar wrote:

I am trying to install esxi7 inside a KVM machine

   virt-install --name=esxi7 \
   --vcpus=2 \
   --memory=4096 \
   
--cdrom=/home/username/isos/VMware-VMvisor-Installer-7.0U2a-17867351.x86_64.iso
   \
   --disk size=33 \
   --os-variant=unknown

the installation process starts but does not get fails with a "No
network adapters" error. This does not happen with other VM's.
What do I have to add to above command in order to attach the default
network adapter to the machine?



First look if the machine has any network interface.  If it does, the
guest OS probably does not support the model, so you can change that.
If it does not have one, then you probably want to use '--network
network=default' in your virt-install command and you can always look
that up in the man page as well (e.g. man virt-install).


or is there any other trick I have to be aware of when it comes to
installing ESXi



No idea as I have never installed anything like that.


thx ... Gunnar


Hope that helped,
Martin


signature.asc
Description: PGP signature


Re: issues with vm after upgrade

2021-08-11 Thread Martin Kletzander

On Tue, Aug 10, 2021 at 09:21:00PM +0200, daggs wrote:

Greetings Martin, Dan


Sent: Wednesday, August 04, 2021 at 1:54 PM
From: "daggs" 
To: "Martin Kletzander" 
Cc: libvirt-users@redhat.com, d...@berrange.com
Subject: Re: issues with vm after upgrade

Greetings Martin,

> Sent: Wednesday, August 04, 2021 at 11:52 AM
> From: "Martin Kletzander" 
> To: "daggs" 
> Cc: libvirt-users@redhat.com, d...@berrange.com
> Subject: Re: issues with vm after upgrade
>
> On Wed, Aug 04, 2021 at 10:30:29AM +0200, daggs wrote:
> >Greetings Martin ,
> >
> >> Sent: Wednesday, August 04, 2021 at 11:11 AM
> >> From: "Martin Kletzander" 
> >> To: "daggs" 
> >> Cc: libvirt-users@redhat.com, d...@berrange.com
> >> Subject: Re: issues with vm after upgrade
> >>
> >> On Tue, Aug 03, 2021 at 08:47:20PM +0200, daggs wrote:
> >> >> Sent: Tuesday, August 03, 2021 at 6:51 PM
> >> >> From: "daggs" 
> >> >> To: d...@berrange.com
> >> >> Cc: "Martin Kletzander" , libvirt-users@redhat.com
> >> >> Subject: Re: issues with vm after upgrade
> >> >>
> >> >> Greetings Daniel,
> >> >>
> >> >> > Sent: Tuesday, August 03, 2021 at 6:39 PM
> >> >> > From: "Daniel P. Berrange" 
> >> >> > To: "daggs" 
> >> >> > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
> >> >> > Subject: Re: issues with vm after upgrade
> >> >> >
> >> >> > On Tue, Aug 03, 2021 at 05:34:53PM +0200, daggs wrote:
> >> >> > > > Sent: Tuesday, August 03, 2021 at 6:29 PM
> >> >> > > > From: "Daniel P. Berrange" 
> >> >> > > > To: "daggs" 
> >> >> > > > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
> >> >> > > > Subject: Re: issues with vm after upgrade
> >> >> > > >
> >> >> > > > On Tue, Aug 03, 2021 at 05:21:52PM +0200, daggs wrote:
> >> >> > > > > Greetings Daniel,
> >> >> > > > >
> >> >> > > > > > Sent: Tuesday, August 03, 2021 at 4:12 PM
> >> >> > > > > > From: "Daniel P. Berrange" 
> >> >> > > > > > To: "daggs" 
> >> >> > > > > > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
> >> >> > > > > > Subject: Re: issues with vm after upgrade
> >> >> > > > > >
> >> >> > > > > > The  element just refers to the *host* backend used 
for audio
> >> >> > > > > > playback. It would not affect guest hardware. Further, this 
has always
> >> >> > > > > > existed - it just wasn't exposed in the XML previously.
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > > > the upgrade changed something, here is the qemu cmd before the 
upgrade: https://dpaste.com/F2N5T8CT8
> >> >> > > > > here is after https://dpaste.com/F2N5T8CT8
> >> >> > > >
> >> >> > > > Those links are both the same I'm afraid
> >> >> > > >
> >> >> > >
> >> >> > > Duh! my bad!
> >> >> > > good log: http://dpaste.com/F2N5T8CT8
> >> >> > > bad log: http://dpaste.com/6ECUHD2J8
> >> >> >
> >> >> > The new log has a CLI flag
> >> >> >
> >> >> >  -audiodev id=audio1,driver=none
> >> >> >
> >> >> > but the old log has an env variable
> >> >> >
> >> >> >   QEMU_AUDIO_DRV=none
> >> >> >
> >> >> > which should be functionally identical, as QEMU will parse them both
> >> >> > to the same internal config.
> >> >> >
> >> >> > The obvious difference in the logs which can cause your guest to fail
> >> >> > is the different QEMU version. The old log shows QEMU 5.2.0, while the
> >> >> > new log shows QEMU 6.0.0
> >> >> >
> >> >>
> >> >> thanks for the help, I went to look why the efi fw and found out that 
the nvram en

Re: issues with vm after upgrade

2021-08-04 Thread Martin Kletzander

On Wed, Aug 04, 2021 at 10:30:29AM +0200, daggs wrote:

Greetings Martin ,


Sent: Wednesday, August 04, 2021 at 11:11 AM
From: "Martin Kletzander" 
To: "daggs" 
Cc: libvirt-users@redhat.com, d...@berrange.com
Subject: Re: issues with vm after upgrade

On Tue, Aug 03, 2021 at 08:47:20PM +0200, daggs wrote:
>> Sent: Tuesday, August 03, 2021 at 6:51 PM
>> From: "daggs" 
>> To: d...@berrange.com
>> Cc: "Martin Kletzander" , libvirt-users@redhat.com
>> Subject: Re: issues with vm after upgrade
>>
>> Greetings Daniel,
>>
>> > Sent: Tuesday, August 03, 2021 at 6:39 PM
>> > From: "Daniel P. Berrange" 
>> > To: "daggs" 
>> > Cc: "Martin Kletzander" , libvirt-users@redhat.com
>> > Subject: Re: issues with vm after upgrade
>> >
>> > On Tue, Aug 03, 2021 at 05:34:53PM +0200, daggs wrote:
>> > > > Sent: Tuesday, August 03, 2021 at 6:29 PM
>> > > > From: "Daniel P. Berrange" 
>> > > > To: "daggs" 
>> > > > Cc: "Martin Kletzander" , libvirt-users@redhat.com
>> > > > Subject: Re: issues with vm after upgrade
>> > > >
>> > > > On Tue, Aug 03, 2021 at 05:21:52PM +0200, daggs wrote:
>> > > > > Greetings Daniel,
>> > > > >
>> > > > > > Sent: Tuesday, August 03, 2021 at 4:12 PM
>> > > > > > From: "Daniel P. Berrange" 
>> > > > > > To: "daggs" 
>> > > > > > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
>> > > > > > Subject: Re: issues with vm after upgrade
>> > > > > >
>> > > > > > The  element just refers to the *host* backend used for 
audio
>> > > > > > playback. It would not affect guest hardware. Further, this has 
always
>> > > > > > existed - it just wasn't exposed in the XML previously.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > > the upgrade changed something, here is the qemu cmd before the 
upgrade: https://dpaste.com/F2N5T8CT8
>> > > > > here is after https://dpaste.com/F2N5T8CT8
>> > > >
>> > > > Those links are both the same I'm afraid
>> > > >
>> > >
>> > > Duh! my bad!
>> > > good log: http://dpaste.com/F2N5T8CT8
>> > > bad log: http://dpaste.com/6ECUHD2J8
>> >
>> > The new log has a CLI flag
>> >
>> >  -audiodev id=audio1,driver=none
>> >
>> > but the old log has an env variable
>> >
>> >   QEMU_AUDIO_DRV=none
>> >
>> > which should be functionally identical, as QEMU will parse them both
>> > to the same internal config.
>> >
>> > The obvious difference in the logs which can cause your guest to fail
>> > is the different QEMU version. The old log shows QEMU 5.2.0, while the
>> > new log shows QEMU 6.0.0
>> >
>>
>> thanks for the help, I went to look why the efi fw and found out that the 
nvram entry in /etc/libvirt/eqmu.conf was deleted upon update.
>> I'm sure fixing this will solve he boot issue, hopefully audio issue too.
>>
>> Thanks,
>>
>> Dagg.
>>
>
>unfortunately, that didn't helped, vm still wont come up, latest log at 
http://dpaste.com/2XZA4VQZA
>any ideas?
>

Seems like the issue is:

2021-07-16T10:29:19.259409Z qemu-system-x86_64: vfio: Cannot reset device 
:00:1f.3, no available reset mechanism.
2021-07-16T10:29:19.369391Z qemu-system-x86_64: vfio: Cannot reset device 
:00:1f.3, no available reset mechanism.

did you upgrade anything else?



are you sure? you can see the same prints in the good log at 
http://dpaste.com/F2N5T8CT8



Oh, sorry, my bad.  Then I do not see why it would not start.  You said
you managed to make the VM start on your own, what was the change that
made it boot?  Maybe there's a bug somewhere in qemu...


signature.asc
Description: PGP signature


Re: issues with vm after upgrade

2021-08-04 Thread Martin Kletzander

On Tue, Aug 03, 2021 at 08:47:20PM +0200, daggs wrote:

Sent: Tuesday, August 03, 2021 at 6:51 PM
From: "daggs" 
To: d...@berrange.com
Cc: "Martin Kletzander" , libvirt-users@redhat.com
Subject: Re: issues with vm after upgrade

Greetings Daniel,

> Sent: Tuesday, August 03, 2021 at 6:39 PM
> From: "Daniel P. Berrange" 
> To: "daggs" 
> Cc: "Martin Kletzander" , libvirt-users@redhat.com
> Subject: Re: issues with vm after upgrade
>
> On Tue, Aug 03, 2021 at 05:34:53PM +0200, daggs wrote:
> > > Sent: Tuesday, August 03, 2021 at 6:29 PM
> > > From: "Daniel P. Berrange" 
> > > To: "daggs" 
> > > Cc: "Martin Kletzander" , libvirt-users@redhat.com
> > > Subject: Re: issues with vm after upgrade
> > >
> > > On Tue, Aug 03, 2021 at 05:21:52PM +0200, daggs wrote:
> > > > Greetings Daniel,
> > > >
> > > > > Sent: Tuesday, August 03, 2021 at 4:12 PM
> > > > > From: "Daniel P. Berrange" 
> > > > > To: "daggs" 
> > > > > Cc: "Martin Kletzander" , 
libvirt-users@redhat.com
> > > > > Subject: Re: issues with vm after upgrade
> > > > >
> > > > > The  element just refers to the *host* backend used for audio
> > > > > playback. It would not affect guest hardware. Further, this has always
> > > > > existed - it just wasn't exposed in the XML previously.
> > > > >
> > > > >
> > > >
> > > > the upgrade changed something, here is the qemu cmd before the upgrade: 
https://dpaste.com/F2N5T8CT8
> > > > here is after https://dpaste.com/F2N5T8CT8
> > >
> > > Those links are both the same I'm afraid
> > >
> >
> > Duh! my bad!
> > good log: http://dpaste.com/F2N5T8CT8
> > bad log: http://dpaste.com/6ECUHD2J8
>
> The new log has a CLI flag
>
>  -audiodev id=audio1,driver=none
>
> but the old log has an env variable
>
>   QEMU_AUDIO_DRV=none
>
> which should be functionally identical, as QEMU will parse them both
> to the same internal config.
>
> The obvious difference in the logs which can cause your guest to fail
> is the different QEMU version. The old log shows QEMU 5.2.0, while the
> new log shows QEMU 6.0.0
>

thanks for the help, I went to look why the efi fw and found out that the nvram 
entry in /etc/libvirt/eqmu.conf was deleted upon update.
I'm sure fixing this will solve he boot issue, hopefully audio issue too.

Thanks,

Dagg.



unfortunately, that didn't helped, vm still wont come up, latest log at 
http://dpaste.com/2XZA4VQZA
any ideas?



Seems like the issue is:

2021-07-16T10:29:19.259409Z qemu-system-x86_64: vfio: Cannot reset device 
:00:1f.3, no available reset mechanism.
2021-07-16T10:29:19.369391Z qemu-system-x86_64: vfio: Cannot reset device 
:00:1f.3, no available reset mechanism.

did you upgrade anything else?


Dagg



signature.asc
Description: PGP signature


Re: issues with vm after upgrade

2021-08-03 Thread Martin Kletzander

On Mon, Aug 02, 2021 at 04:33:20PM +0200, daggs wrote:

Greetings Martin,


Sent: Monday, August 02, 2021 at 12:17 PM
From: "Martin Kletzander" 
To: "daggs" 
Cc: libvirt-users@redhat.com
Subject: Re: issues with vm after upgrade

On Sat, Jul 31, 2021 at 12:19:59PM +0200, daggs wrote:
>Greetings,
>
>a few weeks ago I've upgraded my system, this resulted with qemu and libvirt 
being upgraded to 6.0.0 and ~7.5.0 respectfully.
>I have two vms running on my system, router and streamer.
>the router vm works great, the streamer vm doesn't.
>after the streamer vm start, the monitor screen gets black and thats it. no 
relevant error are found in the log, see: http://dpaste.com/ERWDEJQPC
>the xml ca be found at https://dpaste.com/FQDN6NTN2
>in contrast the following oneliner works: qemu-system-x86_64 \
>-machine pc-q35-5.0,accel=kvm,usb=off,smm=on,dump-guest-core=off \
>-cpu host,migratable=on \
>-m 15360 \
>-smp 4,sockets=1,dies=1,cores=2,threads=2 \
>-drive file=/home/streamer/streamer.img.qcow2.new,if=virtio,format=qcow2 \
>-device 
vfio-pci,host=:00:02.0,romfile=/home/streamer/gpu-8086:5912-uefi.rom,multifunction=on
 \
>-device vfio-pci,host=:00:1f.3,multifunction=on \
>-usb \
>-device usb-host,vendorid=0x046d,productid=0xc52e \
>-device usb-host,vendorid=0x2548,productid=0x1002 \
>-display none \
>-netdev tap,id=hostnet0,ifname=virtsw-streamer,script=no,downscript=no \
>-device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:5a:4c:8c \
>-blockdev 
'{"driver":"file","filename":"/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
>-blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/streamer-vm-q35_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
>
>another issue encountered caused by this param: "-audiodev 
id=audio1,driver=none" which is auto added to the qemu line.
>if I add the line to the above oneliner, the guest doesn't detects the pt 
sound card. without it it does and it works.
>

The links have expired, so I cannot look at the XML.  However do you
have any  in the XML at all?  I believe that without it we are
disabling any audio backends since no audio HW was requested.



here are the links:
1. xml: https://dpaste.com/D6JANX3Z3
2. log: https://dpaste.com/FMUDZY9PD

as for the audio entry, "" is in the xml
I didn't added it



So let get this straight.  You want the VM to use the HW GPU that you
assigned to it and also use the audio on that GPU (e.g. HDMI or DP
output).  When you add the "-audiodev driver=none" the VM cannot see the
audio device on that GPU card?  Or is that unrelated?

There were some strict definitions added for audio devices lately, I
presume to make sure that no data gets leaked in/out the VM and in order
to get audio anywhere else than from/to VNC/spice you'd need to
configure that.  It should not affect device assignment as far as I
understand it, although there might be some misunderstanding.


Thanks,

Dagg



signature.asc
Description: PGP signature


Re: issues with vm after upgrade

2021-08-02 Thread Martin Kletzander

On Sat, Jul 31, 2021 at 12:19:59PM +0200, daggs wrote:

Greetings,

a few weeks ago I've upgraded my system, this resulted with qemu and libvirt 
being upgraded to 6.0.0 and ~7.5.0 respectfully.
I have two vms running on my system, router and streamer.
the router vm works great, the streamer vm doesn't.
after the streamer vm start, the monitor screen gets black and thats it. no 
relevant error are found in the log, see: http://dpaste.com/ERWDEJQPC
the xml ca be found at https://dpaste.com/FQDN6NTN2
in contrast the following oneliner works: qemu-system-x86_64 \
-machine pc-q35-5.0,accel=kvm,usb=off,smm=on,dump-guest-core=off \
-cpu host,migratable=on \
-m 15360 \
-smp 4,sockets=1,dies=1,cores=2,threads=2 \
-drive file=/home/streamer/streamer.img.qcow2.new,if=virtio,format=qcow2 \
-device 
vfio-pci,host=:00:02.0,romfile=/home/streamer/gpu-8086:5912-uefi.rom,multifunction=on
 \
-device vfio-pci,host=:00:1f.3,multifunction=on \
-usb \
-device usb-host,vendorid=0x046d,productid=0xc52e \
-device usb-host,vendorid=0x2548,productid=0x1002 \
-display none \
-netdev tap,id=hostnet0,ifname=virtsw-streamer,script=no,downscript=no \
-device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:5a:4c:8c \
-blockdev 
'{"driver":"file","filename":"/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/streamer-vm-q35_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'

another issue encountered caused by this param: "-audiodev 
id=audio1,driver=none" which is auto added to the qemu line.
if I add the line to the above oneliner, the guest doesn't detects the pt sound 
card. without it it does and it works.



The links have expired, so I cannot look at the XML.  However do you
have any  in the XML at all?  I believe that without it we are
disabling any audio backends since no audio HW was requested.


help on solving both issues will be appreciated.

Thanks,

Dagg




signature.asc
Description: PGP signature


Re: how to build a github release tarball

2021-07-14 Thread Martin Kletzander

On Wed, Jul 14, 2021 at 08:44:52PM +0800, Jiatong Shen wrote:

Hello community,

 I am trying to figure out a way to build a release tarball like
https://github.com/libvirt/libvirt/releases?after=v6.2.0, for libvirt
6.0.0, but don't know how.
Could anyone teach me how to package it? thank you.



If you look at https://libvirt.org/downloads.html then there is a link
to release tarballs: https://libvirt.org/sources/

If you want to build it yourself, then something along the lines of
`meson build && ninja -C build dist` should do, but it should not be
needed.

Otherwise the tarball provided by github is just a snapshot of the git
tree at the point in time of the tag and build needs to be done the same
way as building from git.

Did that answer your question?

Martin


--

Best Regards,

Jiatong Shen


signature.asc
Description: PGP signature


Re: move mount permission denied

2021-04-12 Thread Martin Kletzander

On Wed, Mar 31, 2021 at 05:20:34PM +0800, Jiatong Shen wrote:

Hello community!

 I am faced with a mysterious [error](
https://gist.github.com/jshen28/5f29eed51e0a1308684214b35f009478) which
says move mount is not permissioned.

We are using libvirt with openstack-helm which running libvirt in a docker
based k8s environment. /dev/termination-log is a device created and
attached by k8s and mount looks like `/dev/mapper/ubuntu--vg-root on
/var/log/termination-log type ext4
(rw,relatime,errors=remount-ro,data=ordered)`

Any idea why this happens? appreciate the help!



Because libvirt is shielding the VMs inside containers and it needs to
move some files in there (bind mount to be precise).  You can turn this
off in the config file.  But to be brutally honest I think you will have
some other issues as well and you will have to change few more things
here and there.  If you want to run libvirt inside a container, then I
would suggest you work together with the KubeVirt community [0] who are
already doing that and have some knowledge about what is needed and what
are the requirements.  Don't reinvent the wheel ;-)

Of course if there are some things that we can make better, then we'll
be happy to know about them, so that we can make your experience nicer.
In that case let us know!

[0] https://kubevirt.io/community/


--

Best Regards,

Jiatong Shen


signature.asc
Description: PGP signature


Re: Installing Kali Linux as Guest OS in KVM Hypervisor

2020-12-11 Thread Martin Kletzander

On Tue, Dec 01, 2020 at 09:58:26PM +0530, Kaushal Shriyan wrote:

Hi,

I have run the below command to install Kali Linux using
linux-2020.4-installer-amd64.iso from https://www.kali.org/downloads/

#virt-install --name kalilinux --memory 4096 --vcpus=2
--location=/linuxkvmaddgbdisk/kali-linux-2020.4-installer-amd64.iso,kernel=install.amd/gtk/vmlinuz,initrd=install.amd/gtk/initrd.gz
--network=bridge:br0 --os-type=linux --os-variant=debian9 --graphics=none
--extra-args "console=ttyS0" -v --disk
path=/linuxkvmaddgbdisk/kalilinux.img,size=50

I am not able to get the root login prompt when I run the below command to
set IP and hostname for the guest OS. Am I missing any parameters from the
above virt-install command to install Kali Linux as Guest OS in KVM
Hypervisor?



I'm not sure why you need to set the IP address.  Are you running a network with
static IPs, without DHCP?  As I cannot see where br0 is connected I can't guess
more than that.  You can use Michal's approach if you use the default libvirt
network, though.


#virsh console kalilinux
Connected to domain kalilinux
Escape character is ^]



You might be connected at this point.  It's just that the guest sent the "login:
" prompt before you connected.  Try pressing enter at this point to see whether
there's something listening on the serial console.  If it's not, then I wonder
where it would listen, given the --graphics=none.

There are ways to modify the guest image. Easiest thing might be to use
virt-customize.  But I truly believe you have a working system and all you need
to do is write the username and press enter.  In the end it will look like this:

I'm trying to reproduce the install right now with comparable command-line, but
it's getting stuck on something unrelated.  If I manage to get it to work I will
let you know what I found.


Any help will be highly appreciated. I look forward to hearing from you.
Thanks in Advance.

Best Regards,

Kaushal


signature.asc
Description: PGP signature


Re: image works in native but not in vm when cpu mode='host-passthrough' is set

2020-11-23 Thread Martin Kletzander

On Fri, Nov 20, 2020 at 08:06:08AM +0100, daggs wrote:

Greetings Martin,


Sent: Thursday, November 19, 2020 at 11:23 PM
From: "Martin Kletzander" 
To: "daggs" 
Cc: "libvirt-usersredhat.com" 
Subject: Re: image works in native but not in vm when cpu 
mode='host-passthrough' is set

On Tue, Nov 17, 2020 at 11:32:29AM +0100, daggs wrote:
...
Not sure, but there might be some flags that are not passed through even with
host-passthrough.  Virtualisation ones are definitely one of those that need to
be enabled on top of host-passthrough.  The easiest thing to check that I can
think of would be booting some live distro and checking the flags in
/proc/cpuinfo and how are they different from your host.



I don't need livecd, I can diff both native and vm, see 
https://dpaste.com/ARETBEPCL
from what I can see, the vm is missing these flags: dts acpi tm pbe art pebs 
bts nonstop_tsc aperfmperf dtes64 monitor ds_cpl est tm2 sdbg xtpr pdcm epb 
intel_pt dtherm pln pts hwp hwp_notify hwp_act_window hwp_epp
and have these flags: tsc_known_freq hypervisor umip arch_capabilities

beside the acpi flag which I found strange to be messing, I can't think of any 
other flag which might be needed.



I'm sorry to say that, but nobody else here provides expertise, maybe extracting
the qemu command-lines from the logs and asking on qemu-users might be the best
next step. Sorry I cannot help you more as I do not see anything immediately
obvious here.

Martin


Dagg.




signature.asc
Description: PGP signature


Re: image works in native but not in vm when cpu mode='host-passthrough' is set

2020-11-19 Thread Martin Kletzander

On Tue, Nov 17, 2020 at 11:32:29AM +0100, daggs wrote:

Greetings.

I have an image I've created with a bunch of chost flags which works on my 
machine when it comes to native boot.
if I take that same image into a vm managed via libvirt, I get kernel panic.
I'd assume that something is missing from my vm config, question is what and 
what I can do about it?
here is the flags part of lscpu in native and vm: https://dpaste.com/3TR8QJ5G8
and the vm's xml: https://dpaste.com/984JX4LUQ
if I build the image with the default flags (march=x86-64), the vm boots well.
my new chost is -O2 -pipe -march=skylake -mabm -mno-adx -mno-avx -mno-avx2 
-mno-bmi -mno-bmi2 -mno-f16c -mno-fma -mno-xsave -mno-xsavec -mno-xsaveopt 
-mno-xsaves -mno-sgx
the cpu is Intel(R) Pentium(R) CPU G4560 @ 3.50GHz



Not sure, but there might be some flags that are not passed through even with
host-passthrough.  Virtualisation ones are definitely one of those that need to
be enabled on top of host-passthrough.  The easiest thing to check that I can
think of would be booting some live distro and checking the flags in
/proc/cpuinfo and how are they different from your host.


thoughts?

Thanks,

Dagg.



signature.asc
Description: PGP signature


Re: unable to find any master var store for loader error

2020-10-13 Thread Martin Kletzander

On Mon, Oct 12, 2020 at 10:52:25PM +0200, daggs wrote:

Greetings,

I have the following machine: https://dpaste.com/5BPA3F77F which I'm trying to 
boot in uefi.
/etc/libvirt/qemu.conf looks like this: https://dpaste.com/B3SFHUY6R and the 
ovmf files exists in the path, see:
# ll /usr/share/edk2-ovmf/OVMF_CODE.fd /usr/share/edk2-ovmf/OVMF_VARS.fd 
/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd 
/usr/share/edk2-ovmf/OVMF_VARS.secboot.fd
-rw-r--r-- 1 root root 1966080 Aug 21 14:32 /usr/share/edk2-ovmf/OVMF_CODE.fd
-rw-r--r-- 1 root root 1966080 Aug 21 14:32 
/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd
-rw-r--r-- 1 root root  131072 Aug 21 14:32 /usr/share/edk2-ovmf/OVMF_VARS.fd
-rw-r--r-- 1 root root  131072 Aug 21 14:32 
/usr/share/edk2-ovmf/OVMF_VARS.secboot.fd

when I try to start the machine, I get this error:
error: Failed to start domain vm1
error: operation failed: unable to find any master var store for loader: 
/usr/share/edk2-ovmf/OVMF_CODE.fd

libvirt version is 6.7.0 and qemu version is 5.1.0

any idea how to fix this issue?



What do you have in /usr/share/qemu/firmware/ ? There should be JSON files
installed (by QEMU, I think) describing the possible firmware combinations.


Thanks.

Dagg.



signature.asc
Description: PGP signature


Re: Building libvirt library without libvirtd or virsh

2020-10-08 Thread Martin Kletzander

On Wed, Oct 07, 2020 at 04:50:26PM -0700, Román González wrote:

Hello there,

I'm trying to play with musl and libvirt to see if I'm able to build a
libvirt client binary without dynamic lib dependencies. I have two
questions:

1) to your knowledge, is this exercise futile?

2) Do you know if there is a way to *only* compile the library bits?

I want to reduce the number of dependencies in the build, and only
construct the libvirt libraries, not libvirtd nor virsh.



You can disable building the daemon with -Ddriver_libvirtd=disabled (if I am
reading the code correctly).  I do not think there is something similar for the
clients, but I might be wrong.  Pavel (Cc'd) would definitely know or at least
be able to find it out more easily.  If it is not possible now then it should
not be that difficult to add such option, I think.


Thanks in advance for any help you can provide.

Roman.-


signature.asc
Description: PGP signature


Re: what does "virsh destroy" really ?

2020-10-06 Thread Martin Kletzander

On Tue, Oct 06, 2020 at 10:22:03AM +0200, Michael Hierweck wrote:

On 06.10.20 10:16, Daniel P. Berrangé wrote:


You don't need to be so scared of virsh destroy. It is simply akin to pulling
out the power plug, and modern OS with a decent journaling filesystem will
recover from that quite reasonably. Sure you'll loose state of what's running,
but 99% of the time your guest will boot up again just fine.


In case one of our (many) VMs crash we "destroy" it. We never experiencend any 
Problem you
would not expect in case of physical server crashes.

Over the last 10 years this happened more than 1000 times...



I was a bit too harsh when saying you should not use it.  Of course when the VM
is not running then destroy gets rid of the process.  In case it helps, you can
also set what libvirt is supposed to do when the VM crashes (at least visibly
for libvirt, not when something inside the guest crashes) using the 
element [0].

Have a nice day,
Martin

[0] https://libvirt.org/formatdomain.html#events-configuration


Michael




signature.asc
Description: PGP signature


Re: what does "virsh destroy" really ?

2020-10-06 Thread Martin Kletzander

On Mon, Oct 05, 2020 at 07:12:34PM -0400, Digimer wrote:

On 2020-10-05 6:04 p.m., Lentes, Bernd wrote:

Hi,

what does "virsh destroy" with the domain ? Send a kill -9 to the process ?

Bernd



It forces the guest off, like pulling the power on a hardware machine.
Not sure of the exact mechanism behind the scenes. It does leave the
server defined and you can reboot it again later (albeit like restoring
power to a normal machine, so it might need to replay journals, etc).



The technical details should not matter, but it tries to send "quit" to QEMU and
falls back to killing it IIRC (firsh with SIGTERM and then with SIGKILL).  Don't
do that if you want to use the machine again ;-)


--
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould




signature.asc
Description: PGP signature


Re: can't define domain - error: cannot open /dev/null: Operation not permitted

2020-09-21 Thread Martin Kletzander

On Sun, Sep 20, 2020 at 01:09:51PM +0200, Lentes, Bernd wrote:

Hi,



Hi, I'll start with the usual...


i have a two-node cluster running on SLES 12 with pacemaker.
The cluster refused to start the domains on one node.
So i took some of the domains out of the cluster and tried to start it manually.
This is what happened:

virsh # define /mnt/share/vm_documents-oo.xml
error: Failed to define domain from /mnt/share/vm_documents-oo.xml
error: cannot open /dev/null: Operation not permitted

Same with another domain.



What does the XML look like?  What do the logs[0] say?


On the other node domains are defined and started without problems.


Are the configs (libvirtd.conf and qemu.conf) the same on both nodes?

Have a nice day,
Martin

[0] https://libvirt.org/kbase/debuglogs.html


Permissions on /dev and /dev/null are the same:

ha-idg-1:/mnt/share # ll -d /dev
drwxr-xr-x 25 root root 5420 Sep 17 20:47 /dev
ha-idg-1:/mnt/share # ll /dev/null
crw-rw-rw- 1 root root 1, 3 Aug 24 14:39 /dev/null

ha-idg-2:/mnt/share # ll -d /dev
drwxr-xr-x 25 root root 5340 Sep  9 10:31 /dev
ha-idg-2:/mnt/share # ll /dev/null
crw-rw-rw- 1 root root 1, 3 Aug 24 15:48 /dev/null

ha-idg-1 is the one causing trouble.
Both systems SLES 12 SP4, same patchlevel.
livirt is:
ha-idg-1:/mnt/share # rpm -qa|grep -i libvirt
libvirt-daemon-driver-storage-iscsi-4.0.0-8.15.2.x86_64
libvirt-libs-4.0.0-8.15.2.x86_64
python-libvirt-python-4.0.0-2.34.x86_64
libvirt-daemon-driver-nwfilter-4.0.0-8.15.2.x86_64
libvirt-glib-1_0-0-0.2.1-1.2.x86_64
typelib-1_0-LibvirtGLib-1_0-0.2.1-1.2.x86_64
libvirt-admin-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-core-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-scsi-4.0.0-8.15.2.x86_64
libvirt-client-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-nodedev-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-logical-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-qemu-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-secret-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-rbd-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-interface-4.0.0-8.15.2.x86_64
libvirt-daemon-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-network-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-mpath-4.0.0-8.15.2.x86_64
libvirt-daemon-qemu-4.0.0-8.15.2.x86_64
libvirt-daemon-config-network-4.0.0-8.15.2.x86_64
libvirt-daemon-driver-storage-disk-4.0.0-8.15.2.x86_64

Any ideas ?
Maybe a restart would help, but it's Linux, not Windows ...
I'd like to understand what's going wrong.

Thanks.


Bernd
--

Bernd Lentes
Systemadministration
Institute for Metabolism and Cell Death (MCD)
Building 25 - office 122
HelmholtzZentrum München
bernd.len...@helmholtz-muenchen.de
phone: +49 89 3187 1241
phone: +49 89 3187 3827
fax: +49 89 3187 2294
http://www.helmholtz-muenchen.de/mcd

stay healthy
Helmholtz Zentrum München

Helmholtz Zentrum München




signature.asc
Description: PGP signature


Re: NVDIMM sizes and DIMM hot plug

2020-06-19 Thread Martin Kletzander

On Thu, Jun 18, 2020 at 11:22:46AM +0200, Milan Zamazal wrote:

Peter Krempa  writes:


On Tue, Jun 16, 2020 at 12:54:29 +0200, Milan Zamazal wrote:

Hi,




I've found out that NVDIMM size and label size matter for regular
(non-NV) DIMM hot plug.  If the NVDIMM is not aligned correctly, the
guest OS will not accept the hot plugged memory and will complain with
messages such as

  Block size [0x800] unaligned hotplug range: start 0x22500, size 
0x1000

The start address above is also reported within  element of the
hot plugged memory in the domain XML:

  

Apparently, in order to make memory hot plug working in the guest OS,
the inserted memory must be aligned to the platform memory alignment
(128 MB on x86_64).

I'd like to clarify, how libvirt makes the DIMM address above.  How is


If the address isn't provided in the device XML of the attached device,
libvirt attaches the device without any address at all and then
refreshes the address from qemu in 'qemuDomainUpdateMemoryDeviceInfo'.


OK, I can look into the QEMU source code, but I'd still like to have
some official confirmation, especially regarding possible pitfalls or
future changes.  We can't risk data loss.


the NVDIMM memory range determined?  According to my experiments, it
seems the NVDIMM specified  is taken, NVDIMM  size is
subtracted from it and the resulting value is reduced to the nearest
multiple of NVDIMM .  Is this observation correct?  Is it
guaranteed to be stable in future versions?  I need to determine the
right NVDIMM size to make the subsequent memory modules correctly
aligned and then I can't change the NVDIMM size, to not damage data
stored in the NVDIMM.



Unfortunatelly I didn't implement NVDIMM support so I don't know the
intricacies. I've cc'd Martin Kletzander who did that part.


Martin, do you know how the QEMU part is supposed to work?  I haven't
received any response on the QEMU list, do you know who could I ask
directly?



Sorry, no idea, it was actually Michal (Cc'd) who implemented it if I'm not
mistaken.


Additionally, when adjusting maxMemory due to NVDIMM presence, should I
increase it by the specified NVDIMM  or a different value?

Thank you,
Milan





signature.asc
Description: PGP signature


Re: libvirt dynamic file ownership

2020-03-23 Thread Martin Kletzander

On Mon, Mar 23, 2020 at 10:03:13AM -0500, Joe Muro wrote:


Hi Martin, thanks for the explanation. Now I understand why libvirt doesn't
revert the file permissions back to the original. I am running these VMs on
an isolated test machine, so I'll disable dynamic file ownership and make
sure libvirt has access to image files.



Or access the disks only using libvirt and friends ;)

Also, is there no upgrade for the libvirt package?  Maybe I don't exactly
remember if anything else is needed.  Adding Michal to Cc since he'll know more.


Sorry about the message formatting. I modified settings on my client,
hopefully it sends plaintext now. (I'll switch to personal email going
forward, as the choice of email clients at work is limited.)



No problem, you couldn't know unless you specifically looked for it, don't worry
about it ;)


-Joe



From:   Martin Kletzander 
To: Joe Muro 
Cc: libvirt-users@redhat.com
Date:   03/20/2020 04:01 PM
Subject:[EXTERNAL] Re: libvirt dynamic file ownership



On Fri, Mar 20, 2020 at 03:38:36PM +, Joe Muro wrote:

Hi,



Hi, could you please configure your client to send plaintext version as
well?
We mainly prefer plaintext on this list ;-)


I am trying to understand libvirt dynamic ownership behavior. I have a VM

that

uses a qcow2 image with the following permissions:

$ ll t257kvxg-10-20-101-40.qcow2
-rw-r--r-- 1 jmuro libvirt 2279079936 Mar 20 11:10

t257kvxg-10-20-101-40.qcow2


When I start the domain the permissions are changed:

$ virsh start t257kvxg-10-20-101-40
Domain t257kvxg-10-20-101-40 started
$ ll t257kvxg-10-20-101-40.qcow2
-rw-r--r-- 1 libvirt-qemu libvirt 2279079936 Mar 20 11:18
t257kvxg-10-20-101-40.qcow2

This is expected behavior based on the settings in /etc/libvirt/qemu.conf:

user = "libvirt-qemu"
group = "libvirt"
# Whether libvirt should dynamically change file ownership
# to match the configured user/group above. Defaults to 1.
# Set to 0 to disable file ownership changes.
#dynamic_ownership = 1

However, when I shutdown the domain, the file permissions revert to root.

$ ll t257kvxg-10-20-101-40.qcow2
-rw-r--r-- 1 root root 2282749952 Mar 20 11:20 t257kvxg-10-20-101-40.qcow2

I expect libvirt to revert the file permissions back to the original.
Otherwise, a regular user would lose ownership of the image file. FWIW: I

am

starting the domain as a non-root user under qemu:///system



This has always been the case because the original information is lost
(which is
actually not that easy to store properly, race-free, etc.) and the safest
way to
make sure nobody accesses the disks (e.g. another domain running under
libvirt-qemu:libvirt, that would get exploited) is to just change it to
root:root.  Michal finally managed to make this work, in limited cases, but
I
think it landed in 6.1.0, I'm not sure.

Anyway, there are some workarounds you can do:

 a) set relabel=no for the disk in the XML (and make sure the VM will be
able to
access it),

 b) set relabel=no for the whole domain (and make sure the VM will be able
to
access everything), or

 c) if worse comes to worse, just disable the whole dynamic ownership and
handle
it yourself

If possible, try upgrading libvirt and checking if that helps.


I am running on Ubuntu 20.04 LTS (Focal Fossa) with the following libvirt
level:

libvirt-clients/focal,now 6.0.0-0ubuntu5 s390x [installed]
libvirt-daemon-driver-qemu/focal,now 6.0.0-0ubuntu5 s390x

[installed,automatic]

libvirt-daemon-driver-storage-rbd/focal,now 6.0.0-0ubuntu5 s390x
[installed,automatic]
libvirt-daemon-system-systemd/focal,now 6.0.0-0ubuntu5 s390x
[installed,automatic]
libvirt-daemon-system/focal,now 6.0.0-0ubuntu5 s390x [installed]
libvirt-daemon/focal,now 6.0.0-0ubuntu5 s390x [installed]
libvirt-glib-1.0-0/focal,now 2.0.0-2 s390x [installed,automatic]
libvirt0/focal,now 6.0.0-0ubuntu5 s390x [installed,automatic]
python3-libvirt/focal,now 6.0.0-0ubuntu3 s390x [installed]

Thanks

-Joe


[attachment "signature.asc" deleted by Joe Muro/Poughkeepsie/IBM]






signature.asc
Description: PGP signature


Re: libvirt dynamic file ownership

2020-03-20 Thread Martin Kletzander

On Fri, Mar 20, 2020 at 03:38:36PM +, Joe Muro wrote:

Hi,



Hi, could you please configure your client to send plaintext version as well?
We mainly prefer plaintext on this list ;-)


I am trying to understand libvirt dynamic ownership behavior. I have a VM that
uses a qcow2 image with the following permissions:

$ ll t257kvxg-10-20-101-40.qcow2
-rw-r--r-- 1 jmuro libvirt 2279079936 Mar 20 11:10 t257kvxg-10-20-101-40.qcow2

When I start the domain the permissions are changed:

$ virsh start t257kvxg-10-20-101-40
Domain t257kvxg-10-20-101-40 started
$ ll t257kvxg-10-20-101-40.qcow2
-rw-r--r-- 1 libvirt-qemu libvirt 2279079936 Mar 20 11:18
t257kvxg-10-20-101-40.qcow2

This is expected behavior based on the settings in /etc/libvirt/qemu.conf:

user = "libvirt-qemu"
group = "libvirt"
# Whether libvirt should dynamically change file ownership
# to match the configured user/group above. Defaults to 1.
# Set to 0 to disable file ownership changes.
#dynamic_ownership = 1

However, when I shutdown the domain, the file permissions revert to root.

$ ll t257kvxg-10-20-101-40.qcow2
-rw-r--r-- 1 root root 2282749952 Mar 20 11:20 t257kvxg-10-20-101-40.qcow2

I expect libvirt to revert the file permissions back to the original.
Otherwise, a regular user would lose ownership of the image file. FWIW: I am
starting the domain as a non-root user under qemu:///system



This has always been the case because the original information is lost (which is
actually not that easy to store properly, race-free, etc.) and the safest way to
make sure nobody accesses the disks (e.g. another domain running under
libvirt-qemu:libvirt, that would get exploited) is to just change it to
root:root.  Michal finally managed to make this work, in limited cases, but I
think it landed in 6.1.0, I'm not sure.

Anyway, there are some workarounds you can do:

 a) set relabel=no for the disk in the XML (and make sure the VM will be able to
access it),

 b) set relabel=no for the whole domain (and make sure the VM will be able to
access everything), or

 c) if worse comes to worse, just disable the whole dynamic ownership and handle
it yourself

If possible, try upgrading libvirt and checking if that helps.


I am running on Ubuntu 20.04 LTS (Focal Fossa) with the following libvirt
level:

libvirt-clients/focal,now 6.0.0-0ubuntu5 s390x [installed]
libvirt-daemon-driver-qemu/focal,now 6.0.0-0ubuntu5 s390x [installed,automatic]
libvirt-daemon-driver-storage-rbd/focal,now 6.0.0-0ubuntu5 s390x
[installed,automatic]
libvirt-daemon-system-systemd/focal,now 6.0.0-0ubuntu5 s390x
[installed,automatic]
libvirt-daemon-system/focal,now 6.0.0-0ubuntu5 s390x [installed]
libvirt-daemon/focal,now 6.0.0-0ubuntu5 s390x [installed]
libvirt-glib-1.0-0/focal,now 2.0.0-2 s390x [installed,automatic]
libvirt0/focal,now 6.0.0-0ubuntu5 s390x [installed,automatic]
python3-libvirt/focal,now 6.0.0-0ubuntu3 s390x [installed]

Thanks

-Joe



signature.asc
Description: PGP signature


Re: Detecting of features of VMs

2020-01-29 Thread Martin Kletzander

On Mon, Jan 27, 2020 at 06:56:26PM +0100, Peter Krempa wrote:

Hi,

I was asked by Nir and Eyal of the oVirt project on how to detect
whether a certain feature is supported by libvirt. As I thought it might
be better to document this publically rather than being lost in a
private thread I'm posting this to libvirt-users. The specific question
will be answered below.



It would also be nice to have it in either the documentation or our knowledge
base so next time someone is looking for the same answer it is not like looking
for a needle in a herbal garden (it might get lost in thyme on this list) ;-)


---

There are currently two interfaces which allow discovery of libvirts and
in turn qemu's capabilities. Both return an XML which describes various
aspects of the hosts or VMs capabilities.

virConnectGetCapabilities(conn)

https://libvirt.org/formatcaps.html

The XML returned by this API describes mostly the host itself, the CPU,
NUMA topology, security driver support, migration features but also
describes guests architectures supported by the guest.

In case of the qemu driver the guest section describes some of the
aspects and configurations supported by the default qemu binary, the
machine types and virtualization types it supports. Additionally the
 section describes support for some long-existing features
such as ACPI, APIC and disk snapshots. As these features are supported
for a long time, it can be assumed that they are present (at least in
case of the qemu driver) when the second API is present.

Now while the virConnectGetCapabilities API provides mostly useful
information about the host, the limitation of not being able to report
information about specific qemu binaries or machine types lead to
introduction.

virConnectGetDomainCapabilities(conn, emulator_binary_path, architecture,
   machine_type, virt_type, flags)

https://libvirt.org/formatdomaincaps.html

The XML returned by this API describes the capabilities of an VM which
would be started using the parameters given to the API (note that if the
parameters are NULL a default is provided).

The  subelement describes supported OS loader types and firmware
binaries.  describes which CPU models are supported by the emulator
and also the CPU which would be used if 'host-model' is selected as the
CPU model.

The  section describes models and some properties of devices
supported by the VM. The 'enum's reported in this XML map to supported
values of some of the fields we report the possible configurations for.
Note that these values are reported individually and all combinations
aren't necessarily supported.

The last section 'features' describes whether some high-level features
supported by such a VM. The features themselves are described in the
documentation above.

Note that the entries into 'features' are added arbitrarily depending on
whether a feature is deemed important enough to be exposed. So please
feel free to report if anything is missing or it would be helpful if we
reported any feature.

---

Now specifically to the question: I was asked on when it's safe to pass
VIR_DOMAIN_UNDEFINE_CHECKPOINTS_METADATA to virDomainUndefine.

In this case it's safe to pass it if  contains the 
element regardless of the value of 'supported' attribute. I'll also
mention this in the documentation of the domain caps XML.





signature.asc
Description: PGP signature


Re: Volume file permissions and huge volume downloads

2020-01-17 Thread Martin Kletzander

On Fri, Jan 17, 2020 at 04:30:09PM +0100, R. Diez wrote:

Hi all:

I am using the libvirt version that comes with Ubuntu 18.04.3 LTS.

I want to backup a virtual machine in a foolproof way:

- Gracefully shutdown the VM.
- Backup the disk image.
- Restart the VM.

I wrote the following script to do that:

https://github.com/rdiez/Tools/blob/master/VirtualMachineManager/BackupVm.sh

Writing that script was difficult enough because of the virsh limitations (in 
my opinion) described in the comments. But at least it works.

The main problem is that libvirt sets the ownership and permissions of volume 
files in such a way that a standard user cannot access them,
even if it is member of the 'libvirt' group.



Yes, you are letting libvirt do its dynamic_ownership thing.  You can turn that
off, but you don't want to do that as it would create more problems for you than
it would solve issues.  But don't worry.


While the VM is running, volume file permissions are like this:
  -rw-r- 1 libvirt-qemu kvm [...] /var/lib/libvirt/images/YourVmDisk.qcow2
When the VM is shutoff:
  -rw-r- 1 root root [...] /var/lib/libvirt/images/YourVmDisk.qcow2



If you have new enough libvirt and just change the permissions on your disk file
once to who you want to have access to that when it is not used in any VM, then
(if your FS supports it etc.) it will be reverted to whatever the permissions
were before.


The trouble is, I want to access that .qcow2 file when the VM is shutoff.

I would really like not to run my script as root. I could not find a way to 
specify the permissions for the .qcow2 files, so I tried editing
the group ownership for the whole pool:

virsh pool-edit default


  /var/lib/libvirt/images


The pool represents the directory here, so that won't help you,


  
0711
0
131
  


also the permissions are not parsed in this case I think.  I might be wrong in
this part and it would change something if you did pool-build or something, but
I got carried away.




Setting  to "libvirt" did not work (XML validation error), so I tried 
the numeric ID of that group (131).

That did not work. When I restart libvirt with "service libvirtd restart", my 
changes to the pool XML file disappear (!).



OK, so I was right.



Later on, I found out that you can download a volume like this:

  virsh  vol-download  --pool default  YourVmDisk.qcow2  YourVmDisk.qcow2

The trouble is that I created the virtual disk with a maximum size of 120 GB. I 
copied it around a few times, so I think it has lost any
"sparseness" inside. Command "virsh vol-download" takes ages and downloads all those 120 
GB. My script uses "qemu-img convert", which
discards all unused space and writes just 17 GB of data, and that is without 
turning compression on. The whole backup takes seconds instead
of minutes.



qemu-img convert does an expensive scan for zeroes.  It's good that it works
even for non-sparse volumes, but you can still do better.  You can sparsify the
image where it is by using virt-sparsify.  Then, you can use vol-download and
specify --sparse.

Look at the manual for each command, sudo responsively and have a nice day.



Can somebody help me with these issues?



I hope I did, but there will be others to help as well, so feel free to ask if
that is not enough.  But don't forget there is lot hidden in those manuals, for
example.


Thanks in advance,
  rdiez




signature.asc
Description: PGP signature


Re: [libvirt-users] create virtual network fails with virt-manager

2019-10-11 Thread Martin Kletzander

On Thu, Oct 10, 2019 at 03:40:24PM +0200, Marko Horn wrote:



hello list,

creatig a virtual network via virt-manager fails.
gentoo linux vanilla-sources 5.3.1
virt-manager 2.2.1
qemu 4.0
libvirt 5.5.0



Please try newer libvirt.  There were some fixes related to iptables/nf_tables
in libvirt in recent releases, so it might just solve that for you.



the error output of

Error creating virtual network: internal error: Failed to apply firewall
rules /sbin/iptables -w --table filter --insert LIBVIRT_INP
--in-interface virbr1 --protocol tcp --destination-port 67 --jump
ACCEPT: iptables: No chain/target/match by that name.


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createnet.py", line 472, in
_async_net_create
netobj.create()
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2993, in
create
if ret == -1: raise libvirtError ('virNetworkCreate() failed',
net=self)
libvirt.libvirtError: internal error: Failed to apply firewall rules
/sbin/iptables -w --table filter --insert LIBVIRT_INP --in-interface
virbr1 --protocol tcp --destination-port 67 --jump ACCEPT: iptables: No
chain/target/match by that name.



/sbin/iptables exists

any ideas?

kind regards
m@rko



--
zbfmail - Mittendrin statt nur Datei!
  Datei sein ist alles!

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


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

Re: [libvirt-users] Emulated TPM doesn't work on Debian Buster

2019-10-07 Thread Martin Kletzander

On Sat, Oct 05, 2019 at 02:32:19PM +, proc...@riseup.net wrote:

Hi. I am very interested in the security properties a totally open TPM
can give our users  - its use as a universal smartcard to protect all
types of keys. When adding the virtual 1.2 or 2.0 TPM I get the vague
error below. OS is Debian stable with standard packages.


Error starting domain: Unable to find 'swtpm' binary in $PATH: No such
file or directory

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66,
in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1400, in
startup
    self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: Unable to find 'swtpm' binary in $PATH: No such
file or directory



What is vague about this?  "Unable to find 'swtpm' binary in $PATH:" ???

Have you tried:

 apt install -y swtpm

perhaps?




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


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

Re: [libvirt-users] Error validating install location: Distro 'rhel8' does not exist in our dictionary

2019-10-07 Thread Martin Kletzander

On Sun, Oct 06, 2019 at 10:54:33AM +0530, Kaushal Shriyan wrote:

On Sat, Oct 5, 2019 at 7:27 PM Oliver Dzombic  wrote:


Hi,

if you run on a shell the command:

osinfo-query os

you will see that its:

rhl8.0   | Red Hat Linux 8.0
  | 8.0  | http://redhat.com/rhl/8.0


This is Red Hat Linux 8 with a release date of 30 September 2002 [1] and not Red
Hat Enterprise Linux.  You are not using any new devices/settings.

Instead you should probably use rhel8.0 or, even better, since you are using
centos, the centos release.  However that one does not exist in the osinfo db
yet due to the new style of releases that happened there and we need to figure
out how to properly represent it in the osinfo data.

If ou re not seeing rhel8-unknown or rhel8.0 you should update your osinfo
database.  Either update you package or you can also use `osinfo-db-import
--latest` to update it locally for your user.

Hope that helps,
Martin

[1] https://en.wikipedia.org/wiki/Red_Hat_Linux




so instead of rhel8, i suggest you to try rhl8.0

Good luck !

Greetings
Oliver




Thanks Oliver and it worked like a charm.



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




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

Re: [libvirt-users] virsh -c lxc:/// setvcpus and configuration fails

2019-09-16 Thread Martin Kletzander

On Sun, Sep 15, 2019 at 12:21:08PM +0200, i...@layer7.net wrote:

Hi folks!

i created a server with this XML file:


 lxctest1
 227bd347-dd1d-4bfd-81e1-01052e91ffe2
 
   http://libosinfo.org/xmlns/libvirt/domain/1.0;>
 http://centos.org/centos/6.9"/>
   
 
 1024000
 1024000
2
 
   
 
 
   /machine
 
 
   exe
   /sbin/init
 
 
   
   
 
 
   
 
 
 destroy
 restart
 destroy
 
   /usr/libexec/libvirt_lxc
   
 
 
   
   
 
 
   
   
 
   
 



I would expect it to have 2 cpu cores and 1 GB RAM.


The RAM config works.
The CPU config does not:



You probably checked /proc/meminfo.  That is provided by libvirt using fuse
filesystem, but at least it is guaranteed thanks to cgroups.  We do not (and I
don't think we even can, at least reliably) do that with cpuinfo.

[...]


It gives me all CPU's from the host.



Although if you ran some perf benchmark it should just cap at 2 cpus.


I also tried it with


 




We should not allow this, IMO.  The reason is that we cannot guarantee or even
emulate this (or even the number of CPUs for that matter).  That's not how
containers work.  We can provide /proc/cpuinfo through a fuse filesystem, but if
the code actually asks the cpu directly there is no layer in which to emulate
the returned information.


That didnt help too.

I tried to modify the vcpus through virsh:



#virsh -c lxc:/// setvcpus lxctest1 2

error: this function is not supported by the connection driver:
virDomainSetVcpus



This should not work for LXC, but it does not make sence because if you look at
the XML we allow `2`.


Which didnt work too.


This happens on:



Unfortunately anywhere, for the reasons said above.  Ideally it should not be
able to specify , but rather just , but I don't think we can
change that semantics now that we supported the former for quite some time.


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

Re: [libvirt-users] Detach disk from VM - virsh (working) vs. PHP (not working)

2019-08-02 Thread Martin Kletzander

On Thu, Aug 01, 2019 at 10:12:15AM +0200, Jan Horak wrote:

Hi all,

i created a script in PHP for create a virtual server with two QCOW2 discs … 
one is our system for installation and second is target system.

After successfully instalation (create a blank Debian system, prepare all files 
and grub partitions) i need a restart virtual without a installation disk.

If i use Virsh:

detach-disk --domain debian-test2 --persistent --target vda
reset debian-test2



Hi,

I cannot really help you with the PHP part and I'm not sure about more things,
but this particular scenario is something that libvirt is actually prepared to
do (kind of) and for example virt-install uses it.  The approach is as follows:

1) You create the XML that you want the VM to have when installing the machine,
  let's call it the "install xml".

2) You create the XML that the VM should start with when it is already installed
  and it is the one that will persist in the libvirt configuration for long
  time (well, longer than the install xml).  Let's call this the "persistent 
xml".

3) You define the VM using the persistent xml.  That will get you a VM that is
  not started.

4) Then, you start the machine with the install xml, using the create API
  (analogous to virsh create vm.xml).  Just make sure the name and UUID are the
  same.

That will get you a VM running with the install xml that, when turned off and
then started again (without reboot/reset/restart, you need to have it shut down
completely before starting it) will start with the persistent xml.  No need to
have support for disk hot-(un)plug, no magic.

Even better way to use this is registering a callback for the VM's lifecycle
event, starting the VM after the event was fired.  That way you can automate the
installation to turn off the machine after it is completed and there is no need
for any polling.  I'm not sure, however, how relevant that is or if it is
possible to be used from the PHP bindings.

Have a nice day,
Martin


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

Re: [libvirt-users] Libvirt API for getting disk capacity from VM XML

2019-06-14 Thread Martin Kletzander

On Thu, Jun 13, 2019 at 03:17:16PM +0530, Varsha Verma wrote:

Hello everyone,
I am doing an outreachy internship at Openstack Ironic. In the sushy-tools
project, we are using libvirt VMs to simulate bare metal machines for
testing purposes.

In the XML description of a domain, there are a bunch of disk elements
giving information about the various storage devices attached to the
domain. Is there some way to get the size/capacity of those disks using the
libvirt API?



Yes, there is, virStorageVolGetXMLDesc:

 https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetXMLDesc

Look for 

The tricky part might be to get the storage volume object.  I'm not sure how
sushy-tools are using libvirt and what the deployment looks like, so here are
few tips and feel free to ask for more info.

If it is a path on the local filesystem, you might just use
`virStorageVolLookupByKey` and be done with it:

 https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolLookupByKey

If it is not, you might need to look it up based on the pool it is in.

If you have the pool already, then it is a matter of `virStorageVolLookupBy*`
for example.  If you don't have that you might look for the pool with
`virStoragePoolLookupBy*`, for example `virStoragePoolLookupByName`:

 
https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolLookupByName

And one more general libvirt advice (although maybe not really a good one,
definitely not a silver bullet):

You can always have a look at how `virsh` does things.  It might be a bit
confusing at times, but if you have a command name (in our case we'd use the
`vol-dumpxml` command), you can CamelCase it ("VolDumpXML"), prepend "cmd" (as
in "command") and the resulting name (`cmdVolDumpXML`) is the name of the
function that virsh runs for that command.  You can see it in
tools/virsh-volume.c:

 https://github.com/libvirt/libvirt/blob/master/tools/virsh-volume.c#L1211

The main part of how it looks up a volume is `virshCommandOptVol` which is just
a syntax sugar for `virshCommandOptVolBy` in the same file:

 https://github.com/libvirt/libvirt/blob/master/tools/virsh-volume.c#L68

Which is trying to do the lookup by all various possible things.  Same thing can
be found for `pool-*` commands.

HTH, have a nice day,
Martin


--

*Regards,*

*Varsha Verma*

*Fourth Year Undergraduate*

*Department of Electrical Engineering*

*IIT-BHU, Varanasi*



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




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

Re: [libvirt-users] Cloud automation

2019-06-10 Thread Martin Kletzander

Yes, even though libvirt is remotely accessible, it is node-centric, that is it
manages the whole node (server) for you, but nothing else (well, it can
migrate).  If you want to have a "cloud" or anything involving more servers you
probably want something on top of libvirt as well (oVirt, OpenStack, or others,
see https://libvirt.org/apps.html )

On Fri, Jun 07, 2019 at 04:16:07PM +, Brandon Doyle wrote:

Can you not use virt-manager or ovirt to accomplish this?


Regards,

Brandon Doyle


On 6/6/19 10:25 AM, Adrien Macor wrote:

Hi,

I have a question for you:

Let’s suppose I have three physical servers; two on the same area, and the last 
one elsewhere (not on the same network, but all three have connectivity between 
each others).

May I use this infrastructure with libvirt? I mean in terms of cloud 
automation: is it possible to remotely deploy VMs (with particulary 
configurations) with libvirt?

For example, is it possible to have one master node controlling the two others?

Thanks for the reply



___
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




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

Re: [libvirt-users] VM display is blank when open (but Gnome Boxes thumbnails ok)

2019-05-13 Thread Martin Kletzander

On Mon, May 13, 2019 at 04:40:55PM +0200, Michel Rozpendowski wrote:

Hi,

I also posted this question on the IRC #virt channel but have not received
any reaction at the moment of posting this message to the mailing list.

Since I last turned off my laptop (Dell XPS-15-9570 running Ubuntu 19.04)
on Friday 10 May (I had to do it by long power press by the way), I am no
longer able to get the display of my VMs: I am getting a black screen, even
though I can see it running in the thumbnail of Gnome Boxes.
You can see the described behaviour on the following video capture:
https://youtu.be/Lv67g0foyzc.
Troubleshooting Log from Gnome Boxes is available here:
https://pastebin.com/9eWGYsJV.
It was working all properly on Friday before I turn off my laptop.

Any clue what could be wrong and how I could solve this issue (I digged the
Internet for 2 hours without success)?

Thanks in advance for your help!



Well, sorry, I don't really know what might've caused it, but it looks all kind
of OK from a libvirt standpoint, so my best guess would be something related to
the virtio graphics.  But the I saw you are turning off that VM, so I'm guessing
it happens even after starting the VM back, right?  Still, might be worth asking
on qemu mailing lists if nobody on this list will know.


Kind regards,

Michel



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




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

Re: [libvirt-users] libvirtd not starting

2019-05-03 Thread Martin Kletzander

On Thu, May 02, 2019 at 02:25:28PM +0200, Martin Kletzander wrote:

On Thu, May 02, 2019 at 01:07:32PM +0200, Michal Privoznik wrote:

On 5/2/19 12:08 PM, Lothar Schilling wrote:


I turned logging up to maximum. That's all I get:

May  2 11:02:06 hl308-3 systemd: Starting Virtualization daemon...
May  2 11:02:06 hl308-3 libvirtd: 472: info : libvirt version: 4.5.0, package: 
10.el7_6.7 (CentOS BuildSystem <http://bugs.centos.org>, 2019-04-24-14:04:12, 
x86-01.bsys.centos.org)
May  2 11:02:06 hl308-3 libvirtd: 472: info : hostname: my.server.net
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=1 fd=6 events=1 cb=0x7eff3bbde300 opaque=(nil) 
ff=(nil)
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=2 fd=8 events=1 cb=0x7eff3bd06760 
opaque=0x558f9db485a0 ff=(nil)
May  2 11:02:06 hl308-3 systemd: Started Virtualization daemon.
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=3 fd=11 events=0 cb=0x7eff3bcfb420 
opaque=0x558f9db69520 ff=0x7eff3bcfb3d0
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=4 fd=12 events=0 cb=0x7eff3bcfb420 
opaque=0x558f9db69700 ff=0x7eff3bcfb3d0
May  2 11:02:06 hl308-3 libvirtd: process 472: arguments to 
dbus_message_iter_append_basic() were incorrect, assertion 
"_dbus_check_is_valid_utf8 (*string_p)" failed in file 
../../dbus/dbus-message.c line 2754.
May  2 11:02:06 hl308-3 libvirtd: This is normally a bug in some application 
using the D-Bus library.
May  2 11:02:06 hl308-3 libvirtd: D-Bus not built with -rdynamic so unable to 
print a backtrace
May  2 11:02:06 hl308-3 systemd: libvirtd.service: main process exited, 
code=killed, status=6/ABRT


This is not the maximum loggin. We'll need to see debug logs:

https://wiki.libvirt.org/page/DebugLogs

and perhaps running libvirtd under gdb and getting a stack trace (with
all strings expanded) might help too.



Actually gdb might be the only help here.  The reason is that that dbus call
just reports the error and then calls abort(), so libvirtd will not even get an
error message (which would help us track down what might've been the case).

If you can do something like:



Even better, there are some ways to get the core dump information which I
completely forgot about:

- coredumpctl -- IIRC you are running CentOS 7, so this will not be available
 for you yet.  If it was, coredumpctl show just shows all we
 need (by default it picks the last core dump and stacktrace is
 part of the output).

- abrt-cli -- Similar to the above, it should be available for you, but you
  need to have abrt installed and setup.  Which is not always the
  default.  If you do, or you set it up yourself, however, you
  should be able to get to the core dump as well, but it is not as
  easy as with coredumpctl (i.e. I did not get to it in first 10
  seconds).

- Setup your own -- either set the ulimit for the service and look for the file
that gets created or set kernel.core_pattern using sysctl
to a command that gets ran with each core dump (this one
does not need any ulimit setting, but you need to know what
to specify there.

Please let us know if you got anywhere, I'd like to see what the issue is and
how we can fix it.


 $ dnf --enablerepo='*debug*' install libvirt-debuginfo dbus-debuginfo

 $ cat >/var/lib/libvirt/gdbabortscript </etc/systemd/system/libvirtd.service.d/override.conf <




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




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

Re: [libvirt-users] libvirtd not starting

2019-05-02 Thread Martin Kletzander

On Thu, May 02, 2019 at 01:07:32PM +0200, Michal Privoznik wrote:

On 5/2/19 12:08 PM, Lothar Schilling wrote:


I turned logging up to maximum. That's all I get:

May  2 11:02:06 hl308-3 systemd: Starting Virtualization daemon...
May  2 11:02:06 hl308-3 libvirtd: 472: info : libvirt version: 4.5.0, package: 
10.el7_6.7 (CentOS BuildSystem , 2019-04-24-14:04:12, 
x86-01.bsys.centos.org)
May  2 11:02:06 hl308-3 libvirtd: 472: info : hostname: my.server.net
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=1 fd=6 events=1 cb=0x7eff3bbde300 opaque=(nil) 
ff=(nil)
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=2 fd=8 events=1 cb=0x7eff3bd06760 
opaque=0x558f9db485a0 ff=(nil)
May  2 11:02:06 hl308-3 systemd: Started Virtualization daemon.
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=3 fd=11 events=0 cb=0x7eff3bcfb420 
opaque=0x558f9db69520 ff=0x7eff3bcfb3d0
May  2 11:02:06 hl308-3 libvirtd: 472: info : virEventPollAddHandle:140 : 
EVENT_POLL_ADD_HANDLE: watch=4 fd=12 events=0 cb=0x7eff3bcfb420 
opaque=0x558f9db69700 ff=0x7eff3bcfb3d0
May  2 11:02:06 hl308-3 libvirtd: process 472: arguments to 
dbus_message_iter_append_basic() were incorrect, assertion 
"_dbus_check_is_valid_utf8 (*string_p)" failed in file 
../../dbus/dbus-message.c line 2754.
May  2 11:02:06 hl308-3 libvirtd: This is normally a bug in some application 
using the D-Bus library.
May  2 11:02:06 hl308-3 libvirtd: D-Bus not built with -rdynamic so unable to 
print a backtrace
May  2 11:02:06 hl308-3 systemd: libvirtd.service: main process exited, 
code=killed, status=6/ABRT


This is not the maximum loggin. We'll need to see debug logs:

https://wiki.libvirt.org/page/DebugLogs

and perhaps running libvirtd under gdb and getting a stack trace (with
all strings expanded) might help too.



Actually gdb might be the only help here.  The reason is that that dbus call
just reports the error and then calls abort(), so libvirtd will not even get an
error message (which would help us track down what might've been the case).

If you can do something like:

 $ dnf --enablerepo='*debug*' install libvirt-debuginfo dbus-debuginfo

 $ cat >/var/lib/libvirt/gdbabortscript 

Re: [libvirt-users] Running all my virtual machines with a low priority

2019-05-02 Thread Martin Kletzander

On Thu, May 02, 2019 at 12:10:54PM +0200, R. Diez wrote:



You could perhaps set  'cpu.shares' cgroup setting on /machine.slice.
This isn't really a nice level in the traditional sense, rather it is
a relative weighting evaluated against other cgroups at the same level.
So if you change it from 1024 to 512, then processes under /machine.slice
will get 1/2 the CPU time vs stuff under /system.slice or /user.slice,
when there is contention for CPU time.


Thanks for your help.

There is no "machine.slice" on my system. This is an excerpt from 
"systemd-cgls".


??? ??system.slice
???   ??irqbalance.service
???   ??? ??865 /usr/sbin/irqbalance --foreground
[... blah blah ...]
???   ??wpa_supplicant.service
???   ??? ??878 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
???   ??libvirtd.service
???   ??? ??  987 /usr/sbin/libvirtd
???   ??? ?? 1395 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
???   ??? ?? 1396 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro
--dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
???   ??? ??12285 /usr/bin/qemu-system-x86_64 -name 
guest=UbuntuMATE1804,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-UbuntuMATE1804/master-key.aes
 -machine...



Runing:

 $ systemctl set-property machine.slice CPUShares=512

works for me on some random machine I tried.  As far as I understand, Nice= was
supported (for backward compatibility) but it is not now, or at least not for
slices.

Feel free to set other things with similar commands or just use systemctl edit
machine.slice and configure that however you want.  Looking for the proper
documentation is left as an exercise for the reader.



But I guess there are differences depending on the libvirt version.

I thought of 'nice' because it is an easy way to lower the priority for 
everything (CPU and disk) at once.

This is actually getting too complicated. I am a lone developer and sysadmin in 
a small company. I would need to learn too many things about
control groups etc. One of the reasons I am trying libvirt is because of the 
"Virtual Machine Manager" GUI.



I believe such basic settings should *not* be complicated, and I hope the above
got you closer to the goal.


Is there not an easier way? I realised there is a "libvirtd.service" on my 
system. Is there a simple way in systemd to just lower the
priority of everything under that service? I am assuming that this service is 
starting all the virtual machines.



We are also counting with the use case where you want the machine to take full
advantage of the system and its resources, but you want to restrict the
management of such virtual machines (libvirt in this case), so libvirt has to
explicitly override any possibly inherited configuration for virtual machines it
is starting.  That's why setting anything on the libvirtd.service will not work.


Best regards,
  rdiez


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

Re: [libvirt-users] libvirtd not starting

2019-05-02 Thread Martin Kletzander

On Thu, May 02, 2019 at 11:22:39AM +0200, Lothar Schilling wrote:

Hi everybody,

I've set up an new CentOS 7.6.1810 server. Then, via yum I installed
qemu-kvm libvirt libvirt-python libguestfs-tools virt-install. There
were no problems. But when I try to

systemctl start libvirtd

I get the following message:

"libvirtd: process 472: arguments to dbus_message_iter_append_basic()
were incorrect, assertion "_dbus_check_is_valid_utf8 (*string_p)" failed
in file ../../dbus/dbus-message.c line 2754."



Firstly I would make sure that all the packages are up to date.  I'm not sure
what the relevant versions are on CentOS 7.6.1810, so saying what versio you
have installed might help later.

This message actually doesn't look like it comes from libvirt.  Are there few 
more lines in a log somewhere?


Starting libvirtd manually just by issuing the command "libvirtd"
without any further arguments is working, though.



As root?  This would also make sense if the communication that fails with the
above error is happening between libvirtd and systemd (when the daemon is
started by systemd).


I do not have the slightest idea what is going on, especially as I
didn't change anything about the config files.



I'm not really sure what the daemon is supposed to tell systemd apart
sd_notify() when it is starting.  Maybe it is some value from the environment 
that we're sending and the error originates there, actually.  Like the hostname 
or something similar.  Again, having more logs would help as I too don't really 
know what is going on in there.


Any help would be appreciated, thank you

Lothar Schilling

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


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

Re: [libvirt-users] Running all my virtual machines with a low priority

2019-05-02 Thread Martin Kletzander

On Wed, May 01, 2019 at 11:58:23AM +0200, R. Diez wrote:



You would have to set the priority of all vCPUs in each guest, as well
as emulator threads in each guest (the latter needs very new libvirt).


This does not seem a viable option then with Ubuntu 18.04. And changing XML on 
all guest VMs is extra work.

Is there no other way? For example, are all such virtual machines not some 
daemon or systemd unit or set of units? Would it be feasible to lower the
priority on all of those? Or is that not easy to do either?



I'm not sure if we're resetting all the cgroup values, so it should be possible
by setting this for the machine.slice cgroup (or somewhere around there) which
would make it effective for all the VMs, right?  I have not tested it, though,
sorry.


Thanks again,
  rdiez

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


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

Re: [libvirt-users] KVM-Docker-Networking using TAP and MACVLAN

2019-03-14 Thread Martin Kletzander

On Wed, Mar 13, 2019 at 11:40:51PM +0100, Lars Lindstrom wrote:


On 3/13/19 2:26 PM, Martin Kletzander wrote:

IIUC, you are using the tap0 device, but it is not plugged anywhere.
By that I
mean there is one end that you created and passed through into the VM,
but there
is no other end of that.  I can think of some complicated ways how to
do what
you are trying to, but hopefully the above explanation will move you
forward and
you'll figure out something better than what I'm thinking about right
now.  What
usually helps me is to think of a way this would be done with hardware
and
replicate that as most of the technology is modelled after HW anyway.  Or
someone else will have a better idea.

Before sending it I just thought, wouldn't it be possible to just have
a veth
pair instead of the tap device?  one end would go to the VM and the
other one
would be used for the containers' macvtaps...


What I am trying to achieve is the most performant way to connect a set
of containers to the KVM while having proper isolation. As the Linux
bridge does not support port isolation I started with a 'bridge'
networking and MACVLAN using a VLAN for each container, but this comes
at the cost of bridging and the VLAN trunk on the KVM side. The simplest
(and hopefully therefore most performant) solution I could come up with
was using a 'virtio' NIC in the KVM, with 'direct' connection in 'vepa'
mode to 'some other end' on the host, TAP in its simplest form, which
Docker then uses for its MACVLAN network.



I hope I'm not misunderstanding something, but the way I understand it is the
following:

TAP device is 1 device, a virtual ethernet card or an emulated network card.
Usually (VPNs and such) some user process binds to the device, can read data
which would normally go out on the wire and can write data that will look like
they came on the wire from the outside.  This is "one end of the device", the
software is there instead of a wire connected to it.  The "other end" shows up
in the OS as a network device that it can use to getting an IP address, sending
other packets, etc.

I think we both understand that, I just want to make sure we are on the same
page and also to have something to reference with my highly technical term (like
"other end") =)

Then when you create the VM and give it a VEPA access to the tap device, it
essentially just "duplicates" that device (the part that's in the OS) and
whatever the VM tries to send will be sent out over the wire.

When you create the containers with MACVLAN (macvtap) it does similar thing, it
creates virtual interface over the tap device and whatever the container is
trying to send ends up being sent over the wire.

That is why I think this cannot work for you (unless you have a program that
binds to the tap device and hairpins all the packets, but that's not what you
want I think).



I am not quite sure if I understood you correctly with the 'other end'.


Yeah, sorry for my knowledge on how this is actually called.  I found out,
however, the "other end" is whatever _binds_ to the device.


With the given configuration I would expect that one end of the TAP
device is connected to the NIC in the KVM (and it actually is, it has an
IP address assigned in the KVM and is serving the web configurator) and
the other end is connected to the MACVLAN network of Docker. If this is


From how I understand it you are plugging the same end to all of them.


not how TAP works, how do I then provide a 'simple virtual NIC' which
has one end in the KVM itself and the other on the host (without using


This is what veth pair does, IIUC.  I imagine it as a patch cable.


bridging or alike). I always thought then when using 'bridge' network
libvirt does exactly that, it creates a TAP device on the host and
assigns it to a bridge.



Yes, but it is slightly more complicated.  There is a device that is connected
to the bridge which is on the host, so that the host can communicate with it.
However, when you start a VM, new device is created that is plugged in the
bridge and then passed to the VM.  That is done for each VM (and talking about
the default network).



According to the man page I have to specify both interfaces when
creating the 'vdev' device, but how would I do that on the host with one
end being in the KVM?



I cannot try this right now, but I would try something like this:

ip link add dev veth-vm type veth peer name veth-cont

and then put veth-vm in the VM (type='direct' would work, but I can imagine
type='ethernet' might be even faster) and start the containers with macvtap
using veth-cont.

I am in no position to even estimate what the performance is, neither compare it
to anything.  I would, however, imagine this could be pretty low-overhead
solution.

Let me know if that works or if I made any sense, I'd love to hear that.

Have a nice day,
Martin


signature.asc
Description: PGP signature
__

Re: [libvirt-users] KVM-Docker-Networking using TAP and MACVLAN

2019-03-13 Thread Martin Kletzander

On Tue, Mar 12, 2019 at 11:10:40PM +0100, Lars Lindstrom wrote:

Hi everyone!

I have the following requirement: I need to connect a set of Docker
containers to a KVM. The containers shall be isolated in a way that they
cannot communicate to each other without going through the KVM, which
will act as router/firewall. For this, I thought about the following
simple setup (as opposed to a more complex one involving a bridge with
vlan_filtering and a seperate VLAN for each container):

+--+
| Host |
|  +-+ +--+---+
|  | KVM |  | Docker   +-> | a |
|  |  +--+ +--+ +--+ +---+
|  |  | NIC lan0 | <-> | DEV tap0 | <-> | NET macvlan0 | <-+-> | b |
|  |  +--+ +--+ +--+ +---+
|  | |  |  +-> | c |
|  +-+ +--+---+
| |
+--+

NIC lan0:
   
  
  
   
   *** Welcome to pfSense 2.4.4-RELEASE-p1 (amd64) on pfSense ***
   LAN (lan) -> vtnet0 -> v4: 10.0.20.1/24

DEV tap0:
   [root@server ~]# ip tuntap add tap0 mode tap
   [root@server ~]# ip l set tap0 up
   [root@server ~]# ip l show tap0
   49: tap0:  mtu 1500 qdisc
fq_codel state DOWN mode DEFAULT group default qlen 1000
   link/ether ce:9e:95:89:33:5f brd ff:ff:ff:ff:ff:ff
   [root@server ~]# virsh start pfsense
   [root@server opt]# ip l show tap0
   49: tap0:  mtu 1500 qdisc
fq_codel state DOWN mode DEFAULT group default qlen 1000
   link/ether ce:9e:95:89:33:5f brd ff:ff:ff:ff:ff:ff



IIUC, you are using the tap0 device, but it is not plugged anywhere.  By that I
mean there is one end that you created and passed through into the VM, but there
is no other end of that.  I can think of some complicated ways how to do what
you are trying to, but hopefully the above explanation will move you forward and
you'll figure out something better than what I'm thinking about right now.  What
usually helps me is to think of a way this would be done with hardware and
replicate that as most of the technology is modelled after HW anyway.  Or
someone else will have a better idea.

Before sending it I just thought, wouldn't it be possible to just have a veth
pair instead of the tap device?  one end would go to the VM and the other one
would be used for the containers' macvtaps...


NET macvlan0:
   [root@server ~]# docker network create --driver macvlan
--subnet=10.0.20.0/24 --gateway=10.0.20.1 --opt parent=tap0 macvlan0

CNT a:
   [root@server ~]# docker run --network macvlan0 --ip=10.0.20.2 -it
alpine /bin/sh
   / # ping -c 4 10.0.20.1
   PING 10.0.20.1 (10.0.20.1): 56 data bytes
   --- 10.0.20.1 ping statistics ---
   4 packets transmitted, 0 packets received, 100% packet loss
   / # ifconfig
   eth0  Link encap:Ethernet  HWaddr 02:42:0A:00:14:02
 inet addr:10.0.20.2  Bcast:10.0.20.255 Mask:255.255.255.0
 UP BROADCAST MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
   lo    Link encap:Local Loopback
 inet addr:127.0.0.1  Mask:255.0.0.0
 UP LOOPBACK RUNNING  MTU:65536  Metric:1
 RX packets:4 errors:0 dropped:0 overruns:0 frame:0
 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:448 (448.0 B)  TX bytes:448 (448.0 B)
   / # ip r
   default via 10.0.20.1 dev eth0
   10.0.20.0/24 dev eth0 scope link  src 10.0.20.2

CNT b:
   [root@server ~]# docker run --network macvlan0 --ip=10.0.20.2 -it
alpine /bin/ping 10.0.20.1
   PING 10.0.20.1 (10.0.20.1): 56 data bytes

CNT c:
   [root@server ~]# docker run --network macvlan0 --ip=10.0.20.2 -it
alpine /bin/ping 10.0.20.1
   PING 10.0.20.1 (10.0.20.1): 56 data bytes


The KVM is not reachable from within a Docker container (during the test
firewalld was disabled) and vice versa. The first thing I noticed is
that tap0 remains NO-CARRIER and DOWN, even though the KVM has been
started. Shouldn't the link come up as soon as the KVM is started (and
thus is connected to the tap0 device)? The next thing that looked
strange to me - even though interface and routing configuration within
the container seemingly looks OK, there are 0 packets TX/RX on eth0
after pinging the KVM (but 4 on lo instead).

Any idea on how to proceed from here? Is this a valid setup and a valid
libvirt configuration for that setup?


Thanks and br, Lars


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


signature.asc
Description: PGP signature

Re: [libvirt-users] HELP!

2019-02-15 Thread Martin Kletzander

Please consider writing more descriptive subjects.  No need to shout, too.

On Fri, Feb 15, 2019 at 08:43:36PM +0530, Shashwat shagun wrote:

[...]


func (d *DomService) Connect() error {
   var err error
   d.Conn, err = libvirt.NewConnect("qemu:///system")
   if err != nil {
   fmt.Println(err)
   }
defer d.Conn.Close()


I have no idea how the golang bindings are structured, but I'm quite sure you
don't want to close the connection right after this function ends...


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

Re: [libvirt-users] Libvirt api for esx

2018-12-12 Thread Martin Kletzander

On Wed, Dec 12, 2018 at 03:03:41PM +0530, ROHIT SINGH wrote:

Thanks Martin, It’s working now.
Could you please help me with role of xml in libvirt api and what if I
don’t want use of xml in my code.
Please let me know.



Libvirt uses XML for most of the APIs.  Depends what you need to do you can
transform it with xmltodict or use some higher level API.  I'm not sure I can
help you much with that.  Maybe just find a nice library for XML and don't be
scared of XML =)


Thanks for help!!

Regards
Rohit Singh

On Thu, 6 Dec 2018 at 11:24 PM, ROHIT SINGH 
wrote:


Thanks Martin for help. I will give it a shot.

Regards
Rohit Singh

On Thu, 6 Dec 2018 at 2:55 PM, Martin Kletzander 
wrote:


On Wed, Dec 05, 2018 at 09:44:17PM +0530, ROHIT SINGH wrote:
>Hi Martin,
>
>Could you please help me with below issue, I am not sure what’s wrong
here.
>Please find below code and error snippet.
>
>Thanks for help.
>
>Code Snippet: -
>
>from __future__ import print_function
>import sys
>import libvirt
>SASL_USER = 
>SASL_PASS = 
>def request_cred(credentials, user_data):
>for credential in credentials:
>if credential[0] == libvirt.VIR_CRED_AUTHNAME:
>credential[4] = SASL_USER
>elif credential[0] == libvirt.VIR_CRED_PASSPHRASE:
>credential[4] = SASL_PASS
>return 0
>auth = [[libvirt.VIR_CRED_AUTHNAME, libvirt.VIR_CRED_PASSPHRASE],
>request_cred, None]
>conn = libvirt.openAuth("esx://?no_verify=1", auth, 0)

I don't know.  I don't have any ESX machine handy.  Try to do some
debugging.
Maybe the fact that you have the VM name here instead of the ESX server.

Does the esxlist.py from python examples work?  Maybe you can
differentiate with
that.  Maybe you're not handling some of the credentials right.

>if conn == None:
>print('Failed to open connection to qemu+tcp://localhost/system',
>file=sys.stderr)
>exit(1)
>conn.close()
>
>
>Error Snippet: -
>File
>"/usr/software/pkgs/Python-3.4.3/lib/python3.4/site-packages/libvirt.py",
>line 105, in openAuth
>if ret is None:raise libvirtError('virConnectOpenAuth() failed')
>libvirt.libvirtError: internal error: HTTP response code 404 for call to
>'RetrieveServiceContent'
>
>
>Regards
>Rohit Singh
>
>On Thu, 29 Nov 2018 at 11:13 PM, ROHIT SINGH 
>wrote:
>
>> Thanks a lot Martin for help.
>> Really appreciate it. You’re life saver.
>>
>> I will go through these links and will get back to you in case I need
>> anymore information.
>>
>> Once again, thanks for help.
>>
>> Regards
>> Rohit Singh
>>
>> On Thu, 29 Nov 2018 at 2:34 PM, Martin Kletzander 
>> wrote:
>>
>>> On Wed, Nov 28, 2018 at 10:24:55PM +0530, ROHIT SINGH wrote:
>>> >Hi Martin,
>>> >
>>> >Could you please point me to any example codes in python present for
esx?
>>> >Suppose, I have to power off and power on esx virtual machine, can i
get
>>> >this code somewhere on python to develop some understanding.
>>> >
>>>
>>> https://www.mail-archive.com/libvir-list@redhat.com/msg17903.html
>>>
>>> >Actually, I am not able to find sample code related to esx in python,
>>> >please point me if any such link available.
>>> >
>>>
>>>
https://github.com/libvirt/libvirt-python/blob/master/examples/esxlist.py
>>>
>>> and all other examples:
>>>
>>> https://github.com/libvirt/libvirt-python/tree/master/examples
>>>
>>> The point of libvirt is that the code doesn't have to be (way)
different
>>> depending on the hypervisor.
>>>
>>> >Appreciate your help !!
>>> >
>>> >Thanks.
>>> >
>>> >Regards
>>> >Rohit Singh
>>> >
>>> >On Wed, 28 Nov 2018 at 9:54 PM, ROHIT SINGH <
rohit.singh0...@gmail.com>
>>> >wrote:
>>> >
>>> >> Thanks, I'll check it out.
>>> >>
>>> >> On Wed, 28 Nov 2018 at 9:31 PM, Martin Kletzander <
mklet...@redhat.com
>>> >
>>> >> wrote:
>>> >>
>>> >>> On Mon, Nov 26, 2018 at 04:11:20PM +0530, ROHIT SINGH wrote:
>>> >>> >Hi,
>>> >>> >
>>> >>> >I am doing poc for using libvirt api for implementation of esx in
>>> python.
>>> >>> >
>>> >>> >I tried researching through module but did not find a way how it
>>> works
>>> >>> for
>>> >>> >esx.
>>> >>> >Any help on how to proceed specifically for esx would be of great
>>> help.
>>> >>> >
>>> >>>
>>> >>> See https://libvirt.org/drvesx.html for ESX-related stuff.  But
>>> mainly
>>> >>> it is the
>>> >>> URI you need to use.  Then look at
https://libvirt.org/hvsupport.html
>>> >>> where you
>>> >>> can see what APIs are available for that HV driver.
>>> >>>
>>> >>> >Please let me know as soon as possible, lagging on deliverables.
>>> >>> >
>>> >>> >Thanks for help!!
>>> >>> >
>>> >>> >Regards
>>> >>> >Rohit Singh
>>> >>>
>>> >>> >___
>>> >>> >libvirt-users mailing list
>>> >>> >libvirt-users@redhat.com
>>> >>> >https://www.redhat.com/mailman/listinfo/libvirt-users
>>> >>>
>>> >>>
>>>
>>





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

Re: [libvirt-users] Libvirt api for esx

2018-12-06 Thread Martin Kletzander

On Wed, Dec 05, 2018 at 09:44:17PM +0530, ROHIT SINGH wrote:

Hi Martin,

Could you please help me with below issue, I am not sure what’s wrong here.
Please find below code and error snippet.

Thanks for help.

Code Snippet: -

from __future__ import print_function
import sys
import libvirt
SASL_USER = 
SASL_PASS = 
def request_cred(credentials, user_data):
   for credential in credentials:
   if credential[0] == libvirt.VIR_CRED_AUTHNAME:
   credential[4] = SASL_USER
   elif credential[0] == libvirt.VIR_CRED_PASSPHRASE:
   credential[4] = SASL_PASS
   return 0
auth = [[libvirt.VIR_CRED_AUTHNAME, libvirt.VIR_CRED_PASSPHRASE],
request_cred, None]
conn = libvirt.openAuth("esx://?no_verify=1", auth, 0)


I don't know.  I don't have any ESX machine handy.  Try to do some debugging.
Maybe the fact that you have the VM name here instead of the ESX server.

Does the esxlist.py from python examples work?  Maybe you can differentiate with
that.  Maybe you're not handling some of the credentials right.


if conn == None:
   print('Failed to open connection to qemu+tcp://localhost/system',
file=sys.stderr)
   exit(1)
conn.close()


Error Snippet: -
File
"/usr/software/pkgs/Python-3.4.3/lib/python3.4/site-packages/libvirt.py",
line 105, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirt.libvirtError: internal error: HTTP response code 404 for call to
'RetrieveServiceContent'


Regards
Rohit Singh

On Thu, 29 Nov 2018 at 11:13 PM, ROHIT SINGH 
wrote:


Thanks a lot Martin for help.
Really appreciate it. You’re life saver.

I will go through these links and will get back to you in case I need
anymore information.

Once again, thanks for help.

Regards
Rohit Singh

On Thu, 29 Nov 2018 at 2:34 PM, Martin Kletzander 
wrote:


On Wed, Nov 28, 2018 at 10:24:55PM +0530, ROHIT SINGH wrote:
>Hi Martin,
>
>Could you please point me to any example codes in python present for esx?
>Suppose, I have to power off and power on esx virtual machine, can i get
>this code somewhere on python to develop some understanding.
>

https://www.mail-archive.com/libvir-list@redhat.com/msg17903.html

>Actually, I am not able to find sample code related to esx in python,
>please point me if any such link available.
>

https://github.com/libvirt/libvirt-python/blob/master/examples/esxlist.py

and all other examples:

https://github.com/libvirt/libvirt-python/tree/master/examples

The point of libvirt is that the code doesn't have to be (way) different
depending on the hypervisor.

>Appreciate your help !!
>
>Thanks.
>
>Regards
>Rohit Singh
>
>On Wed, 28 Nov 2018 at 9:54 PM, ROHIT SINGH 
>wrote:
>
>> Thanks, I'll check it out.
>>
>> On Wed, 28 Nov 2018 at 9:31 PM, Martin Kletzander 
>> wrote:
>>
>>> On Mon, Nov 26, 2018 at 04:11:20PM +0530, ROHIT SINGH wrote:
>>> >Hi,
>>> >
>>> >I am doing poc for using libvirt api for implementation of esx in
python.
>>> >
>>> >I tried researching through module but did not find a way how it
works
>>> for
>>> >esx.
>>> >Any help on how to proceed specifically for esx would be of great
help.
>>> >
>>>
>>> See https://libvirt.org/drvesx.html for ESX-related stuff.  But
mainly
>>> it is the
>>> URI you need to use.  Then look at https://libvirt.org/hvsupport.html
>>> where you
>>> can see what APIs are available for that HV driver.
>>>
>>> >Please let me know as soon as possible, lagging on deliverables.
>>> >
>>> >Thanks for help!!
>>> >
>>> >Regards
>>> >Rohit Singh
>>>
>>> >___
>>> >libvirt-users mailing list
>>> >libvirt-users@redhat.com
>>> >https://www.redhat.com/mailman/listinfo/libvirt-users
>>>
>>>





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

Re: [libvirt-users] Libvirt api for esx

2018-11-29 Thread Martin Kletzander

On Wed, Nov 28, 2018 at 10:24:55PM +0530, ROHIT SINGH wrote:

Hi Martin,

Could you please point me to any example codes in python present for esx?
Suppose, I have to power off and power on esx virtual machine, can i get
this code somewhere on python to develop some understanding.



https://www.mail-archive.com/libvir-list@redhat.com/msg17903.html


Actually, I am not able to find sample code related to esx in python,
please point me if any such link available.



https://github.com/libvirt/libvirt-python/blob/master/examples/esxlist.py

and all other examples:

https://github.com/libvirt/libvirt-python/tree/master/examples

The point of libvirt is that the code doesn't have to be (way) different
depending on the hypervisor.


Appreciate your help !!

Thanks.

Regards
Rohit Singh

On Wed, 28 Nov 2018 at 9:54 PM, ROHIT SINGH 
wrote:


Thanks, I'll check it out.

On Wed, 28 Nov 2018 at 9:31 PM, Martin Kletzander 
wrote:


On Mon, Nov 26, 2018 at 04:11:20PM +0530, ROHIT SINGH wrote:
>Hi,
>
>I am doing poc for using libvirt api for implementation of esx in python.
>
>I tried researching through module but did not find a way how it works
for
>esx.
>Any help on how to proceed specifically for esx would be of great help.
>

See https://libvirt.org/drvesx.html for ESX-related stuff.  But mainly
it is the
URI you need to use.  Then look at https://libvirt.org/hvsupport.html
where you
can see what APIs are available for that HV driver.

>Please let me know as soon as possible, lagging on deliverables.
>
>Thanks for help!!
>
>Regards
>Rohit Singh

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




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

Re: [libvirt-users] Libvirt api for esx

2018-11-28 Thread Martin Kletzander

On Mon, Nov 26, 2018 at 04:11:20PM +0530, ROHIT SINGH wrote:

Hi,

I am doing poc for using libvirt api for implementation of esx in python.

I tried researching through module but did not find a way how it works for
esx.
Any help on how to proceed specifically for esx would be of great help.



See https://libvirt.org/drvesx.html for ESX-related stuff.  But mainly it is the
URI you need to use.  Then look at https://libvirt.org/hvsupport.html where you
can see what APIs are available for that HV driver.


Please let me know as soon as possible, lagging on deliverables.

Thanks for help!!

Regards
Rohit Singh



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




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

Re: [libvirt-users] Questions regarding migration from QEMU to libvirt

2018-11-06 Thread Martin Kletzander

On Mon, Oct 22, 2018 at 12:07:13PM -0300, Rodrigo Siqueira wrote:

Hi,

First of all, thanks for your feedback :)



Sorry for the slow reply, lot of work around KVM Forum conference.


On 10/17, Martin Kletzander wrote:

On Wed, Oct 03, 2018 at 01:04:50PM -0300, Rodrigo Siqueira wrote:
> Hi,
>
> My colleagues and I have a set of scripts that we use to automate our
> daily tasks related to the Linux Kernel. As a result, most of our code
> relies on the QEMU features; and recently we decided use libvirt instead
> of QEMU. However, we have some questions, and I would like to know if
> someone could help us. Follows:
>

Could you explain how much do you rely on the VM looking the same from the guest
perspective (Guest ABI stability)?


Actually, we do not use any special feature from QEMU. Just basic
things. Just for illustrate, follows the command that we use for start a
VM:

qemu-system-x86_64 -enable-kvm -daemonize -m 3G -smp cores=4,cpus=4 -net nic \
-net user,hostfwd=tcp::-:22,smb=/home/USER /home/USER/p/DISK.qcow2


If you only need the disk to stay the same and you want to easily migrate
existing machines, then virt-v2v might be good to try.


Thanks! I will take a look on this.


> 1) Import our QEMU images with virsh
>
> Currently, we import the QEMU VMs with virt-install.
>
> Is it possible to automatically discover the distro variant of a QEMU
> image in order to use it in the “--os-variant” option?
>

You might be able to get that info using libguestfs (virt-v2v should be able to
do that for you).


Yes, I did it last week. I'm doing the following steps:

1. I mount the disk image using libguestfs
2. Print the value MOUNT_PATH_DISK/etc/*-release
3. Take the distro and version

Do you know a straightforward path?



 virt-inspector $filename

or

 virt-inspector -d $domain


> Here is how we register a VM:
> 
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113
>
> 2) The requirement of sudo to create a network
>
> When we register our VM, we want to keep the ssh working well. However,
> every time we register a VM we create a new network bridge as a result
> it requires sudo. Is it possible to avoid this? Or at least make this a
> single action?
>

You don't need to have a libvirt network for each VM, you can create a bridge
and use  or just use .  Or
you can have one network for multiple VMs.  What did you use with plain QEMU?


When I use QEMU for work, I need two things: ssh and share a directory.
I'm using samba for sharing a directory and openssh. Again, this is the
command that I'm using:

qemu-system-x86_64 -enable-kvm -daemonize -m 3G -smp cores=4,cpus=4 -net nic \
-net user,hostfwd=tcp::-:22,smb=/home/USER /home/USER/p/DISK.qcow2

For our network configuration, we have:


 kworkflow-network
 7d167334-7e36-475b-a0ae-9889b87848d7
 
 
 
 
   
 
 
   
 


This configuration file worked well on Debian, but when we tried it on
Archlinux things did not work. Actually, we want to keep these things as
simple as possible. Our requirements are only: share a directory and
access VM via ssh. In order to try to make things simples and
'portable', we think about the following approach:

1. Mount the disk image, and set a static IP
2. Our set of scripts, manage the static IPs

I feel that I'm reinventing the wheel, but this approach sounds easier
for me due to my lack of knowledge in the libvirt. Do you have any other
suggestion to make libvirt do the hard work for me?



More straightforward might be using libvirt's default network and libvirt_nss to
connect without knowing the IP address.

To share a directory you can use  for the domain:

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

but to be brutally honest with you, I don't know what that does on the command
line or how to access it in the guest.

As I said, the easiest option for you might be using just virt-v2v for
*everything*.  I'm not sure how that supports just qemu domains and filesystem
passthrough, though.

HTH,
Martin


I'm not sure what the trouble is, also what the use cases are, so the answers
might not be fit for your needs.

> Here is how we handled this:
> * The code for register:
> 
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113
> * The configuration file that we adopted as a default:
> 
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c16482496875afc0d37b181487ae46R1
>
> 3) When using libvirt it changes the owner of our image
>
> If we try to use libvirt, it changes the ownership of our QEMU images
> (root). We fixed it by changing the file “/etc/libvirt/qemu.conf”, and
> switch the option dynamic_ownership to “0”. What is the impact of that
> change? Is it dangerous? There is a way to avoid this change?
>

dynamic_ownership=0 keeps the owners as they are, but libvirt

Re: [libvirt-users] How to change the default connection of 'virsh' tool from 'qemu' to 'xen' ?

2018-10-31 Thread Martin Kletzander

On Wed, Oct 31, 2018 at 09:32:30AM +0100, Andrea Bolognani wrote:

On Wed, 2018-10-31 at 10:56 +0900, Minjun Hong wrote:

Hi.

Thanks to help of this mailing list (especially Jim Fehlig), I have finished 
setup of libvirt.
However, there is something weird. It is that I installed libvirt on 5 servers 
but
the default connection of one of them is 'qemu:///' even if those of the others 
are all 'xen:///'.


You probably installed the QEMU driver on that one server only: if
that's indeed the case, the easiest way to fix the inconsistency
would be to uninstall it.

If that fails...


I searched how to change it but, I only found a bypass adding " 
LIBVIRT_DEFAULT_URI='xen:///' " in my .bashrc file.
Currently, value of the variable (LIBVIRT_DEFAULT_URI) is set to 'qemu:///'.
Since the bypass makes the virtualization type of the server visible 'qemu' to 
the open stack, I have to change libvirt configuration.

I also checked some configure files under '/etc/libvirt', such as libvirt.conf, 
libvirtd.conf and libxl.conf.
But I have no idea, how and what to change.
Please give me some advise. It will be a big help for me.


... you can simply set

 uri_default = "xen:///"

in /etc/libvirt/libvirt.conf to change the system-wide default URI
without having to mess with environment variables.



Or in .config/libvirt/libvirt.conf for a non-root user.


--
Andrea Bolognani / Red Hat / Virtualization

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


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

Re: [libvirt-users] Questions regarding migration from QEMU to libvirt

2018-10-17 Thread Martin Kletzander

On Wed, Oct 03, 2018 at 01:04:50PM -0300, Rodrigo Siqueira wrote:

Hi,

My colleagues and I have a set of scripts that we use to automate our
daily tasks related to the Linux Kernel. As a result, most of our code
relies on the QEMU features; and recently we decided use libvirt instead
of QEMU. However, we have some questions, and I would like to know if
someone could help us. Follows:



Could you explain how much do you rely on the VM looking the same from the guest
perspective (Guest ABI stability)?

If you only need the disk to stay the same and you want to easily migrate
existing machines, then virt-v2v might be good to try.


1) Import our QEMU images with virsh

Currently, we import the QEMU VMs with virt-install.

Is it possible to automatically discover the distro variant of a QEMU
image in order to use it in the “--os-variant” option?



You might be able to get that info using libguestfs (virt-v2v should be able to
do that for you).


Here is how we register a VM:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113

2) The requirement of sudo to create a network

When we register our VM, we want to keep the ssh working well. However,
every time we register a VM we create a new network bridge as a result
it requires sudo. Is it possible to avoid this? Or at least make this a
single action?



You don't need to have a libvirt network for each VM, you can create a bridge
and use  or just use .  Or
you can have one network for multiple VMs.  What did you use with plain QEMU?

I'm not sure what the trouble is, also what the use cases are, so the answers
might not be fit for your needs.


Here is how we handled this:
* The code for register:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452b008bc71362804d54032f24R113
* The configuration file that we adopted as a default:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c16482496875afc0d37b181487ae46R1

3) When using libvirt it changes the owner of our image

If we try to use libvirt, it changes the ownership of our QEMU images
(root). We fixed it by changing the file “/etc/libvirt/qemu.conf”, and
switch the option dynamic_ownership to “0”. What is the impact of that
change? Is it dangerous? There is a way to avoid this change?



dynamic_ownership=0 keeps the owners as they are, but libvirt cannot guarantee
that the VM will have access to all its resources.  If you are taking care of
that, then keeping that turned off should be OK.


Finally, here is the full code of the libvirt part:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files

Thanks
Best Regards

--
Rodrigo Siqueira
http://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo





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




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

Re: [libvirt-users] live migration via unix socket

2018-10-12 Thread Martin Kletzander

On Mon, Sep 17, 2018 at 02:17:39PM +0200, Fabian Deutsch wrote:

On Fri, Sep 14, 2018 at 6:55 PM David Vossel  wrote:

Any chance we can get the safety check removed for the next Libvirt
release? Does there need to be an issue opened to track this?



Regardless of Martin's answer :): Please file one.
Please file an RFE requesting the change and stating the motivation.



Is there any BZ or issue created where I could post an update?  I spent some
time with this and I got stuck at what looks like the daemon not having a remote
driver instantiated "at some times".  Either it's something very peculiar or I'm
missing something.


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

Re: [libvirt-users] Libvirt TLS with Short Lived Certificates

2018-10-01 Thread Martin Kletzander

On Wed, Sep 26, 2018 at 09:06:07AM -0700, Charles Urquiola wrote:

I want to use short lived certificates with libvirtd to provided TLS access
to the daemon.  New certificates are generated on a daily basis and
delivered to the host.  Does libvirtd re-read TLS certificates with a
reload of the service, systemctl reload libvirtd, or with a SIGHUP or is a
full restart of the daemon required?



If I'm reading the code correctly it needs a full restart.  That's something
that could be changed so that it is done on reload as well.  Care to submit a
proposal? O:-)


--charlie



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




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

Re: [libvirt-users] live migration via unix socket

2018-09-12 Thread Martin Kletzander

On Mon, Sep 10, 2018 at 02:38:48PM -0400, David Vossel wrote:

On Wed, Aug 29, 2018 at 4:55 AM, Daniel P. Berrangé 
wrote:


On Tue, Aug 28, 2018 at 05:07:18PM -0400, David Vossel wrote:
> Hey,
>
> Over in KubeVirt we're investigating a use case where we'd like to
perform
> a live migration within a network namespace that does not provide
libvirtd
> with network access. In this scenario we would like to perform a live
> migration by proxying the migration through a unix socket to a process in
> another network namespace that does have network access.  That external
> process would live on every node in the cluster and know how to correctly
> route connections between libvirtds.
>
> virsh example of an attempted migration via unix socket.
>
> virsh migrate --copy-storage-all --p2p --live --xml domain.xml my-vm
> qemu+unix:///system?socket=destination-host-proxy-sock
>
> In this example, the src libvirtd is able to establish a connection to
the
> destination libvirtd via the unix socket proxy. However, the
migration-uri
> appears to require either tcp or rdma network connection.  If I force the
> migration-uri to be a unix socket, I receive an error [1] indicating that
> qemu+unix is not a valid transport.

qemu+unix is a syntax for libvirt's URI format.  The URI scheme for
migration is not the same, so you can't simply plug in qemu+unix here.

>
> Technically with qemu+kvm I believe what we're attempting should be
> possible (even though it is inefficient). Please correct me if I'm wrong.
>
> Is there a way to achieve this migration via unix socket functionality
this
> using Libvirt? Also, is there a reason why the migration uri is limited
to
> tcp/rdma

Internally libvirt does exactly this when using its TUNNELLED live
migration
mode. In this QEMU is passed an anonymous UNIX socket and the data is all
copied over the libvirtd <-> libvirtd connection and then copied again back



Sorry for the delayed response here, I've only just picked this task back
up again recently.

With the TUNNELLED and PEER2PEER migration flags set, Libvirt won't allow
the libvirtd <-> libvirtd connection over a unix socket.

Libvirt returns this error "Attempt to migrate guest to the same host".
The virDomainMigrateCheckNotLocal() function ensures that a peer2peer
migration won't occur when the destination is a unix socket.

Is there anyway around this? We'd like to tunnel the destination connection
through a unix socket. The other side of the unix socket is a network proxy
in a different network namespace which properly performs the remote
connection.



IMHO that is there just for additional safety since the check with serves the
same purpose is done again in more sensible matter later on (checking that the
hostnames and UUIDs are different).  Actually it's just an older check before
the UUID and hostname were sent in the migration cookie.  And that's there for
quite some time.

IMHO that check can go.  In the worst case we can skip that check
(!tempuri->server) if you ask for unsafe migration.

Also, just to try it out, you *might* be able to work around that check by using
something like unix://localhost.localdomain/path/to/unix.socket (basically
adding any hostname different than localhost there), but I might be wrong there.




to QEMU on another UNIX socket. This was done because QEMU has long had no
ability to encrypt live migration, so tunnelling over libvirtd's own TLS
secured connection was only secure mechanism.




We've done work in QEMU to natively support TLS now so that we can get rid
of this tunnelling, as this architecture decreased performance and consumed
precious CPU memory bandwidth, which is particularly bad when libvirtd and
QEMU were on different NUMA nodes. It is already a challenge to get live
migration to successfully complete even with a direct network connection.
Although QEMU can do it at the low level, we've never exposed anything
other than direct network transports at the API level.

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



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

Re: [libvirt-users] How to specify a x509-dir from XML config file?

2018-09-05 Thread Martin Kletzander

On Tue, Sep 04, 2018 at 02:59:43PM +0800, 陈炤 wrote:

Hi Everyone,


I'd like to ask a question about libvirt xml config. I am using kvm with tls 
certification. For some reason I need to specify a unique certificate file for 
every instance, so my kvm command would be like:


   /usr/libexec/qemu-kvm -spice 
port=5900,tls-port=5901,addr=0.0.0.0,disable-ticketing,x509-dir=/openstack/etc/pki/libvirt-spice


the argument x509-dir=/openstack/etc/pki/libvirt-spice is specified in 
/etc/libvirt/qemu.conf. It's a global argument.
Can I specify it from xml? I searched the xml doc but unable to find useful 
infomation.



You cannot, or at least not now.



BR
Don



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




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

Re: [libvirt-users] Setting up port forwarding to guests on nat network

2018-08-31 Thread Martin Kletzander

On Thu, Aug 30, 2018 at 06:50:38PM -0400, Rhys Ferris wrote:

Thanks for the reply!
output:
net.ipv4.ip_forward = 1



OK, so that is fine.


What do you mean "The out:any and"



I started writing something and then realized it's not related.

Anyway, you can also


Anywhere else I can look as to why the connection isn't going?
Do I need some kind of listener at that port on the host? I'm not even
seeing the packet count on the prerouting chain increase when the
connection attempts are made.



You can always check with wireshark to see what packets are arriving.

Anyway, my iptables are rusty since I switched to shorewall and then firewalld,
so I'm not sure what the reason is.  It looks like it should work.


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

Re: [libvirt-users] Setting up port forwarding to guests on nat network

2018-08-30 Thread Martin Kletzander

On Wed, Aug 29, 2018 at 06:31:41PM -0400, Rhys Ferris wrote:

Hello all,

I’m currently trying to figure out how to forward ports to guests that are on a 
NAT Network. I have followed the directions on 
https://wiki.libvirt.org/page/Networking under the “Forwarding Incoming 
Connections” Section and get connection refused when attempting to connect.

System: Ubuntu Server 18.04.1
Virsh / LibVirtd Version: 4.0.0

Here’s the contents of /etc/libvirt/hooks/qemu
 
#!/bin/bash
 
# IMPORTANT: Change the "VM NAME" string to match your actual VM Name.
# In order to create rules to other VMs, just duplicate the below block and 
configure
# it accordingly.
if [ "${1}" = "testy" ]; then
 
   # Update the following variables to fit your setup
   GUEST_IP='10.128.10.100'
   GUEST_PORT='22'
   HOST_PORT='2588'
 
   if [ "${2}" = "stopped" ] || [ "${2}" = "reconnect" ]; then
        /sbin/iptables -D FORWARD -o virbr0 -d  $GUEST_IP -j ACCEPT
        /sbin/iptables -t nat -D PREROUTING -p tcp --dport $HOST_PORT -j DNAT 
--to $GUEST_IP:$GUEST_PORT
   fi
   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then
        /sbin/iptables -I FORWARD -o virbr0 -d  $GUEST_IP -j ACCEPT
        /sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT 
--to $GUEST_IP:$GUEST_PORT


I would do the rules differently, but since it is on the wiki, I'll believe it
works.  You probably checked, but just to make sure, what is the output of
`sysctl net.ipv4.ip_forward` ?


   fi
fi


Here’s my network XML

  olympus
  3b0d968c-8166-42f7-8109-e5f0317cab42
  
    
      
    
  
  
  
  
    
      
      
    
  


And here’s the results of iptables -L -vt nat:
BEFORE VM BOOT:
Chain PREROUTING (policy ACCEPT 46615 packets, 6618K bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain INPUT (policy ACCEPT 46615 packets, 6618K bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 198K packets, 18M bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain POSTROUTING (policy ACCEPT 198K packets, 18M bytes)
 pkts bytes target     prot opt in     out     source               destination
   24  1812 RETURN     all  --  any    any     10.128.10.0/24       
base-address.mcast.net/24
    0     0 RETURN     all  --  any    any     10.128.10.0/24       
255.255.255.255
   17  1020 MASQUERADE  tcp  --  any    any     10.128.10.0/24      
!10.128.10.0/24       masq ports: 1024-65535
   15  1700 MASQUERADE  udp  --  any    any     10.128.10.0/24      
!10.128.10.0/24       masq ports: 1024-65535
    0     0 MASQUERADE  all  --  any    any     10.128.10.0/24      
!10.128.10.0/24
   22  1666 RETURN     all  --  any    any     192.168.122.0/24     
base-address.mcast.net/24
    0     0 RETURN     all  --  any    any     192.168.122.0/24     
255.255.255.255
    0     0 MASQUERADE  tcp  --  any    any     192.168.122.0/24    
!192.168.122.0/24     masq ports: 1024-65535
    8  1168 MASQUERADE  udp  --  any    any     192.168.122.0/24    
!192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  all  --  any    any     192.168.122.0/24    
!192.168.122.0/24
 
 
AFTER VM BOOT
Chain PREROUTING (policy ACCEPT 2 packets, 120 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere    
         tcp dpt:2588 to:10.128.10.100:22
 


The out:any and


Chain INPUT (policy ACCEPT 2 packets, 120 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 18 packets, 1263 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain POSTROUTING (policy ACCEPT 18 packets, 1263 bytes)
 pkts bytes target     prot opt in     out     source               destination
   24  1812 RETURN     all  --  any    any     10.128.10.0/24       
base-address.mcast.net/24
    0     0 RETURN     all  --  any    any     10.128.10.0/24       
255.255.255.255
   17  1020 MASQUERADE  tcp  --  any    any     10.128.10.0/24      
!10.128.10.0/24       masq ports: 1024-65535
   15  1700 MASQUERADE  udp  --  any    any     10.128.10.0/24      
!10.128.10.0/24       masq ports: 1024-65535
    0     0 MASQUERADE  all  --  any    any     10.128.10.0/24      
!10.128.10.0/24
   22  1666 RETURN     all  --  any    any     192.168.122.0/24     
base-address.mcast.net/24
    0     0 RETURN     all  --  any    any     192.168.122.0/24     
255.255.255.255
    0     0 MASQUERADE  tcp  --  any    any     192.168.122.0/24    
!192.168.122.0/24     masq ports: 1024-65535
    8  1168 MASQUERADE  udp  --  any    any     192.168.122.0/24    
!192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  all  --  any    any     192.168.122.0/24    
!192.168.122.0/24

And lastly heres what actually happens on attempt to SSH:
rhys@odin:~$ ssh 

Re: [libvirt-users] Download image to libvirt storage pool

2018-08-27 Thread Martin Kletzander

On Sat, Aug 25, 2018 at 04:48:01PM +0530, Shashwat shagun wrote:

Is there any function in libvirt (golang SDK) to download image to libvirt
storage pool from path?


I _think_ you have to do:

 https://godoc.org/github.com/libvirt/libvirt-go#StoragePool.StorageVolCreateXML

followed by:

 https://godoc.org/github.com/libvirt/libvirt-go#StorageVol.Upload

HTH,
Martin


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

Re: [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests

2018-08-17 Thread Martin Kletzander

On Thu, Aug 16, 2018 at 03:06:00PM +, procmem wrote:



Martin Kletzander:

On Fri, Aug 10, 2018 at 08:33:00PM +, procmem wrote:

Hello. I'm a distro maintainer and was wondering about the efficacy of
entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the
authors of haveged [0] pointed out if the hardware cycles counter is
emulated and deterministic, and thus predictible. He therefore does not
recommend using HAVEGE on those systems. Is this the case with KVM's
counters?



I don't know the answer.  But try asking on qemu-disc...@nongnu.org or
maybe
KVM-related ML.

Have a nice day,
Martin



Thanks. Yes I had already sent there. Waiting patiently for an answer :)



And I should read more e-mail headers before wasting other people's time by
saying pointless words.

/me pust this skeleton in a cupboard


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

Re: [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests

2018-08-16 Thread Martin Kletzander

On Fri, Aug 10, 2018 at 08:33:00PM +, procmem wrote:

Hello. I'm a distro maintainer and was wondering about the efficacy of
entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the
authors of haveged [0] pointed out if the hardware cycles counter is
emulated and deterministic, and thus predictible. He therefore does not
recommend using HAVEGE on those systems. Is this the case with KVM's
counters?



I don't know the answer.  But try asking on qemu-disc...@nongnu.org or maybe
KVM-related ML.

Have a nice day,
Martin


PS. I will be setting VM CPU settings to host-passthrough.

Bonus: Also if anyone knows the answer to this question about Xen please
let me know because its the other main platform we support and they
don't have the luxury of virtio-rng in PVH mode.

Thanks.

[0]
https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-23006392

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


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

Re: [libvirt-users] List-Archives ...

2018-06-07 Thread Martin Kletzander

On Mon, May 28, 2018 at 09:30:42AM +0200, Ján Tomko wrote:

On Sun, May 27, 2018 at 01:04:37PM +0200, thg wrote:

Hi everybody,

actually I wanted to search the list archive, before asking, but
unfortunately I don't "get" it:

$ gunzip 2018-May.txt.gz
gunzip: 2018-May.txt.gz: not in gzip format

It seems, that in every archive-file there is always one message in
plaintext and then a big binary block.

Any hint?



Try a different application to download the file.

Years ago wget did not work for me because of some Content-Encoding
problems, so I had to use Firefox.

(I don't remember whether the server sends incorrect headers or if
the handling in wget was broken, but it works for me now even with
wget)



IMHO there are two different gzip compressions applied, one for the file and one
for the transfer.  If you have new enough wget, then downloading it with
--compression auto (experimental in 1.19.5) should create valid txt.gz files
that you can just gunzip [1] cleanly without errors.


Jano


Martin

[1] Usually when I think of some stupid joke (or maybe just stupidity in this
   case) it already exists on the internet.  But now either my google-fu is
   weak with me or there is no picture of a gun with a zipper on it.  So I
   can't attach any Gun Zip picture :(

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

Re: [libvirt-users] [libvirt] virRandomBits - not very random

2018-06-01 Thread Martin Kletzander

On Fri, Jun 01, 2018 at 01:25:26PM +0100, Daniel P. Berrangé wrote:

On Fri, Jun 01, 2018 at 02:01:03PM +0200, Martin Kletzander wrote:

On Fri, Jun 01, 2018 at 11:17:44AM +0100, Daniel P. Berrangé wrote:
> On Wed, May 30, 2018 at 10:21:54PM +0200, Martin Kletzander wrote:
> > On Tue, May 29, 2018 at 10:06:25AM -0400, John Ferlan wrote:
> > >
> > >
> > > On 05/29/2018 09:44 AM, Michal Privoznik wrote:
> > > > On 05/29/2018 03:38 PM, Martin Kletzander wrote:
> > > > > On Fri, May 25, 2018 at 09:37:44AM -0500, Eric Blake wrote:
> > > > > > On 05/25/2018 09:17 AM, Michal Privoznik wrote:
> > > > > >
> > > > > > > > > We should probably seed it with data from /dev/urandom, 
and/or the new
> > > > > > > > > Linux getrandom() syscall (or BSD equivalent).
> > > > > > >
> > > > > > > I'm not quite sure that right after reboot there's going to be 
enough
> > > > > > > entropy. Every service that's starting wants some random bits. 
But it's
> > > > > > > probably better than what we have now.
> > > > > >
> > > > > > Here's where we left things last time it came up:
> > > > > >
> > > > > > 
https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html
> > > > > >
> > > > > > If gnutls has an interface that will give us random bits
> > > > > > (gnutls_key_generate() in 3.0, perhaps), we should use THAT for all 
of
> > > > > > our random bits (and forget about a seed), except when we are 
mocking
> > > > > > things in our testsuite, and need a deterministic PRNG from a
> > > > > > deterministic seed.
> > > > > >
> > > > > > If not (including if we are not linked with gnutls), then we should
> > > > > > prefer the new Linux syscall but fall back to /dev/urandom for JUST
> > > > > > enough bits for a seed; once we're seeded, stick with using our 
existing
> > > > > > PRNG for all future bits (after all, we aren't trying to generate
> > > > > > cryptographically secure keys using virRandomBits - and the places 
where
> > > > > > we DO need crypto-strong randomness such as setting up TLS 
migration is
> > > > > > where we are relying on gnutls to provide it rather than 
virRandomBits).
> > > > > >
> > > > > > So at this point, it's just a matter of someone writing the patches.
> > > > > >
> > > > >
> > > > > Actually, do we need to have a fallback at all?  Can't we just drop 
all the
> > > > > gross parts of the code the conditionally compile based on GNUTLS
> > > > > support?  Why
> > > > > don't we have gnutls required?
> > > >
> > > > That's exactly what I'm suggesting in my patches [1]. gnutls is widely
> > > > available (including Linux, Windows, *BSD, Mac Os X). However, before
> > > > doing that we need to fix virRandomBits() to actually call gnutls_rnd().
> > > >
> > > > 1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
> > > >
> > >
> > > I have this faint recollection of one of the CI platform builds failing
> > > because something in the gnutls* family didn't exist there when I was
> > > making the changes to add the domain master secret code  After a bit
> > > of digging, it seems it was a perhaps a CENTOS6 environment:
> > >
> > > https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
> > >
> > > and since IIUC that's not an issue any more
> > >
> >
> > Oh, cool to know.  Michal also found the patch [1] where Dan switched the 
gnutls
> > from being mandatory to making it optional and there is no explanation for 
that
> > change in the commit message:
> >
> > [1] f587c27768ee13f5bed6a9262106307b7a124403
>
> Not all usage scenarios in libvirt have required GNUTLS - only the remote
> driver, when using stateful virt drivers. If you're just biulding libvirt
> for usage with ESX/HyperV/etc, there's no reason you'd want GNUTLS 
historically.
>
> Also note when building the setuid libvirt pieces we must never use GNUTLS
> because its library constructors do very bad things leading to CVEs.
>

Good to know, thanks for the info.  I'll need to read up on the gnutls
constructors (is it just gnutls or some other libs as well?) even though I
remember researching

Re: [libvirt-users] [libvirt] virRandomBits - not very random

2018-06-01 Thread Martin Kletzander

On Fri, Jun 01, 2018 at 11:17:44AM +0100, Daniel P. Berrangé wrote:

On Wed, May 30, 2018 at 10:21:54PM +0200, Martin Kletzander wrote:

On Tue, May 29, 2018 at 10:06:25AM -0400, John Ferlan wrote:
>
>
> On 05/29/2018 09:44 AM, Michal Privoznik wrote:
> > On 05/29/2018 03:38 PM, Martin Kletzander wrote:
> > > On Fri, May 25, 2018 at 09:37:44AM -0500, Eric Blake wrote:
> > > > On 05/25/2018 09:17 AM, Michal Privoznik wrote:
> > > >
> > > > > > > We should probably seed it with data from /dev/urandom, and/or 
the new
> > > > > > > Linux getrandom() syscall (or BSD equivalent).
> > > > >
> > > > > I'm not quite sure that right after reboot there's going to be enough
> > > > > entropy. Every service that's starting wants some random bits. But 
it's
> > > > > probably better than what we have now.
> > > >
> > > > Here's where we left things last time it came up:
> > > >
> > > > https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html
> > > >
> > > > If gnutls has an interface that will give us random bits
> > > > (gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of
> > > > our random bits (and forget about a seed), except when we are mocking
> > > > things in our testsuite, and need a deterministic PRNG from a
> > > > deterministic seed.
> > > >
> > > > If not (including if we are not linked with gnutls), then we should
> > > > prefer the new Linux syscall but fall back to /dev/urandom for JUST
> > > > enough bits for a seed; once we're seeded, stick with using our existing
> > > > PRNG for all future bits (after all, we aren't trying to generate
> > > > cryptographically secure keys using virRandomBits - and the places where
> > > > we DO need crypto-strong randomness such as setting up TLS migration is
> > > > where we are relying on gnutls to provide it rather than virRandomBits).
> > > >
> > > > So at this point, it's just a matter of someone writing the patches.
> > > >
> > >
> > > Actually, do we need to have a fallback at all?  Can't we just drop all 
the
> > > gross parts of the code the conditionally compile based on GNUTLS
> > > support?  Why
> > > don't we have gnutls required?
> >
> > That's exactly what I'm suggesting in my patches [1]. gnutls is widely
> > available (including Linux, Windows, *BSD, Mac Os X). However, before
> > doing that we need to fix virRandomBits() to actually call gnutls_rnd().
> >
> > 1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html
> >
>
> I have this faint recollection of one of the CI platform builds failing
> because something in the gnutls* family didn't exist there when I was
> making the changes to add the domain master secret code  After a bit
> of digging, it seems it was a perhaps a CENTOS6 environment:
>
> https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html
>
> and since IIUC that's not an issue any more
>

Oh, cool to know.  Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
change in the commit message:

[1] f587c27768ee13f5bed6a9262106307b7a124403


Not all usage scenarios in libvirt have required GNUTLS - only the remote
driver, when using stateful virt drivers. If you're just biulding libvirt
for usage with ESX/HyperV/etc, there's no reason you'd want GNUTLS historically.

Also note when building the setuid libvirt pieces we must never use GNUTLS
because its library constructors do very bad things leading to CVEs.



Good to know, thanks for the info.  I'll need to read up on the gnutls
constructors (is it just gnutls or some other libs as well?) even though I
remember researching something related to it some time ago.  However that
doesn't mean it has to be optional.

Do you think there are people who would be bothered by the requirement of
gnutls?  I'm sure most of them have gnutls anyway.  Some of them even need to
have, for example if you have a look at virCryptoHashBuf() its stub returns -1
and it is used in ESX.  If you compile without GNUTLS, all the functions that
require it will just fail and it's not something that is used rarely.

We can we make it required only if you are building with qemu or remote or esx
or basically something that requires it.  Encryption of RAW volumes for example.
Or lock driver.  But I don't think there are some who run the builds themselves
and doesn't want gnutls on their system.  I can't think of a reason for having
it and not linking libvirt

Re: [libvirt-users] [libvirt] virRandomBits - not very random

2018-05-30 Thread Martin Kletzander

On Tue, May 29, 2018 at 10:06:25AM -0400, John Ferlan wrote:



On 05/29/2018 09:44 AM, Michal Privoznik wrote:

On 05/29/2018 03:38 PM, Martin Kletzander wrote:

On Fri, May 25, 2018 at 09:37:44AM -0500, Eric Blake wrote:

On 05/25/2018 09:17 AM, Michal Privoznik wrote:


We should probably seed it with data from /dev/urandom, and/or the new
Linux getrandom() syscall (or BSD equivalent).


I'm not quite sure that right after reboot there's going to be enough
entropy. Every service that's starting wants some random bits. But it's
probably better than what we have now.


Here's where we left things last time it came up:

https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html

If gnutls has an interface that will give us random bits
(gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of
our random bits (and forget about a seed), except when we are mocking
things in our testsuite, and need a deterministic PRNG from a
deterministic seed.

If not (including if we are not linked with gnutls), then we should
prefer the new Linux syscall but fall back to /dev/urandom for JUST
enough bits for a seed; once we're seeded, stick with using our existing
PRNG for all future bits (after all, we aren't trying to generate
cryptographically secure keys using virRandomBits - and the places where
we DO need crypto-strong randomness such as setting up TLS migration is
where we are relying on gnutls to provide it rather than virRandomBits).

So at this point, it's just a matter of someone writing the patches.



Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS
support?  Why
don't we have gnutls required?


That's exactly what I'm suggesting in my patches [1]. gnutls is widely
available (including Linux, Windows, *BSD, Mac Os X). However, before
doing that we need to fix virRandomBits() to actually call gnutls_rnd().

1: https://www.redhat.com/archives/libvir-list/2018-May/msg02077.html



I have this faint recollection of one of the CI platform builds failing
because something in the gnutls* family didn't exist there when I was
making the changes to add the domain master secret code  After a bit
of digging, it seems it was a perhaps a CENTOS6 environment:

https://www.redhat.com/archives/libvir-list/2016-April/msg00287.html

and since IIUC that's not an issue any more



Oh, cool to know.  Michal also found the patch [1] where Dan switched the gnutls
from being mandatory to making it optional and there is no explanation for that
change in the commit message:

[1] f587c27768ee13f5bed6a9262106307b7a124403


John

now if I could only figure out why my mail client seems to be dropping
any patches with "crypto" in the subject line (I'm missing patches 2-4
and 10 from the series referenced above)...


Maybe you have some weird server-side filter for it?

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

Re: [libvirt-users] [libvirt] virRandomBits - not very random

2018-05-29 Thread Martin Kletzander

On Fri, May 25, 2018 at 09:37:44AM -0500, Eric Blake wrote:

On 05/25/2018 09:17 AM, Michal Privoznik wrote:


We should probably seed it with data from /dev/urandom, and/or the new
Linux getrandom() syscall (or BSD equivalent).


I'm not quite sure that right after reboot there's going to be enough
entropy. Every service that's starting wants some random bits. But it's
probably better than what we have now.


Here's where we left things last time it came up:

https://www.redhat.com/archives/libvir-list/2014-December/msg00573.html

If gnutls has an interface that will give us random bits
(gnutls_key_generate() in 3.0, perhaps), we should use THAT for all of
our random bits (and forget about a seed), except when we are mocking
things in our testsuite, and need a deterministic PRNG from a
deterministic seed.

If not (including if we are not linked with gnutls), then we should
prefer the new Linux syscall but fall back to /dev/urandom for JUST
enough bits for a seed; once we're seeded, stick with using our existing
PRNG for all future bits (after all, we aren't trying to generate
cryptographically secure keys using virRandomBits - and the places where
we DO need crypto-strong randomness such as setting up TLS migration is
where we are relying on gnutls to provide it rather than virRandomBits).

So at this point, it's just a matter of someone writing the patches.



Actually, do we need to have a fallback at all?  Can't we just drop all the
gross parts of the code the conditionally compile based on GNUTLS support?  Why
don't we have gnutls required?


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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


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

Re: [libvirt-users] Server 2016 locked in paused state

2018-05-01 Thread Martin Kletzander

On Mon, Apr 30, 2018 at 05:46:14PM +0200, Francesc Guasch wrote:

On 30/4/18 16:59, Paul O'Rorke wrote:

Hi all,

I have a number of production Windows servers on KVM/DRBD and two of
them are Server 2016.  Both these guests have started exhibiting the
same behaviour where they enter a paused state and will not resume.



Paul, I experienced this when the server images partition
filled. It may not be your case but it's worth to check it out.



Yeah, that was my first idea as well, you might have ran out of space.  Check
the pause reason for the domain. I'm not sure how to do that in virt-manager,
but you can do that using `virsh domstate --reason $domain`.  You can also check
libvirt logs for something like EIO or I/O error, but that will just be a debug
message saying that QEMU sent us something like that.


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


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

Re: [libvirt-users] Possible to resize a Windows guest's disk while online?

2018-04-17 Thread Martin Kletzander

On Wed, Apr 11, 2018 at 01:30:26PM -0400, Andre Goree wrote:

I'm looking for a way to online resize a Windows disk -- i.e., be able
to resize the disk without shutting down, rebooting, or detaching the
disk.



virsh blockresize $domain $disk $size

and then resize the disk in the disk managing utility inside the guest.  I don't
thinkg qemu-guest-agent can do that for you.


Is this at all possible?  Or am I just barking up the wrong tree?  I'm
not finding a way to do this and even Amazon has a weird workaround, in
which the user must write data to the newly resized-drive in order to
recognize the new size without taking the disk or the VM offline.

[Obligatory] YAY Microsoft.


--
Andre Goree
-=-=-=-=-=-
Email - andre at drenet.net
Website   - http://blog.drenet.net
PGP key   - http://www.drenet.net/pubkey.html
-=-=-=-=-=-

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


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

Re: [libvirt-users] How can we achieve vga emulation over a serial port in libvirt

2018-03-05 Thread Martin Kletzander

On Mon, Mar 05, 2018 at 11:37:08AM +0100, Martin Kletzander wrote:

On Wed, Feb 28, 2018 at 03:10:08PM +0800, Meina Li wrote:

Hi

For the latest seabios version, it said: Support for vga emulation over a
serial port in SeaBIOS (sercon).

So I want to know how can I find the application of this feature in
libvirt? And whether my understanding is correct?
There are no related instruction on the website: https://libvirt.org/

My understanding:
(1) The feature means: we can set this the IO address of a serial port to
"video" element to enable SeaBIOS' VGA adapter emulation on the given
serial port.


Looks like it, however the question is if that's somehow set as a default or
not.  According to the docs for SeaBIOS it says:

sercon-port: Set this to the IO address of a serial port to enable SeaBIOS' VGA
adapter emulation on the given serial port.

However looking at current QEMU master, there is no such setting being done (I
just did simple git grep sercon-port).  However it looks like other options are
being set using fw_cfg_add_file, so it should be possible to set that using
something like:

-fw_cfg name=etc/sercon-port,string=0x3F8

but when I tried (with seabios 1.11.0), I realized I'm not sure how to see
whether it works or not.  How would I try that, easily?

Anyway, if the above is the case, we don't _yet_ have an option in libvirt's
XML.  We will need to add support for fw_cfg, I just didn't, for now.


(2) Libvirt XML examples and with this xml the guest can start successfully:
   
 
   
   
   
   
   



I'm not sure how the inner workings of this are supposed to work, so I can't
comment on the XML structure.



Nah, we cracked the code.  I don't know why I was overcomplicating this, but it
just means that seabios can now do what sgabios was created for (if I'm
understanding this correctly).  So with libvirt you could do that even before,
it's just a matter of adding `` to domain XML under
`` section.  Libvirt will append `-device sga` onto QEMU's command line
which will add sgabios on top of seabios and it will do the same thing.

If there's something more in that, just let me know, but I doubt that.

What's weird, though, is that if I run updated QEMU with only '-nographic'
option, it just works.  I see the iPXE messages and a prompt and I can use it.
However if I create a machine without `` and try to
`virsh start --console` it, I get no output, only with that XML element added.
I whould investigate further, but I don't have enough time+knowledge to go deep
into QEMU and figure that difference out.  And I don't see how the difference
could be caused by libvirt.

Martin

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

Re: [libvirt-users] How can we achieve vga emulation over a serial port in libvirt

2018-03-05 Thread Martin Kletzander

On Wed, Feb 28, 2018 at 03:10:08PM +0800, Meina Li wrote:

Hi

For the latest seabios version, it said: Support for vga emulation over a
serial port in SeaBIOS (sercon).

So I want to know how can I find the application of this feature in
libvirt? And whether my understanding is correct?
There are no related instruction on the website: https://libvirt.org/

My understanding:
(1) The feature means: we can set this the IO address of a serial port to
"video" element to enable SeaBIOS' VGA adapter emulation on the given
serial port.


Looks like it, however the question is if that's somehow set as a default or
not.  According to the docs for SeaBIOS it says:

sercon-port: Set this to the IO address of a serial port to enable SeaBIOS' VGA
adapter emulation on the given serial port.

However looking at current QEMU master, there is no such setting being done (I
just did simple git grep sercon-port).  However it looks like other options are
being set using fw_cfg_add_file, so it should be possible to set that using
something like:

-fw_cfg name=etc/sercon-port,string=0x3F8

but when I tried (with seabios 1.11.0), I realized I'm not sure how to see
whether it works or not.  How would I try that, easily?

Anyway, if the above is the case, we don't _yet_ have an option in libvirt's
XML.  We will need to add support for fw_cfg, I just didn't, for now.


(2) Libvirt XML examples and with this xml the guest can start successfully:
   
 
   
   
   
   
   



I'm not sure how the inner workings of this are supposed to work, so I can't
comment on the XML structure.


Thank in advance.




Best Regards
Meina Li



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




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

Re: [libvirt-users] is it possible to add to libvirt Network XML

2018-01-31 Thread Martin Kletzander

On Tue, Jan 30, 2018 at 10:01:53PM +0530, Shashwat shagun wrote:

i need to know is it possible to add metadata to Libvirt Network XML like i
do in Domain XML with  tag?



Yes.


--
Regards,
Shashwat Shagun



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




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

Re: [libvirt-users] Inter Shared Memory ( Ivshmem ) : Cannot Bind

2017-12-12 Thread Martin Kletzander

On Mon, Dec 11, 2017 at 03:03:34PM +0800, Rogue S.T wrote:

Hello, friends.
I encounter a problem when i use ivshmem with my guest, my ivshmem server is 
not start, and output a error : Example code, do not use in production ,cannot 
bind.


Detail distribution:
Today, I know ivshmem from a topic "QEMU version 2.10.93 User Documentation",
Ivshmem: it can create a shared memory that guest device use, so we can use 
this memory to do something ourselves.
First, I create host memory backend:
-object 
memory-backend-file,size=1M,share,mem-path=/dev/shm/ivshmem,id=hostmem
Twice, Bind a shared memory device to my guest:
   -device ivshmem-plain,memdev=hostmem


You are using plain, but


Then I boot ivshmem servi
   ivshmem-server -p /var/run/ivshmem-server.pid  -S /tmp/ivshmem_socket  -M 
ivshmem -m /dev/shm -l 1M -n 2


You are running a server.  This is not how it works.

Looks like you are playing with something that you don't really need, otherwise
you would do things differetly.  It you are just trying it out, that's fine.
Otherwise make sure it's what you need.  More information on how this hot mess
works is here:

https://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/ivshmem-spec.txt


Next time i get this error:
   *** Example code, do not use in production ***
   cannot bind
And i search the problem on google, but nothing to get, hope you can help me 
solve it.
following message is my host environment:
   host:  ubuntu 1604
   qemu:  version 2.10.90 (v2.11.0-rc0-dirty)
   libvirt:  libvirtd (libvirt) 3.9.0
   guest:window 7 professor


Refer:
   https://qemu.weilnetz.de/doc/qemu-doc.html#Inter_002dVM-Shared-Memory-device 
(topic qemu documention)
   https://helpmanual.io/help/ivshmem-server/  ( how to use ivshmem-server )



___
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] terminating on signal 15 from pid 2146 (/usr/sbin/libvirtd)

2017-10-26 Thread Martin Kletzander

On Wed, Oct 25, 2017 at 09:41:58PM +0300, Matwey V. Kornilov wrote:

Well, I really had to use start --console from the beginning. It would
have safe the time.

# start --console s390_generic
Using guessed DASD geometry.
   Using ECKD scheme (block size  4096), CDL

!
No zIPL section in IPL2 record. !



Yeah, it all looked like the guest OS just ends normally itself.  So
precisely what libvirt was reporting.

I'm glad this is resolved.

Have a nice day,
Martin


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

Re: [libvirt-users] terminating on signal 15 from pid 2146 (/usr/sbin/libvirtd)

2017-10-24 Thread Martin Kletzander

On Fri, Oct 20, 2017 at 10:12:19PM +0300, Matwey V. Kornilov wrote:

2017-10-20 17:14 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>:

2017-10-20 15:16 GMT+03:00 Martin Kletzander <mklet...@redhat.com>:

On Fri, Oct 20, 2017 at 03:07:19PM +0300, Matwey V. Kornilov wrote:


2017-10-20 14:59 GMT+03:00 Martin Kletzander <mklet...@redhat.com>:


On Thu, Oct 19, 2017 at 09:11:00PM +0300, Matwey V. Kornilov wrote:



Hello,

I use libvirt 3.3.0 and qemu 2.9.0

My domain XML spec is the following:


 s390_generic
 82b4d16e-b636-447e-9fda-41d44616bce8
 1048576
 1048576
 1
 
   hvm
   
 
 
 destroy
 restart
 destroy
 
   /usr/bin/qemu-system-s390x
   
 
 
 
 
   
   
 
 
 
 
   
   
 
   
   
 
 
 
 
   
   
 
   
   
 
   
   
 


The issue is that when I try to start it, it starts and shutdowns
immediately:

virsh # start s390_generic
Domain s390_generic started

virsh #

In the domain log file I see the following:

2017-10-19 18:10:21.633+: starting up libvirt version: 3.3.0, qemu
version: 2.9.0(openSUSE Leap 42.3), hostname: oak.local
LC_ALL=C
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-s390x -name
guest=s390_generic,debug-threads=on -S -object


secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-s390_generic/master-key.aes
-machine s390-ccw-virtio-2.9,accel=tcg,usb=off,dump-guest-core=off -m
1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
82b4d16e-b636-447e-9fda-41d44616bce8 -display none -no-user-config
-nodefaults -chardev


socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-s390_generic/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot strict=on -device
virtio-scsi-ccw,id=scsi0,devno=fe.0.0002 -drive


file=/dev/lvm_pda/libvirt_s390,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
-device


virtio-blk-ccw,scsi=off,devno=fe.0.,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,id=drive-scsi0-0-0-0,readonly=on -device


scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
-netdev tap,fd=26,id=hostnet0 -device


virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:e8:61:7e,devno=fe.0.0001
-chardev pty,id=charconsole0 -device
sclpconsole,chardev=charconsole0,id=console0 -device
virtio-balloon-ccw,id=balloon0,devno=fe.0.0003 -msg timestamp=on
2017-10-19T18:10:21.701184Z qemu-system-s390x: -chardev
pty,id=charconsole0: char device redirected to /dev/pts/5 (label
charconsole0)
2017-10-19T18:10:21.721299Z qemu-system-s390x: terminating on signal 15
from pid 2146 (/usr/sbin/libvirtd)
2017-10-19 18:10:21.985+: shutting down, reason=shutdown



You don't have much logging enabled, so there's not that much info.
What's
in
the libvirtd.log?  what is the status reason for the domain?  I.e. output
of
`virsh domstate --reason` ?



How could I increase log level? There is nothing in libvirtd.log.



https://wiki.libvirt.org/page/DebugLogs


Too much info for me...



We are getting 'shutdown' event from the QEMU process, so this is not done by
libvirt.  Could you also check the qemu log now that you have debug logs
enabled?


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

Re: [libvirt-users] terminating on signal 15 from pid 2146 (/usr/sbin/libvirtd)

2017-10-20 Thread Martin Kletzander

On Fri, Oct 20, 2017 at 03:07:19PM +0300, Matwey V. Kornilov wrote:

2017-10-20 14:59 GMT+03:00 Martin Kletzander <mklet...@redhat.com>:

On Thu, Oct 19, 2017 at 09:11:00PM +0300, Matwey V. Kornilov wrote:


Hello,

I use libvirt 3.3.0 and qemu 2.9.0

My domain XML spec is the following:


 s390_generic
 82b4d16e-b636-447e-9fda-41d44616bce8
 1048576
 1048576
 1
 
   hvm
   
 
 
 destroy
 restart
 destroy
 
   /usr/bin/qemu-system-s390x
   
 
 
 
 
   
   
 
 
 
 
   
   
 
   
   
 
 
 
 
   
   
 
   
   
 
   
   
 


The issue is that when I try to start it, it starts and shutdowns
immediately:

virsh # start s390_generic
Domain s390_generic started

virsh #

In the domain log file I see the following:

2017-10-19 18:10:21.633+: starting up libvirt version: 3.3.0, qemu
version: 2.9.0(openSUSE Leap 42.3), hostname: oak.local
LC_ALL=C
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-s390x -name
guest=s390_generic,debug-threads=on -S -object

secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-s390_generic/master-key.aes
-machine s390-ccw-virtio-2.9,accel=tcg,usb=off,dump-guest-core=off -m
1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
82b4d16e-b636-447e-9fda-41d44616bce8 -display none -no-user-config
-nodefaults -chardev

socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-s390_generic/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot strict=on -device
virtio-scsi-ccw,id=scsi0,devno=fe.0.0002 -drive

file=/dev/lvm_pda/libvirt_s390,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
-device

virtio-blk-ccw,scsi=off,devno=fe.0.,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,id=drive-scsi0-0-0-0,readonly=on -device

scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
-netdev tap,fd=26,id=hostnet0 -device

virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:e8:61:7e,devno=fe.0.0001
-chardev pty,id=charconsole0 -device
sclpconsole,chardev=charconsole0,id=console0 -device
virtio-balloon-ccw,id=balloon0,devno=fe.0.0003 -msg timestamp=on
2017-10-19T18:10:21.701184Z qemu-system-s390x: -chardev
pty,id=charconsole0: char device redirected to /dev/pts/5 (label
charconsole0)
2017-10-19T18:10:21.721299Z qemu-system-s390x: terminating on signal 15
from pid 2146 (/usr/sbin/libvirtd)
2017-10-19 18:10:21.985+: shutting down, reason=shutdown



You don't have much logging enabled, so there's not that much info.  What's
in
the libvirtd.log?  what is the status reason for the domain?  I.e. output of
`virsh domstate --reason` ?


How could I increase log level? There is nothing in libvirtd.log.



https://wiki.libvirt.org/page/DebugLogs


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

Re: [libvirt-users] terminating on signal 15 from pid 2146 (/usr/sbin/libvirtd)

2017-10-20 Thread Martin Kletzander

On Thu, Oct 19, 2017 at 09:11:00PM +0300, Matwey V. Kornilov wrote:

Hello,

I use libvirt 3.3.0 and qemu 2.9.0

My domain XML spec is the following:


 s390_generic
 82b4d16e-b636-447e-9fda-41d44616bce8
 1048576
 1048576
 1
 
   hvm
   
 
 
 destroy
 restart
 destroy
 
   /usr/bin/qemu-system-s390x
   
 
 
 
 
   
   
 
 
 
 
   
   
 
   
   
 
 
 
 
   
   
 
   
   
 
   
   
 


The issue is that when I try to start it, it starts and shutdowns
immediately:

virsh # start s390_generic
Domain s390_generic started

virsh #

In the domain log file I see the following:

2017-10-19 18:10:21.633+: starting up libvirt version: 3.3.0, qemu
version: 2.9.0(openSUSE Leap 42.3), hostname: oak.local
LC_ALL=C
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/qemu-system-s390x -name
guest=s390_generic,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-s390_generic/master-key.aes
-machine s390-ccw-virtio-2.9,accel=tcg,usb=off,dump-guest-core=off -m
1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
82b4d16e-b636-447e-9fda-41d44616bce8 -display none -no-user-config
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-s390_generic/monitor.sock,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot strict=on -device
virtio-scsi-ccw,id=scsi0,devno=fe.0.0002 -drive
file=/dev/lvm_pda/libvirt_s390,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
-device
virtio-blk-ccw,scsi=off,devno=fe.0.,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,id=drive-scsi0-0-0-0,readonly=on -device
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
-netdev tap,fd=26,id=hostnet0 -device
virtio-net-ccw,netdev=hostnet0,id=net0,mac=52:54:00:e8:61:7e,devno=fe.0.0001
-chardev pty,id=charconsole0 -device
sclpconsole,chardev=charconsole0,id=console0 -device
virtio-balloon-ccw,id=balloon0,devno=fe.0.0003 -msg timestamp=on
2017-10-19T18:10:21.701184Z qemu-system-s390x: -chardev
pty,id=charconsole0: char device redirected to /dev/pts/5 (label
charconsole0)
2017-10-19T18:10:21.721299Z qemu-system-s390x: terminating on signal 15
from pid 2146 (/usr/sbin/libvirtd)
2017-10-19 18:10:21.985+: shutting down, reason=shutdown



You don't have much logging enabled, so there's not that much info.  What's in
the libvirtd.log?  what is the status reason for the domain?  I.e. output of
`virsh domstate --reason` ?



What is the issue?

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


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

Re: [libvirt-users] Rollback to running VM

2017-09-19 Thread Martin Kletzander

On Tue, Sep 19, 2017 at 01:28:45PM +, Jackson, Gary L. wrote:


I would like to make a snapshot of a running VM, let it continue to run
after the shapshot, and then at some later time roll back the VM to
that previous running state. Can I do that with libvirt? If so, how? I
understand that this will cause all kinds of havoc with things like
ongoing TCP connections, and I accept that risk.



Check `man virsh` and the description to commands `snapshot-create-as`
and `snapshot-revert`.  If more information is needed, feel free to ask,
although if deep knowledge is required I might need to rely on someone
else to reply then.

Have a nice day,
Martin


--
Gary Jackson




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


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

Re: [libvirt-users] How can i limit CPU allowance to 25% of a single core

2017-09-19 Thread Martin Kletzander

On Tue, Sep 19, 2017 at 02:57:09AM +0530, Shashwat shagun wrote:

Hi,
How do Hard limit a CPU allowance to 25% of a single core in KVM?



Using `period`/`quota` and `shares` parameters of cgroups.  This is
mapped to the domain XML's respective `cputune` elements [1].

Martin

[1] https://libvirt.org/formatdomain.html#elementsCPUTuning


Regards,
Shashwat Shagun




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


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

Re: [libvirt-users] How to configure dnsmasq using libvirt?

2017-09-18 Thread Martin Kletzander

On Wed, Aug 23, 2017 at 05:02:48PM -0400, Don Zickus wrote:

Hi,

I am working on a project, beaker, where they use anisble scripts to setup
an environment with 4 virtual machines.  One acts as a server to the other
3.

We noticed after the network was setup, the domainname is not properly
reported with using the 'hostname' command.  We believe that dnsmasq was not
correctly configured.

Is there a recommended way to setup dnsmasq using libvirt and ansible?



Not that I know of (for now).  What is the problem you have?  Can't the
VMs reach each other using hostnames?  Do they properly report hostnames
when asking for a lease?  I've seen bunch of problems with this, but it
was always about not-so-well behaving machines.  By default it should
just work.  Can you elaborate more on how stuff does not work?  Thanks.


Thanks!

Cheers,
Don

ps - please cc me as I am not subscribed to the list

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


signature.asc
Description: Digital signature
___
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-08-31 Thread Martin Kletzander

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.


Cheers,
David


--
David Ayers - Team Austria
Free Software Foundation Europe (FSFE) []  (http://www.fsfe.org)
Join the Fellowship of FSFE! [][][]  (https://fsfe.org/join)
Your donation powers our work! ||   (http://fsfe.org/donate)


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

Re: [libvirt-users] duplicated notifications for suspend and resume

2017-08-25 Thread Martin Kletzander

On Thu, Aug 24, 2017 at 12:54:26PM +, Naud, AntoineX wrote:

Hello,

I am using domain event notifications from libvirt-event API in my application 
and it seems to work fine, except for 'suspend' and 'resume' events where I 
keep receiving duplicated notifications.

Similarly, the example provided with libvirt (in 
examples/object-events/event-test) also produces twice as much notifications 
for 'suspend' and 'resume' than for other events. Here is the sequence of virsh 
commands and the output of event-test:

Virsh start Fed25
Virsh suspend Fed25
Virsh resume Fed25
Virsh shutdown Fed25

[~/libvirt-3.4.0/examples/object-events] ./event-test qemu:///system
Registering event callbacks
myNodeDeviceEventCallback EVENT: Node device net_vnet0_fe_54_00_a0_ba_61 
Created 0
myDomainEventCallback1 EVENT: Domain Fed25(1) Resumed Unpaused
myDomainEventCallback2 EVENT: Domain Fed25(1) Resumed Unpaused
myDomainEventCallback1 EVENT: Domain Fed25(1) Started Booted
myDomainEventCallback2 EVENT: Domain Fed25(1) Started Booted
myDomainEventCallback1 EVENT: Domain Fed25(1) Suspended Paused
myDomainEventCallback2 EVENT: Domain Fed25(1) Suspended Paused
myDomainEventCallback1 EVENT: Domain Fed25(1) Suspended Paused
myDomainEventCallback2 EVENT: Domain Fed25(1) Suspended Paused
myDomainEventCallback1 EVENT: Domain Fed25(1) Resumed Unpaused
myDomainEventCallback2 EVENT: Domain Fed25(1) Resumed Unpaused
myDomainEventCallback1 EVENT: Domain Fed25(1) Resumed Unpaused
myDomainEventCallback2 EVENT: Domain Fed25(1) Resumed Unpaused
myDomainEventCallback1 EVENT: Domain Fed25(1) Shutdown Finished
myDomainEventCallback2 EVENT: Domain Fed25(1) Shutdown Finished
myNodeDeviceEventCallback EVENT: Node device net_vnet0_fe_54_00_a0_ba_61 
Deleted 0

Note that the 2 lines printed for each event are ok since 2 callbacks are 
registered in the example.



We cannot guarantee that some events will not fire multiple times as is
some cases there is no way to check whether it is duplicate or not when
libvirt gets the information.  I have a hunch that the fact that events
can happen multiple times is written somewhere in the docs.

Is there any problem you are trying to solve here?


Has anybody else faced this issue?

I am using libvirt-3.6.0 on Ubuntu 16.04.

Best regards,
Antoine
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.



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


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

Re: [libvirt-users] Regarding KVM-Qemu Migration code

2017-08-02 Thread Martin Kletzander

On Wed, Aug 02, 2017 at 02:48:17PM +0530, Aditya Bhardwaj wrote:

Respected Sir,
I need to modify kvm-qemu migration code. Please tell me where i can
find the code.



If I were in a bad mood, I would just send you this:

 http://lmgtfy.com/?s=d=qemu-kvm+repository

I never send these:

 http://lmgtfy.com/?s=d=1=qemu-kvm+repository

these are just mean and that doesn't align with who I am ;)

But since I'm not, I will explain it for you.  qemu-kvm is part of qemu
(it's not separate repo any more), it is not part of libvirt (mailing
list you are sending this mail to), but it has rather its own community
(even those these two overlap quite a bit) with mailing lists listed
here:

 https://wiki.qemu.org/index.php/MailingLists

They have their own web pages ( https://www.qemu.org/ ) where you can
get all the information ( clicking a "contribute" link will lead you to
https://www.qemu.org/contribute/ where you should find everything
necessary )

When you clone the repository, there will be a folder called "migration"
in which most of the code handling migration is (be sure to check
docs/devel/*migration.txt files as well).

I would also be wise to follow other links from the contribute page,
such as the Getting started for developers:

 https://wiki.qemu.org/index.php/Documentation/GettingStartedDevelopers

Contributor FAQ:

 https://wiki.qemu.org/index.php/Contribute/FAQ

and last, but not least, How to submit a patch:

 https://wiki.qemu.org/index.php/Contribute/SubmitAPatch


Good luck with your contributions and have a nice day,
Martin


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

Re: [libvirt-users] Understanding the contents of virsh dump --memory-only

2017-08-02 Thread Martin Kletzander

On Tue, Aug 01, 2017 at 10:22:43PM -0400, Arnabjyoti Kalita wrote:

Hello,

I was trying to understand the ELF file generated by the virsh dump
(--memory-only) command. I have successfully generated a dump of the VM
memory using this command.



You are running a QEMU machine and the dump is generated by qemu, so
they would be able to explain to much further detail, I'm sure.  Anyway,
here goes my try.


I specifically am trying to understand the loadable segments of this ELF
file.

I ran readelf -a  to get the information that I need. Below shows
the details of the loadable segments in a much better format :-

Loading ELF header #1. offset: 1320 filesize: 655360 memsize: 655360 vaddr:
0 paddr: 0 align: 0 flags: 0
Loading ELF header #2. offset: 656680 filesize: 65536 memsize: 65536 vaddr:
0 paddr: a align: 0 flags: 0
Loading ELF header #3. offset: 722216 filesize: 1072955392 memsize:
1072955392 vaddr: 0 paddr: c align: 0 flags: 0
Loading ELF header #4. offset: 1073677608 filesize: 67108864 memsize:
67108864 vaddr: 0 paddr: f400 align: 0 flags: 0
Loading ELF header #5. offset: 1140786472 filesize: 67108864 memsize:
67108864 vaddr: 0 paddr: f800 align: 0 flags: 0
Loading ELF header #6. offset: 1207895336 filesize: 8192 memsize: 8192
vaddr: 0 paddr: fc054000 align: 0 flags: 0
Loading ELF header #7. offset: 1207903528 filesize: 262144 memsize: 262144
vaddr: 0 paddr: fffc align: 0 flags: 0



Just to be clear, this is the memory of the machine with kernel and
several other things loaded.  I'm not sure what are all the segments,
but since the dump acts as something you can use to debug the guest OS
using the crash utility, which is somehow enhanced gdb for this purpose,
IIRC, then I guess it's the MMU mapping of everything in the guest OS.


I wanted to know why in this case, is the virtual address (denoted by
vaddr) 0 for each of the loadable segments ? Will it be okay if I load the
elf file taking the values of physical address (denoted by paddr) into
account ?



My guess is that those are the addresses from the MMU.  Each segment has
it's own vaddr <-> paddr mapping.


Specifically after loading the file, can I be certain that all of my
contents will have been loaded into memory address starting from 0 ? Will
the loaded contents be present in the exact location as specified (by
paddr) here ?



It depends on what you mean by loading.  You wouldn't be starting that
binary as any other program, it's rather a dump as you would have with a
coredump.  Physical address is probably just the location in the guest
machine, so the thing with paddr 0 would be seabios or something
BIOS-related, etc.

If you want precise answers and not guesses, I would suggest the qemu
mailing list or any other related list.  libvirt is not the best choice
here unless someone from the other communities replies here.

HTH,
Martin


Thanks and Regards.
Arnab



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


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

  1   2   3   4   >