9:23 p.m.
Hi everybody,
We are trying to optimize our continuous integration system around our
ovirt-management software (i.e. we call into the ovirt apis to create VMs,
do funny stuff with the VMs, etc.). For our tests, we deployed a VM that
boots extremely quickly (2 seconds) in hoping to speed up our tests.
Unfortunately, ovirt is not updating the state of the VM to "Up" as fast as
we'd like. VDSM show the following in the logs:
Thread-420807::DEBUG::2012-06-06 22:14:47,662::clientIF::54::vds::(wrapper)
[10.225.52.7]::call *getVmStats *with
('e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',) {}
Thread-420807::DEBUG::2012-06-06
22:14:47,663::libvirtvm::222::vm.Vm::(_getDiskStats)
vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk stats not available
*Thread-420807::DEBUG::2012-06-06
22:14:47,663::libvirtvm::251::vm.Vm::(_getDiskLatency)
vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk latency not available
*Thread-420807::DEBUG::2012-06-06
22:14:47,663::clientIF::59::vds::(wrapper) return getVmStats with
{'status': {'message': 'Done', 'code': 0},
'statsList': [{'status': 'Up',
'username': 'Unknown', 'memUsage': '0',
'acpiEnable': 'tru
e', 'pid': '32299', 'displayIp': '0',
'displayPort': u'5900', 'session':
'Unknown', 'displaySecurePort': u'5901', 'cdrom':
'/rhev/data-center/c861891c-7011-4209-9871-73c4b4e42560/b1ad8b2c-d2e1-479b-be2e-90fcbe446e86/images/11111111
-1111-1111-1111-111111111111/CorePlus-current.iso', 'pauseCode':
'NOERR',
'clientIp': '', 'kvmEnable': 'true', 'network':
{u'vnet0': {'macAddr':
u'00:1a:4a:a8:7a:50', 'rxDropped': '0', 'rxErrors':
'0', 'txDropped': '0',
'txRate': '
0.0', 'rxRate': '0.0', 'txErrors': '0',
'state': 'unknown', 'speed':
'1000', 'name': u'vnet0'}}, 'vmId':
'e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',
'monitorResponse': '0', 'cpuUser': '0.00',
'disks': {u'vda':
{'readLatency': '0', 'app
arentsize': '1073741824', 'writeLatency': '0',
'imageID':
'38ffdd23-e16d-4cde-a384-3290450fe87f', 'flushLatency': '0',
'truesize':
'1073741824'}}, 'boot': 'c', 'statsAge': '1.81',
'cpuIdle': '100.00',
'elapsedTime': '61', 'vmType':
'kvm', 'cpuSys': '0.00', 'timeOffset': '0',
'appsList': [], 'guestIPs':
'', 'displayType': 'qxl', 'nice': ''}]}
This repeats for about a minute until the VM is finally marked "Up". Is
there any trick we can do to get ovirt to mark the VM "Up" quicker? Perhaps
generate some sort of activity on the VM?
Thanks,
Andrey
4:26 a.m.
This is a multi-part message in MIME format.
--------------080409000805020206030308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 06/07/2012 05:23 AM, Andrey F. wrote:
Hi everybody,
We are trying to optimize our continuous integration system around our
ovirt-management software (i.e. we call into the ovirt apis to create
VMs, do funny stuff with the VMs, etc.). For our tests, we deployed a
VM that boots extremely quickly (2 seconds) in hoping to speed up our
tests. Unfortunately, ovirt is not updating the state of the VM to
"Up" as fast as we'd like. VDSM show the following in the logs:
Thread-420807::DEBUG::2012-06-06
22:14:47,662::clientIF::54::vds::(wrapper) [10.225.52.7]::call
*getVmStats *with ('e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',) {}
Thread-420807::DEBUG::2012-06-06
22:14:47,663::libvirtvm::222::vm.Vm::(_getDiskStats)
vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk stats not available
*Thread-420807::DEBUG::2012-06-06
22:14:47,663::libvirtvm::251::vm.Vm::(_getDiskLatency)
vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk latency not available
*Thread-420807::DEBUG::2012-06-06
22:14:47,663::clientIF::59::vds::(wrapper) return getVmStats with
{'status': {'message': 'Done', 'code': 0},
'statsList': [{'status':
'Up', 'username': 'Unknown', 'memUsage': '0',
'acpiEnable': 'tru
e', 'pid': '32299', 'displayIp': '0',
'displayPort': u'5900',
'session': 'Unknown', 'displaySecurePort': u'5901',
'cdrom':
'/rhev/data-center/c861891c-7011-4209-9871-73c4b4e42560/b1ad8b2c-d2e1-479b-be2e-90fcbe446e86/images/11111111
-1111-1111-1111-111111111111/CorePlus-current.iso', 'pauseCode':
'NOERR', 'clientIp': '', 'kvmEnable': 'true',
'network': {u'vnet0':
{'macAddr': u'00:1a:4a:a8:7a:50', 'rxDropped': '0',
'rxErrors': '0',
'txDropped': '0', 'txRate': '
0.0', 'rxRate': '0.0', 'txErrors': '0',
'state': 'unknown', 'speed':
'1000', 'name': u'vnet0'}}, 'vmId':
'e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb', 'monitorResponse': '0',
'cpuUser': '0.00', 'disks': {u'vda':
{'readLatency': '0', 'app
arentsize': '1073741824', 'writeLatency': '0',
'imageID':
'38ffdd23-e16d-4cde-a384-3290450fe87f', 'flushLatency': '0',
'truesize': '1073741824'}}, 'boot': 'c',
'statsAge': '1.81',
'cpuIdle': '100.00', 'elapsedTime': '61',
'vmType':
'kvm', 'cpuSys': '0.00', 'timeOffset': '0',
'appsList': [],
'guestIPs': '', 'displayType': 'qxl', 'nice':
''}]}
This repeats for about a minute until the VM is finally marked "Up".
Is there any trick we can do to get ovirt to mark the VM "Up" quicker?
Perhaps generate some sort of activity on the VM?
Thanks,
Andrey
Do you have the guest agent installed on the guest?
Y.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--------------080409000805020206030308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 06/07/2012 05:23 AM, Andrey F. wrote:
<blockquote
cite="mid:CAD7sfFwi3eeT3mqsNjCttjU8AXLKb-1zqVAsV=S-HN6WPnLd1w@mail.gmail.com"
type="cite">Hi everybody,<br>
<br>
We are trying to optimize our continuous integration system around
our ovirt-management software (i.e. we call into the ovirt apis to
create VMs, do funny stuff with the VMs, etc.). For our tests, we
deployed a VM that boots extremely quickly (2 seconds) in hoping
to speed up our tests. Unfortunately, ovirt is not updating the
state of the VM to "Up" as fast as we'd like. VDSM show the
following in the logs:<br>
<br>
<span style="font-size:11pt;font-family:"Lucida
Grande"">Thread-420807::DEBUG::2012-06-06
22:14:47,662::clientIF::54::vds::(wrapper)
[10.225.52.7]::call <b>getVmStats </b>with
('e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',) {}<br>
Thread-420807::DEBUG::2012-06-06
22:14:47,663::libvirtvm::222::vm.Vm::(_getDiskStats)
vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::<b>Disk stats not
available<br>
</b>Thread-420807::DEBUG::2012-06-06
22:14:47,663::libvirtvm::251::vm.Vm::(_getDiskLatency)
vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::<b>Disk latency not
available<br>
</b></span><span style="font-size: 11pt; font-family:
"Lucida Grande";">Thread-420807::DEBUG::2012-06-06
22:14:47,663::clientIF::59::vds::(wrapper) return getVmStats
with {'status':
{'message': 'Done', 'code': 0}, 'statsList':
[{'status': 'Up',
'username':
'Unknown', 'memUsage': '0', 'acpiEnable':
'tru<br>
e', 'pid': '32299', 'displayIp': '0',
'displayPort': u'5900',
'session': 'Unknown',
'displaySecurePort': u'5901', 'cdrom':
'/rhev/data-center/c861891c-7011-4209-9871-73c4b4e42560/b1ad8b2c-d2e1-479b-be2e-90fcbe446e86/images/11111111<br>
-1111-1111-1111-111111111111/CorePlus-current.iso', 'pauseCode':
'NOERR',
'clientIp': '', 'kvmEnable': 'true',
'network': {u'vnet0':
{'macAddr':
u'00:1a:4a:a8:7a:50', 'rxDropped': '0',
'rxErrors': '0',
'txDropped': '0',
'txRate': '<br>
0.0', 'rxRate': '0.0', 'txErrors': '0',
'state': 'unknown',
'speed': '1000',
'name': u'vnet0'}}, 'vmId':
'e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',
'monitorResponse': '0', 'cpuUser': '0.00',
'disks': {u'vda':
{'readLatency':
'0', 'app<br>
arentsize': '1073741824', 'writeLatency': '0',
'imageID':
'38ffdd23-e16d-4cde-a384-3290450fe87f', 'flushLatency':
'0',
'truesize':
'1073741824'}}, 'boot': 'c', 'statsAge':
'1.81', 'cpuIdle':
'100.00',
'elapsedTime': '61', 'vmType':<br>
'kvm', 'cpuSys': '0.00', 'timeOffset':
'0', 'appsList': [],
'guestIPs':
'', 'displayType': 'qxl', 'nice':
''}]}<br>
<br>
This repeats for about a minute until the VM is finally marked
"Up". Is there any trick we can do to get ovirt to mark the VM
"Up" quicker? Perhaps generate some sort of activity on the
VM?<br>
<br>
Thanks,<br>
Andrey<br>
</span></blockquote>
<br>
Do you have the guest agent installed on the guest?<br>
Y.<br>
<br>
<blockquote
cite="mid:CAD7sfFwi3eeT3mqsNjCttjU8AXLKb-1zqVAsV=S-HN6WPnLd1w@mail.gmail.com"
type="cite"><span
style="font-size:11.0pt;font-family:"Lucida
Grande""><br>
<br>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Users@ovirt.org">Users@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/users">http://...
</pre>
</blockquote>
<br>
</body>
</html>
--------------080409000805020206030308--
2:55 a.m.
On Thu, Jun 07, 2012 at 12:26:30PM +0300, Yaniv Kaul wrote:
On 06/07/2012 05:23 AM, Andrey F. wrote:
>Hi everybody,
>
>We are trying to optimize our continuous integration system around
>our ovirt-management software (i.e. we call into the ovirt apis to
>create VMs, do funny stuff with the VMs, etc.). For our tests, we
>deployed a VM that boots extremely quickly (2 seconds) in hoping
>to speed up our tests. Unfortunately, ovirt is not updating the
>state of the VM to "Up" as fast as we'd like. VDSM show the
>following in the logs:
>
>Thread-420807::DEBUG::2012-06-06
>22:14:47,662::clientIF::54::vds::(wrapper) [10.225.52.7]::call
>*getVmStats *with ('e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',) {}
>Thread-420807::DEBUG::2012-06-06
>22:14:47,663::libvirtvm::222::vm.Vm::(_getDiskStats)
>vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk stats not
>available
>*Thread-420807::DEBUG::2012-06-06
>22:14:47,663::libvirtvm::251::vm.Vm::(_getDiskLatency)
>vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk latency not
>available
>*Thread-420807::DEBUG::2012-06-06
>22:14:47,663::clientIF::59::vds::(wrapper) return getVmStats with
>{'status': {'message': 'Done', 'code': 0},
'statsList':
>[{'status': 'Up', 'username': 'Unknown',
'memUsage': '0',
As you can see, Vdsm reports 'Up' by now. It should have reported
'Powering up' for 60 seconds (unless an internal guest agent reports
that it is up before that).
While the Vm is not reported as 'Up' what is its reproted state?
Do you have the guest agent installed on the guest?
Y.
4:59 a.m.
On Sun, Jun 10, 2012 at 12:55 AM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Thu, Jun 07, 2012 at 12:26:30PM +0300, Yaniv Kaul wrote:
> On 06/07/2012 05:23 AM, Andrey F. wrote:
> >Hi everybody,
> >
> >We are trying to optimize our continuous integration system around
> >our ovirt-management software (i.e. we call into the ovirt apis to
> >create VMs, do funny stuff with the VMs, etc.). For our tests, we
> >deployed a VM that boots extremely quickly (2 seconds) in hoping
> >to speed up our tests. Unfortunately, ovirt is not updating the
> >state of the VM to "Up" as fast as we'd like. VDSM show the
> >following in the logs:
> >
> >Thread-420807::DEBUG::2012-06-06
> >22:14:47,662::clientIF::54::vds::(wrapper) [10.225.52.7]::call
> >*getVmStats *with ('e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb',) {}
> >Thread-420807::DEBUG::2012-06-06
> >22:14:47,663::libvirtvm::222::vm.Vm::(_getDiskStats)
> >vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk stats not
> >available
> >*Thread-420807::DEBUG::2012-06-06
> >22:14:47,663::libvirtvm::251::vm.Vm::(_getDiskLatency)
> >vmId=`e3b250c9-a5ca-42da-bd8f-245a3ef4bbfb`::*Disk latency not
> >available
> >*Thread-420807::DEBUG::2012-06-06
> >22:14:47,663::clientIF::59::vds::(wrapper) return getVmStats with
> >{'status': {'message': 'Done', 'code': 0},
'statsList':
> >[{'status': 'Up', 'username': 'Unknown',
'memUsage': '0',
As you can see, Vdsm reports 'Up' by now. It should have reported
'Powering up' for 60 seconds (unless an internal guest agent reports
that it is up before that).
While the Vm is not reported as 'Up' what is its reproted state?
>
> Do you have the guest agent installed on the guest?
> Y.
>
Sorry for a slow response guys. The state is "Powering up" as Dan has
described. It is taking me a while to install the guest agent on the
VM because it is Tiny Core Linux. Thanks for the tip. I'll post back
if it the agent doesn't work.
4360
days inactive
4363
days old
3 comments
3 participants
participants (3)
-
Andrey F. -
Dan Kenigsberg -
Yaniv Kaul