[libvirt-users] way to see the bootmenu via serial?
by mail list
Maybe this should go to the qemu mail list, but I have domains configured
to dump to serial. Works fine I see Grub menu/kernel messages and the like,
but the "bootmenu" listing only shows up over vnc. Is there a way to have
that show up over serial?
I definitely can hit up the qemu mail list as well if inappropriate for here
9 years, 10 months
[libvirt-users] spice session locking
by Jon Doe
Hi List,
Is it possible to prevent other clients from stealing my libvirtd
hosted spice session? This is a problem for me where multiple
co-workers access the same guest over a qemu+ssh:// connection.
Instead of simply disconnecting clients, I'd like libvirtd to deny the
new client.
I've been looking at polkit acl rules and the vnc sharePolicy
attribute but so far no luck.
9 years, 10 months
[libvirt-users] QEMU 2.2.0 managedsave: Unknown savevm section type 5
by Paul Apostolescu
Hello,
I am running into issues restoring VMs during reboot for some of my XP VMs
- the environment is QEMU 2.2.0, libvirt 1.2.12 on CentOS 6.5 with KVM and
libvirt-guests is set to suspend at shutdown. The weird part is Windows 7
is restored properly from the managedsave however XP does not, doing a
start from virsh shows this:
virsh # start xp-check
error: Failed to start domain xp-check
error: internal error: early end of file from monitor: possible problem:
Unknown savevm section type 5
2015-02-04T23:55:37.117515Z qemu-kvm: load of migration failed: Invalid
argument
(qemu-kvm is a link to qemu-system-x86_64).
Any ideas how to fix this ?
Thanks
9 years, 10 months
[libvirt-users] vm live storage migration with snapshots
by Edward Young
Hi all,
I'm investigating the ways to improve the live migration performance in
libvirt. I have a question about the vm live storage migration. the
platform is libvirt + qemu + kvm
If we want to migrate a running vm with its virtual disk images to another
node.
we can use 'virsh migrate ....' commands.
What if this vm has a number of disk-only external snapshots? In the
current version, how can live migrate this vm?
Is it possible to blockcommit the snapshots to the base image and later
perform the migration, without shutting down the running vm?
Or is it possible to iteratively transfer all the snapshots to the
destination and later live migrate only the latest new data?
Thanks in advance.
Best,
Ed
9 years, 10 months
[libvirt-users] libvirt/virsh change boot order
by Robb Walker
Hello, hope all are well.
Am I missing something?
If I add a cdrom and change boot order in a running vm with virsh edit, I have to shutdown the vm and restart to see the change in boot order. I can not just restart the vm via reboot inside the vm or virsh reboot vm. I don't see anything under /var/lib/libvirt/qemu/saved where I might expect conflict if I was battling against a saved configuration. If obvious, DUH, apologies and virtually bonk me on the head.
Note: This is actually okay. Just don't want to miss on something that would allow me to just cycle the vm after make changes.
on ubu -- 14.04
ii libvirt-bin 1.2.2-0ubuntu13.1.9 amd64 programs for the libvirt library
ii libvirt-dev 1.2.2-0ubuntu13.1.9 amd64 development files for the libvirt library
ii libvirt-doc 1.2.2-0ubuntu13.1.9 all documentation for the libvirt library
ii libvirt0 1.2.2-0ubuntu13.1.9 amd64 library for interfacing with different virtualization systems
<os>
<type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
<boot dev='cdrom'/>
<boot dev='hd'/>
</os>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/foo/Downloads/archlinux-2015.02.01-dual.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
Thanks and Kind Regards all
This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.
9 years, 10 months
Re: [libvirt-users] libvirt 1.2.10 and latest EL6 qemu-kvm
by Franky Van Liedekerke
(I'm sorry, I didn't find my original message but I provide the
archive link: https://www.redhat.com/archives/libvirt-users/2015-January/msg00069.html
)
I just tried the latest libvirt release (1.2.12), combined with the
following qemu EL6 package from centos:
qemu-kvm-0.12.1.2-2.448.el6_6.x86_64
Using 1.2.12 and this version of qemu-kvm, I still get the following
error when trying to start a domain:
error: Failed to start domain btcab0001ap.unix.banksys.be
error: internal error: unable to execute QEMU command 'qom-list': The
command qom-list has not been found
The older qemu package (qemu-kvm-0.12.1.2-2.415.el6_5.14.x86_64) works
just fine though (I also tried the qemu-rhev-packages for el6 from
ovirt, but no change).
I verified the changelog from libvirt 1.2.12 and the earlier suggested
fix is in there (but doesn't seem to change anything):
2015-01-14 Pavel Hrdina <phrdina(a)redhat.com>
qemu_monitor: introduce new function to get QOM path
Now, I have activated libvirtd debug and these are the qom-list lines
(I can provide the full logfile if wanted):
2015-02-11 14:10:33.259+0000: 13280: debug : virJSONValueToString:1528
: result={"execute":"qom-list","arguments":{"path":"/machine/unattached/device[0]"},"id":"libvirt-5"}
2015-02-11 14:10:33.259+0000: 13280: debug :
qemuMonitorJSONCommandWithFd:290 : Send command
'{"execute":"qom-list","arguments":{"path":"/machine/unattached/device[0]"},"id":"libvirt-5"}'
for write with FD -1
2015-02-11 14:10:33.259+0000: 13280: info : qemuMonitorSend:972 :
QEMU_MONITOR_SEND_MSG: mon=0x7fa62801cbf0
msg={"execute":"qom-list","arguments":{"path":"/machine/unattached/device[0]"},"id":"libvirt-5"}
2015-02-11 14:10:33.260+0000: 13278: info : qemuMonitorIOWrite:503 :
QEMU_MONITOR_IO_WRITE: mon=0x7fa62801cbf0
buf={"execute":"qom-list","arguments":{"path":"/machine/unattached/device[0]"},"id":"libvirt-5"}
2015-02-11 14:10:33.261+0000: 13278: info : qemuMonitorIOProcess:399 :
QEMU_MONITOR_IO_PROCESS: mon=0x7fa62801cbf0 buf={"id": "libvirt-5",
"error": {"class": "CommandNotFound", "desc": "The command qom-list
has not been found", "data": {"name": "qom-list"}}}
2015-02-11 14:10:33.261+0000: 13278: debug :
qemuMonitorJSONIOProcessLine:183 : Line [{"id": "libvirt-5", "error":
{"class": "CommandNotFound", "desc": "The command qom-list has not
been found", "data": {"name": "qom-list"}}}]
2015-02-11 14:10:33.261+0000: 13278: debug :
virJSONValueFromString:1361 : string={"id": "libvirt-5", "error":
{"class": "CommandNotFound", "desc": "The command qom-list has not
been found", "data": {"name": "qom-list"}}}
2015-02-11 14:10:33.261+0000: 13278: info :
qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_REPLY:
mon=0x7fa62801cbf0 reply={"id": "libvirt-5", "error": {"class":
"CommandNotFound", "desc": "The command qom-list has not been found",
"data": {"name": "qom-list"}}}
2015-02-11 14:10:33.289+0000: 13280: debug : virJSONValueToString:1528
: result={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-7"}
2015-02-11 14:10:33.289+0000: 13280: debug :
qemuMonitorJSONCommandWithFd:290 : Send command
'{"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-7"}'
for write with FD -1
2015-02-11 14:10:33.289+0000: 13280: info : qemuMonitorSend:972 :
QEMU_MONITOR_SEND_MSG: mon=0x7fa62801cbf0
msg={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-7"}
2015-02-11 14:10:33.289+0000: 13278: info : qemuMonitorIOWrite:503 :
QEMU_MONITOR_IO_WRITE: mon=0x7fa62801cbf0
buf={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-7"}
2015-02-11 14:10:33.291+0000: 13278: info : qemuMonitorIOProcess:399 :
QEMU_MONITOR_IO_PROCESS: mon=0x7fa62801cbf0 buf={"id": "libvirt-7",
"error": {"class": "CommandNotFound", "desc": "The command qom-list
has not been found", "data": {"name": "qom-list"}}}
2015-02-11 14:10:33.291+0000: 13278: debug :
qemuMonitorJSONIOProcessLine:183 : Line [{"id": "libvirt-7", "error":
{"class": "CommandNotFound", "desc": "The command qom-list has not
been found", "data": {"name": "qom-list"}}}]
2015-02-11 14:10:33.291+0000: 13278: debug :
virJSONValueFromString:1361 : string={"id": "libvirt-7", "error":
{"class": "CommandNotFound", "desc": "The command qom-list has not
been found", "data": {"name": "qom-list"}}}
2015-02-11 14:10:33.291+0000: 13278: info :
qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_REPLY:
mon=0x7fa62801cbf0 reply={"id": "libvirt-7", "error": {"class":
"CommandNotFound", "desc": "The command qom-list has not been found",
"data": {"name": "qom-list"}}}
2015-02-11 14:10:33.291+0000: 13280: debug : virJSONValueToString:1528
: result={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-7"}
2015-02-11 14:10:33.292+0000: 13280: debug : virJSONValueToString:1528
: result={"id":"libvirt-7","error":{"class":"CommandNotFound","desc":"The
command qom-list has not been found","data":{"name":"qom-list"}}}
2015-02-11 14:10:33.292+0000: 13280: debug :
qemuMonitorJSONCheckError:370 : unable to execute QEMU command
{"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-7"}:
{"id":"libvirt-7","error":{"class":"CommandNotFound","desc":"The
command qom-list has not been found","data":{"name":"qom-list"}}}
2015-02-11 14:10:33.292+0000: 13280: error :
qemuMonitorJSONCheckError:381 : internal error: unable to execute QEMU
command 'qom-list': The command qom-list has not been found
(again: full log can be provided, but maybe that should be sent in
private, I don't know if it is allowed as an attachment here).
Any tips?
Franky
9 years, 10 months
Re: [libvirt-users] About live migration with snapshots
by Edward Young
Hi All,
Sorry, I do not know to reply the previous message directly, so I have to
manually copy them here.
I have two questions about the following issue?
1. I follow the instructions blew to migrate a vm with snapshots. When I
perform 'virsh snapshot-create --redefine $dom file' on the destination.' I
got an error saying that "no domain with matching name $dom". I'm wondering
during the mgiration, what do we need to do in the destination? create a
new base file?
2. What does the following instruction do?
"you then loop over 'virsh snapshot-delete --metadata $dom
$name' on the source, at which point, live migration will now work."
3. Also, could you explain a little about the high level techniques for
this function.
suppose we have a vm with one base file and two snapshots. How does the
following instructions do to migrate all of them?
Thanks!
Edward
------------------------------
- *From*: Eric Blake <eblake redhat com>
- *To*: Chiang Hubert <clhtwn gmail com>
- *Cc*: libvirt-users redhat com
- *Subject*: Re: [libvirt-users] About live migration with snapshots
- *Date*: Wed, 20 Mar 2013 21:40:26 -0600
------------------------------
On 03/20/2013 08:45 PM, Chiang Hubert wrote:
> Hello,
>
> I'd like to live migration with snapshots.
>
> But it doesn't work. It comes out a message "cannot migrate domain with 1
> snapshots"
Unfortunately, figuring out how to migrate snapshot information at the
libvirt API level requires some engineering work - the current RPC
protocol for migration is not set up to migrate an arbitrary amount of
snapshots in a single call.
On the other hand, if you are allowed to make more than one API call,
the solution is already available; maybe we should patch virsh to learn
how to make the series of API calls, to automate what I will describe below.
>
> Then I try to trace the code(Libvirt 0.9.8 to 1.0.3), I find out the code
> in src/qemu/qemu_migration.c @ Line 1395 - 1440 (Libvirt 1.0.3)
It's still unimplemented at the libvirt level, even in libvirt.git.
>
> It will check the VM which has snapshots or not.
>
> I just curious about this limitation, why the VM can't live migration with
> snapshots?
Doing it all in one RPC call would be a potential denial-of-service
(RPCs are bounded in length to avoid consuming server resources, and
taking lots of snapshots on the source could easily be made to exceed
bounds). If someone can design a way to set up a series of RPC
handshakes, then we could do it at the libvirt level in a single API
call, but I'm not sure it is worth it.
>
> What happen if I skip this check?
>
> Does it has any suggestion way or virsh command with options to do live
> migration with snapshots?
The existing solution at the management tool layer is to migrate the
snapshot information first, and then to migrate the domain. For each
snapshot in 'virsh snapshot-list --name $dom', you will want to 'virsh
snapshot-dumpxml $dom $name > file' on the source, then 'virsh
snapshot-create --redefine $dom file' on the destination. Next,
determine 'virsh snapshot-current --name $dom' on the source, and use
'virsh snapshot-current $dom $name' on the destination to set it as
current (if there is a current snapshot). After the destination has all
the snapshots, you then loop over 'virsh snapshot-delete --metadata $dom
$name' on the source, at which point, live migration will now work.
Patches to teach virsh how to do all this work in a single 'virsh
migrate' are welcome.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
*Attachment: signature.asc
<https://www.redhat.com/archives/libvirt-users/2013-March/pgpmxFegVXm2O.pgp>*
*Description:* OpenPGP digital signature
9 years, 10 months
[libvirt-users] Possible to change 'machine type' attribute while vm is running?
by Andre Goree
Hello. I'd like to determine if it's possible to change the 'machine
type' attribute while a vm is running.
For example, I have:
<os>
<type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
<boot dev='hd'/>
</os>
I'd like to change that to "machine='pc-i440fx-1.7'" due to an error[1]
I'm seeing while migrated similar images to another host.
The only way I've been able to change the machine is by first shutting
down the vm, making the change, then starting the vm back up. I'd like
to avoid that if at all possible.
I did find the tool "libvirt-migrate-qemu-machinetype", but it doesn't
seem to do what I think it's intended to do -- i.e., it does NOT change
the machine type, even after reboot. Perhaps I'm just using it wrong?
I performed the following:
root:~# libvirt-migrate-qemu-machinetype -t pc-i440fx-1.7 <domain>
Waiting up to 10 seconds for libvirtd to start...
Waiting up to 30 seconds for libvirtd to respond to requests...
Checking domains defined in /etc/libvirt/qemu...
Migration complete
But the machine type remains the same after the above command has been
run.
Thanks in advance for any insight you can provide.
[1] - error: internal error: process exited while connecting to monitor:
Supported machines are:
--
Andre Goree
-=-=-=-=-=-
Email - andre at drenet.net
Website - http://www.drenet.net
PGP key - http://www.drenet.net/pubkey.txt
-=-=-=-=-=-
9 years, 10 months
[libvirt-users] CPU model and type
by Paul Apostolescu
Hello,
Is there a way to configure the domain cpu in such a way that the info
reported to the guest OS system will remain constant ? For example in older
versions of of libvirt/qemu the cpu was reported as "QEMU Virtual CPU
version (cpu64_rhel6)" but moving the vm on a qemu2.2.0 is is reported as
"QEMU Virtual CPU version 2.2.0".
Thanks.
9 years, 10 months
[libvirt-users] CPU model and missing AES-NI extension
by Dennis Jacobfeuerborn
Hi,
today I tried to configure a guest using Virt-Manager and used the "copy
host cpu configuration" option which resultet in a "Sandy Bridge" model.
What I noticed is that for example the "aes" extension is not available
in the guest even though it is available on the host cpu.
This is what the host cpu looks like:
model name : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2
x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm
abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority
ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
And this is what I get in the guest:
model name : Intel Xeon E312xx (Sandy Bridge)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb lm
constant_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm abm
Is there a way to get closer to the hardware and get as many of the host
features in the guest as possible? I never intend to do anything like
live-migration with this guest so compatibility for that case is not a
concern.
Regards,
Dennis
9 years, 10 months
