settingsLogin | Registersettings

[Openstack-operators] Venom vulnerability

0 votes

Looking through the details of the Venom vulnerability, https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it would appear that the QEMU processes need to be restarted.

Our understanding is thus that a soft reboot of the VM is not sufficient but a hard one would be OK.

Some quick tests have shown that a suspend/resume of the VM also causes a new process.

How are others looking to address this vulnerability ?

(I guess the security session will have a few extra people signing up in Vancouver now...)

Tim


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
asked May 13, 2015 in openstack-operators by Tim_Bell (16,440 points)   1 8 10

29 Responses

0 votes

Hello,

Looking through the details of the Venom vulnerability,
https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it
would appear that the QEMU processes need to be restarted.

Our understanding is thus that a soft reboot of the VM is not sufficient
but a hard one would be OK.

Some quick tests have shown that a suspend/resume of the VM also causes a
new process.

The RedHat KB article (linked in the blog post you gave) also mentions that
migrating to a patched server should also be sufficient. If either methods
(suspend or migration) work, I think those are nicer ways of handling this
than hard reboots.

I also found this statement to be curious:

"The sVirt and seccomp functionalities used to restrict host's QEMU process
privileges and resource access might mitigate the impact of successful
exploitation of this issue."

So perhaps RedHat already has mechanisms in place to prevent exploits such
as this from being successful? I wonder if Ubuntu has something similar in
place.

How are others looking to address this vulnerability ?

It looks like RedHat has released updates, but I haven't received an
announcement for Ubuntu yet -- does anyone know the status?

As soon as a fix is released, we'll update our hosts. That will ensure new
instances aren't vulnerable. We'll then figure out some way of coordinating
fixing of older instances.

Joe


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Joe_Topjian (5,780 points)   1 6 10
0 votes

On Wed, May 13, 2015 at 02:31:26PM +0000, Tim Bell wrote:

Looking through the details of the Venom vulnerability,
https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it
would appear that the QEMU processes need to be restarted.

Our understanding is thus that a soft reboot of the VM is not sufficient
but a hard one would be OK.

Yes, the key requirement is that you get a new QEMU process running. So
this means a save-to-disk followed by restore, or a shutdown + boot,
or a live migration to another (patched) host.

In current Nova code a hard reboot operation will terminate the QEMU
process and then start it again, which is the same as shutdown + boot
really. A soft reboot will also terminate the QEMU process and start
it again, when when terminating it, it will try to do so gracefully.
ie init gets a chance todo a orderly shutdown of services. A soft
reboot though is not guaranteed to ever finish / happen, since it
relies on co-operating guest OS to respond to the ACPI signal. So
soft reboot is probably not a reliable way of guaranteeing you get
a new QEMU process.

My recommendation would be a live migration, or save to disk and restore
though, since those both minimise interruption to your guest OS workloads
where as a hard reboot or shutdown obviously kills them.

Also note that this kind of bug in QEMU device emulation is the poster
child example for the benefit of having sVirt (either SELinux or AppArmor
backends) enabled on your compute hosts. With sVirt, QEMU is restricted
to only access resources that have been explicitly assigned to it. This
makes it very difficult (likely/hopefully impossible[1]) for a compromised
QEMU to be used to break out to compromise the host as a whole, likewise
protect against compromising other QEMU processes on the same host. The
common Linux distros like RHEL, Fedora, Debian, Ubuntu, etc all have
sVirt feature available and enabled by default and OpenStack doesn't
do anything to prevent it from working. Hopefully no one is actively
disabling it themselves leaving themselves open to attack...

Finally QEMU processes don't run as root by default, they use a
'qemu' user account with minimal privileges, which adds another layer
of protection against total host compromise

So while this bug is no doubt serious and worth patching asap, IMHO,
it is not the "immediate end of the world" scale disaster that some
are promoting it to be.

NB, this mail is my personal analysis of the problem - please refer
to the above linked redhat.com blog post and/or CVE errata notes,
or contact Red Hat support team, for the official Red Hat view on
this.

Regards,
Daniel

