This only happens on Fedora, on ubuntu it works fine.
I have a VM contain a symlink point to actual image. When I start the vm, it error out due to permission denied:
error: internal error: process exited while connecting to monitor: 2020-10-15T19:24:24.359891Z qemu-system-x86_64: -drive file=/some-local-pool/VM01.current,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe,discard=unmap,aio=threads: Could not open '/some-local-pool/VM01.current': Permission denied
But the permission is fine:
lrwxrwxrwx. 1 root root 32 Oct 15 20:37 VM01.current -> VM01.deployed
-rw-rw-r--. 1 root root 20G Oct 15 21:01 VM01.deployed
unconfined_u:object_r:unlabeled_t:s0 VM01.current
system_u:object_r:default_t:s0 VM01.deployed
Directly use the actual image path works. qemu-img info on the symlink works too. Any idea why this won't work?
it is the selinux context problem. Somehow, the VM01.deployed get wrong type of default_t if start the VM with it. We need to change it to virt_content_t, if we want the symlink as image path.
Moreover, the label of symlink itself need to match the target.
# chcon --reference=VM01.deployed VM01.current
Then it is going to work.
It is still not clear why use the VM01.deployed as image path can still work if type label is default_t.
So far if we use libvirt and qemu tools to create new qcow2 disk or snapshots. The labels can be many things: default_t, virt_image_t, virt_content_t ... no idea why cannot they all agree on one type. This is really confusing.
When libvirt runs QEMU, it is given a unique SELinux label that is specific to that VM instance. In order for this to work, libvirt has to set the SELinux label on every disk image that QEMU is intended to access prior to QEMU being started. The label that libvirt sets will apply to the real disk image (VM01.deployed), but not the symlink (VM01.current) which you need to set to virt_image_t/virt_content_t.
Related
I have tried to connect my Jetson Nano with TTL UART cable using minicom. When I typed
sudo minicom
It showed an error
minicom throwing an error minicom: cannot open /dev/modem: No such file or directory
Later I tried with
sudo minicom -s
It worked
sudo is always a way...
What minicom tells you with this message that it has tried to open a interface called /dev/modem. It is telling you, that it can't be opened due to insufficient permissions.
On my system /dev/modem does not even exist! Anyhow, minicom expects in it's settings the /dev/modem as default. That's why it's trying to connect to that.
So, the solution is minicom -s, where you actually enter the settings of minicom. Her you'll find the the settings to properly configure your board. If you run this with sudo, you are able to also save your settings, if you want to. You might want to change those settings to e.g. /dev/ttyUSB0 or something.
I am getting the below given error when I try to forward certain log files using syslog-ng in Suse Linux
Starting syslog servicesError opening file for reading; filename='/tmp/app.log', error='Permission denied (13)'
my conf file - Source definition seems to be ok
source app {
file("/tmp/app.log");
};
I went through similar posts and dont see any problems with my steps.The weird part is that the file is owned by root and when i run syslog-ng as root it gives read permission error
Am I missing anything?
This problem is caused because of AppArmor linux security module. Solution to this problem is mentioned in attached thread. syslog-ng read file permission denied
Here are steps I followed.
Open /etc/apparmor.d/sbin.syslong-ng
Add /opt/xxx/logs/* rw, line anywhere. rw below means allow read & write access. Change your directory appropriately.
Run apparmor_parser -r /etc/apparmor.d/sbin.syslong-ng to set new rules.
Restart syslog-ng using service command or any other way you have set up.
I'm using apparmor as hardening layer for libvirt-qemu , everything is OK , but there is one thing that I can't solve systematically, let me explain :
When create a new qemu instance , profile is generated from /etc/apparmor.d/libvirt/TEMPLATE.qemu to a file with path /etc/apparmor.d/libvirt/libvirt-81303229-df4c-4b18-b33b-277bcda81b0f for example .
When instance is shut-off profile is unloaded from kernel by apparmor and it is OK as expected. But if i remove the instance definitively, i would expect that profile is removed also from filesystem, but it is not and still present in filesystem. After some time I have very big mess in libvirt instance profile files
Yes .. I can write a cron job what will be delete unnecessary libvirt profile files ... but ..is there some more clear solution , maybe builtin function of apparmor ?
Thanks
Are you using libvirt undefine to delete the stopped guest? It appears that virt-aa-helper should delete an undefined domain but I think it is a bug and you should file a ticket.
You can use the virt-aa-helper command directly to remove the files which is probably the safest as it should deal with the dependencies for you.
An example command is:
$ sudo /usr/lib/libvirt/virt-aa-helper -D -u libvirt-3c3d5aa2-f581-457d-b5ab-efbf9fdd4a6e
But it may be some edge case that they need to account for, where you can undefine a running instance to convert it to ephemeral. You would need to take care of that edge case.
Note: Because virt-aa-helper is intended to be run by libvirt you will have to use sudo with the command. If you do not it will silently fail and not remove the profile.
I try to install qemu, but I should intall the kvm first, and I have checked my cpu supporting the visualization, so I don't know why. Here is the error, when I input kvm.
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support
And a new window for qemu comes out, but there are
boot failed....could not read the boot disk, could not read from CDROM(code 0003)
What can I do. I searched the methods for a long time. Thanks!
when I use mobprobe, the problem is here, (I checked my CPU, it supports VMX.)
FATAL: Error inserting kvm_intel (/lib/modules/2.6.38-8-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not supported
When I use:~$ kvm -cdrom img.iso -hda disk.img -boot d
open /dev/kvm: No such file or directory Could not initialize KVM, will disable KVM support kvm: -cdrom img.iso: could not open disk image img.iso: No such file or directory
I don't know why..... Thanks!
The "could not open disk image img.iso" problem is the easier of the two errors: that file does not exist. That argument means "mount the disk image in the file img.iso as the CD-ROM"; that file must exist (and should be a valid ISO). Try downloading a ISO of any Linux flavor, for example.
disk.img must also exist (that argument means "use the disk image contained in the file disk.img as the hard disk"). You can create it using dd, e.g.:
dd if=/dev/zero of=images/disk.img bs=512M count=20
That will create a 10GB disk image in a file called disk.img. Adjust the block size and # of blocks (bs and count) to increase or decrease the size; bs cannot be larger than available memory.
For the second problem, Could not initialize KVM, will disable KVM, there are a number of possible causes:
disabled in BIOS
you are not running as root (i.e. using sudo) and your user cannot access /dev/kvm
the machine you are on is already virtualized (e.g. you are using Amazon EC2). These CPUs may have the VMX flag (because they are paravirtualized) but cannot be virtualized (because the hypervisor won't allow it.)
Note that this is NOT a fatal error; qemu can run without KVM support, it just runs in emulation mode and is quite slow.
The first problem will probably produce some output, examine the output of dmesg (dmesg | grep kvm). It can be solved by enabling it in BIOS.
The second problem can be diagnosed easily by running the commands as root instead of as a user. If that works, you have identified the problem.
The third problem is more difficult to resolve. XEN-blanket may help.
Pasting the output of "sudo kvm-ok" might be allow someone to offer more insight.
The instructions given in here would be translatable to other platforms:
https://help.ubuntu.com/community/KVM/Installation
If you provide more information about the machines you are using and your desired goals, we can be more helpful.
Did you check your BIOS-Settings? Some BIOS let you choose wether you want to activate VT / VMX or not.
Furthermore, I've found following, pretty similiar thread:
http://ubuntuforums.org/archive/index.php/t-755122.html
Hope this helps
Your problem is your system does not have KVM modules inserted. Please check your BIOS setting regarding VT is enabled, and also your KVM module matches your specific Linux distribution. An unmatched version of KVM module and Linux cannot be inserted.
Check the VM xml CD-ROM is set as 'file' not 'block'.
try to load kvm-intel or kvm-amd kernel modules, then take a look at dmesg, if loaded successfully you should be good to go
I'm trying make a copy of a MySQL database on another server. I stop the server, tar up the mysql directory, copy it to the other server and untar it. I set all the permissions to match to the working server, and copied the my.cnf file so everything is the same except for server specific changes.
However, when I try to startup the server, I get the following InnoDB error:
InnoDB: Operating system error number 13 in a file operation.
This error means mysql does not have the access rights to
the directory.
File name /var/lib/mysql/ibdata1
File operation call: 'open'.
The owner/group for all the files is mysql. I even tried changing permissions to a+rw. I can su to the mysql user and access the ibdata1 file using head.
SOLUTION:
The problem was selinux was enabled and preventing the new files from being accessed.
A silly question, but people forget: you said you checked that all files have the same permissions; still, even though it said so in the message, might you possibly have forgotten to check the permissions on the containing directory?
UPDATE: Two more suggestions:
You might try inserting --console and --log-warnings flags, for lots of debugging output, something like this (on my Mac):
/usr/libexec/mysqld --console --log-warnings --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock
If all else fails, you can probably try strace mysqld ... to see what exactly is it failing. The error will be somewhere at the bottom.
UPDATE2: Interesting indeed... I can't see what your OS is. I normally don't use /sbin/service, it's a bit mysterious for me; on a Mac, it's deprecated in favour of launchctl with config file in /System/Library/LaunchDaemons/mysqld.plist, and on most Linux boxes you have /etc/init.d/mysqld. So you could insert strace there.
Or (untested, but manpage suggests it's possible) you could try stracing the service call:
strace -ff -o straces /sbin/service start mysqld
This should produce files straces.pid, one of which should be mysqld's, and hopefully you'll find your error there.
This isn't a direct answer to your question, but I would recommend trying one of these programs for your backup / restore needs.
Percona Xtrabackup: https://launchpad.net/percona-xtrabackup
Mydumper: http://www.mydumper.org/
Both are great tools, are free and open source, and will help you avoid that problem entirely.
Hope that helps.