11:04 a.m.
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:
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?
Here is how we register a VM:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452...
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?
Here is how we handled this:
* The code for register:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452...
* The configuration file that we adopted as a default:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c164824...
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?
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
6:36 a.m.
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-70617d452...
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 <interface type='bridge'/> or just use <interface
type='direct'/>. 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-70617d452...
* The configuration file that we adopted as a default:
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c164824...
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
10:07 a.m.
Hi,
First of all, thanks for your feedback :)
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::2222-: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?
> Here is how we register a VM:
>
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-70617d452...
>
> 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 <interface type='bridge'/> or just use <interface
type='direct'/>. 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::2222-:22,smb=/home/USER /home/USER/p/DISK.qcow2
For our network configuration, we have:
<network>
<name>kworkflow-network</name>
<uuid>7d167334-7e36-475b-a0ae-9889b87848d7</uuid>
<forward mode='nat'/>
<bridge name='virbr-kworkflow' stp='on' delay='0'/>
<mac address='52:54:00:8a:da:00'/>
<ip address='10.0.1.1' netmask='255.255.255.0'>
<dhcp>
<range start='10.0.1.2' end='10.0.1.2'/>
<host mac='52:54:00:21:23:52' name='kworflow-vm'
ip='10.0.1.2'/>
</dhcp>
</ip>
</network>
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?
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-70617d452...
> * The configuration file that we adopted as a default:
>
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c164824...
>
> 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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
--
Rodrigo Siqueira
https://siqueira.tech
https://twitter.com/siqueirajordao
Graduate Student
Department of Computer Science
University of São Paulo
3:15 a.m.
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::2222-: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-70617d452...
> >
> > 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 <interface type='bridge'/> or just use <interface
type='direct'/>. 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::2222-:22,smb=/home/USER /home/USER/p/DISK.qcow2
For our network configuration, we have:
<network>
<name>kworkflow-network</name>
<uuid>7d167334-7e36-475b-a0ae-9889b87848d7</uuid>
<forward mode='nat'/>
<bridge name='virbr-kworkflow' stp='on' delay='0'/>
<mac address='52:54:00:8a:da:00'/>
<ip address='10.0.1.1' netmask='255.255.255.0'>
<dhcp>
<range start='10.0.1.2' end='10.0.1.2'/>
<host mac='52:54:00:21:23:52' name='kworflow-vm'
ip='10.0.1.2'/>
</dhcp>
</ip>
</network>
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 <filesystem/> 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-70617d452...
> > * The configuration file that we adopted as a default:
> >
https://github.com/rodrigosiqueira/kworkflow/pull/23/files#diff-d8c164824...
> >
> > 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(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/libvirt-users
>
--
Rodrigo Siqueira
https://siqueira.tech
https://twitter.com/siqueirajordao
Graduate Student
Department of Computer Science
University of São Paulo
2089
days inactive
2123
days old
3 comments
2 participants
participants (2)
-
Martin Kletzander -
Rodrigo Siqueira