[1] I'll never claim anything is 100% foolproof, but it is intended to
to be impossible to escape sVirt, so any such viable escape routes
would themselves be considered security bugs.
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Daniel_P._Berrange (27,920 points)   2 4 10
0 votes

So far, your assessment is spot on from what we've seen. A migration (if you have live migrate that's even better) should net the same result for QEMU. Some have floated the idea of live migrate within the same host. I don't know if nova out of the box would support such a thing.

Thanks!
Matt

From: Tim Bell Tim.Bell@cern.ch
Date: Wednesday, May 13, 2015 9:31 AM
To: "openstack-operators@lists.openstack.org" openstack-operators@lists.openstack.org
Subject: [Openstack-operators] Venom vulnerability

Looking through the details of the Venom vulnerability, https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it would appear that the QEMU processes need to be restarted.

Our understanding is thus that a soft reboot of the VM is not sufficient but a hard one would be OK.

Some quick tests have shown that a suspend/resume of the VM also causes a new process.

How are others looking to address this vulnerability ?

(I guess the security session will have a few extra people signing up in Vancouver now...)

Tim


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Matt_Van_Winkle (2,260 points)   1 3
0 votes

On Wed, May 13, 2015 at 03:08:47PM +0000, Matt Van Winkle wrote:
So far, your assessment is spot on from what we've seen. A migration
(if you have live migrate that's even better) should net the same result
for QEMU. Some have floated the idea of live migrate within the same
host. I don't know if nova out of the box would support such a thing.

Localhost migration (aka migration within the same host) is not something
that is supported by libvirt/KVM. Various files QEMU has on disk are based
on the VM name/uuid and you can't have 2 QEMU processes on the host having
the files at the same time, which precludes localhost migration working.

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Daniel_P._Berrange (27,920 points)   2 4 10
0 votes

honestly that seems like a very useful feature to ask for... specifically
for upgrading qemu.

-matt

On Wed, May 13, 2015 at 11:19 AM, Daniel P. Berrange berrange@redhat.com
wrote:

On Wed, May 13, 2015 at 03:08:47PM +0000, Matt Van Winkle wrote:

So far, your assessment is spot on from what we've seen. A migration
(if you have live migrate that's even better) should net the same result
for QEMU. Some have floated the idea of live migrate within the same
host. I don't know if nova out of the box would support such a thing.

Localhost migration (aka migration within the same host) is not something
that is supported by libvirt/KVM. Various files QEMU has on disk are based
on the VM name/uuid and you can't have 2 QEMU processes on the host having
the files at the same time, which precludes localhost migration working.

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
:|
|: http://libvirt.org -o- http://virt-manager.org
:|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/
:|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc
:|


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by matt (5,480 points)   1 2 3
0 votes

Hi Tim, et al,

We (Time Warner Cable) will be doing a live-migration (L-M) of all
instances one the QEMU package is upgraded. That will start new QEMU
instances on the target host allowing us to vacate the source host. We may
roll in a kernel upgrade due to another security vulnerability at the same
time.

I'm doing a Show and Tell in YVR about the topic of L-Ms and this topic now
has its own slide.

On Wed, May 13, 2015 at 8:31 AM, Tim Bell Tim.Bell@cern.ch wrote:

Looking through the details of the Venom vulnerability,
https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it
would appear that the QEMU processes need to be restarted.

Our understanding is thus that a soft reboot of the VM is not sufficient
but a hard one would be OK.

Some quick tests have shown that a suspend/resume of the VM also causes a
new process.

How are others looking to address this vulnerability ?

(I guess the security session will have a few extra people signing up in
Vancouver now...)

Tim


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by David_Medberry (8,000 points)   1 4 5
0 votes

Yeah, something like that would be handy.

From: matt matt@nycresistor.com
Date: Wednesday, May 13, 2015 10:29 AM
To: "Daniel P. Berrange" berrange@redhat.com
Cc: Matt Van Winkle mvanwink@rackspace.com, "openstack-operators@lists.openstack.org" openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Venom vulnerability

honestly that seems like a very useful feature to ask for... specifically for upgrading qemu.

-matt

On Wed, May 13, 2015 at 11:19 AM, Daniel P. Berrange berrange@redhat.com wrote:
On Wed, May 13, 2015 at 03:08:47PM +0000, Matt Van Winkle wrote:
So far, your assessment is spot on from what we've seen. A migration
(if you have live migrate that's even better) should net the same result
for QEMU. Some have floated the idea of live migrate within the same
host. I don't know if nova out of the box would support such a thing.

Localhost migration (aka migration within the same host) is not something
that is supported by libvirt/KVM. Various files QEMU has on disk are based
on the VM name/uuid and you can't have 2 QEMU processes on the host having
the files at the same time, which precludes localhost migration working.

Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Matt_Van_Winkle (2,260 points)   1 3
0 votes

Looks like the updated Ubuntu packages are available:

http://www.ubuntu.com/usn/usn-2608-1/

On Wed, May 13, 2015 at 10:44 AM, Matt Van Winkle mvanwink@rackspace.com
wrote:

Yeah, something like that would be handy.

From: matt matt@nycresistor.com
Date: Wednesday, May 13, 2015 10:29 AM
To: "Daniel P. Berrange" berrange@redhat.com
Cc: Matt Van Winkle mvanwink@rackspace.com, "
openstack-operators@lists.openstack.org" <
openstack-operators@lists.openstack.org>
Subject: Re: [Openstack-operators] Venom vulnerability

honestly that seems like a very useful feature to ask for...
specifically for upgrading qemu.

-matt

On Wed, May 13, 2015 at 11:19 AM, Daniel P. Berrange berrange@redhat.com
wrote:

On Wed, May 13, 2015 at 03:08:47PM +0000, Matt Van Winkle wrote:

So far, your assessment is spot on from what we've seen. A migration
(if you have live migrate that's even better) should net the same result
for QEMU. Some have floated the idea of live migrate within the same
host. I don't know if nova out of the box would support such a thing.

Localhost migration (aka migration within the same host) is not something
that is supported by libvirt/KVM. Various files QEMU has on disk are based
on the VM name/uuid and you can't have 2 QEMU processes on the host having
the files at the same time, which precludes localhost migration working.

Regards,
Daniel
--
|: http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o-
http://virt-manager.org :|
|: http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Joe_Topjian (5,780 points)   1 6 10
0 votes

Would a virsh suspend/save/restore/resume operation accomplish similar
result as the localhost migration?

Best,
Favyen

On 05/13/2015 12:44 PM, Matt Van Winkle wrote:
Yeah, something like that would be handy.

From: matt matt@nycresistor.com
Date: Wednesday, May 13, 2015 10:29 AM
To: "Daniel P. Berrange" berrange@redhat.com
Cc: Matt Van Winkle mvanwink@rackspace.com, "openstack-operators@lists.openstack.org" openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Venom vulnerability

honestly that seems like a very useful feature to ask for... specifically for upgrading qemu.

-matt

On Wed, May 13, 2015 at 11:19 AM, Daniel P. Berrange berrange@redhat.com wrote:
On Wed, May 13, 2015 at 03:08:47PM +0000, Matt Van Winkle wrote:

So far, your assessment is spot on from what we've seen. A migration
(if you have live migrate that's even better) should net the same result
for QEMU. Some have floated the idea of live migrate within the same
host. I don't know if nova out of the box would support such a thing.

Localhost migration (aka migration within the same host) is not something
that is supported by libvirt/KVM. Various files QEMU has on disk are based
on the VM name/uuid and you can't have 2 QEMU processes on the host having
the files at the same time, which precludes localhost migration working.

Regards,
Daniel

-----BEGIN PGP MESSAGE----- Version: GnuPG v1 Comment: Charset: us-ascii
hQIMA4ToeuPbGFzLAQ//WKATa6VRGKJKq7zAcUTO0tS8Lgq5zuo1buc2pJtbPKXi
pFmHpgTsXxoU3LNhfWelAToCQdacVLUw5OiFsWyoVsjAcuRzMrN+l8WHYG4jZDGs
bXCUp4XwShex35/vmI15NTAKrmbgIJZRi80sewCZ8H13rei86TPKA5b1C9SFxiqq
KGmntJdiEyk+x2SOz5xvZVx/29XryUSBXo6YAVQmW4AZrrdVdkRxDKCX3tw90UZ+
RCibGl1nac4n2rrXZ+izKcq6d+CYo28yBaEJ5zecrU1K9M/rZwyVWnr5NTP0bs0B
EOBV+0YsaBJdfbdrntKGUZCKVta4QdX9mOIQ7GYM/DP3IxHywFKfcwjG0iRjHYQG
sNCK0ymhr+eNcBKWHjyVqvy/W5IIep+ES1Y7xhmwqPfWEraNQ+Scc9T6i7mWAaam
dn7fVaO3dOHEoKVGX6Z+TtQS+FjesrgtOtvEeonVAkQLNEBVnQcMaMOrz+Ia1AXf
+SwkcksDaqylXC1TqTLjyA7ceEHWqPL7d6EfIM7dBT/tg0h5WL2XgoJlFddSXDoR
99b2Arc9jaG+tJamvRO+M8Ky8uVuD5pF68wDwfvPqHbzSzzt3fmmkQkOVmtNLkjp
ZAGDxV/0+xhurdz4HFDz6q3ShpgREsgBEOd8uY7UCn67nRZbrS4YtdUIV25dhknS
6gGkwfhs5IR99F/IvQUXsUs1m5DCWZI0GkWEaTcTEJfNoYHLPH+vLdtzupNz7ihp
sNtie42q3urYLW5irAFeTW8jyjS4V5TPMMUXMvp5DG4eOGGCoKiZQhmT3JJB3PHe
5kghWgOlRQyK9trkH1zS8cgpXPhL+g/LGRfrp+xH7E7Hn1DLMizeQargFpcLmpdR
KHQQCHlBuB4gTQ0n/ai5zRVrioH+6GVMVedUxsYTMlrVWNGocYVZ/lzjHdDGVPiQ
JoxmMxVqL8icPu21FoIXGKiTA6VI0cAmugpQDXFVuk+HVYyYGtj9swmPyaR7ykXU
1+4KAyBXsmz4y/mQxKsSVZnlp+cq9Y6iR7IPcj06KMeTF61Zc6sJZ0aIDl6IzzOB
UErMtFTKuAMAFPmB2wZ2kMsuz5K48BZcDSeO6PT6fbsWtQvmRK+Fqjf8iLtpLnEj
2aG0hKeDTJkZKJOtaHoePx1MBrfRS1kCSAhjTCIxgSuIKLsRx9M+8KfqB+suYXUA
RbrSrOyvl16YfUmTaWdYS+PdKuLYEVHViqZecvc30jALJoQOcvoWO7Kwzh4Tl4H9
jeSA1+lpV0P25tm7x+PbpAVgbX0aBD4rs2TYU79MersBvL8trm3q6UcB0Bcud/XQ
rUTUa7xUgS8XO+EsU6WMKmRZ+Usl+yTqaXH4eTMMAAL1b2Kq9Lr3RZP/zuQpYfiG
aSfX8al6YJQRGRVwYORbeUjcOw5fioash8Xf1OEpj0fYLGbsqhRUZU6UbADjEcHo
YJID1xvBUmw149iCbOTwHb1rTfw2t8VThkfIxbSTd7t/urYNn5F5H1dhWocvs+oR
cd4GKZJjvQcT2/RH8taspQjWNL5asRQvwdb6ZUYQDa5G6o2N3pjIrP9Itue8Iaf6
B/xZ6MnFnAB821YiT1V0KbX7FB8bE6HE9z7jR1zpqBA3LbPxVtst2AxenVxbCSQT
scA5c4YoXXgxPbrCyX22lyAKwuYEaRa7KrPVjrJoyjDDK1uFD0JRqzokJcS/7dBY
F9xrz5H9yRoyVwy/pG9uEdoQkGth3DiOBkqUMYrvipqP0AKHRHcASdL/3fbgdB9Q
bmCwWVTyUVbmqztawJ8Xc9+QRk1wEbLvt3df9DZkUT8lqR9JUt4xLWpMvhOhsIVQ
iXFaeSoZTpa7B8NzTpJPfCrZtTYnZxzHewxg0gViHQPSv+LmvpR2Z3k6CkgRdqKE
1vM/+Ih2Ksc+Yyd5T40IObyaTmSigXnIkKv3vHQtaZaLmwiZRFJY8EmLASSz5/o/
LUNMH1CPPvj00W3rLzMHDnYu2ZhWETpQBGjNUWcQnzo6Vfg3SBXse3WbZu73Ix2f
O+kMHjMtB9Nf4URij4D3obLpSVZ1F95wyS63yTuS7nncSNnvbm891946F4/k/J79
4fsPVdOA3JSrR9nl10yKsxlfbeTh3saPP2GvDd7TWmC1AdCej64RyyNojJONvbi2
su4esVJicnUZM0/d4nqhiYacVxhDU4PnWcy9xISEwgKT0LTlC8VWO8qdRqa5RFlq
ewUoE1pCoxapKYOv+GC4DKHmGXp4xcpDnQvQFqcG7ntlZGPmfu4kyCguniCGF0yV
nbffVuNUQYNlBt9Y1X9YBZX+DAlx822qOXWDnqe9yhPlEcH7RxmXqdQlqDDZZDhs
QhJvqVuBSRxmEoi4K/vE04HPa79L39h40jX1NmGuBjwhst1+1fYfHHS16PqlbNZF
H1KuELxVkK4HKhyxr5xTGubLHjIC13tMe73bQadFod5cUiZj+fhRSTzHrAUru9Jk
HvUDPF3b9R2fcPRqD5Mtg2gjRDsgWvrODoLW+tCdNuBf3eg3JJYzlFkJU1wiMaml
XdQwiGD8m0hABnae7RFODogXpzfKkeFIRmV7vWQqkRc4LUBE0+diw61qaIJE+9d8
3NGdESlAleI9hMQVSuwzb5vEn5d4+qPoi1/LhlToho2WJo1By9KkAIUY4eSo8jih
CY+QgrLGZ6CRDLkkj7hVIDdThVcTxesPeDL4DStdee/d2g1PLzWMsQlp0/NDyDZx
azBbdEZub5/el9Buzgmrv/NgKP3GYLiexFcMe4B9p8Q7AqbtE7oPxOZD4a6EVVe0
3u6WKkNOzqDgLKUmt6EAYI9zxwKz/r8K4UKahoi9abrmGwvsrApICJfThC74aw== =QMaw -----END
PGP MESSAGE-----

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1
Comment: Charset: us-ascii

hQIMA4ToeuPbGFzLARAAg0zb38BESkbvvLbom+Lcf+NpIfxCZvsok8DRTEeEO3v5
sCsiK50E/IwxRpdO0IhqfOmMhJDmHAOD8emqgNMH6dppiV2ftuxraTU27+I8Kmdi
o8VUDb98XvH1DjsjcKLGWwM5+dKqtnh7adiJwsRRiEswuumtsh+eH5R9D7928kgV
ZZn6b615jGulXMeIf6BuSEfLXBiSE5hgYfizcakFzdW/gm+8URGUQYGBlwm/qQoV
f37TmSqrDiM1nVn7KF2NGdGG72NBtgkQ05GnNiYN+1L2wDnegwhHHnQzz56VJOSJ
FcDnIDms3JhV0FxjsWTeFwvvWBYahd7EEgzTO+xY3rntU9uiQS60HHh1l9RTNyVt
AlTmkH0BnEfzeWp/Yq5ynCQ3Sosy4LuZucmwvZeFeVtksArehSW8Gpe1p5RaP2Gy
12EMp9EaexKL73W4F0XQpgljNt0kKeqE16M7xE1dlxtcTU6ftwJj75L+eFbRYJYQ
09M75ui0PUAFidTljjx1t9ChPwjJzEZ/krm3YI193NbxXT2cL5zCwOV3XILKL8q1
FVbUDREQqaZi09sPst06Z3ODUVFMgCG3OpQcsyIQnYhMMhWxvAsg4UIh/vagkeFL
oHtVU+AWsO4RMqfrDUvNMUzUpe15mR61A8qGooEF56IehvCPh1obPQnGzS622f7S
jwGgCLs9PZAs/f7S0gKKQtExxuK1cvXbgR8L6KgkNFZxdXJyiLdCZ34VURqoQ+zu
nrdRbY+kVNx3+slu5Qlyi2RMNsrmE6Y9V2YNPcwXBHLDgGgvtyqsE7zUkWrGxZYQ
AztYQPdi6fU8K2muzJDS+f5j9F4YPcotARHv0H3KHO+ZJrxSX1R8G8eG1YbtFrLG
=aZhd
-----END PGP MESSAGE-----


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Favyen_Bastani (240 points)   2
0 votes

It would. I'd test though. Depending on the amount of RAM and the I/O of
the underlying host, we saw that some larger instances could take longer
to suspend/resume than shutdown/power up. You maintain the state of the
system, but may see longer "downtime" for the instance. Something to
think about.

Thanks!
Matt

On 5/13/15 6:19 PM, "Favyen Bastani" fbastani@perennate.com wrote:

Would a virsh suspend/save/restore/resume operation accomplish similar
result as the localhost migration?

Best,
Favyen

On 05/13/2015 12:44 PM, Matt Van Winkle wrote:

Yeah, something like that would be handy.

From: matt matt@nycresistor.com
Date: Wednesday, May 13, 2015 10:29 AM
To: "Daniel P. Berrange"
berrange@redhat.com
Cc: Matt Van Winkle
mvanwink@rackspace.com,
"openstack-operators@lists.openstack.org<mailto:openstack-operators@lists
.openstack.org>"
<openstack-operators@lists.openstack.org<mailto:openstack-operators@lists
.openstack.org>>
Subject: Re: [Openstack-operators] Venom vulnerability

honestly that seems like a very useful feature to ask for...
specifically for upgrading qemu.

-matt

On Wed, May 13, 2015 at 11:19 AM, Daniel P. Berrange
berrange@redhat.com wrote:
On Wed, May 13, 2015 at 03:08:47PM +0000, Matt Van Winkle wrote:

So far, your assessment is spot on from what we've seen. A migration
(if you have live migrate that's even better) should net the same
result
for QEMU. Some have floated the idea of live migrate within the same
host. I don't know if nova out of the box would support such a thing.

Localhost migration (aka migration within the same host) is not
something
that is supported by libvirt/KVM. Various files QEMU has on disk are
based
on the VM name/uuid and you can't have 2 QEMU processes on the host
having
the files at the same time, which precludes localhost migration working.

Regards,
Daniel

-----BEGIN PGP MESSAGE----- Version: GnuPG v1 Comment: Charset:
us-ascii
hQIMA4ToeuPbGFzLAQ//WKATa6VRGKJKq7zAcUTO0tS8Lgq5zuo1buc2pJtbPKXi
pFmHpgTsXxoU3LNhfWelAToCQdacVLUw5OiFsWyoVsjAcuRzMrN+l8WHYG4jZDGs
bXCUp4XwShex35/vmI15NTAKrmbgIJZRi80sewCZ8H13rei86TPKA5b1C9SFxiqq
KGmntJdiEyk+x2SOz5xvZVx/29XryUSBXo6YAVQmW4AZrrdVdkRxDKCX3tw90UZ+
RCibGl1nac4n2rrXZ+izKcq6d+CYo28yBaEJ5zecrU1K9M/rZwyVWnr5NTP0bs0B
EOBV+0YsaBJdfbdrntKGUZCKVta4QdX9mOIQ7GYM/DP3IxHywFKfcwjG0iRjHYQG
sNCK0ymhr+eNcBKWHjyVqvy/W5IIep+ES1Y7xhmwqPfWEraNQ+Scc9T6i7mWAaam
dn7fVaO3dOHEoKVGX6Z+TtQS+FjesrgtOtvEeonVAkQLNEBVnQcMaMOrz+Ia1AXf
+SwkcksDaqylXC1TqTLjyA7ceEHWqPL7d6EfIM7dBT/tg0h5WL2XgoJlFddSXDoR
99b2Arc9jaG+tJamvRO+M8Ky8uVuD5pF68wDwfvPqHbzSzzt3fmmkQkOVmtNLkjp
ZAGDxV/0+xhurdz4HFDz6q3ShpgREsgBEOd8uY7UCn67nRZbrS4YtdUIV25dhknS
6gGkwfhs5IR99F/IvQUXsUs1m5DCWZI0GkWEaTcTEJfNoYHLPH+vLdtzupNz7ihp
sNtie42q3urYLW5irAFeTW8jyjS4V5TPMMUXMvp5DG4eOGGCoKiZQhmT3JJB3PHe
5kghWgOlRQyK9trkH1zS8cgpXPhL+g/LGRfrp+xH7E7Hn1DLMizeQargFpcLmpdR
KHQQCHlBuB4gTQ0n/ai5zRVrioH+6GVMVedUxsYTMlrVWNGocYVZ/lzjHdDGVPiQ
JoxmMxVqL8icPu21FoIXGKiTA6VI0cAmugpQDXFVuk+HVYyYGtj9swmPyaR7ykXU
1+4KAyBXsmz4y/mQxKsSVZnlp+cq9Y6iR7IPcj06KMeTF61Zc6sJZ0aIDl6IzzOB
UErMtFTKuAMAFPmB2wZ2kMsuz5K48BZcDSeO6PT6fbsWtQvmRK+Fqjf8iLtpLnEj
2aG0hKeDTJkZKJOtaHoePx1MBrfRS1kCSAhjTCIxgSuIKLsRx9M+8KfqB+suYXUA
RbrSrOyvl16YfUmTaWdYS+PdKuLYEVHViqZecvc30jALJoQOcvoWO7Kwzh4Tl4H9
jeSA1+lpV0P25tm7x+PbpAVgbX0aBD4rs2TYU79MersBvL8trm3q6UcB0Bcud/XQ
rUTUa7xUgS8XO+EsU6WMKmRZ+Usl+yTqaXH4eTMMAAL1b2Kq9Lr3RZP/zuQpYfiG
aSfX8al6YJQRGRVwYORbeUjcOw5fioash8Xf1OEpj0fYLGbsqhRUZU6UbADjEcHo
YJID1xvBUmw149iCbOTwHb1rTfw2t8VThkfIxbSTd7t/urYNn5F5H1dhWocvs+oR
cd4GKZJjvQcT2/RH8taspQjWNL5asRQvwdb6ZUYQDa5G6o2N3pjIrP9Itue8Iaf6
B/xZ6MnFnAB821YiT1V0KbX7FB8bE6HE9z7jR1zpqBA3LbPxVtst2AxenVxbCSQT
scA5c4YoXXgxPbrCyX22lyAKwuYEaRa7KrPVjrJoyjDDK1uFD0JRqzokJcS/7dBY
F9xrz5H9yRoyVwy/pG9uEdoQkGth3DiOBkqUMYrvipqP0AKHRHcASdL/3fbgdB9Q
bmCwWVTyUVbmqztawJ8Xc9+QRk1wEbLvt3df9DZkUT8lqR9JUt4xLWpMvhOhsIVQ
iXFaeSoZTpa7B8NzTpJPfCrZtTYnZxzHewxg0gViHQPSv+LmvpR2Z3k6CkgRdqKE
1vM/+Ih2Ksc+Yyd5T40IObyaTmSigXnIkKv3vHQtaZaLmwiZRFJY8EmLASSz5/o/
LUNMH1CPPvj00W3rLzMHDnYu2ZhWETpQBGjNUWcQnzo6Vfg3SBXse3WbZu73Ix2f
O+kMHjMtB9Nf4URij4D3obLpSVZ1F95wyS63yTuS7nncSNnvbm891946F4/k/J79
4fsPVdOA3JSrR9nl10yKsxlfbeTh3saPP2GvDd7TWmC1AdCej64RyyNojJONvbi2
su4esVJicnUZM0/d4nqhiYacVxhDU4PnWcy9xISEwgKT0LTlC8VWO8qdRqa5RFlq
ewUoE1pCoxapKYOv+GC4DKHmGXp4xcpDnQvQFqcG7ntlZGPmfu4kyCguniCGF0yV
nbffVuNUQYNlBt9Y1X9YBZX+DAlx822qOXWDnqe9yhPlEcH7RxmXqdQlqDDZZDhs
QhJvqVuBSRxmEoi4K/vE04HPa79L39h40jX1NmGuBjwhst1+1fYfHHS16PqlbNZF
H1KuELxVkK4HKhyxr5xTGubLHjIC13tMe73bQadFod5cUiZj+fhRSTzHrAUru9Jk
HvUDPF3b9R2fcPRqD5Mtg2gjRDsgWvrODoLW+tCdNuBf3eg3JJYzlFkJU1wiMaml
XdQwiGD8m0hABnae7RFODogXpzfKkeFIRmV7vWQqkRc4LUBE0+diw61qaIJE+9d8
3NGdESlAleI9hMQVSuwzb5vEn5d4+qPoi1/LhlToho2WJo1By9KkAIUY4eSo8jih
CY+QgrLGZ6CRDLkkj7hVIDdThVcTxesPeDL4DStdee/d2g1PLzWMsQlp0/NDyDZx
azBbdEZub5/el9Buzgmrv/NgKP3GYLiexFcMe4B9p8Q7AqbtE7oPxOZD4a6EVVe0
3u6WKkNOzqDgLKUmt6EAYI9zxwKz/r8K4UKahoi9abrmGwvsrApICJfThC74aw== =QMaw
-----END
PGP MESSAGE-----

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1
Comment: Charset: us-ascii

hQIMA4ToeuPbGFzLARAAg0zb38BESkbvvLbom+Lcf+NpIfxCZvsok8DRTEeEO3v5
sCsiK50E/IwxRpdO0IhqfOmMhJDmHAOD8emqgNMH6dppiV2ftuxraTU27+I8Kmdi
o8VUDb98XvH1DjsjcKLGWwM5+dKqtnh7adiJwsRRiEswuumtsh+eH5R9D7928kgV
ZZn6b615jGulXMeIf6BuSEfLXBiSE5hgYfizcakFzdW/gm+8URGUQYGBlwm/qQoV
f37TmSqrDiM1nVn7KF2NGdGG72NBtgkQ05GnNiYN+1L2wDnegwhHHnQzz56VJOSJ
FcDnIDms3JhV0FxjsWTeFwvvWBYahd7EEgzTO+xY3rntU9uiQS60HHh1l9RTNyVt
AlTmkH0BnEfzeWp/Yq5ynCQ3Sosy4LuZucmwvZeFeVtksArehSW8Gpe1p5RaP2Gy
12EMp9EaexKL73W4F0XQpgljNt0kKeqE16M7xE1dlxtcTU6ftwJj75L+eFbRYJYQ
09M75ui0PUAFidTljjx1t9ChPwjJzEZ/krm3YI193NbxXT2cL5zCwOV3XILKL8q1
FVbUDREQqaZi09sPst06Z3ODUVFMgCG3OpQcsyIQnYhMMhWxvAsg4UIh/vagkeFL
oHtVU+AWsO4RMqfrDUvNMUzUpe15mR61A8qGooEF56IehvCPh1obPQnGzS622f7S
jwGgCLs9PZAs/f7S0gKKQtExxuK1cvXbgR8L6KgkNFZxdXJyiLdCZ34VURqoQ+zu
nrdRbY+kVNx3+slu5Qlyi2RMNsrmE6Y9V2YNPcwXBHLDgGgvtyqsE7zUkWrGxZYQ
AztYQPdi6fU8K2muzJDS+f5j9F4YPcotARHv0H3KHO+ZJrxSX1R8G8eG1YbtFrLG
=aZhd
-----END PGP MESSAGE-----


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded May 13, 2015 by Matt_Van_Winkle (2,260 points)   1 3
...