[libvirt-users] [virtual interface] detach interface during boot succeed with no changes
by Yalan Zhang
Hi guys,
when I detach an interface from vm during boot (vm boot not finished), it
always fail. I'm not sure if there is an existing bug. I have
confirmed with someone that for disk, there is similar behavior, if
this is also acceptable?
# virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2; virsh
detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
dumpxml rhel7.2 |grep /interface -B9
Domain rhel7.2 destroyed
Domain rhel7.2 started
Interface detached successfully
<address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:98:c4:a0'/>
<source network='default' bridge='virbr0'/>
<target dev='vnet0'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
When I detach after the vm boot, expand the sleep time to 10, it will succeed.
# virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10; virsh
detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
dumpxml rhel7.2 |grep /interface -B9
Domain rhel7.2 destroyed
Domain rhel7.2 started
Interface detached successfully
-------
Best Regards,
Yalan Zhang
IRC: yalzhang
Internal phone: 8389413
2 years, 2 months
Set hostname of guest during installation time
by john doe
Hi,
I would like to set the hostname when installing a guest, with the below
command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
How can I set the hostname of the guest during installation time?
I realy appriciate the support I'm getting in here, I'm fairly new to
libvirt.
--
John Doe
4 years
Two questions about NVDIMM devices
by Milan Zamazal
Hi,
I've met two situations with NVDIMM support in libvirt where I'm not
sure all the parties (libvirt & I) do the things correctly.
The first problem is with memory alignment and size changes. In
addition to the size changes applied to NVDIMMs by QEMU, libvirt also
makes some NVDIMM size changes for better alignments, in
qemuDomainMemoryDeviceAlignSize. This can lead to the size being
rounded up, exceeding the size of the backing device and QEMU failing to
start the VM for that reason (I've experienced that actually). I work
with emulated NVDIMM devices, not a bare metal hardware, so one might
argue that in practice the device sizes should already be aligned, but
I'm not sure it must be always the case considering labels or whatever
else the user decides to set up. And I still don't feel very
comfortable that I have to count with two internal size adjustments
(libvirt & QEMU) to the `size' value I specify, with the ultimate goal
of getting the VM started and having the NVDIMM aligned properly to make
(non-NVDIMM) memory hot plug working. Is the size alignment performed
by libvirt, especially rounding up, completely correct for NVDIMMs?
The second problem is that a VM fails to start with a backing NVDIMM in
devdax mode due to SELinux preventing access to the /dev/dax* device (it
doesn't happen with any other NVDIMM modes). Who should be responsible
for handling the SELinux label appropriately in that case? libvirt, the
system administrator, anybody else? Using <seclabel> in NVDIMM's source
doesn't seem to be accepted by the domain XML schema.
Thanks,
Milan
4 years, 2 months
Problem with a RAW Disk and Xen
by Christoph
Hi All,
I have in config of 2 Xen DomU's this disk:
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/dev/mapper/keys'/>
<target dev='xvdz' bus='xen'/>
<readonly/>
</disk>
If I start the DomU's then all starts without problem, see this in log
of the DomU:
{
"pdev_path": "/dev/mapper/keys",
"vdev": "xvdz",
"backend": "qdisk",
"format": "raw",
"removable": 1,
"discard_enable": "False",
"colo_enable": "False",
"colo_restore_enable": "False"
}
but this disk isn't there in the domU... Why?
It is a shared disk between the DomU's but configured as "readonly" so
there shouldnt be a problem (with the same xen xl configuration, there
is no problem)
--
------
Greetz
4 years, 2 months
Meson build
by Toolybird
Hi,
Just a heads up on my experiences with the new build system.
Arch Linux
meson-0.55.1
Overall, it looks good, so well done!
Just a couple of minor things I noted:
1. Arch uses a meson wrapper script (arch-meson) that sets:
--buildtype plain
This seems to trigger a bug in meson that results in copious bogus compiler warnings:
cc1: warning: ‘-Wformat-y2k’ ignored without ‘-Wformat’ [-Wformat-y2k]
cc1: warning: ‘-Wformat-extra-args’ ignored without ‘-Wformat’ [-Wformat-extra-args]
cc1: warning: ‘-Wformat-zero-length’ ignored without ‘-Wformat’ [-Wformat-zero-length]
cc1: warning: ‘-Wformat-contains-nul’ ignored without ‘-Wformat’ [-Wformat-contains-nul]
cc1: warning: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Wformat-security]
which of course breaks -Werror builds.
I can easily work around it by setting `-D git_werror=disabled' or even better still:
CFLAGS+=" -Wall" arch-meson...
Maybe this github issue is related?:
https://github.com/mesonbuild/meson/issues/7399
2. Arch currently builds libvirt with support for ZFS. Seeing as ZFS is not in the distro proper, a simple Autoconf tweak is used:
ZFS=/usr/bin/zfs ZPOOL=/usr/bin/zpool \
./configure ...
This is surprisingly hard to emulate with meson, in fact it appears impossible, unless I resort to dodgy hacks with sed etc.
Cheers
4 years, 2 months
Re: plug pre-created tap devices to libvirt guests
by Marcus
> On Tue, Jun 30, 2020 at 04:02:05PM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 30, 2020 at 12:59:03PM +0200, Miguel Duarte de Mora Barroso wrote:
> > > On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump redhat com> wrote:
> > > >
> > > > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote:
> > > > > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote:
> > > > >> Hi all,
> > > > >>
> > > > >> I'm aware that it is possible to plug pre-created macvtap devices to
> > > > >> libvirt guests - tracked in RFE [0].
> > > > >>
> > > > >> My interpretation of the wording in [1] and [2] is that it is also
> > > > >> possible to plug pre-created tap devices into libvirt guests - that
> > > > >> would be a requirement to allow kubevirt to run with less capabilities
> > > > >> in the pods that encapsulate the VMs.
> > > > >>
> > > > >> I took a look at the libvirt code ([3] & [4]), and, from my limited
> > > > >> understanding, I got the impression that plugging existing interfaces
> > > > >> via `managed='no' ` is only possible for macvtap interfaces.
> > > >
> > > >
> > > > No, it works for standard tap devices as well.
> > > >
> > > >
> > > > The reason the BZs and commit logs talk mostly about macvtap rather than
> > > > tap is because 1) that's what kubevirt people had asked for and 2) it
> > > > already *mostly* worked for tap devices, so most of the work was related
> > > > to macvtap (my memory is already fuzzy, but I think there were a couple
> > > > privileged operations we still tried to do for standard tap devices even
> > > > if they were precreated (standard disclaimer: I often misremember, so
> > > > this memory could be wrong! But definitely precreated tap devices do work).
> > > >
> > >
> > > It's been a while since I've started this thread, but lately I've
> > > understood better how tap devices work, and that new insight makes me
> > > wonder about a couple of things.
> > >
> > > Our ultimate goal In kubevirt is to consume a pre-created tap device
> > > by a kubernetes pod that doesn't have the NET_ADMIN capability.
> > >
> > > After looking at the current libvirt code, I don't think that is
> > > currently supported, since we'll *always* enter the
> > > `virNetDevTapCreate` function in [1] (I'm interested in the *tap*
> > > scenario).
> > >
> > > The tap device is effectively created in that function - [2] - by
> > > opening the clone device (/dev/net/tun), and calling `ioctl(fd,
> > > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the
> > > NET_ADMIN capability. If I'm correct, this means that the current
> > > libvirt implementation makes our goals impossible to achieve.
> >
> > AFAIK, that is not correct - CAP_NET_ADMIN isn't required to open
> > or create a tap device - only to add the tap device to a bridge.
> >
> > So if you create the tap device & attach it to a bridge ahead of
> > time, libvirt should then be able to open it and give it to QEMU
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/d...
>
> ((uid_valid(tun->owner) && !uid_eq(cred->euid, tun->owner)) ||
> (gid_valid(tun->group) && !in_egroup_p(tun->group))) &&
> !ns_capable(net->user_ns, CAP_NET_ADMIN);
>
>
> This is called by the TUNSETIFF code.
>
> AFAICT, that means if you fchown(tapfd, uid, gid), to the uid+gid of
> libvirtd, it should not require CAP_NET_ADMIN.
>
> Regards,
> Daniel
I have no idea if this message will get linked into the thread properly, but
I came across this and wanted to comment on the mystery without having an actual
email to reply to or headers.
I recently ran into this issue as well, and found that even *with* NET_ADMIN at
the container level, trying to launch Qemu directly results in:
qemu-system-x86_64: -netdev tap,id=hostnet0,ifname=tap0: could not
configure /dev/net/tun (tap0): Permission denied
So as a note I'd say even Libvirt aside, Qemu is trying to do this as well:
https://github.com/qemu/qemu/blob/0982a56a551556c704dc15752dabf57b4be1c64...
But it's unclear where the EPERM is coming from in the kernel at tun_set_iff().
Of note, if I give Qemu a non-existing tap name, it will create it,
but if I give
it an existing tap name, I get EPERM.
4 years, 2 months
