Re: [Qemu-discuss] changing from net to netdev with vde switches and double nics

[Paolo]

> On Wed, 30 Aug 2017 08:03:31 +0200
> Thomas Huth wrote:

> >  NET0="-net vde,vlan=0,sock=/var/run/vde.ctl00 -net 
> > nic,vlan=0,model=rtl8139,macaddr=$NIC0MAC"
> >  NET1="-net vde,vlan=1,sock=/var/run/vde.ctl01 -net 
> > nic,vlan=1,model=rtl8139,macaddr=$NIC1MAC"
> > 
> > Now I guess this is impossbile to achieve with netdev?
> > How may I tell to qemu that the guest's NIC0 has to be wired to the vde 
> > switch vde.ctl00 run on host has, and NIC1 to vde.ctl01?  
> 
> It should be doable. Could you please try something like this:
> 
>  NET0="-netdev vde,id=v0,sock=/var/run/vde.ctl00 -device 
> rtl8139,netdev=v0,mac=$NIC0MAC"
>  NET1="-netdev vde,id=v1,sock=/var/run/vde.ctl01 -device 
> rtl8139,netdev=v1,mac=$NIC1MAC"
> 
> I haven't tested it though, so you still might have to tweak it. Run qemu
> with "-device rtl8139,?" to see the options of the rtl8139 device.

Just tested. Those lines work very well. Here are mines (I've a group kvm):

NET0="-netdev vde,id=v0,sock=/var/run/vde.ctl00,group=kvm,mode=0770 -device 
rtl8139,netdev=v0,mac=$NIC0MAC"
NET1="-netdev vde,id=v1,sock=/var/run/vde.ctl01,group=kvm,mode=0770 -device 
rtl8139,netdev=v1,mac=$NIC1MAC"

Can't understand why the guest OS (windows 7) reinstalls the network cards 
(nothing should have changed from it's point of view), but it's ok.
All I needed to keep the list of NICs short and minimal, was to disable and 
uninstall the two network cards inside the windows environment before the 
migration from the -net to -netdev syntax, and, of course to reassign the 
IP/subnet mask/etc after the next boot.

Thank you

Paul

Re: [Qemu-discuss] Accessing a shared folder

[Greg Kurz]

On Wed, 30 Aug 2017 14:35:00 + (UTC)
Mahmood  wrote:

> OK. I reconfigured 2.9.0 with --enable-virtfs. Please note:
> 1- If I use -virtfs option, I get 
>  qemu-option.c:547: opt_set: Assertion `opt->str' failed
> 

If you use the local fsdriver, security_model is mandatory with -virtfs just
like it is with -fsdev.

> 2- If I use -fsdev and -device, then I *must* use security_model
> 

True, as indicated in the QEMU manpage:

"Security model is mandatory only for local fsdriver.
 Other fsdrivers (like handle, proxy) don't take security model
 as a parameter."

> 3- If I use -fsdev and -device and security_model, then the guest boots 
> normally.
> 
> I haven't tried to see if I am able to access the shared folder nor not. Do 
> you have any note on the above items?
> 
> 
> Regards,
> Mahmood
> 

Cheers,

--
Greg


pgpmWs5FAycBz.pgp
Description: OpenPGP digital signature

Re: [Qemu-discuss] Accessing a shared folder

[Mahmood]

OK. I reconfigured 2.9.0 with --enable-virtfs. Please note:
1- If I use -virtfs option, I get 
 qemu-option.c:547: opt_set: Assertion `opt->str' failed

2- If I use -fsdev and -device, then I *must* use security_model

3- If I use -fsdev and -device and security_model, then the guest boots 
normally.

I haven't tried to see if I am able to access the shared folder nor not. Do you 
have any note on the above items?


Regards,
Mahmood

[Qemu-discuss] Qemu overhead of VxWorks?

[Dong-In Kang]

Hi,

Has anyone measured how much overhead (extra latencies in interrupt, etc.) will 
be added when we run Vxwork in Qemu?
I’ll appreciate any help.

David

Re: [Qemu-discuss] Accessing a shared folder

[Thomas Huth]

On 30.08.2017 12:11, Greg Kurz wrote:
[...]
> Hi,
> 
> Both -virtfs and -fsdev/-device syntaxes work for me with the current QEMU
> master branch :) Where's your qemu-system-x86_64 binary coming from ?

There is at least one problem with -virtfs if you forget to specify
the "security_model=xxx" option:

$ x86_64-softmmu/qemu-system-x86_64 -virtfs 
local,id=shared,path=/tmp,mount_tag=tag
qemu-system-x86_64: util/qemu-option.c:547: opt_set: Assertion `opt->str' 
failed.
Aborted (core dumped)

According to the qemu-doc, the securit_model is optional, so it
should be possible to run qemu without it, too, shouldn't it?

 Thomas

Re: [Qemu-discuss] Accessing a shared folder

[Greg Kurz]

On Wed, 30 Aug 2017 12:17:22 +0200
Thomas Huth  wrote:

> On 30.08.2017 12:11, Greg Kurz wrote:
> [...]
> > Hi,
> > 
> > Both -virtfs and -fsdev/-device syntaxes work for me with the current QEMU
> > master branch :) Where's your qemu-system-x86_64 binary coming from ?  
> 
> There is at least one problem with -virtfs if you forget to specify
> the "security_model=xxx" option:
> 
> $ x86_64-softmmu/qemu-system-x86_64 -virtfs 
> local,id=shared,path=/tmp,mount_tag=tag
> qemu-system-x86_64: util/qemu-option.c:547: opt_set: Assertion `opt->str' 
> failed.
> Aborted (core dumped)
> 

Yeah, we should print out that security_model is missing instead of dumping
core... :-\

> According to the qemu-doc, the securit_model is optional, so it
> should be possible to run qemu without it, too, shouldn't it?
> 

Hmm... the documentation is a bit misleading. We indeed have:

-virtfs fsdriver[,path=path],mount_tag=mount_tag[,security_model=security_model]
[,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd]

but the description of security_model says: 

Security model is mandatory only for local fsdriver. Other fsdrivers (like
handle, proxy) don't take security model as a parameter.

The same goes for the proxy fsdriver which needs socket or sock_fd, and doesn't 
use
path.

Should we have a -virtfs line for each fsdriver ?

>  Thomas



pgpINdAGRev_A.pgp
Description: OpenPGP digital signature

Re: [Qemu-discuss] Accessing a shared folder

[Peter Maydell]

On 30 August 2017 at 12:38, Mahmood  wrote:
> Hello again,I installed 2.5.0 quickly and it was pretty straight forward!
>
> Here is the error message I get regarding the 'virtio-9p-pci'
> 'virtio-9p-pci' is not a valid device model name

Are you building your own QEMU binary or is it from somewhere
else? I wonder if it was built without support for the 9p
filesystem code. For this to be enabled:
 * host machine must be Linux
 * system building QEMU must have libcap development package installed

If you're building it yourself then you can pass configure
'--enable-virtfs' which will mean configure will stop with
an error if it can't enable virtfs rather than just disabling
this optional feature.

QEMU ought to produce a helpful error if you try to use -virtfs
when virtfs wasn't compiled in, but it may be that this check
was broken accidentally at some point.

Also, 2.5.0 is a couple of years old, you might try with 2.9.0
(or even with the 2.10.0 we're about to release today).

thanks
-- PMM

Re: [Qemu-discuss] Accessing a shared folder

[Mahmood]

Hello again,I installed 2.5.0 quickly and it was pretty straight forward!

Here is the error message I get regarding the 'virtio-9p-pci'



mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -virtfs 
local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
qemu-system-x86_64: -virtfs 
local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads: 
'virtio-9p-pci' is not a valid device model name
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -fsdev 
local,id=shared,path=/home/mahmood/Downloads -device 
virtio-9p-pci,fsdev=shared,mount_tag=Downloads
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
warning: host doesn't support requested feature: 
CPUID.4001H:EAX.kvm_asyncpf [bit 4]
qemu-system-x86_64: -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads: 
'virtio-9p-pci' is not a valid device model name
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -version
QEMU emulator version 2.5.0, Copyright (c) 2003-2008 Fabrice Bellard






I appreciate if you help. Thanks.


Regards,
Mahmood

Re: [Qemu-discuss] Accessing a shared folder

[Mahmood]

The security_model=none also doesn't work and get the same error.

mahmood@cluster:qemu-vm$ qemu-system-x86_64 -version
QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard


I know it is old but I think I installed this version three years ago due to 
the Rocks-6 version old libraries (which is based on Centos-6). I will try some 
newer versions to find which version is better.


One more question. How can I uninstall the qemu which is built from source? 
"make uninstall" in the source folder doesn't work.


Sorry for taking up your time.


Regards,
Mahmood

Re: [Qemu-discuss] Accessing a shared folder

[Greg Kurz]

On Wed, 30 Aug 2017 09:28:57 + (UTC)
Mahmood  wrote:

> >Could you please try to replace the -virtfs option with these two options:
> >
>  >-fsdev local,id=shared,path=/home/mahmood/Downloads \
>  >-device virtio-9p-pci,fsdev=shared,mount_tag=Downloads  
> 
> 
> 
> 
> Still get the same error!
> 
> mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 
> -hda centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
> e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -fsdev 
> local,id=shared,path=/home/mahmood/Downloads -device 
> virtio-9p-pci,fsdev=shared,mount_tag=Downloads
> qemu-system-x86_64: -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads: 
> Parameter 'driver' expects device type
> mahmood@cluster:qemu-vm$
> 

Hi,

Both -virtfs and -fsdev/-device syntaxes work for me with the current QEMU
master branch :) Where's your qemu-system-x86_64 binary coming from ?

Cheers,

--
Greg

PS: I'm on vacation. I'll be fully available next week.


> 
> 
> 
> Regards,
> Mahmood
> 



pgp39C1IpyH5l.pgp
Description: OpenPGP digital signature

Re: [Qemu-discuss] Live VM backup

[Vincenzo Romano]

2017-08-30 11:58 GMT+02:00 Fam Zheng :
> On Wed, 08/30 11:45, Vincenzo Romano wrote:
>> 2017-08-30 11:40 GMT+02:00 Fam Zheng :
>> > On Wed, 08/30 11:16, Vincenzo Romano wrote:
>> >> 2017-08-30 10:53 GMT+02:00 Fam Zheng :
>> >> > On Wed, 08/30 08:17, Vincenzo Romano wrote:
>> >> >> Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:
>> >> >>
>> >> >> On Tue, 08/29 18:32, Vincenzo Romano wrote:
>> >> >> > I'd like to move away from "another virtualization solution" to QEmu.
>> >> >> > I've more or less all the needed bits in my hands in order to define,
>> >> >> > run and manage QEmu VMs.
>> >> >> > What I am missing is the knowledge of how to backup a live VM.
>> >> >> > Of course, if I shutdown the VM, I can simply copy its files and the
>> >> >> > startup script on another QEmu host.
>> >> >> > But my main objective is to do the backup while the VM is running.
>> >> >> > I think I could use the snapshot feature, but have no idea on how to
>> >> >> proceed.
>> >> >> > Any hint?
>> >> >>
>> >> >> In short, just do what libvirt would do: use QMP and send 
>> >> >> 'drive-backup'
>> >> >> command.
>> >> >>
>> >> >> This is a very good howto:
>> >> >>
>> >> >> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
>> >> >> lock-operations.rst
>> >> >>
>> >> >> Fam
>> >> >>
>> >> >>
>> >> >> Thanks.
>> >> >> I presume there's a 'drive-restore', though I need to look better in 
>> >> >> the
>> >> >> docs.
>> >> >>
>> >> >> Is there any side effect in case the CPU where the VM will be restored 
>> >> >> is
>> >> >> not exactly the same as the one where the VM got backed up?
>> >> >
>> >> > No, there isn't a 'drive-restore'. 'drive-backup' only takes care of 
>> >> > the disks,
>> >> > so the CPU, ram and device states aren't saved.
>> >> >
>> >> > If you boot from the backup image, CPU and ram are restarted from 
>> >> > powered off
>> >> > state, so what happens is effectively like a power loss at the point of
>> >> > 'drive-backup': anything not saved to disk are lost.
>> >> >
>> >> > Fam
>> >>
>> >> I understand.
>> >>
>> >> So, if I haven't miunderstood, at the moment QEmu-KVM doesn't
>> >> implement  "VM snapshots".
>> >
>> > It does. There are "savevm" and "migrate" (or "migrate -b") that can save 
>> > the
>> > CPU/ram etc:
>> >
>> > https://www.linux-kvm.org/page/Migration#savevm.2Floadvm_to_an_external_state_file_.28using_pseudo-migration.29
>> >
>> > Fam
>>
>> Thanks again, Fam.
>>
>> So I should issue both QMP commands, in theory, with the VM in a
>> frozen state. Right?
>
> I think with "savevm", your VM is automatically paused when the command is 
> being
> handled. The "migrate -b 'exec: ...'" way is an alternative and doesn't need 
> the
> VM to stop, which should be better.
>
> Fam

Thanks.
What if the two hosts have "slightly different" CPU capabilities?
I have a main host with a  "Xeon E5-2620 v3" while the backup one is a
"Xeon E5-2407".
Apart of the performances, the former is lacking some instruction set
extensions:
SSE2, MMX, SSE3, SSE, SSE4.1, SSE4.2, Supplemental SSE3 and AES
despite being much newer than the latter which "only" lacks AVX 2.0.

In this case the current virtualization technology is showing its deficiencies.
For a number of reasons I am also testing this type of "corner cases",
when a backup cannot be restored on exactly the same hardware it comes
from.

-- 
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS

Re: [Qemu-discuss] Accessing a shared folder

[Thomas Huth]

On 30.08.2017 11:28, Mahmood wrote:
>> Could you please try to replace the -virtfs option with these two options:
>>
>  >-fsdev local,id=shared,path=/home/mahmood/Downloads \
>  >-device virtio-9p-pci,fsdev=shared,mount_tag=Downloads
> 
> Still get the same error!
> 
> mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 
> -hda centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
> e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -fsdev 
> local,id=shared,path=/home/mahmood/Downloads -device 
> virtio-9p-pci,fsdev=shared,mount_tag=Downloads
> qemu-system-x86_64: -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads: 
> Parameter 'driver' expects device type
> mahmood@cluster:qemu-vm$

Hmmm, I forgot to ask: Which version of QEMU are you using? I think this
should work with the latest version, you just might need to add
"security_model=none" to the -fsdev option there.

 Thomas

Re: [Qemu-discuss] Live VM backup

[Fam Zheng]

On Wed, 08/30 11:45, Vincenzo Romano wrote:
> 2017-08-30 11:40 GMT+02:00 Fam Zheng :
> > On Wed, 08/30 11:16, Vincenzo Romano wrote:
> >> 2017-08-30 10:53 GMT+02:00 Fam Zheng :
> >> > On Wed, 08/30 08:17, Vincenzo Romano wrote:
> >> >> Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:
> >> >>
> >> >> On Tue, 08/29 18:32, Vincenzo Romano wrote:
> >> >> > I'd like to move away from "another virtualization solution" to QEmu.
> >> >> > I've more or less all the needed bits in my hands in order to define,
> >> >> > run and manage QEmu VMs.
> >> >> > What I am missing is the knowledge of how to backup a live VM.
> >> >> > Of course, if I shutdown the VM, I can simply copy its files and the
> >> >> > startup script on another QEmu host.
> >> >> > But my main objective is to do the backup while the VM is running.
> >> >> > I think I could use the snapshot feature, but have no idea on how to
> >> >> proceed.
> >> >> > Any hint?
> >> >>
> >> >> In short, just do what libvirt would do: use QMP and send 'drive-backup'
> >> >> command.
> >> >>
> >> >> This is a very good howto:
> >> >>
> >> >> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
> >> >> lock-operations.rst
> >> >>
> >> >> Fam
> >> >>
> >> >>
> >> >> Thanks.
> >> >> I presume there's a 'drive-restore', though I need to look better in the
> >> >> docs.
> >> >>
> >> >> Is there any side effect in case the CPU where the VM will be restored 
> >> >> is
> >> >> not exactly the same as the one where the VM got backed up?
> >> >
> >> > No, there isn't a 'drive-restore'. 'drive-backup' only takes care of the 
> >> > disks,
> >> > so the CPU, ram and device states aren't saved.
> >> >
> >> > If you boot from the backup image, CPU and ram are restarted from 
> >> > powered off
> >> > state, so what happens is effectively like a power loss at the point of
> >> > 'drive-backup': anything not saved to disk are lost.
> >> >
> >> > Fam
> >>
> >> I understand.
> >>
> >> So, if I haven't miunderstood, at the moment QEmu-KVM doesn't
> >> implement  "VM snapshots".
> >
> > It does. There are "savevm" and "migrate" (or "migrate -b") that can save 
> > the
> > CPU/ram etc:
> >
> > https://www.linux-kvm.org/page/Migration#savevm.2Floadvm_to_an_external_state_file_.28using_pseudo-migration.29
> >
> > Fam
> 
> Thanks again, Fam.
> 
> So I should issue both QMP commands, in theory, with the VM in a
> frozen state. Right?

I think with "savevm", your VM is automatically paused when the command is being
handled. The "migrate -b 'exec: ...'" way is an alternative and doesn't need the
VM to stop, which should be better.

Fam

Re: [Qemu-discuss] Live VM backup

[Vincenzo Romano]

2017-08-30 11:40 GMT+02:00 Fam Zheng :
> On Wed, 08/30 11:16, Vincenzo Romano wrote:
>> 2017-08-30 10:53 GMT+02:00 Fam Zheng :
>> > On Wed, 08/30 08:17, Vincenzo Romano wrote:
>> >> Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:
>> >>
>> >> On Tue, 08/29 18:32, Vincenzo Romano wrote:
>> >> > I'd like to move away from "another virtualization solution" to QEmu.
>> >> > I've more or less all the needed bits in my hands in order to define,
>> >> > run and manage QEmu VMs.
>> >> > What I am missing is the knowledge of how to backup a live VM.
>> >> > Of course, if I shutdown the VM, I can simply copy its files and the
>> >> > startup script on another QEmu host.
>> >> > But my main objective is to do the backup while the VM is running.
>> >> > I think I could use the snapshot feature, but have no idea on how to
>> >> proceed.
>> >> > Any hint?
>> >>
>> >> In short, just do what libvirt would do: use QMP and send 'drive-backup'
>> >> command.
>> >>
>> >> This is a very good howto:
>> >>
>> >> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
>> >> lock-operations.rst
>> >>
>> >> Fam
>> >>
>> >>
>> >> Thanks.
>> >> I presume there's a 'drive-restore', though I need to look better in the
>> >> docs.
>> >>
>> >> Is there any side effect in case the CPU where the VM will be restored is
>> >> not exactly the same as the one where the VM got backed up?
>> >
>> > No, there isn't a 'drive-restore'. 'drive-backup' only takes care of the 
>> > disks,
>> > so the CPU, ram and device states aren't saved.
>> >
>> > If you boot from the backup image, CPU and ram are restarted from powered 
>> > off
>> > state, so what happens is effectively like a power loss at the point of
>> > 'drive-backup': anything not saved to disk are lost.
>> >
>> > Fam
>>
>> I understand.
>>
>> So, if I haven't miunderstood, at the moment QEmu-KVM doesn't
>> implement  "VM snapshots".
>
> It does. There are "savevm" and "migrate" (or "migrate -b") that can save the
> CPU/ram etc:
>
> https://www.linux-kvm.org/page/Migration#savevm.2Floadvm_to_an_external_state_file_.28using_pseudo-migration.29
>
> Fam

Thanks again, Fam.

So I should issue both QMP commands, in theory, with the VM in a
frozen state. Right?

-- 
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS

Re: [Qemu-discuss] Live VM backup

[Fam Zheng]

On Wed, 08/30 11:16, Vincenzo Romano wrote:
> 2017-08-30 10:53 GMT+02:00 Fam Zheng :
> > On Wed, 08/30 08:17, Vincenzo Romano wrote:
> >> Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:
> >>
> >> On Tue, 08/29 18:32, Vincenzo Romano wrote:
> >> > I'd like to move away from "another virtualization solution" to QEmu.
> >> > I've more or less all the needed bits in my hands in order to define,
> >> > run and manage QEmu VMs.
> >> > What I am missing is the knowledge of how to backup a live VM.
> >> > Of course, if I shutdown the VM, I can simply copy its files and the
> >> > startup script on another QEmu host.
> >> > But my main objective is to do the backup while the VM is running.
> >> > I think I could use the snapshot feature, but have no idea on how to
> >> proceed.
> >> > Any hint?
> >>
> >> In short, just do what libvirt would do: use QMP and send 'drive-backup'
> >> command.
> >>
> >> This is a very good howto:
> >>
> >> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
> >> lock-operations.rst
> >>
> >> Fam
> >>
> >>
> >> Thanks.
> >> I presume there's a 'drive-restore', though I need to look better in the
> >> docs.
> >>
> >> Is there any side effect in case the CPU where the VM will be restored is
> >> not exactly the same as the one where the VM got backed up?
> >
> > No, there isn't a 'drive-restore'. 'drive-backup' only takes care of the 
> > disks,
> > so the CPU, ram and device states aren't saved.
> >
> > If you boot from the backup image, CPU and ram are restarted from powered 
> > off
> > state, so what happens is effectively like a power loss at the point of
> > 'drive-backup': anything not saved to disk are lost.
> >
> > Fam
> 
> I understand.
> 
> So, if I haven't miunderstood, at the moment QEmu-KVM doesn't
> implement  "VM snapshots".

It does. There are "savevm" and "migrate" (or "migrate -b") that can save the
CPU/ram etc:

https://www.linux-kvm.org/page/Migration#savevm.2Floadvm_to_an_external_state_file_.28using_pseudo-migration.29

Fam

Re: [Qemu-discuss] Accessing a shared folder

[Mahmood]

>Could you please try to replace the -virtfs option with these two options:
>
 >-fsdev local,id=shared,path=/home/mahmood/Downloads \
 >-device virtio-9p-pci,fsdev=shared,mount_tag=Downloads




Still get the same error!

mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -fsdev 
local,id=shared,path=/home/mahmood/Downloads -device 
virtio-9p-pci,fsdev=shared,mount_tag=Downloads
qemu-system-x86_64: -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads: 
Parameter 'driver' expects device type
mahmood@cluster:qemu-vm$




Regards,
Mahmood

Re: [Qemu-discuss] Live VM backup

[Vincenzo Romano]

2017-08-30 10:53 GMT+02:00 Fam Zheng :
> On Wed, 08/30 08:17, Vincenzo Romano wrote:
>> Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:
>>
>> On Tue, 08/29 18:32, Vincenzo Romano wrote:
>> > I'd like to move away from "another virtualization solution" to QEmu.
>> > I've more or less all the needed bits in my hands in order to define,
>> > run and manage QEmu VMs.
>> > What I am missing is the knowledge of how to backup a live VM.
>> > Of course, if I shutdown the VM, I can simply copy its files and the
>> > startup script on another QEmu host.
>> > But my main objective is to do the backup while the VM is running.
>> > I think I could use the snapshot feature, but have no idea on how to
>> proceed.
>> > Any hint?
>>
>> In short, just do what libvirt would do: use QMP and send 'drive-backup'
>> command.
>>
>> This is a very good howto:
>>
>> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
>> lock-operations.rst
>>
>> Fam
>>
>>
>> Thanks.
>> I presume there's a 'drive-restore', though I need to look better in the
>> docs.
>>
>> Is there any side effect in case the CPU where the VM will be restored is
>> not exactly the same as the one where the VM got backed up?
>
> No, there isn't a 'drive-restore'. 'drive-backup' only takes care of the 
> disks,
> so the CPU, ram and device states aren't saved.
>
> If you boot from the backup image, CPU and ram are restarted from powered off
> state, so what happens is effectively like a power loss at the point of
> 'drive-backup': anything not saved to disk are lost.
>
> Fam

I understand.

So, if I haven't miunderstood, at the moment QEmu-KVM doesn't
implement  "VM snapshots".

Thanks a lot for the insights.

-- 
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS

Re: [Qemu-discuss] Live VM backup

[Fam Zheng]

On Wed, 08/30 08:17, Vincenzo Romano wrote:
> Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:
> 
> On Tue, 08/29 18:32, Vincenzo Romano wrote:
> > I'd like to move away from "another virtualization solution" to QEmu.
> > I've more or less all the needed bits in my hands in order to define,
> > run and manage QEmu VMs.
> > What I am missing is the knowledge of how to backup a live VM.
> > Of course, if I shutdown the VM, I can simply copy its files and the
> > startup script on another QEmu host.
> > But my main objective is to do the backup while the VM is running.
> > I think I could use the snapshot feature, but have no idea on how to
> proceed.
> > Any hint?
> 
> In short, just do what libvirt would do: use QMP and send 'drive-backup'
> command.
> 
> This is a very good howto:
> 
> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
> lock-operations.rst
> 
> Fam
> 
> 
> Thanks.
> I presume there's a 'drive-restore', though I need to look better in the
> docs.
> 
> Is there any side effect in case the CPU where the VM will be restored is
> not exactly the same as the one where the VM got backed up?

No, there isn't a 'drive-restore'. 'drive-backup' only takes care of the disks,
so the CPU, ram and device states aren't saved.

If you boot from the backup image, CPU and ram are restarted from powered off
state, so what happens is effectively like a power loss at the point of
'drive-backup': anything not saved to disk are lost.

Fam

Re: [Qemu-discuss] Accessing a shared folder

[Thomas Huth]

On 30.08.2017 09:55, Mahmood wrote:
>> You don't have to write "fsdriver" here, but replace it with "local",
>> "handle" or "proxy".
> 
> Still get the same error
> 
> mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 
> -hda centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
> e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -virtfs 
> local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads 
> qemu-system-x86_64: -virtfs 
> local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads: Parameter 
> 'driver' expects device type 

Hmm, I've got the strange feeling that the -virtfs parameter might
currently be broken.

Could you please try to replace the -virtfs option with these two options:

 -fsdev local,id=shared,path=/home/mahmood/Downloads \
 -device virtio-9p-pci,fsdev=shared,mount_tag=Downloads

I hope that works better...

 Thomas

Re: [Qemu-discuss] Accessing a shared folder

[Mahmood]

>You don't have to write "fsdriver" here, but replace it with "local",
>"handle" or "proxy".


Still get the same error


mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -virtfs 
local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads 
qemu-system-x86_64: -virtfs 
local,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads: Parameter 
'driver' expects device type 

mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -virtfs 
handle,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads 
qemu-system-x86_64: -virtfs 
handle,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads: Parameter 
'driver' expects device type 


mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda 
centos7server.img -boot c  -usbdevice tablet -enable-kvm -device 
e1000,netdev=host_files -netdev user,net=10.0.2.0/24,id=host_files -virtfs 
proxy,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads 
qemu-system-x86_64: -virtfs 
proxy,id=shared,path=/home/mahmood/Downloads,mount_tag=Downloads: Parameter 
'driver' expects device type




Regards,
Mahmood

Re: [Qemu-discuss] [Qemu-devel] [QGA] Bug of qga?

[Sam]

Hi all,

I could repeat it, host os and guest os is Centos-7, qemu-ga is alive in
guest. the step to repeat it is:

1. run python script just like the first email.
2. send qmp command1(cmd in the python script, like `route -n` command or
something, of course it's qmp format), and interrupt it immediately(use
`ctrl+c`).
3. then use that script to send command2(do not send command1) again, then
you could get the result of command1.


2017-08-29 17:04 GMT+08:00 Sameeh Jubran :

> Hi Sam,
>
> Thanks for reporting this, in order to debug this efficiently I need you
> to provide me with more info, if you can provide it that would be great.
> Can you reproduce the issue with ncat? You can use ncat to connect to the
> socket by running the following command:
>
> nc -U /tmp/qga.sock
>
> Which OS are you running? Which qemu-ga version are you running? can you
> reproduce with upstream qemu-ga?
>
> On Tue, Aug 29, 2017 at 9:19 AM, Sam  wrote:
>
>> So how to fix this bug? And where should I to report bug?
>>
>> 2017-08-29 13:52 GMT+08:00 Sam :
>>
>> > I could repeat this several times, I think it's mis-order of qmp in qga
>> > socket.
>> >
>> > 2017-08-25 11:09 GMT+08:00 Sam :
>> >
>> >> Also I found:
>> >>
>> >> when I use `socat` to take a qga socket, then I use `socat` to
>> >> communicate it will got error.
>> >> But also SOMETIMES, I will not got error and will communicate OK.
>> >>
>> >> If one user take qga socket, another user should got error, is it? But
>> >> why sometimes, the communicate is OK?
>> >>
>> >> 2017-08-25 10:11 GMT+08:00 Sam :
>> >>
>> >>> Hi all,
>> >>>
>> >>> I'm using qga to send `route -n` and `ping` command to guest. But I
>> >>> found SOMETIMES, the second `ping` command's result is the same as
>> `route
>> >>> -n` command.
>> >>>
>> >>> So I guess is there some cache mechanism of qga command result? So
>> when
>> >>> I send the second command, and receive from qga socket, I receive the
>> >>> result of first command.
>> >>>
>> >>> Or is this bug happened because of I use async mechanism of python
>> code
>> >>> to operate qga socket?
>> >>>
>> >>> This is the python code I use to operate on this qga socket:
>> >>>
>> >>> try:
>>  sock=socket(AF_UNIX, SOCK_STREAM)
>>  sock.settimeout(20)
>>  sock.connect(vm_qga_sockpath)
>>  sock.send(cmd)
>>  while True:
>>  res = sock.recv(1024)
>>  if len(res):
>>  break
>>  except Exception as e:
>>  res = -1
>>  finally:
>>  sock.settimeout(None)
>>  sock.close()
>> >>>
>> >>>
>> >>
>> >
>>
>
>
>
> --
> Respectfully,
> *Sameeh Jubran*
> *Linkedin *
> *Software Engineer @ Daynix .*
>

Re: [Qemu-discuss] [Qemu-devel] [QGA] Bug of qga?

[Sam]

Qemu-2.6.0

2017-08-30 14:20 GMT+08:00 Sam :

> Hi all,
>
> I could repeat it, host os and guest os is Centos-7, qemu-ga is alive in
> guest. the step to repeat it is:
>
> 1. run python script just like the first email.
> 2. send qmp command1(cmd in the python script, like `route -n` command or
> something, of course it's qmp format), and interrupt it immediately(use
> `ctrl+c`).
> 3. then use that script to send command2(do not send command1) again, then
> you could get the result of command1.
>
>
> 2017-08-29 17:04 GMT+08:00 Sameeh Jubran :
>
>> Hi Sam,
>>
>> Thanks for reporting this, in order to debug this efficiently I need you
>> to provide me with more info, if you can provide it that would be great.
>> Can you reproduce the issue with ncat? You can use ncat to connect to the
>> socket by running the following command:
>>
>> nc -U /tmp/qga.sock
>>
>> Which OS are you running? Which qemu-ga version are you running? can you
>> reproduce with upstream qemu-ga?
>>
>> On Tue, Aug 29, 2017 at 9:19 AM, Sam  wrote:
>>
>>> So how to fix this bug? And where should I to report bug?
>>>
>>> 2017-08-29 13:52 GMT+08:00 Sam :
>>>
>>> > I could repeat this several times, I think it's mis-order of qmp in qga
>>> > socket.
>>> >
>>> > 2017-08-25 11:09 GMT+08:00 Sam :
>>> >
>>> >> Also I found:
>>> >>
>>> >> when I use `socat` to take a qga socket, then I use `socat` to
>>> >> communicate it will got error.
>>> >> But also SOMETIMES, I will not got error and will communicate OK.
>>> >>
>>> >> If one user take qga socket, another user should got error, is it? But
>>> >> why sometimes, the communicate is OK?
>>> >>
>>> >> 2017-08-25 10:11 GMT+08:00 Sam :
>>> >>
>>> >>> Hi all,
>>> >>>
>>> >>> I'm using qga to send `route -n` and `ping` command to guest. But I
>>> >>> found SOMETIMES, the second `ping` command's result is the same as
>>> `route
>>> >>> -n` command.
>>> >>>
>>> >>> So I guess is there some cache mechanism of qga command result? So
>>> when
>>> >>> I send the second command, and receive from qga socket, I receive the
>>> >>> result of first command.
>>> >>>
>>> >>> Or is this bug happened because of I use async mechanism of python
>>> code
>>> >>> to operate qga socket?
>>> >>>
>>> >>> This is the python code I use to operate on this qga socket:
>>> >>>
>>> >>> try:
>>>  sock=socket(AF_UNIX, SOCK_STREAM)
>>>  sock.settimeout(20)
>>>  sock.connect(vm_qga_sockpath)
>>>  sock.send(cmd)
>>>  while True:
>>>  res = sock.recv(1024)
>>>  if len(res):
>>>  break
>>>  except Exception as e:
>>>  res = -1
>>>  finally:
>>>  sock.settimeout(None)
>>>  sock.close()
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>>
>> --
>> Respectfully,
>> *Sameeh Jubran*
>> *Linkedin *
>> *Software Engineer @ Daynix .*
>>
>
>

Re: [Qemu-discuss] Live VM backup

[Vincenzo Romano]

Il 30 ago 2017 05:19, "Fam Zheng"  ha scritto:

On Tue, 08/29 18:32, Vincenzo Romano wrote:
> I'd like to move away from "another virtualization solution" to QEmu.
> I've more or less all the needed bits in my hands in order to define,
> run and manage QEmu VMs.
> What I am missing is the knowledge of how to backup a live VM.
> Of course, if I shutdown the VM, I can simply copy its files and the
> startup script on another QEmu host.
> But my main objective is to do the backup while the VM is running.
> I think I could use the snapshot feature, but have no idea on how to
proceed.
> Any hint?

In short, just do what libvirt would do: use QMP and send 'drive-backup'
command.

This is a very good howto:

https://github.com/qemu/qemu/blob/master/docs/interop/live-b
lock-operations.rst

Fam


Thanks.
I presume there's a 'drive-restore', though I need to look better in the
docs.

Is there any side effect in case the CPU where the VM will be restored is
not exactly the same as the one where the VM got backed up?

Re: [Qemu-discuss] changing from net to netdev with vde switches and double nics

[Thomas Huth]

On 29.08.2017 21:22, Paolo wrote:
> 
> --
>> On Tue, 29 Aug 2017 11:48:20 +0200
>> Thomas Huth  wrote:
> [cut]
>> That's interesting, I think you're the first person I know in months or
>> even years who really seems to be using the vlan=x parameter (with x >=
>> 1)...
> 
> I can't see any other way to realize this topology:
>
>  Internet---HOST--SambaServer
>||
>||
>   pubNETprvNET
>   | |
>|--  |
>||
>  NIC0  NIC1-|
>||
>   machine_1     machine_N
>> You're right, you can not translate your setup 1:1 to -netdev anymore,
>> since there are no 'vlan's (or rather hubs, since 'vlan' is rather a
>> misnomer here) available with the -netdev parameter.
> 
> This might be a problem for me, as I explain later 
>> Question is: Why do you need it at all? I see your point that you want
>> to have two network cards, but why does each NIC has to be wired to two
>> host networks (vde *and* tap)? Isn't it sufficient if you connect each
>> NIC to one VDE network?
> 
> Easily: by ignorance.

Deja vu ... this is actually one of the reasons why we want to get rid
of this "vlan" stuff in QEMU. Hardly anybody gets it really right, it
mainly causes confusion and mis-configurations.

> Writing that script (about 8 years ago) with almost zero knowledge of 
> networking and difference between tap, vde (and much more stuff), made me 
> rely on a Frankenstein-style patchwork from midnight readings of the various 
> howtos on internet. Quite a mess and a long and painful trial-and-error race. 
> Nor that today I might be regarded as an expert in networking, I didn't 
> progress very much (and it' not my job anyway).
> 
> Back on topic, following your hint, I've tried just know that all I need is 
> vde, and everything works fine:
> 
>  NET0="-net vde,vlan=0,sock=/var/run/vde.ctl00 -net 
> nic,vlan=0,model=rtl8139,macaddr=$NIC0MAC"
>  NET1="-net vde,vlan=1,sock=/var/run/vde.ctl01 -net 
> nic,vlan=1,model=rtl8139,macaddr=$NIC1MAC"
> 
> Now I guess this is impossbile to achieve with netdev?
> How may I tell to qemu that the guest's NIC0 has to be wired to the vde 
> switch vde.ctl00 run on host has, and NIC1 to vde.ctl01?

It should be doable. Could you please try something like this:

 NET0="-netdev vde,id=v0,sock=/var/run/vde.ctl00 -device 
rtl8139,netdev=v0,mac=$NIC0MAC"
 NET1="-netdev vde,id=v1,sock=/var/run/vde.ctl01 -device 
rtl8139,netdev=v1,mac=$NIC1MAC"

I haven't tested it though, so you still might have to tweak it. Run qemu
with "-device rtl8139,?" to see the options of the rtl8139 device.

> Also hubport function is unclear to me. It reproduces the previous vlan 
> concept, but it's left orphan, because no other devices seems to be made 
> aware that hubportN exists, nor they can be wired to it.

You mean "-netdev hubport"? Forget about it, you don't need it. The hubport
is only required if you want to connect a device to a legacy "vlan" hub. In
your case, you should be fine without these legacy "vlan"s.

 HTH,
  Thomas

Re: [Qemu-discuss] changing from net to netdev with vde switches and double nics

[Paolo]

Hi Thomas,

thank you for your interest in the question

> On Tue, 29 Aug 2017 11:48:20 +0200
> Thomas Huth  wrote:  
[cut]
> That's interesting, I think you're the first person I know in months or
> even years who really seems to be using the vlan=x parameter (with x >=
> 1)...  

I currently can't see any other way to realize this topology:
   
NIC_0.1---|
  |   |
  |   NIC_0.NSWITCH_0(on HOST)<>Internet
  | |
GUEST_1   ...   GUEST_N 
  | |
  |   NIC_1.N-|
  |  SWITCH_1(on HOST)>SambaServer(on HOST)
NIC_1.1---|

> You're right, you can not translate your setup 1:1 to -netdev anymore,
> since there are no 'vlan's (or rather hubs, since 'vlan' is rather a
> misnomer here) available with the -netdev parameter.  

This might be a problem for me, as I explain later 

> Question is: Why do you need it at all? I see your point that you want
> to have two network cards, but why does each NIC has to be wired to two
> host networks (vde *and* tap)? Isn't it sufficient if you connect each
> NIC to one VDE network?  

Easily: by ignorance. I wrote that script (about 8 years ago) with almost zero 
knowledge of networking and difference between tap, vde (and much more stuff), 
sort of a Frankenstein-style patchwork inspired by midnight readings of the 
various howtos on internet. Quite a mess and a long and painful trial-and-error 
race. Nor that today I might be regarded as an expert in networking, I didn't 
progress very much (as it's not my job anyway).

Back on topic, following your hint, I've tried just know that all I need is 
vde, and everything works fine:

 NET0="-net vde,vlan=0,sock=/var/run/vde.ctl00 -net 
nic,vlan=0,model=rtl8139,macaddr=$NIC0MAC"
 NET1="-net vde,vlan=1,sock=/var/run/vde.ctl01 -net 
nic,vlan=1,model=rtl8139,macaddr=$NIC1MAC"

Now I guess this is impossbile to achieve with netdev?

How may I tell to qemu that the guest's NIC0 has to be wired to the vde switch 
vde.ctl00 (run on host), and NIC1 to vde.ctl01?
Also hubport function is unclear to me. It reproduces the previous vlan 
concept, but it's left orphan, because no other devices seems to be made aware 
that hubport_n exists, nor looks to me that they could be wired to it.

Is there a feasible way to have the same network layout with netdev in place of 
net? Any hint on alternative ways to do it?

  Paolo